7b:T4f0,In traditional networking, every server connects to a physical switch through physical cables. Network configuration means walking into a datacenter, plugging cables into ports, and configuring hardware switches through command-line interfaces. For decades, this model served enterprise IT well—but it fundamentally cannot scale to meet the demands of modern cloud computing and virtualization. **The virtualization revolution** transformed how we think about compute resources. A single physical server now hosts dozens or hundreds of virtual machines, each requiring its own network connectivity. Yet we cannot run dozens of physical cables from each server, and physical switches cannot efficiently manage hundreds of thousands of virtual endpoints that appear, disappear, and migrate in milliseconds. This is where **virtual switches** enter the picture—software constructs that replicate the functionality of physical switches entirely within the hypervisor layer, enabling the same level of network abstraction for virtual machines that physical switches provide for physical servers. Virtual switches are not merely a convenience feature; they are the **foundational building block** upon which all network virtualization technologies are constructed.7c:T7be,A virtual switch is fundamentally a **software-based Layer 2 switch** running within the hypervisor kernel. It implements the same forwarding logic as a physical switch: learning MAC addresses, building forwarding tables, and switching frames between ports. However, its architecture is fundamentally different because it operates entirely in software and integrates deeply with the virtualization layer. ### Core Architectural Components Every virtual switch consists of these essential components: **1. Virtual Ports (vPorts)** Virtual ports are logical connection points where virtual NICs attach. Unlike physical ports that are fixed hardware interfaces, virtual ports are data structures created on-demand. Each virtual port maintains: - Port state (up/down, link speed, duplex settings) - MAC address learning table entries - Traffic statistics (bytes/packets in/out) - QoS policies and rate limiting configurations - VLAN membership and tagging rules **2. Forwarding Engine** The forwarding engine is the decision-making core that determines how frames are switched. It maintains a MAC-to-port mapping table and implements forwarding logic: - Unicast: Forward to specific learned port - Broadcast/Unknown unicast: Flood to all ports in the VLAN - Multicast: Forward to registered recipient ports **3. Uplink Ports** Uplink ports connect the virtual switch to physical network interfaces, bridging the virtual and physical domains. When a VM needs to communicate with the external network, frames traverse the uplink port to reach physical networking infrastructure. **4. Internal Ports** Internal ports connect to the host operating system's network stack, enabling the hypervisor itself to communicate on virtual networks. **5. Management Plane** The management plane provides configuration interfaces—CLIs, APIs, or GUI tools—that allow administrators and orchestration systems to create/destroy ports, configure VLANs, set QoS policies, and monitor performance.7d:T6ab,Understanding how packets flow through a virtual switch is critical for both operational troubleshooting and performance optimization. The data path differs significantly from physical switches due to software implementation constraints. ### The Transmission Path (VM to Network) When a virtual machine transmits a frame, the following sequence occurs: **Step 1: Virtual NIC Transmission** The VM's network stack builds an Ethernet frame and writes it to a ring buffer shared with the hypervisor. The vNIC driver signals the hypervisor (typically via a hypercall or trap) that data is available. **Step 2: Virtual Switch Ingress Processing** The virtual switch receives the frame on the corresponding virtual port. Ingress processing includes: - MAC address learning (update forwarding table with source MAC → port mapping) - VLAN tag verification/manipulation - Security policy checks (MAC spoofing protection, ACLs) - QoS classification and marking - Statistics collection **Step 3: Forwarding Decision** The forwarding engine examines the destination MAC address: - If the destination MAC is in the forwarding table → forward to corresponding port - If destination is unknown → flood to all ports in the VLAN (except ingress) - If destination is broadcast/multicast → handle according to multicast/broadcast policy **Step 4: Egress Processing** Before transmission on the output port, egress processing applies: - Output QoS shaping/policing - VLAN tag manipulation (push/pop based on port configuration) - Output ACL filtering - Statistics update **Step 5: Physical Transmission (if uplink)** If the destination port is an uplink, the frame is queued for DMA to the physical NIC hardware.7e:T916,// Simplified Virtual Switch Frame Processing Pseudocode function process_ingress_frame(frame, ingress_port): // MAC Learning fdb_table[frame.src_mac] = ingress_port fdb_table[frame.src_mac].timestamp = now() // Security Check if security_policy.anti_spoof_enabled: if ingress_port.allowed_macs not contains frame.src_mac: drop(frame, "MAC spoofing detected") return // VLAN Processing if frame.has_vlan_tag: if ingress_port.mode == TRUNK: if frame.vlan_id not in ingress_port.allowed_vlans: drop(frame, "VLAN not permitted") return else: // ACCESS mode drop(frame, "Tagged frame on access port") return else: if ingress_port.mode == ACCESS: frame.vlan_id = ingress_port.native_vlan // QoS Classification frame.priority = classify_priority(frame, ingress_port.qos_policy) // Statistics ingress_port.stats.rx_bytes += frame.size ingress_port.stats.rx_packets += 1 // Forward to egress processing egress_ports = lookup_destination(frame) for port in egress_ports: process_egress_frame(frame.clone(), port) function lookup_destination(frame): if frame.dst_mac == BROADCAST or is_multicast(frame.dst_mac): // Flood to all ports in VLAN except ingress return [p for p in vlan_ports[frame.vlan_id] if p != frame.ingress_port] if frame.dst_mac in fdb_table: return [fdb_table[frame.dst_mac]] // Unknown unicast - flood return [p for p in vlan_ports[frame.vlan_id] if p != frame.ingress_port] function process_egress_frame(frame, egress_port): // Output ACL if not egress_port.output_acl.permit(frame): drop(frame, "Denied by output ACL") return // VLAN Tag Manipulation if egress_port.mode == ACCESS: frame.strip_vlan_tag() elif egress_port.mode == TRUNK: if frame.vlan_id == egress_port.native_vlan: frame.strip_vlan_tag() else: // Keep or push VLAN tag ensure_vlan_tag(frame) // QoS Shaping egress_port.shaper.enqueue(frame) // Statistics egress_port.stats.tx_bytes += frame.size egress_port.stats.tx_packets += 17f:T6c3,The Forwarding Database (FDB), also known as the MAC address table, is the core data structure enabling efficient Layer 2 switching. Virtual switches implement this exactly as physical switches do, but with some significant advantages due to tight integration with the virtualization layer. ### Learning Process MAC learning in virtual switches follows the standard 802.1D bridge learning behavior: 1. **Observe source MAC addresses**: Every frame arriving on a port provides information about which MAC address is reachable via that port 2. **Update forwarding table**: Store the mapping (source_MAC → ingress_port) with a timestamp 3. **Age entries**: Periodically scan the table and remove entries that haven't been refreshed within the aging time (typically 300 seconds) ### FDB Data Structure The FDB must support extremely fast lookups (O(1) average case) since every frame requires a lookup. Most implementations use: - **Hash table** with MAC address as key - **Collision resolution** via chaining or open addressing - **Per-VLAN tables** for VLAN-aware bridges (IVL - Independent VLAN Learning) ### Virtual Switch FDB Advantages Virtual switches have advantages over physical switches: **Pre-populated entries**: The hypervisor knows exactly which MAC addresses belong to which VMs. Instead of learning through traffic, entries can be pre-populated when VMs start. **Instant migration updates**: When a VM migrates, the hypervisor can immediately update FDB entries across the source and destination hosts, avoiding the learning delay that physical networks experience. **Reduced table size**: Since virtual switches only serve their local VMs (not an entire datacenter), FDB tables remain manageable in size.80:T415,### VMware vSwitch and vDistributed Switch VMware offers two virtual switch products integrated with vSphere: **vSwitch (vSS - vSphere Standard Switch)** - Included in all vSphere editions - Per-host configuration (no centralized management) - Basic VLAN, NIC teaming, and traffic shaping - Simpler operation, lower resource usage **vDistributed Switch (vDS)** - Requires Enterprise Plus license - Centralized management across all hosts in datacenter - Advanced features: Network I/O Control (NIOC), port mirroring, NetFlow, LACP - Consistent network policy across host migrations - NSX integration for network virtualization ### Microsoft Hyper-V Virtual Switch Integrated with Windows Server Hyper-V: **Key characteristics:** - Deep Windows ecosystem integration - Azure integration through Azure Stack HCI - Switch Embedded Teaming (SET) for NIC aggregation without separate teaming config - Virtual Filtering Platform (VFP) - extensible datapath for SDN - Single Root I/O Virtualization (SR-IOV) for hardware-accelerated VM networking81:T67a,Open vSwitch deserves special attention due to its widespread adoption and elegant multi-layer architecture. Understanding OVS architecture is essential for anyone working with OpenStack, Kubernetes networking, or SDN deployments. ### Component Architecture **ovs-vswitchd (User Space Daemon)** The core OVS daemon running in user space. It: - Communicates with SDN controllers via OpenFlow - Manages the flow table - Handles the "slow path" - packets that don't match cached flow entries - Computes flow actions for complex matches - Pushes fast-path flow entries to the kernel datapath **Datapath (Kernel Module)** The kernel module handles the "fast path": - Receives packets from virtual and physical interfaces - Performs flow table lookups using tuple-space search - Executes cached actions (forward, drop, modify, encapsulate) - For unmatched packets: upcall to ovs-vswitchd **OVSDB (Database)** A lightweight JSON-RPC database storing switch configuration: - Bridge configuration - Port and interface settings - Controller connections - QoS policies - Persists across restarts ### The Flow Cache Mechanism OVS's performance secret is its **megaflow cache**: 1. First packet of a flow hits kernel datapath → no match → upcall to ovs-vswitchd 2. ovs-vswitchd computes OpenFlow match and actions 3. ovs-vswitchd installs a *megaflow* cache entry in kernel 4. Subsequent packets match the cached megaflow → fast-path processing entirely in kernel Megaflows are generalized using wildcards, so a single cache entry can match many microflows (individual 5-tuple connections), dramatically reducing cache size while maintaining high hit rates.82:T711,The connection between a VM and a virtual switch occurs through a **virtual NIC (vNIC)**. Different vNIC types offer varying tradeoffs between compatibility, performance, and features. ### Emulated NICs (Full Virtualization) **How it works**: The hypervisor fully emulates a legacy NIC in software. The guest OS uses standard drivers for that NIC model. **Examples**: - Intel e1000/e1000e (Intel Pro/1000) - Realtek RTL8139 - AMD PCNet **Pros**: Maximum compatibility—works with any OS that has drivers for the emulated hardware. **Cons**: Significant CPU overhead. Every hardware register access traps to the hypervisor. Performance limited to 1-2 Gbps realistically. ### Paravirtual NICs (PV NICs) **How it works**: Guest OS uses a hypervisor-aware driver that communicates directly with the hypervisor through shared memory rings, eliminating most traps. **Examples**: - **virtio-net**: Standard for KVM/QEMU, also supported on other hypervisors - **VMware VMXNET3**: VMware's paravirtual NIC - **Hyper-V NetVSC**: Microsoft's synthetic NIC **Pros**: Near-native performance (10+ Gbps easily), lower CPU utilization. **Cons**: Requires guest driver installation (though drivers are now included in most OS kernels). ### SR-IOV (Single Root I/O Virtualization) **How it works**: SR-IOV-capable physical NICs present multiple **Virtual Functions (VFs)** that can be directly assigned to VMs, bypassing the hypervisor datapath entirely. **Pros**: True hardware-accelerated networking with bare-metal performance, lowest latency. **Cons**: - Requires SR-IOV-capable NIC hardware - Limits VM mobility (VFs tied to physical location) - Fewer VFs than virtual ports (typically 64-256 VFs per physical function) - Bypass limits some virtual switch features (port mirroring, deep packet inspection)83:T577,Production virtual switches typically connect to multiple physical NICs for **redundancy and increased bandwidth**. The process of combining multiple NICs into a single logical interface is called **bonding** (Linux) or **NIC teaming** (Windows/VMware). ### Why Bond NICs? **Redundancy (Failover)**: If one NIC or its uplink fails, traffic automatically fails over to surviving NICs without disrupting VMs. **Increased Bandwidth**: Traffic can be distributed across multiple NICs, potentially multiplying available bandwidth. ### Bonding Modes Different bonding modes provide different failover and load-balancing behaviors: **Mode 1: Active-Backup** - Only one NIC active at a time; others standby - Zero aggregated bandwidth benefit (simple failover) - Compatible with any switch configuration - Simplest and most widely used **Mode 4: LACP (802.3ad)** - Dynamic link aggregation negotiated with physical switch - Full bandwidth aggregation - Requires switch support and configuration - Industry standard for data center deployments **Mode 5: Balance-TLB (Transmit Load Balancing)** - Outbound traffic distributed across NICs based on load - Incoming traffic uses one NIC - No switch configuration required **Mode 6: Balance-ALB (Adaptive Load Balancing)** - Both transmit and receive load balancing - Uses ARP negotiation to distribute incoming traffic - No switch configuration required73:{"json":{"id":"seed_ef3ba0aa0e5ac9c7780f32eeadf646c6","slug":"network-virtualization","category":"Computer Networks","topic":"Network Virtualization","title":"Network Virtualization: Abstracting Physical Infrastructure","description":"Master the principles and technologies of network virtualization, from virtual switches and overlay networks to VXLAN, network segmentation, and multi-tenancy. Understand how modern datacenters and cloud environments decouple logical networks from physical infrastructure to achieve unprecedented scalability, flexibility, and operational efficiency.","difficulty":"ADVANCED","estimatedMinutes":90,"pages":[{"id":"seed_bb7f1ad438a33a2c66bec176b31e25c6","title":"Virtual Switches: The Foundation of Network Virtualization","order":0,"content":[{"id":"opening-paradigm-shift","title":"The Need for Virtual Networking","content":[{"data":{"content":"$7b"},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the architectural principles behind virtual switches, how they differ from physical switches, the internal data path mechanics, integration with hypervisor environments, the major virtual switch implementations (Open vSwitch, VMware vSwitch, Hyper-V Virtual Switch), and the critical role virtual switches play in enabling advanced network virtualization features.","variant":"info"},"type":"callout"}]},{"id":"fundamental-problem","title":"The Fundamental Problem: Connecting Virtual Machines","content":[{"data":{"content":"To understand why virtual switches exist, we must first understand the problem they solve. Consider a physical server hosting ten virtual machines:\n\n**The naive approach would be:**\n1. Give each VM a physical NIC\n2. Connect each NIC to a physical switch\n3. Configure the physical switch for all 10 ports\n\nThis immediately reveals multiple fatal flaws:\n\n- **Physical limitation**: Servers have limited PCIe slots for NICs (typically 2-4), yet may host 50+ VMs\n- **Cable management nightmare**: Datacenters with thousands of VMs would require millions of cables\n- **Static provisioning**: Adding a new VM would require physical intervention\n- **Cost explosion**: Enterprise-grade NICs cost hundreds of dollars each\n- **Switch port exhaustion**: Physical switches have finite port counts (typically 24-48 ports)\n\nThe fundamental insight is that **virtual machines don't need physical network interfaces—they need the *illusion* of network interfaces**. This illusion is precisely what virtual switches provide."},"type":"text"},{"data":{"rows":[["NIC per VM","Physical NIC (hardware)","Virtual NIC (vNIC) - software emulation"],["Switching fabric","Hardware ASIC in physical switch","Software implementation in hypervisor"],["Port capacity","Limited by switch hardware (24-48 ports)","Limited only by host memory/CPU"],["Provisioning time","Minutes to hours (physical access required)","Milliseconds (API call)"],["VM migration","Requires cable reconfiguration","Seamless—virtual switch state moves with VM"],["Cost per port","$$50-500 per switch port","Near-zero marginal cost"],["Configuration change","CLI on hardware device","Programmatic API or orchestration"]],"caption":"Physical vs. Virtual Network Connectivity","headers":["Aspect","Physical Approach","Virtual Switch Approach"]},"type":"table"},{"data":{"icon":"Lightbulb","title":"The Abstraction Principle","content":"Virtual switches follow the same principle that made virtualization successful: present a familiar interface (Ethernet NIC) while completely abstracting the underlying implementation. VMs don't know they're connected to a virtual switch—they see what appears to be a standard Ethernet network.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"virtual-switch-architecture","title":"Virtual Switch Architecture Deep Dive","content":[{"data":{"content":"$7c"},"type":"text"},{"data":{"height":"500px","mermaidSyntax":"\nflowchart TB\n subgraph \"Physical Server\"\n subgraph \"Hypervisor Layer\"\n subgraph \"Virtual Switch\"\n MP[Management Plane\nConfiguration & APIs]\n FE[Forwarding Engine\nMAC Learning & Switching]\n VP1[vPort 1]\n VP2[vPort 2]\n VP3[vPort 3]\n IP[Internal Port]\n UP[Uplink Port]\n end\n end\n subgraph \"Virtual Machines\"\n VM1[VM 1\nvNIC: MAC-A]\n VM2[VM 2\nvNIC: MAC-B]\n VM3[VM 3\nvNIC: MAC-C]\n end\n HOST[Host OS Network Stack]\n PNIC[Physical NIC\nHardware]\n end\n \n VM1 --> VP1\n VM2 --> VP2\n VM3 --> VP3\n HOST --> IP\n VP1 --> FE\n VP2 --> FE\n VP3 --> FE\n IP --> FE\n FE --> UP\n UP --> PNIC\n MP -.-> FE\n "},"type":"mermaid-excalidraw"},{"data":{"icon":"Info","title":"Kernel vs. User Space Implementation","content":"Most virtual switches run in kernel space for performance reasons—switching frames through user space would add significant latency due to context switches. However, some implementations (like DPDK-based switches) run in user space and achieve even higher performance by bypassing the kernel entirely through polling drivers and huge pages.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"data-path-packet-processing","title":"Data Path and Packet Processing Pipeline","content":[{"data":{"content":"$7d"},"type":"text"},{"data":{"code":"$7e","fileName":"virtual-switch-data-path.pseudo","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Performance Critical Path","content":"The data path is performance-critical code executed for every single frame. Even a few microseconds of additional latency per frame can significantly impact application performance at high packet rates. This is why virtual switch optimization—fast path caching, lock-free data structures, and kernel bypass—is crucial for high-performance networking.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"mac-learning-fdb","title":"MAC Address Learning and Forwarding Database","content":[{"data":{"content":"$7f"},"type":"text"},{"data":{"rows":[["00:50:56:01:02:03","vPort-VM1","100","Dynamic","45","Active"],["00:50:56:01:02:04","vPort-VM2","100","Static","-","Permanent"],["00:50:56:01:02:05","vPort-VM3","200","Dynamic","180","Active"],["00:50:56:01:02:06","Uplink-0","100","Dynamic","5","Active"],["FF:FF:FF:FF:FF:FF","All Ports","-","Reserved","-","Flood"]],"caption":"Example Virtual Switch Forwarding Database","headers":["MAC Address","Port","VLAN","Type","Age (seconds)","State"]},"type":"table"},{"data":{"items":["**Dynamic entries**: Learned from traffic, subject to aging timeout","**Static entries**: Administratively configured, never age out","**Self entries**: MAC addresses of the switch itself (internal ports)","**Reserved entries**: Special addresses (broadcast, multicast groups)","**Sticky entries**: Learned dynamically but converted to static (port security)"],"title":{"icon":"Target","text":"FDB Entry Types","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":4},{"id":"major-implementations","title":"Major Virtual Switch Implementations","content":[{"data":{"content":"Several virtual switch implementations dominate the datacenter and cloud landscape. Each offers different tradeoffs between performance, features, and ecosystem integration.\n\n### Open vSwitch (OVS)\n\nOpen vSwitch is the **de facto standard for open-source virtual switching**. Originally developed by Nicira (later acquired by VMware), OVS is now an independent project under the Linux Foundation.\n\n**Key characteristics:**\n- **OpenFlow-native**: Full support for OpenFlow protocol, enabling SDN controllers to program forwarding rules\n- **Rich matching**: Supports matching on all standard headers plus tunnel metadata\n- **Kernel + userspace components**: ovs-vswitchd (userspace daemon) manages slow path; datapath module handles fast path in kernel\n- **DPDK integration**: Can bypass kernel entirely for ultra-high-performance scenarios\n- **Extensive tunnel support**: VXLAN, GRE, Geneve, STT for overlay networking\n- **Dominant in OpenStack**: Default virtual switch for OpenStack Neutron networking"},"type":"text"},{"data":{"code":"# Create a new Open vSwitch bridge\novs-vsctl add-br br-int\n\n# Add a virtual port connected to a VM\novs-vsctl add-port br-int vnet0 -- \\\n set Interface vnet0 type=internal\n\n# Add VXLAN tunnel port for overlay networking\novs-vsctl add-port br-int vxlan0 -- \\\n set Interface vxlan0 type=vxlan \\\n options:remote_ip=192.168.1.100 \\\n options:key=5000\n\n# Display flow rules (OpenFlow match-action entries)\novs-ofctl dump-flows br-int\n\n# Add OpenFlow rule: redirect HTTP traffic to port 2\novs-ofctl add-flow br-int \\\n \"priority=100,tcp,tp_dst=80,actions=output:2\"\n\n# Show MAC address table (FDB)\novs-appctl fdb/show br-int\n\n# Display port statistics\novs-vsctl get interface vnet0 statistics","fileName":"ovs-commands.sh","languages":[{"label":"OVS CLI","value":"bash"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"$80"},"type":"text"},{"data":{"rows":[["License","Open Source (Apache 2.0)","Proprietary (Enterprise Plus)","Included with Windows Server"],["SDN Protocol","OpenFlow native","NSX Manager API","VFP + Network Controller"],["Primary Hypervisor","KVM, Xen","ESXi","Hyper-V"],["DPDK Support","Yes","No","No"],["Max Ports","Thousands","Thousands","Thousands"],["Hardware Offload","Yes (ASAP²)","Yes (vSphere 7+)","Yes (SR-IOV, VFP offload)"],["Overlay Tunnels","VXLAN, Geneve, GRE, STT","VXLAN, Geneve","VXLAN, NVGRE"],["Centralized Mgmt","SDN Controller","vCenter","Network Controller"]],"caption":"Virtual Switch Implementation Comparison","headers":["Feature","Open vSwitch","VMware vDS","Hyper-V Virtual Switch"]},"type":"table"}],"titleType":"number","titleNumber":5},{"id":"ovs-architecture","title":"Open vSwitch Architecture Deep Dive","content":[{"data":{"content":"$81"},"type":"text"},{"data":{"height":"500px","mermaidSyntax":"\nflowchart TB\n subgraph \"User Space\"\n CTRL[SDN Controller\nOpenFlow]\n OVSDB[\"(OVSDB\nConfiguration)\"]\n DAEMON[ovs-vswitchd\nSlow Path Processing]\n end\n \n subgraph \"Kernel Space\"\n DP[Datapath Module\nFast Path Processing]\n CACHE[Megaflow Cache\nWildcard Entries]\n VPORTS[Virtual Ports]\n end\n \n subgraph \"Interfaces\"\n VM1[VM Interface]\n VM2[VM Interface]\n PNIC[Physical NIC]\n TUN[Tunnel Interface]\n end\n \n CTRL <-->|\"OpenFlow\"| DAEMON\n OVSDB <-->|\"JSON-RPC\"| DAEMON\n DAEMON <-->|\"Netlink\"| DP\n DAEMON -->|\"Install Flows\"| CACHE\n \n VM1 <--> VPORTS\n VM2 <--> VPORTS\n PNIC <--> VPORTS\n TUN <--> VPORTS\n \n VPORTS <--> DP\n DP <--> CACHE\n DP -.->|\"Cache Miss\n(Upcall)\"| DAEMON\n "},"type":"mermaid-excalidraw"},{"data":{"icon":"Zap","title":"DPDK Userspace Datapath","content":"For ultimate performance, OVS can replace the kernel datapath with a DPDK (Data Plane Development Kit) userspace datapath. DPDK bypasses the kernel entirely using kernel bypass drivers, huge pages, and busy-polling to achieve line-rate forwarding on 40/100Gbps NICs. This is commonly deployed in NFV and telco environments where every microsecond matters.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"virtual-nic-types","title":"Virtual Network Interface Types","content":[{"data":{"content":"$82"},"type":"text"},{"data":{"rows":[["Typical Throughput","1-2 Gbps","10-25 Gbps","25-100 Gbps (line rate)"],["Latency Overhead","100-500 μs","10-50 μs","< 5 μs"],["CPU Utilization","High","Low-Medium","Minimal"],["Guest Driver","In-box everywhere","Modern kernels","Vendor-specific VF driver"],["Live Migration","Full support","Full support","Limited (downtime)"],["vSwitch Features","Full","Full","Limited bypass"],["Hardware Required","None","None","SR-IOV NIC"],["Primary Use Case","Legacy compatibility","General purpose","High-performance NFV"]],"caption":"Virtual NIC Type Comparison","headers":["Characteristic","Emulated (e1000)","Paravirtual (virtio)","SR-IOV Virtual Function"]},"type":"table"},{"data":{"icon":"Info","title":"Hardware Offload Evolution","content":"Modern smart NICs (Mellanox/NVIDIA ConnectX, Intel IPU, Broadcom Stingray) blur these lines by offloading virtual switch functionality to hardware while maintaining full feature support. Technologies like OVS hardware offload (ASAP²) accelerate OVS flows in NIC ASICs, providing SR-IOV-level performance with full virtual switch feature support.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"nic-teaming","title":"NIC Teaming and Bonding","content":[{"data":{"content":"$83"},"type":"text"},{"data":{"code":"# Create LACP bond with Open vSwitch\n# Add bond to OVS bridge with two physical NICs\novs-vsctl add-bond br-int bond0 eth0 eth1 \\\n bond_mode=balance-tcp \\\n lacp=active \\\n other_config:lacp-time=fast\n\n# View bond status\novs-appctl bond/show bond0\n# Output:\n# ---- bond0 ----\n# bond_mode: balance-tcp\n# bond-hash-basis: 0\n# updelay: 0 ms\n# downdelay: 0 ms\n# lacp_status: negotiated\n# active-backup primary: \n#\n# slave eth0: enabled\n# active slave\n# may_enable: true\n# hash: 0-127\n#\n# slave eth1: enabled\n# may_enable: true \n# hash: 128-255\n\n# Force failover for testing\novs-appctl bond/set-active-slave bond0 eth1\n\n# View LACP negotiation details\novs-appctl lacp/show bond0","fileName":"bond-configuration.sh","languages":[{"label":"Linux Bond","value":"bash"}],"showLineNumbers":true},"type":"code"},{"data":{"items":["**Switch configuration must match**: Both ends must agree on LACP mode (active/passive) and speed/duplex","**Same physical switch or MLAG**: Traditional LACP requires all links to same switch; for multi-rack use MLAG/vPC","**Hashing algorithm**: Traffic is distributed by hash of frame attributes—uneven distribution possible for few large flows","**Fast/Slow LACP timers**: Fast (1s) detects failures quicker but generates more control traffic","**SR-IOV conflicts**: SR-IOV Virtual Functions typically cannot participate in software bonds"],"title":{"icon":"AlertCircle","text":"LACP Configuration Considerations","type":"icon","color":"accent","variant":"outline-circle"},"variant":"glass"},"type":"list"}],"titleType":"number","titleNumber":8},{"id":"summary","title":"Summary: Virtual Switches as Foundation","content":[{"data":{"content":"Virtual switches are far more than simple frame-forwarding engines—they are the **foundational abstraction layer** that makes network virtualization possible. Without virtual switches, we would have no way to efficiently connect virtual machines to networks, no way to logically separate network traffic across tenants, and no way to implement software-defined networking in virtualized environments."},"type":"text"},{"data":{"type":"ordered","items":["**Virtual switches solve the VM connectivity problem** by creating software-based Layer 2 switches that operate entirely within the hypervisor, eliminating the need for physical NIC per VM","**Architecture consists of vPorts, forwarding engine, uplinks, and management plane**, mirroring physical switches but implemented in software","**Data path processing** follows standard bridge behavior: MAC learning, FDB lookups, VLAN processing, and frame forwarding","**Major implementations** include Open vSwitch (open-source, OpenFlow-native), VMware vDS (enterprise vSphere), and Hyper-V Virtual Switch (Windows integration)","**OVS uses megaflow caching** to achieve near-hardware performance by caching flow decisions in kernel datapath","**Virtual NIC types** (emulated, paravirtual, SR-IOV) offer tradeoffs between compatibility and performance","**NIC bonding** provides redundancy and bandwidth aggregation for production virtual switch deployments","**Virtual switches are the enabler** for overlay networks, network segmentation, and multi-tenancy—topics we'll explore in subsequent pages"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"CheckCircle","title":"Foundation Established","content":"You now understand how virtual switches transform physical network infrastructure into flexible, programmable, software-defined connectivity. This foundation is essential for understanding the overlay networks, VXLAN encapsulation, and multi-tenant architectures we'll explore next.","variant":"success"},"type":"callout"},{"data":{"content":"**Next Up**: We'll build on this foundation to explore **Overlay Networks**—how virtual switches combine with encapsulation protocols to create logical networks that are completely independent of physical network topology, enabling true network virtualization across datacenters and cloud environments."},"type":"text"}],"titleType":"number","titleNumber":9}],"isLocked":false},{"id":"seed_be595d99a028e8b43e028984b3ac2de0","title":"Overlay Networks: Decoupling Logical from Physical","order":1,"content":null,"isLocked":true},{"id":"seed_f4071265f83a69cc46c6487c37677e72","title":"VXLAN: The Dominant Overlay Protocol","order":2,"content":null,"isLocked":true},{"id":"seed_ca3cc7d02b60daecd25586b94127f902","title":"Network Segmentation: Isolating and Securing Network Domains","order":3,"content":null,"isLocked":true},{"id":"seed_bffb4bbc52d9fbfe5329ff2692fb1623","title":"Multi-Tenancy: Shared Infrastructure, Complete Isolation","order":4,"content":null,"isLocked":true}]}}