Karios Integrated Network

Overview

Karios leverages FreeBSD’s networking performance and stability, while removing the operational barriers that make network management complex. It provides a web-managed, centralized, and validated networking stack that works across single-node or multi-node FreeBSD deployments.

Challenges Without Karios

Organizations often face hurdles with networking:

Challenge	Impact
Multi-Node Coordination and Visibility	Configurations drift between nodes, creating inconsistent connectivity.
Expertise Barrier	Teams require deep networking knowledge to build even basic topologies.

How Karios Transforms Networking

Karios addresses these problems while preserving FreeBSD’s strengths:

Feature	Benefit
Intuitive Web Management	Point-and-click operations; no command syntax required.
Centralized Multi-Node Control	Define virtual switches, VLANs, and VM connectivity once, and apply everywhere.
Built-in Validation	Prevents common misconfigurations before they impact production.
Operational Simplification	Teams focus on outcomes, not implementation details.
Real-Time Monitoring	Dashboards provide instant visibility into connectivity and performance.

What Makes Karios Essential

• A comprehensive network management platform that simplifies FreeBSD networking without losing its performance advantages.

• Unified control over virtual switches, VLANs, VALE switches, VXLANs, and tunnels.

• Automated configuration validation and warnings to reduce risk.

• Full lifecycle management: design, deploy, monitor, and troubleshoot—all from one place.

Core Network Components

Physical Interfaces

Overview

Physical interfaces (NICs) form the foundation of all networking in Karios. They are discovered automatically and presented in the Physical Interfaces tab under the Network menu. From here, administrators can monitor live status and review interface properties before layering VLANs or virtual interfaces on top.

Tip

• At least two NICs are recommended.

• One NIC can serve management traffic, while the other can host VLANs for storage or tenant workloads.

• A third NIC, while optional, provides redundancy—ensuring uninterrupted connectivity during maintenance or link failures.

Monitoring Capabilities

The Physical Interfaces panel displays key real-time information for each NIC:

Property	What You See
Status	Active/Inactive state, link availability, and whether editable.
Speed & Duplex	Current negotiated speed (e.g., 1000 Mbps) and duplex mode.
MAC Address	Hardware identifier, useful for mapping cables to ports.
IP Configuration	IPv4/IPv6 assignments with CIDR notation.
MTU	Configured Maximum Transmission Unit for the interface.
Packets/Traffic	Counters for received and transmitted packets (via View Details).

Figure: Landing page for physical NICs

Figure: Detailed statistics with packet counters and throughput

Notes

• Live Tracking: Data updates continuously, reflecting the current NIC state.

• View Details: Available only for active interfaces; provides per-port statistics.

Virtual Switches

Overview

A virtual switch is a software-based Layer 2 device that enables VMs to communicate with external networks. They act much like a physical Ethernet switch—forwarding traffic based on MAC addresses—but are implemented entirely in software. In modern virtualization platforms, virtual switches provide flexible connectivity without requiring extra hardware, and they can enforce segmentation, isolation, and monitoring policies at the network edge.

Karios builds on this concept by offering a UI-driven management layer, removing the need for manual command-line work. Administrators can create, attach, and monitor switches directly from the Control Center, making VM networking both accessible and consistent across nodes.

Key Uses

• Provide VM-to-VM communication within an isolated network segment.

• Attach a switch to a plain NIC to extend VM traffic out to the physical network.

• Integrate with VLAN-backed interfaces for segmented multi-tenant networking.

• Track status and usage centrally across nodes, with real-time monitoring built in.

Tip

• Use a plain NIC for switch attachment.

• Avoid running both a VLAN and a switch on the same parent NIC, as this can cause conflicts.

• Two NICs are generally sufficient; a third NIC is recommended for redundancy and maintenance flexibility.

Switch Management in Karios

The Network → Switches view in Karios provides a clear overview of all configured virtual switches and their associations:

Display Item	What It Shows
Switch Inventory	A complete list of all created virtual switches across the node or cluster.
Interface Association	Specifies which physical NIC (or VLAN interface) each switch is attached to.
Status Monitoring	Real-time operational status, active/inactive state, and traffic counters.
Configuration Access	Direct entry points for editing, reassigning, or deleting switches.

Figure: Switch component view in Karios

Switch Lifecycle

Karios abstracts common operations into a straightforward workflow:

1. Create – Open the creation form, name the switch, and assign a parent interface.

2. Review – Confirm parameters before deployment; validation catches conflicts like duplicate names or unavailable NICs.

3. Delete – Switches can be modified or removed, with warnings shown if connected VMs may be impacted.

Figure: Switch dashboard in Karios

User Journey

Figure: Switch journey in Karios

Considerations

• Configuration Planning: Define your network architecture before creating switches, as changes may affect running VMs.

• Impact Awareness: Deleting a switch immediately disconnects attached VMs, please review warnings before taking a action.

• Persistence: Switch configurations are saved and restored automatically after reboot.

• Scalability: Excessive switches may increase resource usage (e.g., forwarding tables, CPU load).

Best Practices

• Use descriptive names for switches to simplify troubleshooting and VM assignment.

• Keep VLANs and switches separate on physical NICs to avoid conflicts.

• Regularly review switch statistics in the dashboard to identify performance issues early.

• Document switch purposes and parent interface choices as your topology grows.

VALE High-Speed Network Switch

Overview

VALE is a high-performance software switch. It delivers packet forwarding speeds far beyond traditional virtual switches—reaching tens of millions of packets per second per CPU core and near line-rate performance with standard Ethernet frames. General benchmarks show that while regular software switches may handle 1–2 million packets per second, VALE can reach tens of millions of packets per second per core and approach 70 Gbps line rates with standard frames. This makes it especially valuable for where performance is critical. Karios integrates VALE for scenarios where ultra-fast intra-host networking is required, such as VM-to-VM communication, NFV workloads, or research environments. To protect operational stability, Karios enforces design rules that prevent common pitfalls with VALE usage.

Key Caveats

VALE behaves differently than standard switches, and these differences are critical:

Warning

• NIC IP Loss – If VALE is connected directly to a physical NIC, that NIC loses its IP address completely and can no longer be used for management or external access. This is inherent to VALE’s design.

• VLAN-Only Requirement – In Karios, VALE can only be attached to a VLAN sub-interface, not to a raw NIC.

• Eligibility Rule – The VLAN must not already be connected to another virtual switch or VM.

• Network Separation – By attaching VALE only to VLANs, Karios ensures that high-speed VALE networks remain isolated from regular management and tenant traffic.

Figure: Example VALE topology with VLAN parent and TAP interfaces

Management in Karios

The Karios UI simplifies VALE operations, providing:

• Add/remove parent VLANs

• Attach/detach VM TAP interfaces

• Monitor total TAPs, active VALE switches, and live traffic counters

• Destroy unused VALE switches safely

Figure: VALE landing page in Karios

Connectivity Models

Karios supports several network arrangements to track and manage VALE usage:

Model	Description
Fully Connected	VALE switch attached to a VLAN parent and VM TAP interfaces, giving VMs external access through the VLAN.
Isolated	VALE switch with only TAP interfaces attached; used for secure, high-speed VM-to-VM communication.
Unused	VALE configured on a VLAN parent but with no VM connections; consumes resources but not forwarding traffic.

Best Practices

• Keep Management Separate – Always reserve at least one NIC for host management; do not attach it to VALE.

• Use VLANs as Parents – VLANs dedicated to VALE should not also carry regular switches or VM traffic.

• One Parent VLAN Recommended – Use a single VLAN as the parent for all VALE switches to minimize risk.

• Plan for Separation – Treat VALE networks as a “high-speed lane” and keep them isolated from your standard production paths.

Recovery if Misconfigured

If a NIC carrying SSH or management is accidentally attached to VALE and loses its IP:

• Use out-of-band management (BMC/IPMI) to access the node.

• Remove the VALE parent assignment.

• Restart network services to restore connectivity.

Use Cases

• Ultra-fast VM-to-VM networking (intra-host).

• High-performance NFV and packet processing workloads.

• Network simulation or research environments where isolation is required.

• Appliance development (firewalls, routers) using netmap-enabled applications.

Virtual Local Area Networks (VLANs)

Overview

In Karios, VLANs are one of the core building blocks for network segmentation. They allow you to create multiple logical networks over the same physical interface, without touching CLI.

VLANs are created, monitored and managed through Control Center. Each VLAN is tied to a parent NIC, given a tag ID, and optionally configured with an IP (static or DHCP). From there, VLANs integrate seamlessly with switches, VALE networks, and overlays.

What VLANs Are in Karios

• Logical Interfaces – Each VLAN you create in Karios appears as its own network interface, built on top of a physical NIC.

• Segmentation Tool – VLANs separate traffic for different roles: management, storage, tenant workloads, or underlay for VALE/VXLAN.

• Always Monitored – Every VLAN in Karios is actively tracked: gateway reachability, external connectivity, packet counters, and error rates.

• Persistent – Once created, VLANs are written into system configuration and restored after reboot.

Figure: VLAN component overview in Karios

VLAN Dashboard in Karios

The Network → Interfaces → Virtual tab provides a central place for VLAN lifecycle management:

Feature	In Karios
Landing Page	Shows VLAN count, tag IDs, status, IP configuration, and parent NICs.
Add VLAN	Guided form: choose Tag ID, parent NIC, and IP assignment.
VLAN Details	View MAC, MTU, routing table entries, and attached switches.
Monitoring	Live statistics, packet counters, and ping tests to gateway/external hosts.
Actions	View, Stats, Ping, and Delete, all directly from the dashboard.

Figure: VLAN management overview panel

• View Details – Opens a detailed panel with MAC address, MTU, routing entries, and attached switches.

Figure: VLAN sequence overview in Karios

Connectivity & Status Tracking

Unlike raw FreeBSD VLANs, Karios doesn’t just stop at creating tagged interfaces:

• Gateway Verification – Automated pings confirm if the VLAN can reach its configured gateway.

• External Reachability – If gateway checks fail, Karios tests well-known IPs (e.g., 8.8.8.8).

• Status Classes – VLANs are labeled Active or No Connectivity, giving at-a-glance health.

• Traffic Monitoring – Per-VLAN stats for packets sent/received and error counts.

Best Practices in Karios

Tip

• Use descriptive Tag IDs (e.g., VLAN 110 for Storage, 120 for Tenants).

• Avoid attaching management traffic VLANs to VALE or experimental overlays.

• Plan L2 switch trunking before creating VLANs in Karios to prevent mismatched configs.

• Parent NICs must be active and VLAN-aware in the physical network.

• VLAN tag IDs must be unique; Karios enforces this but good planning avoids collisions.

• Deleting a VLAN will isolate any switches or VMs attached — Karios warns you, but downtime cannot be avoided.

How VLANs Fit Into the Bigger Picture

• Switch Attachment – VLANs are common parents for virtual switches, enabling VMs to join the segmented network.

• VALE Eligibility – Only unused VLANs (not already tied to switches/VMs) may serve as VALE parents.

• VXLAN Underlay – Active VLANs often act as the underlay fabric for VXLAN overlays.

• Segmentation by Design – VLANs allow you to separate management, storage, and tenant workloads cleanly in Karios.

Virtual Extensible LAN (VXLAN) Overlay Networks

Overview

VXLAN is a network virtualization technology that extends Layer 2 segments across Layer 3 boundaries using encapsulation. It addresses the limitations of VLANs, providing a 24-bit VXLAN Network Identifier (VNI) space with support for up to 16 million segments. Karios integrates VXLAN within its networking stack, enabling scalable overlay connectivity between nodes while enforcing validation and configuration consistency.

Protocol and Standards

VXLAN is defined in RFC 7348 and operates by encapsulating Ethernet frames within UDP packets. Key aspects include:

• Encapsulation – VXLAN encapsulates Ethernet frames in UDP packets (port 4789), allowing Layer 2 networks to traverse Layer 3 infrastructure.

• VNI Space – 24-bit VNIs provide 16,777,216 possible segments, far exceeding the 4094 limit of VLANs.

• Transport Requirements – The underlay network must support appropriate MTU sizes to accommodate VXLAN overhead without fragmentation.

Karios VXLAN Implementation

Karios abstracts VXLAN creation and lifecycle management into a controlled workflow:

• VLAN Dependency – Only active, reachable VLANs can serve as VXLAN tunnel endpoints (VTEPs).

• Node Validation – Both participating nodes must be online, with IP reachability confirmed before tunnel instantiation.

• Static IP Requirement – VXLAN endpoints require static addressing; DHCP is not supported for overlay interfaces.

• VNI Allocation – Karios allocates VNIs from a defined range, ensuring uniqueness and preventing conflicts.

• Configuration Persistence – All VXLAN definitions are persisted into system configuration for restoration on reboot.

Tunnel Lifecycle

VXLAN tunnels in Karios are established and managed with the following phases:

1. Pre-Deployment Validation

   • Verify node availability and inter-VLAN connectivity.

   • Detect existing tunnels between node pairs to prevent duplicates.

   • Reserve a VNI and overlay subnet.

2. Tunnel Configuration

   • Create VXLAN interfaces on each node with identical VNI assignment.

   • Assign static tunnel IP addresses within a common subnet.

   • Bind the VXLAN interface to the selected VLAN parent.

Figure: Example VXLAN creation flow.

Configuration Model

Each VXLAN tunnel in Karios consists of two endpoints, each defined by: * Node – The Karios node hosting the VXLAN interface. * VLAN Parent – The active VLAN interface that serves as the underlay for the VXLAN tunnel. * VNI – The unique VXLAN Network Identifier assigned to the tunnel.

A VXLAN tunnel connects two VLAN interfaces across distinct nodes:

Figure: Example VXLAN configuration between two nodes with VLAN endpoints and static tunnel IPs.

Operational Considerations

• MTU Planning – The underlay must support larger MTUs (typically +50 bytes) to accommodate encapsulated traffic.

• Firewall Requirements – UDP/4789 must be permitted between VXLAN endpoints.

• Immutability of Core Parameters – VNIs, node pairings, and VLAN parents cannot be modified after creation; re-deployment is required.

• Monitoring Integration – Tunnel health, packet counters, and endpoint reachability are continuously tracked in Karios.

Integration with Karios Networking

• Virtual Switch Attachment – VXLAN interfaces are automatically integrated into the virtual switch framework, providing a bridge for VM attachment.

• Isolation by Design – Each VNI provides full isolation from other overlays, ensuring strict traffic segmentation in multi-tenant environments.

• Scalability – VXLAN overlays allow Karios clusters to span across racks, data centers, or distributed sites without the limitations of VLANs.

Best Practices

• Allocate VNIs systematically (e.g., project-based ranges) to simplify management at scale.

• Use dedicated VLANs as VXLAN underlays to separate overlay traffic from management or storage paths.

• Validate gateway and inter-VLAN reachability prior to tunnel creation to avoid incomplete deployments.

• Document tunnel endpoints and IP plans, as overlays introduce additional address spaces that must be tracked.

Troubleshooting and Best Practices

Performance Optimization Guidelines

CPU and Memory Tuning:

• Configure CPU affinity for network-intensive workloads, especially VALE switches

• Allocate dedicated CPU cores for high-performance packet processing

• Optimize buffer sizes based on traffic patterns and latency requirements

• Configure NUMA-aware memory allocation for multi-socket systems

Network Interface Optimization:

• Enable appropriate hardware offloading features (TSO, LRO, checksum offloading)

• Configure multi-queue settings to match CPU core availability

• Tune interrupt coalescing parameters for latency vs. throughput optimization

• Monitor hardware queue depths and adjust as needed for traffic patterns

Switch Configuration Best Practices:

• Limit virtual switches to recommended maximums (100 per node)

• Use VALE switches for high-performance requirements

• Configure proper VLAN trunk settings to avoid unnecessary broadcast traffic

• Implement appropriate spanning tree configuration in multi-switch topologies

Common Issues and Resolution Strategies

Connectivity Problems:

1. Physical Layer Issues: Verify cable integrity, link status, and port configuration

2. VLAN Configuration: Validate tag settings, trunk configuration, and switch compatibility

3. IP Address Conflicts: Check DHCP scope configuration and static IP assignments

4. Routing Issues: Verify default gateway settings and inter-VLAN routing configuration

Performance Degradation:

1. CPU Utilization: Monitor network interrupt handling and consider CPU affinity tuning

2. Buffer Sizes: Optimize network buffer allocation for specific traffic patterns

3. Switch Table Limits: Monitor MAC address table utilization and aging parameters

Configuration Conflicts:

1. VLAN ID Conflicts: Use configuration validation tools to prevent overlapping assignments

2. Interface Naming: Follow systematic naming conventions to avoid confusion

3. Resource Limits: Monitor system resources and adjust limits as needed

4. Dependencies: Understand component dependencies before making configuration changes

Management Access Issues:

1. SSH Connectivity Loss: Always ensure backup management access before major changes

2. BMC/IPMI Access: Verify out-of-band management capabilities before NIC reassignment

3. Network Recovery: Understand rollback procedures for critical network changes

4. Service Recovery: Know how to restart network services without full system reboot

Security Best Practices

Network Segmentation:

• Implement proper VLAN segmentation for security boundaries

• Use isolated networks for sensitive workloads and testing environments

• Configure appropriate firewall rules for each network segment

Conclusion

Karios solves the fundamental problem that prevents organizations from leveraging FreeBSD’s superior networking capabilities: operational complexity. By transforming FreeBSD VM networking from a specialist skill into mainstream operations capability, Karios enables organizations to deploy high-performance virtualization infrastructure without the traditional learning curve and operational overhead.

The Karios Advantage:

Karios enables practical FreeBSD virtualization by solving real operational challenges:

• Accessibility: Makes FreeBSD VM networking manageable for any operations team, regardless of FreeBSD expertise level

• Operational Speed: Reduces VM networking deployment time from hours of manual work to minutes of guided configuration

• Error Prevention: Eliminates configuration mistakes through built-in validation and automated best-practice enforcement

• Centralized Control: Provides unified management across multiple Karios nodes, eliminating coordination overhead

• Performance Preservation: Maintains all FreeBSD networking advantages while improving operational experience