CCNA Virtualization: Server VMs, Containers, and VRFs Explained

A hypervisor is software that creates and manages virtual machines (VMs) by abstracting physical hardware. Each VM has its own virtual CPU, RAM, storage, and network interfaces — it looks like a dedicated physical server to the operating system running inside it.

A Type 1 hypervisor (bare-metal) runs directly on the physical hardware without a host OS. Examples: VMware ESXi, Microsoft Hyper-V Server, KVM (Linux kernel). The hypervisor is the operating system. This gives VMs direct access to hardware with minimal overhead, making Type 1 the data center standard.

A Type 2 hypervisor runs as an application on top of a conventional operating system. Examples: VMware Workstation, Oracle VirtualBox, Parallels Desktop. The host OS manages hardware, and the hypervisor runs as a process within it. This adds a layer of overhead but makes it easy to run VMs on developer laptops and workstations without dedicated hardware.

For the CCNA exam, the key distinction: Type 1 = bare-metal, used in data centers, best performance. Type 2 = hosted, runs on a desktop OS, used for development and testing.

Containers are lighter-weight than VMs because they share the host OS kernel instead of running their own. A container packages an application and its dependencies into an isolated user-space environment. Multiple containers run on a single host OS, each isolated from the others. Docker is the most common container runtime; Kubernetes orchestrates containers at scale.

The key difference: a VM has a full OS (kernel + userland), making it larger (GBs) and slower to start (minutes). A container shares the host kernel, contains only the app and its libraries (MBs), and starts in seconds. VMs provide stronger isolation (separate kernel, hardware-level virtualization); containers provide better density and agility.

From a networking perspective, containers typically get their own virtual network interfaces on a bridge network managed by Docker or Kubernetes. Containers can expose ports and be placed on overlay networks that span multiple hosts. The CCNA exam tests the conceptual distinction rather than Docker command syntax.

VRF is a network virtualization technique that creates multiple independent routing tables on a single router or Layer 3 switch. Each VRF instance has its own routing table, its own set of interfaces, and its own forwarding table. Traffic in one VRF cannot reach traffic in another VRF without explicit routing policy (route leaking or VPN).

The classic use case is a service provider carrying traffic for multiple customers on the same router. Each customer gets its own VRF — their routes don't appear in other customers' routing tables, and their traffic is completely isolated even though it shares the same physical infrastructure. This is the foundation of MPLS L3 VPN services.

Enterprise networks also use VRFs for traffic segmentation. A common pattern: a Management VRF carries only device management traffic (SSH, SNMP, syslog), isolated from production traffic. If the production network is compromised, the management plane remains accessible via the Management VRF.

On Cisco IOS, VRF-aware interfaces are assigned with `ip vrf forwarding <name>` and routing protocols can be placed in VRF context. The default routing table is called the global routing table; all other VRF tables exist alongside it.

When a hypervisor runs multiple VMs, the physical host has one or more physical NICs (pNICs). A virtual switch (vSwitch) on the hypervisor connects VM virtual NICs (vNICs) to each other and to the physical network. VMware's standard vSwitch and the Cisco Nexus 1000V are examples.

VMs on the same vSwitch can communicate at Layer 2 without hitting the physical network. VMs on different hosts communicate through the physical switches. The vSwitch can carry multiple VLANs via trunk links to the physical switch — the hypervisor administrator assigns VMs to VLANs just like a physical switch administrator assigns ports.