Lab brief & addressing
Topology Open full size ↗
The Mission
One physical router, two customers who must never see each other — and, to make it interesting, both customers use the exact same IP address for their most important host. Your job is to carve R1 into two independent routers using VRF-Lite: two routing tables, two ARP tables, two FIBs, on one box. Then prove the separation with pings that succeed in one VRF and fail in the other — to the same destination address.
Along the way you will hit, on purpose, the two mistakes that account for most real-world VRF outages: the interface IP that silently vanishes when you assign a VRF, and the VRF that refuses to carry IPv4 at all because one sub-command is missing.
You'll be able to
- Define a VRF with the modern
vrf definition+address-family ipv4syntax and place interfaces into it. - Explain why
vrf forwardingdeletes the interface's IP address — and re-apply it without panic. - Read per-VRF state:
show ip route vrf,show arp vrf,show ip cef vrf, and per-VRFping. - Prove that overlapping address space in two VRFs is legal and fully functional.
- Leak a single prefix between VRFs with an interface-qualified static route — a controlled hole in the wall.
- Recognise the
Enable IPv4 on that VRF firsterror and know exactly which line is missing.
Before you start
- Finished C06 (static routes) and ideally E09 — VRFs are the other half of ENCOR's virtualization domain: GRE virtualizes the path, VRFs virtualize the router.
- Three IOSv routers: R1 is the provider-edge (PE) box you will slice up; R2 and R3 are plain customer routers (CE) that know nothing about VRFs.
Addressing plan
| Device | Interface | Address |
|---|---|---|
| R1 (PE) | Gi0/0→R2 (VRF RED) / Gi0/1→R3 (VRF BLUE) | 10.1.12.1/30 · 10.1.13.1/30 |
| R2 (CE-RED) | Gi0/0 / Lo0 / Lo1 | 10.1.12.2/30 · 172.16.1.1/32 · 192.168.2.2/32 |
| R3 (CE-BLUE) | Gi0/0 / Lo0 / Lo1 | 10.1.13.2/30 · 172.16.1.1/32 · 192.168.3.3/32 |
The one idea behind this lab
A router is, at heart, three data structures: a routing table (RIB), an ARP table, and a forwarding table (FIB/CEF). A VRF — Virtual Routing and Forwarding instance — is simply a second, independent copy of all three, plus a list of which interfaces belong to it. A packet arriving on a RED interface is looked up only in RED's tables; BLUE's routes might as well be on another planet.
Mgmt-vrf on every modern switch), and multi-tenant data centres. And because each VRF is a separate address universe, two VRFs can hold overlapping — even identical — prefixes. That is how every cloud provider on earth gives millions of customers the same 10.0.0.0/8.The lab drives one router, R1, and slices it into RED and BLUE. The two CE routers are ordinary routers — a customer never has to know they're in a VRF.
It's the same carve-up you did in C04 with router-on-a-stick subinterfaces — one box, several logically separate tenants — except there the physical port was sliced by dot1Q tag, and here the routing table itself is sliced by VRF.
See & Do Slice one router into two
Plain addressing first — the "before" picture
Configure the CEs like any router (R2 shown; R3 mirrors it on 10.1.13.x / Lo0 172.16.1.1 / Lo1 192.168.3.3):
R2(config)# interface Gi0/0 R2(config-if)# ip address 10.1.12.2 255.255.255.252 R2(config-if)# no shutdown R2(config-if)# interface Loopback0 R2(config-if)# ip address 172.16.1.1 255.255.255.255 R2(config-if)# interface Loopback1 R2(config-if)# ip address 192.168.2.2 255.255.255.255 R2(config-if)# exit R2(config)# ip route 0.0.0.0 0.0.0.0 10.1.12.1
On R1, address both customer-facing interfaces in the global table for now — deliberately, so you can watch what the VRF does to them in a moment:
R1# show ip interface brief | include Gigabit
GigabitEthernet0/0 10.1.12.1 YES manual up up GigabitEthernet0/1 10.1.13.1 YES manual up up GigabitEthernet0/2 unassigned YES unset administratively down down GigabitEthernet0/3 unassigned YES unset administratively down down
Define the two VRFs
R1(config)# vrf definition RED R1(config-vrf)# address-family ipv4 ! without this line the VRF cannot carry IPv4 at all R1(config-vrf-af)# exit-address-family R1(config-vrf)# vrf definition BLUE R1(config-vrf)# address-family ipv4 R1(config-vrf-af)# exit-address-family
Put an interface into a VRF — and watch the famous side effect
R1(config)# interface Gi0/0 R1(config-if)# vrf forwarding RED
% Interface GigabitEthernet0/0 IPv4 disabled and address(es) removed due to enabling VRF RED
Read that line again — the router just deleted the IP address you configured in step 1. Confirm it:
R1# show ip interface brief | include Gigabit
GigabitEthernet0/0 unassigned YES manual up up <-- IP is gone
GigabitEthernet0/1 10.1.13.1 YES manual up up
vrf forwarding is an outage unless you immediately re-apply the IP. Order matters: VRF first, IP second.Re-apply the address, then do Gi0/1 in the correct order:
R1(config-if)# ip address 10.1.12.1 255.255.255.252 R1(config-if)# interface Gi0/1 R1(config-if)# vrf forwarding BLUE R1(config-if)# ip address 10.1.13.1 255.255.255.252
Read the sliced router
R1# show vrf
Name Default RD Protocols Interfaces BLUE <not set> ipv4 Gi0/1 RED <not set> ipv4 Gi0/0
Now the punchline. The global routing table — the one every show ip route you have ever typed looked at — is empty, because both interfaces left it:
R1# show ip route
Gateway of last resort is not set
<-- nothing. No connected routes. They moved out. -->
Each VRF has its own connected routes:
R1# show ip route vrf RED
Routing Table: RED
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.12.0/30 is directly connected, GigabitEthernet0/0
L 10.1.12.1/32 is directly connected, GigabitEthernet0/0
R1# show ip route vrf BLUE
Routing Table: BLUE
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.13.0/30 is directly connected, GigabitEthernet0/1
L 10.1.13.1/32 is directly connected, GigabitEthernet0/1
The same route, twice — overlapping prefixes
Point each VRF at "its" 172.16.1.1. The identical prefix, two different next-hops, two different tables — and zero conflict:
R1(config)# ip route vrf RED 172.16.1.1 255.255.255.255 10.1.12.2 R1(config)# ip route vrf BLUE 172.16.1.1 255.255.255.255 10.1.13.2
R1# show ip route vrf RED static 172.16.0.0/32 is subnetted, 1 subnets S 172.16.1.1 [1/0] via 10.1.12.2 R1# show ip route vrf BLUE static 172.16.0.0/32 is subnetted, 1 subnets S 172.16.1.1 [1/0] via 10.1.13.2
Prove it with pings — same address, three different answers
R1# ping 172.16.1.1 ! global table -- which is empty
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
R1# ping vrf RED 172.16.1.1
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/12/20 ms <-- that was R2
R1# ping vrf BLUE 172.16.1.1
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/10/19 ms <-- that was R3
One address, one router, and the answer depends entirely on which universe you asked from. The separation goes all the way down — ARP and CEF are per-VRF too:
R1# show arp vrf RED Protocol Address Age (min) Hardware Addr Type Interface Internet 10.1.12.1 - 0ccc.746e.0000 ARPA GigabitEthernet0/0 Internet 10.1.12.2 1 0c51.f6db.0000 ARPA GigabitEthernet0/0 R1# show ip cef vrf RED 172.16.1.1 172.16.1.1/32 nexthop 10.1.12.2 GigabitEthernet0/0 R1# show ip cef vrf BLUE 172.16.1.1 172.16.1.1/32 nexthop 10.1.13.2 GigabitEthernet0/1
RIB, ARP, FIB — all three data structures duplicated, all three consistent. R1 is now genuinely two routers.
Now You Prove the isolation from the customer's side
Everything so far was measured on the PE. A skeptical customer wants proof from their router. From R2 (in RED), try to reach R3's link address 10.1.13.2 — a real, live address that is up right now, one hop past R1, but in BLUE. Predict the ping result before you run it: timeout dots (.....) or unreachables (UUUUU)? Then explain the difference.
What happens, and why it's a U and not a dot
R2# ping 10.1.13.2
Sending 5, 100-byte ICMP Echos to 10.1.13.2, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
U means an ICMP destination unreachable came back. R2 sent the packet to its default gateway 10.1.12.1; R1 looked the destination up in RED's table only, found nothing, and actively said "no such destination." A trace shows exactly where the world ends:
R2# traceroute 10.1.13.1 timeout 1 1 10.1.12.1 31 msec 7 msec 18 msec 2 10.1.12.1 !H !H !H <-- !H = host unreachable, from R1 itself
To the RED customer, BLUE's addresses do not exist — not filtered, not firewalled, simply absent from the only routing table their packets are allowed to consult. That's the difference between segmentation by ACL (a lookup that refuses) and segmentation by VRF (a lookup that can't find).
Solo Challenge A controlled hole in the wall — route leaking
Scenario: The two customers stay isolated — but they buy a shared service from each other: RED must reach R3's service loopback 192.168.3.3/32, and BLUE must reach R2's 192.168.2.2/32. Nothing else may cross. (Note you could never leak the 172.16.1.1s — they collide. This is why shared services always live in non-overlapping space.)
Rules: static routes only, on R1 only. The CEs already have defaults. Success = R2 pings 192.168.3.3 sourced from Lo1, 100%.
Hint: the trick is naming the exit interface
A normal ip route vrf RED ... 10.1.13.2 fails, because RED's table can't resolve a BLUE next-hop. But if you name the egress interface, IOS resolves the next-hop's adjacency in the VRF that owns that interface: ip route vrf RED <dest> <mask> GigabitEthernet0/1 10.1.13.2. Remember traffic needs a leak in both directions or the replies die.
Check your work (open only after you've done it)
R1(config)# ip route vrf RED 192.168.3.3 255.255.255.255 GigabitEthernet0/1 10.1.13.2 R1(config)# ip route vrf BLUE 192.168.2.2 255.255.255.255 GigabitEthernet0/0 10.1.12.2
R1# show ip route vrf RED 192.168.3.3 Routing Table: RED Routing entry for 192.168.3.3/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.1.13.2, via GigabitEthernet0/1 <-- a RED route whose exit interface lives in BLUE
R2# ping 192.168.3.3 source Loopback1
Packet sent with a source address of 192.168.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 6/8/11 ms
Exactly one prefix crosses each way; 172.16.1.1 and everything else stays sealed. In production this same job is usually done with route-targets and MP-BGP, but the interface-qualified static is the VRF-Lite classic — and an exam favourite.
Break & Fix The VRF that refuses to carry IPv4
A colleague adds a third customer in a hurry — defines the VRF, moves the interface in, and then the IP address won't stick:
R1(config)# vrf definition TEST R1(config-vrf)# exit ! left immediately -- spot the missing line R1(config)# interface Gi0/2 R1(config-if)# vrf forwarding TEST R1(config-if)# ip address 192.0.2.1 255.255.255.0
%GigabitEthernet0/2 is linked to a VRF. Enable IPv4 on that VRF first.
vrf definition creates an empty shell; unlike the legacy ip vrf command, it carries no address families until you add them. No address-family ipv4, no IPv4 — on any interface in that VRF. In a real change window this reads as "the new customer port won't take config" and burns half an hour, because the person staring at the interface never thinks to look at the VRF definition.The fix is the one missing line, and the address then applies normally:
R1(config)# vrf definition TEST R1(config-vrf)# address-family ipv4 R1(config-vrf-af)# exit-address-family R1(config)# interface Gi0/2 R1(config-if)# ip address 192.0.2.1 255.255.255.0 ! accepted now
Done check
Close this lab when every row is true and you can explain it without notes:
| Run on | Proof you want |
|---|---|
R1 show vrf | RED → Gi0/0 and BLUE → Gi0/1, protocol ipv4 on both |
R1 show ip route vs show ip route vrf RED | global table empty; each VRF holds only its own C/L/S routes |
R1 ping vrf RED 172.16.1.1 and ping vrf BLUE 172.16.1.1 | both 100% — same address, different responders (check show arp vrf) |
R2 ping 10.1.13.2 | UUUUU — unreachable from R1, not a timeout |
R2 ping 192.168.3.3 source Lo1 | 100% — the leaked prefix works both directions; nothing else crosses |