Virtualization Fundamentals: VMs, Containers, and VRFs

CCNA objective 1.12 asks for "virtualization fundamentals: server virtualization, containers, and VRFs" - three technologies that all answer the same question at different layers: how do you run multiple isolated things on one piece of hardware? Servers virtualize the machine, containers virtualize the operating system, and VRFs virtualize the router. This guide covers all three, and demonstrates the VRF case with something that looks impossible: the same IP address configured twice on one router, live from our Network Fundamentals lab.

Server virtualization: slicing the machine

A hypervisor presents virtual hardware - vCPUs, vRAM, vNICs, vDisks - so that multiple complete operating systems share one physical server, each convinced it owns the box. Two flavors:

• Type 1 (bare metal): the hypervisor IS the OS on the hardware - VMware ESXi, Hyper-V, KVM, Proxmox. This is what runs data centers (and, for what it's worth, the CML server this lab lives on runs on ESXi).
• Type 2 (hosted): an application on a normal OS - VMware Workstation, VirtualBox. Labs and desktops.

The networking angle the exam cares about: every hypervisor contains a virtual switch. VM traffic to another VM on the same host never touches your physical network - a fact with real consequences for where you can capture packets and enforce ACLs. The physical NIC becomes an uplink/trunk, and VLANs extend into the host. Your access layer no longer ends at the switchport; it ends inside the server.

Containers: slicing the operating system

A container doesn't boot its own OS. It's a set of processes on the host's kernel, isolated by namespaces (its own view of processes, filesystem, network stack) and limited by cgroups (CPU/memory caps). No emulated hardware means containers start in milliseconds and pack far more densely than VMs - the tradeoff being weaker isolation (shared kernel) and Linux-only workloads.

Containers are already in your network gear: the hosts in our CML labs are Docker containers, and IOS XE itself can run containerized apps on Catalyst switches. When a container needs to talk to your network, it usually does so through NAT on its host or via a bridge - one more virtual switch to keep in your mental topology.

VRF: slicing the router

Virtual Routing and Forwarding gives one physical router multiple independent routing tables. An interface assigned to a VRF exists only in that VRF's world: its routes, its ARP, its forwarding decisions. Traffic cannot cross VRFs unless you deliberately leak routes. It's the routing equivalent of what VLANs did to switches.

The classic proof is overlapping addresses. On our lab router, two customer VRFs each use 172.16.1.0/24 - simultaneously:

R1# show vrf
  Name        Default RD   Protocols   Interfaces
  BLUE        <not set>    ipv4        Lo10
  RED         <not set>    ipv4        Lo20

R1# show ip route vrf BLUE
Routing Table: BLUE
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.1.0/24 is directly connected, Loopback10
L        172.16.1.1/32 is directly connected, Loopback10

R1# show ip route vrf RED
Routing Table: RED
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.1.0/24 is directly connected, Loopback20
L        172.16.1.1/32 is directly connected, Loopback20

Same prefix, same host address, one router, zero conflict - because "the routing table" is now "a routing table per VRF." The global table (plain show ip route) doesn't contain 172.16.1.0/24 at all. When troubleshooting a VRF'd network, every command needs the qualifier: ping vrf BLUE 172.16.1.1, show ip arp vrf BLUE. Forgetting the keyword and concluding "the route is missing" is the classic VRF beginner error.

Where you'll meet VRFs: service providers separating customers (the mechanism under MPLS L3VPN), enterprises separating guest/IoT/PCI traffic end-to-end (VRF-lite), out-of-band management (the Mgmt-vrf that IOS XE puts your management port in by default), and every SD-WAN segment you've ever configured.

One mental model for all three

Each technology takes a resource that used to be singular and makes it plural behind an isolation boundary: hypervisors do it to hardware, namespaces do it to the kernel, VRFs do it to the RIB. In every case the network engineer's job is the same - know where the virtual switches and virtual tables are, because packets now make forwarding decisions in places you can't physically point at.

FAQ

What is the difference between a VRF and a VLAN?

Layer. A VLAN partitions a switch's Layer 2 domain (separate broadcast domains, one MAC table per VLAN); a VRF partitions a router's Layer 3 domain (separate routing tables). They pair naturally: VLAN 20 carries guest traffic to the router, where interface VLAN 20 sits in the GUEST VRF so guest routes never mix with corporate ones. End-to-end isolation needs both.

What is VRF-lite?

VRFs without MPLS. Full VRF deployments in service providers use MPLS and route distinguishers to carry many customers across a shared core; VRF-lite is the enterprise version - the same per-VRF routing tables, extended between devices by dedicating an interface (or 802.1Q subinterface) per VRF. Simpler, works everywhere, scales to a handful of segments rather than thousands.

Can two VRFs on the same router talk to each other?

Not by default - that isolation is the whole point. When you need controlled crossings (shared services like DNS or internet breakout), you either leak specific routes between VRFs (route-target import/export with BGP, or static routes pointing across) or hairpin through a firewall that has a leg in each VRF. Deliberate, auditable, and the firewall option is what security teams usually prefer.

Is a container a lightweight VM?

Tempting shorthand, architecturally wrong. A VM virtualizes hardware and boots its own kernel; a container is processes on the host's kernel wearing isolation (namespaces + cgroups). That's why containers start in milliseconds, why a kernel exploit threatens every container on the host, and why you can't run Windows containers on a Linux kernel.

Why is my server's VM invisible to my packet capture?

Because VM-to-VM traffic on the same host switches inside the hypervisor's vSwitch and never reaches your physical port. To see it you need a capture inside the host (vSwitch port mirroring, or a capture VM) or force the traffic through the physical network. When a "network problem" involves two VMs, always ask first whether they share a host.

Key takeaways

• Type 1 hypervisors run on bare metal (ESXi, KVM); Type 2 run as apps. Both embed virtual switches that extend your access layer into the server.
• Containers share the host kernel: faster and denser than VMs, weaker isolation. They ride bridges and NAT on their hosts.
• A VRF is a separate routing table on one router - overlapping IP space becomes legal, and every diagnostic command needs the vrf keyword.
• All three are isolation multiplexers. Find the virtual switch/table and the topology makes sense again.

Related: VLAN vs VXLAN for isolation at Layer 2 scale, and the Network Fundamentals guide for the rest of domain 1.