3.2 Data Path Virtualization: VRF-Lite, GRE Tunneling, and IPsec VPN Fundamentals

Data Path Virtualization: VRF-Lite, GRE Tunneling, and IPsec VPN Fundamentals

Enterprise data path virtualization isolates logical communication channels across shared physical network infrastructure. By virtualizing routing instances and encapsulating packets across overlay tunnels, network administrators can enforce multi-tenant segmentation, transport diverse protocols across non-contiguous networks, and secure enterprise traffic over untrusted transit networks.

Virtual Routing and Forwarding Lite (VRF-Lite)

Traditional enterprise routers maintain a single global Routing Information Base (RIB) and Forwarding Information Base (FIB). In this shared model, all interfaces and routing protocols reside in the same routing domain, prohibiting duplicate IP addresses and preventing administrative separation.

Virtual Routing and Forwarding (VRF) virtualizes the router's control and forwarding planes, enabling a single physical router to host multiple independent virtual routing instances:

• Independent Tables: Each VRF maintains a dedicated RIB, FIB, and ARP table. Routes learned in one VRF are completely isolated from all other VRFs by default.
• Overlapping Address Spaces: Multiple tenants or departments can utilize identical IP subnets (e.g., 10.1.1.0/24) without collision, because forwarding lookups execute strictly within the tenant's private forwarding table.
• VRF-Lite Architecture: When VRF is deployed without Multiprotocol BGP (MP-BGP) and MPLS label switching across the core, it is termed VRF-Lite. In VRF-Lite deployments, tenant isolation across intermediate switches is preserved by binding each VRF to dedicated 802.1Q VLAN subinterfaces.

! VRF-Lite configuration on Cisco IOS-XE
vrf definition TENANT_RED
 rd 65000:10
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet0/0/1.10
 encapsulation dot1Q 10
 vrf forwarding TENANT_RED
 ip address 10.1.1.1 255.255.255.0

Generic Routing Encapsulation (GRE) Tunneling

Generic Routing Encapsulation (GRE), defined in RFC 2784 and RFC 1701, is an unencrypted tunneling protocol that encapsulates arbitrary network-layer passenger protocols inside an IP delivery header.

Encapsulation Mechanics and Packet Format

GRE establishes a virtual point-to-point connection between two routers across an intermediate transit network:

• Passenger Protocol: The original packet being encapsulated (e.g., IPv4, IPv6, or routing protocol traffic such as OSPF hello packets).
• Carrier Protocol (GRE Header): A 4-byte header containing flags, a Protocol Type field (e.g., 0x0800 for IPv4), and optional checksum or key fields.
• Delivery Protocol (Outer IP Header): A 20-byte IPv4 header using IP protocol number 47, addressed from the tunnel source IP to the tunnel destination IP.

Total GRE encapsulation overhead is 24 bytes (20 bytes outer IP + 4 bytes GRE header). Because GRE supports multicast and broadcast traffic, dynamic routing protocols (OSPF, EIGRP, BGP) can establish adjacencies directly across GRE tunnels. However, GRE provides no native data confidentiality or encryption.

! Point-to-point GRE tunnel configuration with keepalives
interface Tunnel0
 ip address 172.16.1.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel destination 198.51.100.2
 keepalive 10 3

Keepalives and Recursive Routing Avoidance

• GRE Keepalives: A GRE interface remains up/up as long as a route to the destination exists. Configuring keepalive [seconds] [retries] instructs the router to send periodic inner-encapsulated probes to detect dead peers or unidirectional path failures.
• Recursive Routing Avoidance: A recursive routing error (%TUN-5-RECURDOWN) occurs when the routing protocol learns a route to the tunnel destination through the tunnel interface itself. The router disables the tunnel to prevent an infinite forwarding loop. This is prevented by filtering tunnel destination advertisements or using separate underlay static routes.

IPsec VPN Architecture: Security Services, Protocols, and Modes

IPsec (IP Security) provides cryptographic protection at the network layer:

• Security Services: Confidentiality (AES encryption), Data Integrity (HMAC-SHA hashing), Origin Authentication (pre-shared keys or digital certificates), and Anti-Replay protection (sequence numbers).
• AH vs. ESP:
  • Authentication Header (AH, IP Protocol 51): Provides data integrity and origin authentication, but no data confidentiality. Because AH includes the outer IP header in its hash, it fails across Network Address Translation (NAT) devices.
  • Encapsulating Security Payload (ESP, IP Protocol 50): Provides confidentiality, integrity, and origin authentication. ESP supports NAT traversal (NAT-T) by encapsulating ESP inside UDP port 4500.
• Transport vs. Tunnel Mode:
  • Transport Mode: Protects only the payload and Layer 4 header, preserving the original IP header. Commonly used for host-to-host communication or GRE over IPsec.
  • Tunnel Mode: Encrypts the entire original IP packet and adds a new outer IP header. This is the enterprise default for site-to-site VPNs.

Tunnel Header Comparison

Internet Key Exchange: IKEv1 vs. IKEv2

Internet Key Exchange (IKE) automates mutual authentication and Security Association (SA) parameter negotiation:

• IKEv1: Splits negotiation into two phases. Phase 1 (ISAKMP SA) negotiates management tunnels using Main Mode (6 packets, identity protected) or Aggressive Mode (3 packets, cleartext identities). Phase 2 (Quick Mode, 3 packets) negotiates IPsec transform sets. Establishing an active tunnel requires 9 messages in Main Mode.
• IKEv2 (RFC 7296): Replaces IKEv1 with a streamlined 4-message exchange. IKE_SA_INIT (2 messages) negotiates cryptographic proposals and Diffie-Hellman keys. IKE_AUTH (2 messages) authenticates identities and creates the initial CHILD_SA for data forwarding. IKEv2 includes native NAT-T, asymmetric authentication, and anti-DoS cookies.

IKE Protocol Comparison

Crypto Maps vs. Virtual Tunnel Interfaces (VTI)

Traditional policy-based IPsec VPNs used crypto maps bound to physical interfaces. Crypto maps evaluate access lists to identify interesting traffic, but they do not create a routable logical interface, preventing direct dynamic routing without GRE.

Virtual Tunnel Interfaces (VTI) provide modern route-based IPsec:

• Instantiates a routable interface TunnelX operating in IPsec mode (tunnel mode ipsec ipv4).
• Natively transports dynamic routing protocols (OSPF, EIGRP, BGP) over IPsec without GRE overhead.
• Simplifies routing policies, firewall zone integration, and interface QoS.

! IKEv2 Static Virtual Tunnel Interface (SVTI) configuration
crypto ikev2 proposal IKE2_PROP
 encryption aes-gcm-256
 prf sha256
 group 19
!
crypto ikev2 policy IKE2_POL
 proposal IKE2_PROP
!
crypto ikev2 keyring IKE2_KEYRING
 peer BRANCH
  address 198.51.100.2
  pre-shared-key Str0ngSharedKey
!
crypto ikev2 profile IKE2_PROF
 match identity remote address 198.51.100.2 255.255.255.255
 identity local address 203.0.113.1
 authentication remote pre-share
 authentication local pre-share
 keyring local IKE2_KEYRING
!
crypto ipsec profile VTI_IPSEC_PROFILE
 set ikev2-profile IKE2_PROF
!
interface Tunnel1
 ip address 10.254.1.1 255.255.255.252
 tunnel source GigabitEthernet0/0/0
 tunnel destination 198.51.100.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI_IPSEC_PROFILE
 ip tcp adjust-mss 1360

MTU, Fragmentation, and TCP MSS Clamping

Encapsulating packets inside GRE (24 bytes) and IPsec ESP (50–56 bytes) expands a standard 1500-byte packet to 1574–1580 bytes. If intermediate transit networks cannot accommodate jumbo frames and packets have the Don't Fragment (DF) bit set, routers drop them and return ICMP Type 3 Code 4. If firewalls block ICMP, path MTU discovery fails, causing application drops.

To prevent fragmentation and black holes, routers enforce TCP MSS Clamping:

• The router inspects TCP SYN packets traversing the tunnel and rewrites the Maximum Segment Size using ip tcp adjust-mss 1360.
• Setting MSS to 1360 ensures that TCP segments plus IP, TCP, and IPsec/GRE headers remain under the standard 1500-byte physical MTU.

Configuring and Verifying the Data Path

Topic 2.2 says configure and verify, so you must know the commands that prove each technology works.

VRF-Lite routing and verification

A VRF needs its own routing information. With OSPF, each VRF runs its own process:

router ospf 10 vrf TENANT_RED
 network 10.1.1.0 0.0.0.255 area 0

GRE and IPsec verification

If #pkts encaps rises but #pkts decaps stays at zero, packets are leaving but nothing is coming back. Check the peer's profile and keys, and look for a firewall blocking ESP (IP protocol 50) or UDP 500 and 4500.