Network Fundamentals Foundational

Network Virtualization & Containers

Hypervisors, virtual machines, virtual switches, containers, container networking — how server virtualization changed networking and what a CCNA candidate must understand.

TL;DR

Server virtualization (VMware ESXi, KVM, Hyper-V) lets one physical server run dozens of guest VMs, each with its own NIC, MAC, and IP — multiplying the number of network endpoints behind one switch port.
A virtual switch (vSwitch, Distributed vSwitch, OVS) lives inside the hypervisor and forwards traffic between VMs and out to the physical network.
Containers (Docker, Kubernetes) share the host OS kernel — networking uses bridges, overlays (VXLAN), and CNI plugins. Different model from VMs but the network-engineer problems are the same: addressing, isolation, routing.

Mental model

For decades, “one server = one set of NICs = one set of IPs.” Then VMware (and later KVM, Hyper-V, Xen) broke that — a single physical server can now host dozens of independent guest operating systems, each with its own network identity.

For the network engineer this means:

Far more endpoints per switch port — one physical port might handle traffic for 50 VMs.
Virtual switches inside the server — packets get switched in software before they ever reach your physical switch.
VLANs and trunks now end inside the hypervisor, not at the physical NIC.
Live migration (VMs moving across hosts) requires MAC and IP mobility — which forces design decisions about subnet stretching, overlay networks, and ARP behavior.

Container networking (Docker, Kubernetes) raised the count again — instead of dozens of VMs per host, hundreds of containers. The networking model is different (shared kernel, namespaces, CNI plugins) but the engineer’s job is the same: make traffic flow, scale, and stay secure.

This is one of the CCNA 200-301 blueprint topics that grew from “describe” to “describe + apply” in v1.1.

Server virtualization — the building blocks

                   Physical Server
            ┌──────────────────────────────┐
            │     Guest VM 1 (Linux)        │
            │     Guest VM 2 (Windows)      │
            │     Guest VM 3 (Ubuntu)       │
            ├──────────────────────────────┤
            │       Hypervisor (ESXi)       │
            │   ┌──────────────────────┐    │
            │   │   Virtual Switch     │    │
            │   └─────────┬────────────┘    │
            ├─────────────┼─────────────────┤
            │   Physical NICs (eth0/eth1)   │
            └─────────────┴─────────────────┘
                          │
                          ▼
                  Physical switch (yours)

Three components matter:

Component	What it does
Hypervisor	Software layer (Type 1 = bare metal, Type 2 = on top of OS) that runs the guests
Virtual NIC (vNIC)	Software NIC presented to the guest — guest thinks it’s a real network card
Virtual switch (vSwitch)	L2 switch inside the hypervisor — forwards between VMs and out to physical

Type 1 vs Type 2 hypervisors

Type	Examples	Where
Type 1 (bare-metal)	VMware ESXi, KVM, Hyper-V, Xen, Proxmox	Production servers
Type 2 (hosted)	VMware Workstation, VirtualBox, Parallels	Dev/laptop

Production server farms run Type 1. CCNA tests recognition of both.

Virtual switches (vSwitch / DVS / OVS)

A vSwitch is a software Layer-2 switch inside the hypervisor. It learns MAC addresses, forwards traffic between VMs, handles VLAN tagging, and connects up to the physical NIC.

Three common forms:

vSwitch	Vendor / Project	Notes
Standard vSwitch	VMware	Per-host. Simple but no centralized config.
Distributed vSwitch (DVS / VDS)	VMware	Spans many hosts, configured centrally from vCenter.
Open vSwitch (OVS)	Open source	Used by KVM, OpenStack, many Kubernetes setups. Programmable.

VLANs and trunks at the hypervisor edge

The physical switch port connecting to a virtualized host is almost always a trunk (rarely access). The hypervisor sees the dot1Q tags and delivers each VLAN to the right vSwitch port-group.

SW1(config)# interface Gi1/0/24
SW1(config-if)# description ESX-01 uplink
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk allowed vlan 10,20,30,99
SW1(config-if)# spanning-tree portfast trunk     ! virtualization hosts are not switches

In vCenter / vSphere:

Create port-groups (VLAN 10 = USERS, VLAN 20 = SERVERS, VLAN 99 = MGMT).
Assign each VM’s vNIC to the appropriate port-group.
The vSwitch tags outgoing frames with the right VLAN ID.

Live migration — vMotion

VMware vMotion (and Hyper-V Live Migration, KVM live migration) moves a running VM from one physical host to another with no downtime.

Network implication: the VM keeps its IP and MAC. ARP tables across the network briefly update via gratuitous ARP. Both source and destination hosts need access to the VM’s VLANs, which usually means:

Stretched VLANs (same VLAN trunked to many hosts) — simple but limits failure domain.
VXLAN overlays (VLANs encapsulated and tunneled across L3 boundaries) — modern datacenter answer; supports L2 mobility across racks and sites.

Containers — the second wave

Containers (Docker, Podman, containerd) are lighter than VMs. Instead of running a full guest OS, containers share the host kernel and isolate processes using Linux namespaces and cgroups.

                   Physical Server
            ┌──────────────────────────────┐
            │  Container 1 │ Container 2 │ Container 3
            │  (Linux ns)  │ (Linux ns)  │ (Linux ns)
            ├──────────────────────────────┤
            │     Container runtime (containerd, Docker engine)
            ├──────────────────────────────┤
            │     Host OS (Linux kernel)
            ├──────────────────────────────┤
            │     Physical hardware
            └──────────────────────────────┘

Container networking — three main modes

Mode	What it does
Bridge	Container gets a virtual interface attached to a host-side Linux bridge. NATted to host’s IP for outbound. Default Docker mode.
Host	Container shares the host’s network namespace. No isolation; container binds directly to host ports.
None	No network. Container is fully isolated.
Overlay	Multi-host networking — containers across many hosts can talk as if on the same L2. Uses VXLAN. Standard in Kubernetes / Docker Swarm.

Kubernetes networking

Kubernetes adds its own abstractions on top:

Pod — one or more containers sharing a network namespace (same IP, same ports).
Service — virtual IP and DNS name fronting a group of pods. Uses iptables/IPVS for load balancing.
CNI (Container Network Interface) plugin — provides the actual networking: Calico, Cilium, Flannel, Weave, AWS VPC CNI.

A Kubernetes cluster of 100 nodes might have 10,000+ pods, each with its own IP. Networking has to scale to that without falling over.

For CCNA depth: recognize the terms and that pod networking exists; full Kubernetes networking is CCNP / specialist scope.

VMs vs containers — the comparison

Aspect	VMs	Containers
Isolation	Full OS isolation (stronger)	Process + namespace isolation (weaker)
Startup time	30s – minutes	<1 second
Density	10s per host	100s per host
Image size	10s of GB	10s of MB to GB
Networking	vSwitch + VLAN	Bridge + overlay + CNI
OS flexibility	Any guest OS	Same kernel as host (Linux ↔ Linux, Windows ↔ Windows)
Use case	Traditional workloads, multi-OS environments	Microservices, stateless apps, dev environments

In 2026 real datacenters: both coexist. VMs for stateful / legacy / Windows. Containers for microservices and modern apps.

Where networking-engineer skills apply

You’re still the network engineer for virtualized environments — the surfaces just changed:

VLAN trunking design — same skills as ever, but ending at the hypervisor’s vSwitch.
VRF isolation — many vendors map VRFs to vSwitch port-groups for multi-tenant clouds.
Overlay design — VXLAN, NVGRE, Geneve for inter-host L2 mobility. Cisco SD-Access and VMware NSX both rest on VXLAN.
Anycast gateways — fabric-wide gateway address so VMs/pods can move without re-ARP’ing.
Underlay routing — OSPF or BGP between the physical switches carrying the overlays.
Microsegmentation — per-pod or per-VM firewall policy, enforced at the hypervisor or by Cilium-style eBPF.

Common mistakes

Access-port to a virtualization host. Most environments need a trunk. Access port means all VMs land on one VLAN, defeating multi-tier design.
PortFast off on host trunks. Hypervisor uplinks bounce occasionally (firmware updates, link flaps). Without portfast trunk, every bounce triggers STP recompute. Enable it on host-facing ports.
STP between hypervisors. vSwitches do NOT participate in STP. Connecting two physical switch ports to one vSwitch as redundancy needs an EtherChannel (LACP) — not two independent ports.
Live migration across L3 boundaries without an overlay. VMs lose their IP when crossing subnets. Either stretch the VLAN (limited) or build a VXLAN overlay.
Confusing VM and container networking. A container is not a tiny VM. Bridge mode, host mode, overlay mode — different semantics from vSwitch port-groups.
Defaulting to Docker bridge mode in production. Bridge mode NATs containers behind the host IP. Inbound connections need port mappings. Plan for overlay or host mode at production scale.
Forgetting MAC-table size on physical switches. A virtualized rack with 200 VMs × 4 vNICs each = 800+ MACs visible on the trunk. Older switches’ MAC tables overflow.
No vCenter / hypervisor visibility for the network team. If you don’t have read access to vSphere / the hypervisor, you’ll spend hours debugging issues that are obvious from inside the host.

Lab to try tonight

Install VirtualBox or VMware Workstation. Build 2-3 small Linux VMs.
Configure the VMware/VirtualBox virtual network in different modes (NAT, Bridged, Host-only). Note IP behavior.
Boot a Cisco IOS-XR or IOS-XE virtual image (via CML or EVE-NG). Notice it runs as a VM on your host.
Install Docker on a Linux VM. Run docker network ls and docker network inspect bridge. See the default Linux bridge docker0.
Run two containers. Verify they can reach each other on the bridge.
Try Docker overlay: docker swarm init + docker service create --network overlay-name .... See VXLAN packets in the underlay if you have access.
Bonus: spin up a single-node Kubernetes (kind or minikube). Watch the CNI assign per-pod IPs. Use kubectl exec to ping between pods.

Cheat strip

Concept	Plain English
Hypervisor	Software that runs guest VMs. Type 1 = bare metal, Type 2 = hosted
VM	Full guest OS running on a hypervisor
Virtual NIC (vNIC)	Software NIC presented to a VM
Virtual switch (vSwitch)	L2 switch inside the hypervisor. Forwards between VMs and to physical NICs
Distributed vSwitch (DVS)	vSwitch spanning many hosts, central config
Open vSwitch (OVS)	Open-source programmable vSwitch — Linux/KVM/OpenStack
Container	Process-level isolation using kernel namespaces. Lighter than VM
Docker / containerd	Most common container runtime
CNI	Container Network Interface — plugin model for pod networking in Kubernetes
Pod	One or more containers sharing a network namespace (Kubernetes)
Overlay (VXLAN)	L2 over L3 tunnel. Enables container/VM mobility across rack and site boundaries
vMotion / live migration	Move a running VM to another host with no downtime
Trunk to hypervisor	Standard pattern — multiple VLANs reach the vSwitch
No STP from vSwitches	They don’t participate. Use EtherChannel for redundancy
CCNA depth	Recognize the model, understand VLAN-to-port-group mapping, know VXLAN exists for mobility

← Previous topic

VRF Basics — Virtual Routing and Forwarding

How a router can pretend to be multiple separate routers with isolated routing tables — VRF-lite vs MPLS-VPN VRFs, RDs/RTs, and the use cases (multi-tenant, management plane, lab isolation).

Next topic →

Cybersecurity Threats & Mitigation

The threat landscape every network engineer must recognize — phishing, ransomware, MITM, DDoS, supply-chain attacks, insider threats — and the mitigation controls that actually move the needle.

Master this on a real network

Want this drilled into reflex?

1:1 weekly sessions, live feedback on your labs, and US interview prep — built around the CCNA® exam blueprint. Free first session. No card on file until you decide.

Claim my free session →

One topic per email, every fortnight

VLANs, OSPF, ACLs, subnetting, automation — written like this. Unsubscribe in one click.

We respect your inbox. One email per week, max. Unsubscribe any time.