Exam 350-401 | Complete Study Guide with Diagrams, Labs & Quiz
10% of Exam Weight
๐ Section 2.0 Virtualization โ Exam Overview
Section 2.0 Virtualization accounts for 10% of the CCNP ENCOR 350-401 v1.2 exam. It tests your ability to describe device virtualization (hypervisors, VMs, virtual switches), configure and verify data path virtualization (VRF, GRE, IPsec), and explain network overlay virtualization (LISP, VXLAN).
10% โ Virtualization (this section)
| Sub-topic | Topic | Type |
|---|---|---|
| 2.1.a | Hypervisor Type 1 & Type 2 | Describe |
| 2.1.b | Virtual Machines | Describe |
| 2.1.c | Virtual Switching (vSwitch / DVS) | Describe |
| 2.2.a | VRF (Virtual Routing and Forwarding) | Configure & Verify |
| 2.2.b | GRE and IPsec Tunnels | Configure & Verify |
| 2.3.a | LISP (Locator/ID Separation Protocol) | Describe |
| 2.3.b | VXLAN (Virtual Extensible LAN) | Describe |
2.1 โ Device Virtualization Technologies
Device virtualization abstracts physical hardware into logical units, enabling multiple workloads to share a single physical server. The hypervisor is the engine that makes this possible.
2.1.a โ Hypervisor Type 1 & Type 2
A hypervisor (also called a Virtual Machine Monitor / VMM) is software that creates and manages virtual machines by abstracting the underlying physical hardware.
Figure 1 โ Hypervisor Type 1 (bare-metal) vs Type 2 (hosted)
| Attribute | Type 1 (Bare-Metal) | Type 2 (Hosted) |
|---|---|---|
| Runs on | Directly on hardware (no host OS) | On top of a host OS |
| Performance | High โ direct hardware access | Lower โ goes through host OS |
| Use case | Production data centers, enterprise servers | Development, testing, personal labs |
| Security | Smaller attack surface | Larger (host OS vulnerabilities) |
| Examples | VMware ESXi, MS Hyper-V, KVM, Citrix XenServer | VMware Workstation, VirtualBox, Parallels |
| Management | vCenter (VMware), SCVMM (Hyper-V) | Local GUI on host machine |
2.1.b โ Virtual Machines
A Virtual Machine (VM) is a software emulation of a physical computer. Each VM has its own virtual hardware โ vCPU, vRAM, vNIC, and virtual disk โ and runs an independent guest OS fully isolated from other VMs on the same host.
Figure 2 โ Multiple VMs sharing one physical server, each fully isolated
Key VM Concepts
- VM Snapshot โ Point-in-time capture of VM disk + memory state. Enables rapid rollback.
- vMotion / Live Migration โ Moves a running VM between physical hosts with zero downtime. Requires shared storage.
- Template โ Golden master VM image used to rapidly provision identical VMs.
- VM Isolation โ VMs cannot access each other’s memory or disk. A compromised VM cannot escape to the hypervisor without a hypervisor exploit.
- Overcommitment โ Hypervisor can allocate more vCPU/vRAM than physically present (using memory ballooning, transparent page sharing).
2.1.c โ Virtual Switching
Virtual switches connect VMs to each other and to physical networks entirely in software, inside the hypervisor host. They support VLANs, QoS, port security, and trunk/access ports โ just like physical switches.
Figure 3 โ Virtual Switch connecting VMs with VLAN segmentation
| Feature | Standard vSwitch (VSS) | Distributed vSwitch (DVS) |
|---|---|---|
| Scope | Single ESXi host | Spans multiple ESXi hosts |
| Management | Per-host (local) | Centralized via vCenter |
| Configuration consistency | Manual on each host | Automatic across all hosts |
| Advanced features | Basic VLAN, NIC teaming | NetFlow, port mirroring, QoS, LACP |
| vMotion port group | Reconfigured per host | Follows VM automatically |
| Cisco equivalent | Cisco AVS (per-host) | Cisco AVS Distributed (ACI) |
2.2 โ Data Path Virtualization
Data path virtualization separates logical network paths from the physical infrastructure โ allowing one physical router to act like many, and creating secure tunnels across untrusted networks.
2.2.a โ VRF (Virtual Routing and Forwarding)
VRF creates multiple independent routing tables on a single router. Each VRF is a completely isolated routing domain โ routes in VRF-A are invisible to VRF-B and vice versa. This is sometimes called VRF Lite in enterprise contexts (VRF without MPLS).
Figure 4 โ VRF-Lite: three isolated routing domains on one physical router
VRF Key Concepts
- Route Distinguisher (RD) โ Makes routes unique in MPLS VPN environments (format: ASN:NN or IP:NN). Used to prevent prefix collisions in the BGP table.
- Route Target (RT) โ Controls which VRF routes are exported/imported in MPLS L3VPN.
- VRF Lite โ VRF without MPLS. Used in enterprise to segment departments, customers, or security zones on a shared router.
- Route Leaking โ Deliberately sharing specific routes between VRFs (e.g., allowing Guest VRF to reach a shared DNS server in the MGMT VRF).
- Global routing table โ The default VRF. Any interface not assigned to a VRF is in the global table.
vrf definition (modern syntax) vs ip vrf (legacy). Use show ip route vrf <name> to verify. Ping within a VRF: ping vrf <name> <IP>.2.2.b โ GRE & IPsec Tunneling
GRE (Generic Routing Encapsulation)
GRE creates a virtual point-to-point tunnel between two routers, encapsulating any Layer 3 protocol (including multicast and routing protocol packets) inside a new IP header.
- Protocol number: IP protocol 47
- Supports multicast โ routing protocols (OSPF, EIGRP) can run over GRE tunnels
- Adds 24 bytes overhead (20-byte outer IP header + 4-byte GRE header)
- No encryption โ traffic is visible in plaintext
- Tunnel source/destination = physical router IP addresses (RLOC)
Dst: R2-Physical
4 bytes
Dst: 10.0.0.2
User Data
Figure 5a โ GRE encapsulation (no encryption)
IPsec (IP Security)
IPsec provides authenticated, encrypted communication between peers. It consists of two frameworks:
- IKE (Internet Key Exchange) โ Phase 1: Negotiates a secure channel (ISAKMP SA). Phase 2: Negotiates the IPsec SA (encryption + hashing for data).
- IKEv1 โ Legacy. Uses Main Mode (6 messages) or Aggressive Mode (3 messages).
- IKEv2 โ Modern, preferred. More efficient (4 messages), built-in NAT traversal, EAP auth support.
| IPsec Mode | What’s encrypted | Use case |
|---|---|---|
| Tunnel Mode | Entire original IP packet (header + payload) | Site-to-site VPN between routers |
| Transport Mode | Payload only (original IP header preserved) | End-to-end between hosts (e.g. GRE + IPsec) |
+ Payload
Figure 5b โ GRE over IPsec (tunnel mode) โ full encryption
GRE over IPsec โ Why Combine Them?
GRE alone
- โ Supports multicast (routing protocols)
- โ Any protocol tunneled
- โ No encryption
- โ No authentication
IPsec alone
- โ Full encryption + authentication
- โ No multicast support
- โ Routing protocols can’t run over it
- โ Unicast-only
IPsec Components โ Quick Reference
| Component | Purpose |
|---|---|
| AH (Authentication Header) | Integrity + authentication. No encryption. Protocol 51. |
| ESP (Encapsulating Security Payload) | Encryption + integrity + authentication. Protocol 50. Most used. |
| ISAKMP / IKE Phase 1 | Establishes secure management channel. Negotiates: encryption, hash, DH group, auth method. |
| IKE Phase 2 (Quick Mode) | Negotiates IPsec SAs for data encryption. Uses PFS optionally. |
| Diffie-Hellman (DH) | Key exchange protocol. DH Group 14+ recommended (2048-bit+). |
| SA (Security Association) | One-directional agreement on algorithms. Two SAs per IPsec tunnel (one each way). |
2.3 โ Network Virtualization (Overlay Networks)
Overlay networks create logical network topologies on top of an existing physical (underlay) network. The underlay provides transport; the overlay provides virtualization, segmentation, and mobility.
2.3.a โ LISP (Locator/ID Separation Protocol)
Traditional IP networking ties two roles to a single address: who you are (your identity) and where you are (your location on the network). LISP separates these roles.
Figure 6 โ Traditional IP vs LISP separation of identity and location
LISP Component Roles
| Component | Role | Analogy |
|---|---|---|
| ITR (Ingress Tunnel Router) | Sends LISP Map-Request to find a remote EID’s RLOC; encapsulates packets toward remote RLOC | DNS client |
| ETR (Egress Tunnel Router) | Receives encapsulated LISP packets; decapsulates and delivers to local EIDs; registers EIDs with Map-Server | DNS server hosting the record |
| xTR | Performs both ITR and ETR roles (common in SD-Access edge nodes) | โ |
| Map-Server (MS) | Receives EID registrations from ETRs; stores EID-to-RLOC mappings | DNS server / authoritative |
| Map-Resolver (MR) | Receives Map-Requests from ITRs; queries MS or answers from cache | DNS resolver / recursive |
| PITR/PETR | Proxy ITR/ETR for interoperability with non-LISP sites | NAT proxy |
LISP Packet Flow
- Host A (EID 10.1.1.10) sends packet to Host B (EID 10.2.2.20)
- Edge node (ITR) checks its local LISP map cache โ no entry for 10.2.2.20
- ITR sends a Map-Request to Map-Resolver
- Map-Resolver forwards to Map-Server, which looks up 10.2.2.20 โ RLOC 192.168.100.2
- ITR receives Map-Reply: RLOC = 192.168.100.2, caches it
- ITR encapsulates original packet with outer IP (src RLOC โ dst RLOC) and forwards
- Remote ETR (192.168.100.2) decapsulates and delivers to Host B
2.3.b โ VXLAN (Virtual Extensible LAN)
VXLAN tunnels Layer 2 Ethernet frames over a Layer 3 IP/UDP network, extending L2 segments across routed boundaries. It overcomes the 4094 VLAN limit by using a 24-bit VNID (Virtual Network Identifier), supporting over 16 million virtual segments.
Figure 7 โ VXLAN extending L2 across an L3 underlay between VTEPs
VXLAN Frame Format
โ VTEP-B MAC
Dst: VTEP-B
Dst: 4789
8 bytes total
VM-A โ VM-B
IP Packet
Figure 8 โ VXLAN encapsulation: MAC-in-UDP, VNID identifies the virtual segment
VXLAN vs Traditional VLAN
| Attribute | 802.1Q VLAN | VXLAN |
|---|---|---|
| Identifier bits | 12-bit โ 4094 VLANs | 24-bit VNID โ 16 million segments |
| Scope | Layer 2 broadcast domain only | Stretches L2 across L3 boundaries |
| Transport | Requires L2 adjacency | Any IP routed underlay |
| STP dependency | Yes โ loops possible | No โ L3 underlay eliminates STP |
| Overhead | 4 bytes (802.1Q tag) | 50 bytes (outer headers + VXLAN header) |
| Use case | Traditional campus/DC | Data center fabric, SD-Access, cloud |
VTEP (VXLAN Tunnel Endpoint)
The VTEP performs VXLAN encapsulation and decapsulation. It can be:
- Hardware VTEP โ Cisco Nexus, Catalyst 9000 series switches with ASIC support
- Software VTEP โ VMware DVS, Open vSwitch (OVS) inside hypervisor
- MAC learning โ VTEPs learn remote endpoint MACs via data-plane flooding (multicast or ingress replication) or control-plane (BGP EVPN)
๐งช Lab Exercises
VRF-Lite โ Segmenting Departments on One Router (Topic 2.2.a)
Objective: Configure two VRFs (DEPT-A and DEPT-B) on one router. Verify routing isolation โ each department has its own routing table and cannot see the other’s routes.
Router(config)# vrf definition DEPT-A Router(config-vrf)# address-family ipv4 Router(config-vrf-af)# exit-address-family Router(config-vrf)# exit Router(config)# vrf definition DEPT-B Router(config-vrf)# address-family ipv4 Router(config-vrf-af)# exit-address-family
Router(config)# interface GigabitEthernet0/0 Router(config-if)# vrf forwarding DEPT-A Router(config-if)# ip address 10.1.0.1 255.255.255.0 Router(config-if)# no shutdown Router(config)# interface GigabitEthernet0/1 Router(config-if)# vrf forwarding DEPT-B Router(config-if)# ip address 10.2.0.1 255.255.255.0 Router(config-if)# no shutdown
! Static default route for DEPT-A toward WAN Router(config)# ip route vrf DEPT-A 0.0.0.0 0.0.0.0 10.1.0.254 ! OSPF per VRF (optional) Router(config)# router ospf 10 vrf DEPT-A Router(config-router)# network 10.1.0.0 0.0.0.255 area 0
Router# show ip route vrf DEPT-A ! Shows only DEPT-A routes Router# show ip route vrf DEPT-B ! Shows only DEPT-B routes โ cannot see DEPT-A Router# show vrf ! Name Default RD Protocols Interfaces ! DEPT-A <not set> ipv4 Gi0/0 ! DEPT-B <not set> ipv4 Gi0/1
! Ping within same VRF โ should succeed Router# ping vrf DEPT-A 10.1.0.100 ! Ping across VRFs without route leaking โ should FAIL Router# ping vrf DEPT-A 10.2.0.100 ! Output: Success rate is 0 percent โ correct isolation!
GRE Tunnel Configuration & Verification (Topic 2.2.b)
Topology: R1 (Gi0/0: 203.0.113.1) โโ Internet โโ R2 (Gi0/0: 198.51.100.1). Configure GRE tunnel to run OSPF between sites.
R1(config)# interface Tunnel0 R1(config-if)# description GRE to R2 R1(config-if)# ip address 172.16.12.1 255.255.255.0 R1(config-if)# tunnel source GigabitEthernet0/0 ! or use IP: 203.0.113.1 R1(config-if)# tunnel destination 198.51.100.1 R1(config-if)# tunnel mode gre ip ! default โ explicit is best practice R1(config-if)# no shutdown
R2(config)# interface Tunnel0 R2(config-if)# description GRE to R1 R2(config-if)# ip address 172.16.12.2 255.255.255.0 R2(config-if)# tunnel source GigabitEthernet0/0 R2(config-if)# tunnel destination 203.0.113.1 R2(config-if)# tunnel mode gre ip R2(config-if)# no shutdown
! On both R1 and R2: Router(config)# router ospf 1 Router(config-router)# network 172.16.12.0 0.0.0.255 area 0 Router(config-router)# network 192.168.1.0 0.0.0.255 area 0 ! local LAN
R1# show interface Tunnel0 ! Tunnel0 is up, line protocol is up ! Internet address is 172.16.12.1/24 ! Tunnel source 203.0.113.1 (GigabitEthernet0/0) ! Tunnel destination 198.51.100.1 ! Tunnel protocol/transport GRE/IP R1# show ip ospf neighbor ! 172.16.12.2 โ should show FULL state R1# show ip route ! O 192.168.2.0/24 [110/1001] via 172.16.12.2, Tunnel0
IPsec Site-to-Site VPN with IKEv2 (Topic 2.2.b)
Objective: Configure an IPsec VPN using IKEv2 between R1 and R2. Protect traffic between LAN1 (192.168.1.0/24) and LAN2 (192.168.2.0/24).
R1(config)# crypto ikev2 proposal PROP-1 R1(config-ikev2-proposal)# encryption aes-cbc-256 R1(config-ikev2-proposal)# integrity sha256 R1(config-ikev2-proposal)# group 14 R1(config-ikev2-proposal)# exit R1(config)# crypto ikev2 policy POL-1 R1(config-ikev2-policy)# proposal PROP-1
R1(config)# crypto ikev2 keyring KR-1 R1(config-ikev2-keyring)# peer R2 R1(config-ikev2-keyring-peer)# address 198.51.100.1 R1(config-ikev2-keyring-peer)# pre-shared-key Cisco@12345 R1(config-ikev2-keyring-peer)# exit R1(config)# crypto ikev2 profile IKEv2-PROFILE R1(config-ikev2-profile)# match identity remote address 198.51.100.1 R1(config-ikev2-profile)# authentication remote pre-share R1(config-ikev2-profile)# authentication local pre-share R1(config-ikev2-profile)# keyring local KR-1
R1(config)# crypto ipsec transform-set TS-1 esp-aes 256 esp-sha256-hmac R1(cfg-crypto-trans)# mode tunnel R1(config)# ip access-list extended VPN-TRAFFIC R1(config-ext-nacl)# permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255 R1(config)# crypto map CMAP 10 ipsec-isakmp R1(config-crypto-map)# set peer 198.51.100.1 R1(config-crypto-map)# set transform-set TS-1 R1(config-crypto-map)# set ikev2-profile IKEv2-PROFILE R1(config-crypto-map)# match address VPN-TRAFFIC R1(config)# interface GigabitEthernet0/0 R1(config-if)# crypto map CMAP
R1# show crypto ikev2 sa ! IPv4 Crypto IKEv2 SA ! Tunnel-id: 1, Status: READY(ESTAB) ! Local 203.0.113.1/500, Remote 198.51.100.1/500 R1# show crypto ipsec sa ! interface: GigabitEthernet0/0 ! inbound esp sas: spi = 0x... status = ACTIVE ! outbound esp sas: spi = 0x... status = ACTIVE R1# show crypto session ! Session status: UP-ACTIVE
GRE over IPsec โ Combining Both (Topic 2.2.b)
Objective: Add IPsec encryption to the GRE tunnel from Lab 2, using a tunnel protection profile (modern approach).
R1(config)# crypto ipsec profile GRE-IPSEC-PROFILE R1(ipsec-profile)# set transform-set TS-1 R1(ipsec-profile)# set ikev2-profile IKEv2-PROFILE
R1(config)# interface Tunnel0 R1(config-if)# tunnel protection ipsec profile GRE-IPSEC-PROFILE ! Same on R2: R2(config)# interface Tunnel0 R2(config-if)# tunnel protection ipsec profile GRE-IPSEC-PROFILE
R1# show interface Tunnel0 ! Tunnel protocol/transport GRE/IP ! Tunnel protection via IPSec (profile "GRE-IPSEC-PROFILE") R1# show crypto ipsec sa | include pkts ! #pkts encaps: 1024, #pkts encrypt: 1024 โ traffic flowing encrypted R1# ping 172.16.12.2 ! Success rate is 100 percent โ GRE tunnel works R1# show ip ospf neighbor ! Neighbor UP โ routing protocols work over encrypted GRE!
Verify VXLAN on a Cisco Nexus / Catalyst (Topic 2.3.b)
Objective: Configure a basic NVE (Network Virtualization Edge) interface and VXLAN segment on a Cisco Nexus 9000 / Catalyst 9300. Verify VTEP operation.
N9K(config)# feature nv overlay N9K(config)# feature vn-segment-vlan-based
N9K(config)# vlan 10 N9K(config-vlan)# vn-segment 10010 ! VNI 10010 maps to VLAN 10 N9K(config)# vlan 20 N9K(config-vlan)# vn-segment 10020 ! VNI 10020 maps to VLAN 20
N9K(config)# interface nve1 N9K(config-if-nve)# no shutdown N9K(config-if-nve)# source-interface loopback0 ! VTEP source IP N9K(config-if-nve)# member vni 10010 N9K(config-if-nve-vni)# ingress-replication protocol bgp N9K(config-if-nve)# member vni 10020 N9K(config-if-nve-vni)# ingress-replication protocol bgp
N9K# show nve peers ! Interface VNI Peer-IP State LearnType ! nve1 10010 192.168.100.2 Up CP (BGP EVPN) ! nve1 10020 192.168.100.2 Up CP (BGP EVPN) N9K# show nve vni ! Codes: CP - Control Plane DP - Data Plane UC - Unconfigured ! Interface VNI Multicast-group State Mode Type ! nve1 10010 N/A Up CP L2 ! nve1 10020 N/A Up CP L2 N9K# show vxlan ! Vlan VNI Status ! 10 10010 Enabled ! 20 10020 Enabled
Check Your Understanding
Twenty questions on this section. Each answer is explained as you go.
