Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 1.12 — Explain virtualization fundamentals

Virtualization creates logical isolation over shared physical resources. Server virtualization, containers, and VRFs operate at different layers and should not be used as interchangeable answers.

Virtual machines

A hypervisor presents virtual hardware to guest operating systems. Each virtual machine runs its own OS instance, applications, virtual interfaces, storage, and allocated compute. VMs improve consolidation and isolation but still require capacity planning, patching, backup, network policy, and failure-domain design. Losing one physical host can affect many guests unless the platform provides and tests recovery.

Virtual switches connect guest interfaces to one another or to physical uplinks. VLANs and security policy still need deliberate configuration at the virtual and physical boundary.

Containers

Containers package processes and dependencies while commonly sharing the host kernel. They are lighter than full VMs and support consistent application deployment, but they are not tiny virtual machines in every respect. Images, runtime privileges, network namespaces, persistent storage, and orchestration all introduce controls that must be managed.

A container can move application packaging without moving an entire guest OS. Its network may use bridges, overlays, address translation, or routed designs.

Virtual routing and forwarding

A VRF gives one network device multiple separate Layer 3 routing tables. The same prefix can exist in different VRFs without colliding because each lookup occurs in a selected table. Interfaces belong to routing contexts, and traffic does not cross between VRFs unless an explicit route-leaking or external policy design allows it.

VRFs isolate routing state; they do not virtualize compute or automatically encrypt traffic. They are useful for tenant, management, or policy separation.

Worked comparison

A company needs two customers to use overlapping 10.0.0.0/8 routes on one router: use separate VRFs. It needs two operating systems on one host: use VMs. It needs a consistent lightweight application package sharing a supported host kernel: use a container. One design can combine all three.

Verification evidence

For VMs, inspect guest placement, virtual interfaces, and host capacity. For containers, inspect image version, namespace, exposed ports, and runtime state. For VRFs, inspect interface membership and run route or ping commands in the correct VRF context. A route in the global table does not prove availability in a tenant VRF.

Common traps

• Calling a VRF a virtual machine.
• Assuming containers include a separate kernel.
• Treating shared hardware as a single failure-free resource.
• Expecting VRF separation to encrypt traffic.
• Troubleshooting the global route table for a VRF-bound interface.

Readiness checklist

• I can state the isolation boundary of VMs, containers, and VRFs.
• I can choose the right mechanism from a requirement.
• I understand virtual networking still needs switching and routing policy.
• I verify state in the correct virtual context.