2.2Configuring and verifying data path virtualization (VRF, GRE, and IPsec)

If the previous section was "virtualizing the box," this one is virtualizing the path itself. Even with one physical link and one physical router, you can overlay multiple independent routing spaces. VRF gives one device several routing tables so routes are fully separated per customer or department, while GRE builds a logical link that behaves "as if two points were directly connected," regardless of the network in between. But GRE has no encryption, so crossing a public network requires combining it with IPsec. What is tested here is not definitions but which to choose for which requirement and where to look when a tunnel will not come up or keeps flapping.

2.2.1Route separation with VRF

• VRF (Virtual Routing and Forwarding) gives one router/L3 switch multiple independent routing (and forwarding) tables. Because each VRF has a completely separate route space, different VRFs can coexist even with overlapping IP address space (e.g., both using 10.1.1.0/24). Its biggest advantage is separating customer, departmental, or management traffic without dedicating separate hardware.
• The key to configuration is the order: define the VRF, place the interface into the VRF, then assign the IP in that VRF. Define it with vrf definition CUST_A (enabling the address family with address-family ipv4), then under the interface enter vrf forwarding CUST_A before configuring ip address .... Placing an interface into a VRF clears its existing IP address, so getting the order wrong drops existing connectivity.
• Verification must also name the VRF. The default (global) table shown by show ip route does not list VRF routes, so use show ip route vrf CUST_A. Reachability checks likewise need the VRF: ping vrf CUST_A 10.1.1.1, traceroute vrf CUST_A .... List memberships with show vrf (or per interface with show ip vrf interfaces).

2.2.2Configuring and verifying GRE tunnels

• GRE (Generic Routing Encapsulation) wraps an arbitrary L3 protocol in a new IP header, making the intervening network look like a one-hop logical link. Its advantage is that it can carry traffic IPsec alone cannot, such as multicast and IGPs (OSPF/EIGRP). But it performs encapsulation only and no encryption whatsoever—the payload travels in cleartext.
• Configure interface tunnel 0 with tunnel source (your real interface/IP), tunnel destination (the peer's reachable real IP), and an inside ip address. The default tunnel mode is GRE over IP (tunnel mode gre ip). Verify with show interfaces tunnel 0, checking the line protocol state and input/output counters.
• GRE has three classic failures. (1) The tunnel destination is unreachable over the real network (no route/reachability to tunnel destination), so the line protocol goes down. (2) Recursive routing—the route to the tunnel destination itself is learned through the tunnel, and the tunnel flaps with %TUN-5-RECURDOWN; the fix is to not advertise the tunnel destination inside the tunnel (or reach it via a static/alternate path). (3) MTU/fragmentation—the 24-byte GRE header pushes past the path MTU and large packets with the DF bit are dropped; mitigate with ip mtu 1400 or ip tcp adjust-mss 1360.

2.2.3IPsec and GRE over IPsec

• IPsec is a framework providing confidentiality (encryption), integrity, authentication, and anti-replay at the IP layer. IKE performs key exchange and establishes SAs (security associations), and ESP encrypts the payload (AH authenticates only and does not encrypt). But plain IPsec (the classic crypto map approach) targets mainly unicast IP traffic and cannot natively carry multicast or IGP hellos.
• So in practice you use GRE over IPsec—wrap in GRE, then encrypt with IPsec. GRE makes multicast/IGPs carriable while IPsec supplies confidentiality, yielding an encrypted WAN over which dynamic routing runs. The current standard configuration keeps tunnel mode gre ip on the tunnel interface and applies an IPsec profile with tunnel protection ipsec profile <name>.
• Verify layer by layer. Tunnel up/down: show interfaces tunnel 0. IKE phase 1: show crypto isakmp sa (for IKEv2, show crypto ikev2 sa). Phase 2 and actual data encryption: show crypto ipsec sa, checking whether the encaps/decaps counters increment in both directions. If only one direction increments, suspect a blocked return path or a policy mismatch on the peer (transform set/cipher suite, or the definition of interesting traffic).

You build a new WAN linking headquarters and a branch across the internet, running OSPF over a GRE tunnel. The tunnel comes up once and OSPF adjacency forms, but every few tens of seconds the tunnel bounces down/up, and the log repeats %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing. Drifting to external causes—"the circuit is poor," "an ISP outage"—means skipping past a message that states the cause outright. Recursive routing is the state where the route to the tunnel destination (the peer's real IP named in tunnel destination) has been learned through that very tunnel. The direct trigger here is that the OSPF network statements were too broad, so the network of the outside-facing interface/real IP used to terminate the tunnel was itself advertised into OSPF. The peer then learns "that destination is reachable via the tunnel," and building the tunnel requires going through the tunnel—a self-reference. IOS detects this and temporarily disables the tunnel, producing a flap loop: down, route disappears, path reverts to the real network, up, learned again. The remedy is clear: reach the tunnel destination over a path that is not learned inside the tunnel—a static route over the real network, or a separate IGP/provider route. Concretely, remove the outside-facing interface network from OSPF advertisement (refine the network statements; note that marking the interface passive-interface is not enough—you must stop advertising the prefix itself), and add an explicit static route to the tunnel destination if needed. For isolation, the decisive step is to run show ip route <tunnel destination IP> and check whether its outgoing interface is Tunnel0; if it points at Tunnel0, recursive routing is confirmed. A related problem often accompanies this design: MTU-driven symptoms, which look different—the tunnel stays stably up while only large packets fail (small pings succeed but file transfers or HTTPS hang). The practical heart of this section is being able to split on symptom: "the tunnel drops" points to recursive routing or destination reachability, while "the tunnel is up but only large traffic fails" points to MTU/MSS.

2.2.4Section summary

• VRF holds multiple independent routing tables in one device, so different VRFs coexist even with overlapping addresses. Configure in the order vrf forwarding then ip address, and verify with show ip route vrf X / ping vrf X
• GRE is encapsulation only (no encryption) yet carries multicast/IGPs, while IPsec encrypts but cannot carry multicast alone; combine them as GRE over IPsec
• Isolate tunnel faults by symptom: flapping with %TUN-5-RECURDOWN = recursive routing (confirmed if the outgoing interface in show ip route <destination> is the tunnel), and stays up but only large traffic fails = MTU/MSS (ip mtu / ip tcp adjust-mss)