VRF-Lite — Virtual Routing & Forwarding

A router normally has one routing table — the global table — shared by every interface and every routing process on the device. VRF (Virtual Routing and Forwarding) breaks that assumption. It allows a single physical router to maintain multiple, completely independent routing tables simultaneously, each invisible to the others. Traffic in one VRF cannot leak into another VRF unless explicitly configured to do so — the isolation is enforced in hardware at the forwarding plane, not just in software policy.

VRF-Lite is the standalone version of VRF — it provides routing table isolation on a single router without requiring MPLS labels. Full MPLS VPN (used by service providers to carry multiple customers across a shared backbone) builds on top of VRF, but VRF-Lite works entirely in plain IP environments. It is the technology behind multi-tenant edge routers, out-of-band management networks, overlapping IP address spaces, and security-zone separation on a single device.

Before starting, ensure you are comfortable reading the IP routing table from show ip route and understand interface assignment from Basic Interface Configuration. For context on how routing decisions are made between competing sources, see Administrative Distance and Default Routes. For static route syntax used throughout this lab, see Static Route Configuration. If you plan to run OSPF within a VRF, review OSPF Single-Area Configuration first — per-VRF OSPF uses slightly different syntax covered in Step 5 of this lab.

1. VRF-Lite — Core Concepts

What a VRF Actually Creates

When you create a VRF on a Cisco router, IOS instantiates three separate data structures for that VRF — completely independent from the global table and from every other VRF:

  Without VRF (default):
  ┌─────────────────────────────────────────────────────────────┐
  │  Single global routing table                                │
  │  All interfaces share the same table                        │
  │  Gi0/0 (10.0.0.1)  Gi0/1 (10.0.1.1)  Gi0/2 (10.0.2.1)    │
  │  10.0.0.0/24 → Gi0/0     10.0.1.0/24 → Gi0/1              │
  └─────────────────────────────────────────────────────────────┘

  With VRF-Lite (two VRFs + global):
  ┌─────────────────────┐  ┌─────────────────────┐  ┌──────────────────┐
  │  VRF: CUSTOMER-A    │  │  VRF: CUSTOMER-B    │  │  Global Table    │
  │  Gi0/0: 10.0.0.1    │  │  Gi0/1: 10.0.0.1   │  │  Gi0/2: 1.1.1.1 │
  │  10.0.0.0/24 →Gi0/0 │  │  10.0.0.0/24 →Gi0/1│  │  (management)   │
  │  Routing table A    │  │  Routing table B    │  │                  │
  └─────────────────────┘  └─────────────────────┘  └──────────────────┘
       ↕ fully isolated          ↕ fully isolated
       Cannot see B or global    Cannot see A or global

  Each VRF has its own:
  • Routing Information Base (RIB) — the routing table
  • Forwarding Information Base (FIB) — the forwarding table (CEF)
  • ARP table — independent Layer 2 to Layer 3 mappings

VRF-Lite vs Full MPLS VPN

Feature	VRF-Lite	MPLS L3VPN (Full VRF)
MPLS required	No — plain IP forwarding	Yes — MPLS labels carry VRF context across the core
Scale	Single router or a chain of routers with sub-interfaces	Service provider backbone — hundreds of customers across shared core
Route distribution	Static or per-VRF IGP (OSPF, EIGRP, RIP) between PE and CE	MP-BGP with Route Distinguishers (RD) and Route Targets (RT)
Route Distinguisher	Optional — can be configured but not used for forwarding	Mandatory — makes routes globally unique in the BGP table
Typical use case	Enterprise multi-tenant, OOB management, security zones, overlapping IPs on a single router	ISP/carrier backbone — multiple customer VPNs over shared infrastructure

Key Use Cases for VRF-Lite

Use Case	Problem Solved	Example
Overlapping IP addresses	Two customers or departments use the same IP range — normally a conflict on a shared router	Customer-A: 10.0.0.0/24, Customer-B: 10.0.0.0/24 — both hosted on the same router in separate VRFs
Traffic isolation	Finance, HR, and IT must not be able to route to each other — policy requires Layer 3 separation	Each department in its own VRF — inter-VRF communication only possible via a firewall
Out-of-band management	Management traffic (SSH, SNMP, syslog) must travel on a completely separate path from production traffic	Dedicated MGMT VRF with its own default route to a management-only network
Multi-tenant hosting	A managed service provider runs routing for multiple customers on shared hardware	Each customer gets its own VRF — their routing policies, static routes, and IGP instances are fully isolated

VRF Configuration Flow

  Three steps — always in this order:

  Step 1: Define the VRF
          ip vrf CUSTOMER-A
           description Customer A routing domain

  Step 2: Assign an interface to the VRF
          interface GigabitEthernet0/0
           ip vrf forwarding CUSTOMER-A   ← WARNING: clears the IP address!
           ip address 10.0.0.1 255.255.255.0

  Step 3: Add routes (static or dynamic per-VRF)
          ip route vrf CUSTOMER-A 0.0.0.0 0.0.0.0 203.0.113.1

  CRITICAL: ip vrf forwarding MUST come before ip address on the interface.
  Assigning vrf forwarding removes any existing IP address from the interface.
  Always re-enter the ip address command after vrf forwarding.

2. Lab Topology & Scenario

This lab uses a single router — NetsTuts_R1 — acting as a multi-tenant edge device for two customers. Both customers deliberately use the same IP address space (10.0.0.0/24) to demonstrate VRF's ability to handle overlapping addresses. A third interface remains in the global routing table for out-of-band management. A second router (NetsTuts_R2) serves as a simple reachability target to verify end-to-end isolation.

                         NetsTuts_R1
              ┌──────────────────────────────────────────┐
              │                                          │
  [CustA-PC]──┤Gi0/0  VRF: CUSTOMER-A                   │
  10.0.0.10   │10.0.0.1/24                               │
              │                                 Gi0/2    ├──── NetsTuts_R2
  [CustB-PC]──┤Gi0/1  VRF: CUSTOMER-B          (CUST-A) │     203.0.113.2
  10.0.0.20   │10.0.0.1/24  ← same IP as A!    203.0.113.1/30
              │                                          │
  [Mgmt-PC] ──┤Gi0/3  Global Table              Gi0/4   ├──── NetsTuts_R2
  192.168.99.10│192.168.99.1/24                 (CUST-B) │     10.1.1.2
              │                                10.1.1.1/30
              └──────────────────────────────────────────┘

  VRF Summary:
  ┌──────────────────┬──────────┬─────────────────────────────────┐
  │ VRF Name         │ Interface│ Purpose                         │
  ├──────────────────┼──────────┼─────────────────────────────────┤
  │ CUSTOMER-A       │ Gi0/0    │ Customer A LAN (10.0.0.0/24)    │
  │ CUSTOMER-A       │ Gi0/2    │ Customer A WAN to R2            │
  │ CUSTOMER-B       │ Gi0/1    │ Customer B LAN (10.0.0.0/24)    │
  │ CUSTOMER-B       │ Gi0/4    │ Customer B WAN to R2            │
  │ Global           │ Gi0/3    │ Out-of-band management          │
  └──────────────────┴──────────┴─────────────────────────────────┘

  Objectives:
  1. Create VRFs CUSTOMER-A and CUSTOMER-B
  2. Assign interfaces — note identical 10.0.0.0/24 in both VRFs
  3. Add static routes within each VRF
  4. Verify routing table isolation with show ip route vrf
  5. Configure per-VRF OSPF (Step 5 — advanced)
  6. Confirm VRF-aware ping proves isolation

Interface	VRF	IP Address	Role
Gi0/0	CUSTOMER-A	10.0.0.1/24	Customer A LAN gateway
Gi0/1	CUSTOMER-B	10.0.0.1/24	Customer B LAN gateway (same IP — demonstrates overlap)
Gi0/2	CUSTOMER-A	203.0.113.1/30	Customer A WAN link to R2
Gi0/3	Global	192.168.99.1/24	Out-of-band management (global table)
Gi0/4	CUSTOMER-B	10.1.1.1/30	Customer B WAN link to R2

3. Step 1 — Create the VRF Instances

VRFs are defined in global configuration mode with the ip vrf command. At this stage the VRF is just a named container — no interfaces are assigned yet and no routing table entries exist:

NetsTuts_R1>en
NetsTuts_R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

! ── Define VRF for Customer A ────────────────────────────
NetsTuts_R1(config)#ip vrf CUSTOMER-A
NetsTuts_R1(config-vrf)#description Customer A — isolated routing domain
NetsTuts_R1(config-vrf)#exit

! ── Define VRF for Customer B ────────────────────────────
NetsTuts_R1(config)#ip vrf CUSTOMER-B
NetsTuts_R1(config-vrf)#description Customer B — isolated routing domain
NetsTuts_R1(config-vrf)#exit

The ip vrf [name] command creates the VRF and enters VRF configuration mode. The name is case-sensitive and local to the router — CUSTOMER-A and customer-a are two different VRFs. At this point IOS has allocated a separate RIB and FIB for each VRF but they are empty. The global routing table is untouched.

Verify VRFs Exist

NetsTuts_R1#show ip vrf
  Name                             Default RD          Interfaces
  CUSTOMER-A                       <not set>
  CUSTOMER-B                       <not set>

Both VRFs are created with no Route Distinguisher (RD) and no interfaces assigned yet. The RD column shows <not set> — in VRF-Lite, the RD is optional (it is mandatory in full MPLS VPN to make routes globally unique in MP-BGP). For this lab the RD will remain unset since we are not using MPLS.

4. Step 2 — Assign Interfaces to VRFs

Interfaces are assigned to a VRF using the ip vrf forwarding command inside interface configuration mode. This command must be entered before the IP address — assigning a VRF clears any existing IP address on the interface:

Customer A Interfaces

! ── Customer A LAN interface ─────────────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#description CustA-LAN
NetsTuts_R1(config-if)#ip vrf forwarding CUSTOMER-A
! ── WARNING: Any existing IP address is now removed ──────
NetsTuts_R1(config-if)#ip address 10.0.0.1 255.255.255.0
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

! ── Customer A WAN interface (to R2) ─────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/2
NetsTuts_R1(config-if)#description CustA-WAN-to-R2
NetsTuts_R1(config-if)#ip vrf forwarding CUSTOMER-A
NetsTuts_R1(config-if)#ip address 203.0.113.1 255.255.255.252
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

Customer B Interfaces

! ── Customer B LAN interface ─────────────────────────────
! ── Note: same IP as Customer A — this is valid in VRF! ──
NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#description CustB-LAN
NetsTuts_R1(config-if)#ip vrf forwarding CUSTOMER-B
NetsTuts_R1(config-if)#ip address 10.0.0.1 255.255.255.0
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

! ── Customer B WAN interface (to R2) ─────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/4
NetsTuts_R1(config-if)#description CustB-WAN-to-R2
NetsTuts_R1(config-if)#ip vrf forwarding CUSTOMER-B
NetsTuts_R1(config-if)#ip address 10.1.1.1 255.255.255.252
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

Both Gi0/0 (Customer A) and Gi0/1 (Customer B) are assigned identical IP addresses — 10.0.0.1/24. On a router without VRF this would be rejected outright. With VRF, IOS accepts this because 10.0.0.1 in CUSTOMER-A and 10.0.0.1 in CUSTOMER-B are entries in two completely separate routing tables — they do not conflict any more than two different routers having the same address.

Management Interface (Global Table — No VRF)

! ── Management interface stays in the global routing table
! ── No ip vrf forwarding command needed ──────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/3
NetsTuts_R1(config-if)#description OOB-Management
NetsTuts_R1(config-if)#ip address 192.168.99.1 255.255.255.0
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

Any interface without ip vrf forwarding belongs to the global routing table by default. The management interface (Gi0/3) is left in the global table intentionally — management plane traffic (SSH, SNMP, syslog) travels on a completely separate network segment from either customer's data traffic.

Verify Interface VRF Assignment

NetsTuts_R1#show ip vrf
  Name                             Default RD          Interfaces
  CUSTOMER-A                       <not set>           Gi0/0
                                                       Gi0/2
  CUSTOMER-B                       <not set>           Gi0/1
                                                       Gi0/4

Both VRFs now show their assigned interfaces. Gi0/3 (management) does not appear in the VRF table — it remains in the global routing table. This output is the fastest way to audit which interfaces belong to which VRF.

5. Step 3 — Configure Per-VRF Static Routes

Static routes in a VRF use the vrf keyword to place them into the correct routing table. A static route without the vrf keyword goes into the global table regardless of which interfaces are in VRFs:

! ── Default route for Customer A — out Gi0/2 WAN ─────────
NetsTuts_R1(config)#ip route vrf CUSTOMER-A 0.0.0.0 0.0.0.0 203.0.113.2

! ── Specific host route within Customer A ────────────────
NetsTuts_R1(config)#ip route vrf CUSTOMER-A 10.0.0.10 255.255.255.255 GigabitEthernet0/0

! ── Default route for Customer B — out Gi0/4 WAN ─────────
NetsTuts_R1(config)#ip route vrf CUSTOMER-B 0.0.0.0 0.0.0.0 10.1.1.2

! ── Specific host route within Customer B ────────────────
NetsTuts_R1(config)#ip route vrf CUSTOMER-B 10.0.0.20 255.255.255.255 GigabitEthernet0/1

! ── Global static route for management (no vrf keyword) ──
NetsTuts_R1(config)#ip route 0.0.0.0 0.0.0.0 192.168.99.254

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]

The syntax difference is critical: ip route vrf [name] [network] [mask] [next-hop] — the vrf [name] goes immediately after ip route and before the destination prefix. Without the vrf keyword, the route lands in the global table. Notice both VRFs have completely independent default routes pointing to different next-hops: Customer A exits via 203.0.113.2 while Customer B exits via 10.1.1.2 — traffic from both customers uses the same physical router but follows entirely separate forwarding paths. Verify VRF routes with show ip route vrf [name] and save with write memory.

6. Step 4 — Verify Routing Table Isolation

The definitive proof of VRF isolation is comparing the routing tables. Each VRF must only contain routes relevant to its own domain — no routes from other VRFs or the global table should be visible:

show ip route vrf CUSTOMER-A

NetsTuts_R1#show ip route vrf CUSTOMER-A

Routing Table: CUSTOMER-A
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2

Gateway of last resort is 203.0.113.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 203.0.113.2
      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.0.0.0/24 is directly connected, GigabitEthernet0/0
L        10.0.0.1/32 is directly connected, GigabitEthernet0/0
S        10.0.0.10/32 [1/0] via GigabitEthernet0/0
      203.0.113.0/8 is variably subnetted, 2 subnets, 2 masks
C        203.0.113.0/30 is directly connected, GigabitEthernet0/2
L        203.0.113.1/32 is directly connected, GigabitEthernet0/2

CUSTOMER-A's routing table contains only its own routes: the LAN (10.0.0.0/24 on Gi0/0), the WAN link (203.0.113.0/30 on Gi0/2), and its default route via 203.0.113.2. There is no trace of Customer B's 10.0.0.0/24, 10.1.1.0/30, or the management 192.168.99.0/24. The header Routing Table: CUSTOMER-A confirms you are viewing the VRF-specific table.

show ip route vrf CUSTOMER-B

NetsTuts_R1#show ip route vrf CUSTOMER-B

Routing Table: CUSTOMER-B
Codes: C - connected, S - static, R - RIP, ...

Gateway of last resort is 10.1.1.2 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 10.1.1.2
      10.0.0.0/8 is variably subnetted, 3 subnets, 3 masks
C        10.0.0.0/24 is directly connected, GigabitEthernet0/1
L        10.0.0.1/32 is directly connected, GigabitEthernet0/1
S        10.0.0.20/32 [1/0] via GigabitEthernet0/1
C        10.1.1.0/30 is directly connected, GigabitEthernet0/4
L        10.1.1.1/32 is directly connected, GigabitEthernet0/4

CUSTOMER-B's table also shows 10.0.0.0/24 — on Gi0/1, not Gi0/0. The identical prefix in two VRFs coexists without conflict. Customer B's default route points to 10.1.1.2, completely separate from Customer A. The 203.0.113.0/30 WAN link used by Customer A is entirely invisible here.

show ip route (Global Table)

NetsTuts_R1#show ip route

Codes: C - connected, S - static, ...

Gateway of last resort is 192.168.99.254 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.168.99.254
      192.168.99.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.99.0/24 is directly connected, GigabitEthernet0/3
L        192.168.99.1/32 is directly connected, GigabitEthernet0/3

The global routing table contains only the management interface (Gi0/3). Neither customer's routes are visible here — Gi0/0, Gi0/1, Gi0/2, and Gi0/4 are all assigned to VRFs and do not appear in the global table at all. This is the out-of-band management separation: an SSH session to 192.168.99.1 uses only the management network, with no possibility of routing into or out of either customer domain.

VRF-Aware Ping — Proving Isolation

! ── Ping from within CUSTOMER-A VRF context ──────────────
NetsTuts_R1#ping vrf CUSTOMER-A 203.0.113.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 203.0.113.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)

! ── Ping from CUSTOMER-B VRF context ────────────────────
NetsTuts_R1#ping vrf CUSTOMER-B 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)

! ── Attempt to reach Customer B's gateway FROM Customer A ─
! ── This must FAIL — proving isolation ───────────────────
NetsTuts_R1#ping vrf CUSTOMER-A 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

The three ping results together prove VRF isolation conclusively. CUSTOMER-A can reach its own WAN next-hop (203.0.113.2). CUSTOMER-B can reach its own WAN next-hop (10.1.1.2). But CUSTOMER-A cannot reach 10.1.1.2 — even though 10.1.1.2 is physically reachable on the same router — because CUSTOMER-A's routing table has no entry for 10.1.1.0/30. The isolation is enforced at the forwarding plane, not just in policy. The ping vrf [name] syntax is the VRF-aware form of ping — it sources the packet from within the specified VRF context.

7. Step 5 — Per-VRF Dynamic Routing with OSPF

Static routes work for simple VRF scenarios but real deployments need dynamic routing. Each VRF can run its own independent instance of OSPF, EIGRP, RIP, or BGP. The key difference in syntax is the vrf keyword in the router ospf process — each VRF OSPF process must have a unique process ID:

OSPF Instance for CUSTOMER-A

! ── OSPF process 10 is dedicated to CUSTOMER-A VRF ───────
NetsTuts_R1(config)#router ospf 10 vrf CUSTOMER-A
NetsTuts_R1(config-router)#router-id 1.1.1.1
NetsTuts_R1(config-router)#network 10.0.0.0 0.0.0.255 area 0
NetsTuts_R1(config-router)#network 203.0.113.0 0.0.0.3 area 0
NetsTuts_R1(config-router)#exit

OSPF Instance for CUSTOMER-B

! ── OSPF process 20 is dedicated to CUSTOMER-B VRF ───────
NetsTuts_R1(config)#router ospf 20 vrf CUSTOMER-B
NetsTuts_R1(config-router)#router-id 2.2.2.2
NetsTuts_R1(config-router)#network 10.0.0.0 0.0.0.255 area 0
NetsTuts_R1(config-router)#network 10.1.1.0 0.0.0.3 area 0
NetsTuts_R1(config-router)#exit

NetsTuts_R1(config)#end
NetsTuts_R1#wr
Building configuration...
[OK]

Both OSPF processes advertise 10.0.0.0/24 — the same prefix — but in completely separate OSPF domains. Process 10 runs inside CUSTOMER-A and process 20 runs inside CUSTOMER-B. Their OSPF Hello packets never interact even if they traverse the same physical link, because VRF membership is checked before OSPF processing. Each VRF OSPF process has its own neighbour table, LSDB, and SPF calculation.

Verify Per-VRF OSPF Neighbours

NetsTuts_R1#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   FULL/DR         00:00:37    203.0.113.2     GigabitEthernet0/2
4.4.4.4           1   FULL/DR         00:00:32    10.1.1.2        GigabitEthernet0/4

Both OSPF adjacencies are up — one for Customer A (via Gi0/2) and one for Customer B (via Gi0/4). The command show ip ospf neighbor shows all neighbours across all VRF OSPF processes. To see only a specific VRF's neighbours, use show ip ospf 10 neighbor (by process ID) or check show ip route vrf CUSTOMER-A ospf to see OSPF-learned routes specifically within that VRF.

Verify OSPF Routes in VRF Table

NetsTuts_R1#show ip route vrf CUSTOMER-A ospf

Routing Table: CUSTOMER-A
Codes: O - OSPF ...

      172.16.0.0/24 is subnetted, 1 subnets
O        172.16.10.0/24 [110/2] via 203.0.113.2, 00:02:14, GigabitEthernet0/2

OSPF has learned a remote network (172.16.10.0/24) from R2 and installed it into the CUSTOMER-A VRF routing table only. This network is completely invisible in the CUSTOMER-B table and the global table.

8. Step 6 — Route Leaking Between VRFs (Controlled Inter-VRF Communication)

By default, VRFs are completely isolated. Sometimes you need controlled communication between VRFs — for example, both customers need to reach a shared DNS server or internet gateway. Route leaking selectively imports routes from one VRF into another using static routes with a special syntax that specifies the source VRF:

! ── Scenario: Both customers need to reach a shared DNS
! ── server at 8.8.8.8 reachable only via CUSTOMER-A's WAN

! ── Leak the DNS host route FROM global INTO CUSTOMER-B ──
! ── Syntax: ip route vrf [dest-vrf] [prefix] [mask] [next-hop] global
NetsTuts_R1(config)#ip route vrf CUSTOMER-B 8.8.8.8 255.255.255.255 203.0.113.2 global

! ── Now CUSTOMER-B has a route to 8.8.8.8 via the global table
NetsTuts_R1#show ip route vrf CUSTOMER-B 8.8.8.8
Routing entry for 8.8.8.8/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 203.0.113.2, via GigabitEthernet0/2
      Route metric is 0, traffic share count is 1

The keyword global at the end of the static route tells IOS to resolve the next-hop (203.0.113.2) in the global routing table, not in CUSTOMER-B's VRF table. This creates a deliberate, surgical leak: only the specific 8.8.8.8/32 host route is shared — not the entire routing table. For broader inter-VRF communication (such as access to a shared services VRF), this same technique is applied per-prefix or using route maps and BGP with Route Targets (the full MPLS VPN approach).

Security warning: Route leaking deliberately breaks VRF isolation. Every leaked route is a deliberate hole in the separation boundary. In multi-tenant environments, route leaking requires explicit business justification and should be documented. Leaking a broad prefix (e.g., 0.0.0.0/0) effectively merges the two VRFs for all practical purposes — always leak the most specific prefix possible.

9. Verification Command Summary

Full show ip vrf detail

NetsTuts_R1#show ip vrf detail CUSTOMER-A
VRF CUSTOMER-A (VRF Id = 1); default RD <not set>
  Description: Customer A — isolated routing domain
  Interfaces:
    GigabitEthernet0/0       GigabitEthernet0/2
  Associated addresses:
    10.0.0.1/24              203.0.113.1/30
  No Export VPN route-target communities
  No Import VPN route-target communities
  No import route-map
  No global export route-map
  No export route-map
  VRF label distribution protocol: lpd
  VRF label allocation mode: per-prefix

Command	What It Shows	Primary Use
`show ip vrf`	All VRFs — name, RD, assigned interfaces	Quick audit — confirm VRFs exist and interfaces are correctly assigned
`show ip vrf detail [name]`	Full VRF config — description, interfaces, IP addresses, RT/RD, route-maps	Detailed audit of a single VRF — used when troubleshooting or documenting
`show ip vrf interfaces`	All interfaces with their VRF membership and IP addresses in one table	Cross-reference every interface against its VRF — spot mis-assigned interfaces quickly
`show ip route vrf [name]`	Full routing table for the specified VRF	Primary verification — confirm routes exist only in the correct VRF
`show ip route vrf [name] [prefix]`	Detailed entry for a specific prefix within a VRF	Trace a specific route — confirm next-hop and source within the VRF context
`show ip route vrf [name] ospf`	Only OSPF-learned routes within the VRF	Verify dynamic routing is populating the correct VRF table
`ping vrf [name] [destination]`	ICMP ping sourced from within the specified VRF	Prove reachability within a VRF and prove isolation (failed ping from wrong VRF)
`traceroute vrf [name] [destination]`	Path trace within a VRF routing context	Trace the path taken through VRF-specific routes
`show ip ospf [pid] neighbor`	OSPF neighbours for a specific process (VRF-bound)	Verify per-VRF OSPF adjacencies are forming on the correct interfaces
`show run \| section ip vrf`	All VRF definitions from running-config	Full config audit — see all VRFs, descriptions, and RDs in one view

10. Troubleshooting VRF-Lite Issues

Problem	Symptom	Cause	Fix
Interface loses IP address after VRF assignment	Interface configured with IP before VRF — after `ip vrf forwarding`, the IP address disappears	Assigning `ip vrf forwarding` to an interface with an existing IP address automatically removes it. IOS enforces this — an interface can only have addresses in one routing context	Always enter `ip vrf forwarding [name]` first, then `ip address`. If the IP was lost, simply re-enter `ip address [addr] [mask]` on the interface after the VRF assignment
Static route not appearing in VRF table	`ip route 10.0.0.0 255.255.255.0 [next-hop]` configured but not visible in `show ip route vrf CUSTOMER-A`	The `vrf` keyword was omitted — the route was placed in the global table instead	Remove the global route: `no ip route 10.0.0.0 255.255.255.0 [next-hop]`. Add the correct VRF route: `ip route vrf CUSTOMER-A 10.0.0.0 255.255.255.0 [next-hop]`. Verify with `show ip route vrf CUSTOMER-A`
ping vrf fails even though route exists	`show ip route vrf CUSTOMER-A` shows the destination route but `ping vrf CUSTOMER-A [dest]` fails	The next-hop IP in the VRF static route is not directly reachable within the VRF. The next-hop must be reachable via an interface in the same VRF — a next-hop that is only reachable in another VRF or the global table will not work without route leaking	Verify the next-hop address is on a subnet that is directly connected within the VRF: `show ip route vrf CUSTOMER-A [next-hop-IP]`. If not found, check which interface the next-hop is on and confirm that interface is in the same VRF
OSPF not forming in VRF	`show ip ospf neighbor` shows no neighbours for the VRF OSPF process	The `network` statement in the VRF OSPF process does not match any interfaces in that VRF, or the interface IP address was removed when VRF forwarding was assigned and not re-entered	Confirm the OSPF `network` statement matches an active interface in the VRF: `show ip vrf interfaces` to see VRF-to-interface mapping. Confirm the interface has an IP: `show ip interface brief`. Ensure the process was created with `router ospf [pid] vrf [name]`
Traffic leaking between VRFs unexpectedly	A host in CUSTOMER-A can reach destinations that should only be in CUSTOMER-B	A route leak (intentional or accidental) was configured. Either a static route with the `global` keyword exists, or an interface was accidentally assigned to the wrong VRF	Check for leaked static routes: `show run \| include ip route vrf`. Verify all interface VRF assignments: `show ip vrf interfaces`. Remove any unintended leaks with `no ip route vrf [name] [prefix] [mask] [next-hop] global`
SSH connects to wrong VRF context	SSH to the router's management IP works but enters into a wrong routing context — show ip route shows unexpected routes	Management interface is accidentally assigned to a customer VRF instead of the global table, or the SSH source-interface is bound to a VRF interface	Verify the management interface has no `ip vrf forwarding` command: `show run interface [mgmt-int]`. The management interface should be in the global table. If SSH is being sourced from a VRF interface, use `ip ssh source-interface [global-int]` to fix

Key Points & Exam Tips

VRF-Lite creates multiple independent routing tables (RIB), forwarding tables (FIB), and ARP tables on a single router. Each VRF is completely isolated from others and from the global table — traffic cannot cross VRF boundaries unless explicitly leaked.
The three mandatory steps are always in order: (1) define the VRF with ip vrf [name], (2) assign interfaces with ip vrf forwarding [name] on each interface, (3) add routes with ip route vrf [name] or per-VRF dynamic routing.
ip vrf forwarding clears the IP address from the interface when applied. Always enter VRF forwarding before the IP address command — or re-enter the IP address immediately after assigning VRF forwarding to an existing interface.
VRF-Lite allows overlapping IP address spaces — two VRFs can both have 10.0.0.0/24 on different interfaces with no conflict, because the addresses exist in separate routing tables. This is one of VRF's most powerful enterprise use cases.
Static routes within a VRF use the syntax ip route vrf [name] [network] [mask] [next-hop]. Without the vrf [name] keyword, the route goes into the global table regardless of the interface's VRF membership.
Dynamic routing protocols (OSPF, EIGRP, BGP) can run per-VRF with unique process IDs. OSPF syntax: router ospf [pid] vrf [name]. Each VRF OSPF process has its own neighbour table and LSDB — completely independent from OSPF processes in other VRFs.
Use ping vrf [name] [dest] and traceroute vrf [name] [dest] for VRF-aware connectivity tests. A plain ping without the vrf keyword uses the global routing table and will not test VRF reachability.
Route leaking between VRFs uses static routes with the global keyword: ip route vrf [dest-vrf] [prefix] [mask] [next-hop] global. This resolves the next-hop in the global table, creating a surgical one-way leak. Always leak the most specific prefix possible — leaking broad ranges or default routes undermines VRF isolation.
VRF-Lite does not require MPLS. It is the lightweight, IP-only version of VRF. Full MPLS L3VPN adds Route Distinguishers (RD), Route Targets (RT), and MP-BGP to carry VRF routes across a provider backbone — VRF-Lite is the customer-side or single-router equivalent.
For the exam: know the difference between show ip route (global table) and show ip route vrf [name] (VRF-specific table). Know that interfaces in a VRF do not appear in the global routing table. Know that the vrf forwarding command removes the IP address and that re-entry is required.

Next Steps: VRF-Lite provides the isolation foundation that more advanced technologies build on. To add dynamic routing within each VRF, complete OSPF Single-Area Configuration and OSPF Multi-Area Configuration, then apply the vrf keyword to the OSPF process as shown in Step 5. For per-VRF EIGRP see EIGRP Configuration. For understanding how service providers extend VRF across a backbone using MPLS labels and MP-BGP, start with MPLS Overview and BGP Overview, then progress to BGP Basics — eBGP Between Two Routers for the routing foundation. For securing management access to the global VRF management interface, see SSH Configuration and Console & VTY Line Configuration. For VRF troubleshooting beyond this lab, see Troubleshooting Layer 3 Routing and verify full config with show running-config.

TEST WHAT YOU LEARNED

1. What three separate data structures does IOS create for each VRF instance?

A. MAC address table, VLAN database, and STP instance B. BGP table, OSPF LSDB, and EIGRP topology table C. Routing Information Base (RIB — the routing table), Forwarding Information Base (FIB — the CEF forwarding table), and ARP table. Each is completely independent per VRF — routes, forwarding entries, and Layer 2 to Layer 3 mappings are all isolated D. Interface table, access-list table, and NAT translation table

Correct answer is C. When a VRF is created, IOS allocates three independent data structures: the RIB (routing table — what you see with show ip route vrf [name]), the FIB (CEF forwarding table — the hardware-level lookup used for fast packet forwarding), and the ARP table (Layer 3 to Layer 2 address mappings per VRF). This three-layer isolation is what makes VRF a true forwarding plane separation, not just a policy overlay. Two hosts in different VRFs with the same IP address will have separate ARP entries, separate routing table entries, and separate CEF entries — the forwarding hardware treats them as completely different entities.

2. An engineer configures `ip vrf forwarding CUSTOMER-A` on an interface that already has IP address 10.0.0.1/24. What happens immediately?

A. The IP address 10.0.0.1/24 is automatically removed from the interface. IOS displays a warning message. The engineer must re-enter ip address 10.0.0.1 255.255.255.0 after the VRF assignment for the interface to be operational B. The IP address is preserved and automatically moved into the CUSTOMER-A VRF routing table C. IOS rejects the command — VRF forwarding can only be assigned to interfaces that have no IP address D. The interface is shut down temporarily, then brought back up with the IP in the new VRF context

Correct answer is A. This is one of the most important VRF operational facts. When ip vrf forwarding is applied to an interface, IOS immediately removes any existing IP address because an IP address is inextricably tied to a routing table context — and the routing table context just changed. IOS will display: "%Interface GigabitEthernet0/0 IP address 10.0.0.1 removed due to enabling VRF CUSTOMER-A". The fix is simply to re-enter the ip address command after the VRF forwarding command. This catches many engineers by surprise when migrating existing interfaces to VRF — always verify with show ip interface brief after VRF assignment.

3. Two VRFs — CUSTOMER-A and CUSTOMER-B — both have 192.168.10.0/24 configured on different interfaces. Is this valid, and what does it demonstrate?

A. Invalid — IOS rejects duplicate prefixes across any routing table on the same router B. Valid, but IOS installs only one of the two routes — the second is held in standby C. Valid only if the two interfaces are in different VLANs D. Fully valid — each VRF maintains its own completely independent routing table. 192.168.10.0/24 in CUSTOMER-A and 192.168.10.0/24 in CUSTOMER-B are separate entries in separate tables, just as they would be on two completely different physical routers. This is the overlapping IP address capability — a core VRF-Lite use case for multi-tenant environments

Correct answer is D. Overlapping IP address support is one of the most powerful VRF capabilities. Without VRF, a router rejects duplicate prefixes on different interfaces — there is only one routing table and two entries for the same prefix would conflict. With VRF, each VRF has its own routing table, so identical prefixes coexist without conflict. This is exactly how service providers host multiple customers who all happen to use 192.168.1.0/24 or 10.0.0.0/8 internally — they put each customer in a separate VRF. From the router's perspective, CUSTOMER-A's 192.168.10.0/24 and CUSTOMER-B's 192.168.10.0/24 are as separate as they would be on two different physical devices.

4. What is the correct syntax to add a default route for VRF CUSTOMER-B with next-hop 10.1.1.2?

A. ip route 0.0.0.0 0.0.0.0 10.1.1.2 vrf CUSTOMER-B B. ip route vrf CUSTOMER-B 0.0.0.0 0.0.0.0 10.1.1.2 C. ip route CUSTOMER-B 0.0.0.0 0.0.0.0 10.1.1.2 D. ip default-route vrf CUSTOMER-B 10.1.1.2

Correct answer is B. The VRF static route syntax is ip route vrf [name] [destination] [mask] [next-hop] — the vrf [name] portion comes immediately after ip route and before the destination prefix. Option A places the vrf keyword at the end — this is incorrect syntax and IOS will either reject it or misinterpret it. The vrf keyword position matters because IOS parses the command sequentially: it needs to know which routing table to place the route in before processing the destination and next-hop. Without vrf [name], the route goes into the global table — one of the most common VRF configuration mistakes.

5. What does `ping vrf CUSTOMER-A 10.1.1.2` returning 0% success rate prove — assuming 10.1.1.2 is the next-hop in VRF CUSTOMER-B?

A. There is a physical Layer 1 or Layer 2 connectivity problem between the router and 10.1.1.2 B. CUSTOMER-A's OSPF process has not converged and is missing the route C. VRF isolation is working correctly. CUSTOMER-A has no route to 10.1.1.2 because that address only exists in CUSTOMER-B's routing table. The failed ping from CUSTOMER-A's context proves the two VRFs are completely isolated at the forwarding plane — traffic cannot cross VRF boundaries without explicit route leaking D. The ping vrf command requires a source interface — without it, all pings fail

Correct answer is C. This is the definitive VRF isolation test. A successful ping within a VRF proves connectivity. A failed ping from VRF CUSTOMER-A to an address that only exists in VRF CUSTOMER-B proves isolation. The router physically has the path to 10.1.1.2 — there is an interface with that subnet. But CUSTOMER-A's routing table has no entry for 10.1.1.x and cannot see CUSTOMER-B's interfaces. The packet is dropped with "no route to host" — not due to a physical problem but due to the forwarding table separation. This is exactly the behaviour you want to confirm in a VRF deployment: the isolation is working as designed.

6. What is the key difference between VRF-Lite and a full MPLS L3VPN implementation?

A. VRF-Lite works on a single router (or a chain of directly connected routers) using plain IP — no MPLS required. Full MPLS L3VPN uses MPLS labels to carry VRF context across a shared provider backbone with MP-BGP, Route Distinguishers, and Route Targets to distribute VRF routes between PE routers B. VRF-Lite supports only static routing; MPLS L3VPN supports dynamic routing protocols C. VRF-Lite is a Cisco proprietary feature; MPLS L3VPN is an open standard available on all vendors D. VRF-Lite requires a Route Distinguisher on every VRF; MPLS L3VPN makes the RD optional

Correct answer is A. The fundamental difference is the transport mechanism. VRF-Lite provides routing table isolation on a single device using plain IP forwarding — perfect for enterprise multi-tenant routers, security zone separation, or OOB management. Full MPLS L3VPN extends VRF isolation across a service provider backbone: PE routers each maintain per-customer VRFs, MP-BGP with Route Distinguishers (to make routes globally unique) and Route Targets (to control import/export between VRFs) distributes the routes between PEs, and MPLS labels carry the VRF context across P routers that have no knowledge of individual VRFs. VRF-Lite and MPLS VPN both use the same ip vrf configuration commands — MPLS VPN simply adds the BGP/MPLS layer on top.

7. An interface is in VRF CUSTOMER-A. A plain `show ip route` (no vrf keyword) is run. Will routes from CUSTOMER-A appear?

A. Yes — show ip route always shows all routes from all VRFs and the global table B. Yes — connected routes from VRF interfaces are always reflected in the global table as well C. Partially — connected VRF routes appear but static and dynamic VRF routes do not D. No — show ip route without the vrf keyword shows only the global routing table. Interfaces assigned to a VRF are completely absent from the global table — their connected routes, static routes, and dynamic routes exist only in the VRF-specific RIB. You must use show ip route vrf CUSTOMER-A to see them

Correct answer is D. This is one of the most important operational facts about VRF. Once an interface is assigned to a VRF with ip vrf forwarding, it disappears entirely from the global routing table. Running show ip route will not show the connected routes for that interface, any static routes placed in the VRF, or any dynamic routes learned on VRF interfaces. The global table only knows about interfaces explicitly in the global context (no VRF assignment). This complete separation is what makes VRF powerful — and it is also what trips up engineers who forget to add the vrf keyword to their show ip route command when troubleshooting a VRF interface.

8. To run OSPF within VRF CUSTOMER-A using process ID 10, what is the correct command?

A. router ospf 10 followed by vrf CUSTOMER-A as a sub-command inside the OSPF process B. router ospf 10 vrf CUSTOMER-A — the vrf [name] is appended directly to the router ospf command on the same line, binding the entire OSPF process to that VRF C. router ospf vrf CUSTOMER-A 10 D. router ospf 10 then network [prefix] [wildcard] area 0 vrf CUSTOMER-A inside the process

Correct answer is B. The VRF binding for a dynamic routing process is specified on the same line as the process declaration: router ospf [process-id] vrf [name]. Once declared this way, the entire OSPF process — its interfaces, neighbours, LSDB, and routing updates — operates exclusively within the CUSTOMER-A VRF. The network statements inside this process will only match interfaces that are also in CUSTOMER-A. You cannot change the VRF of an OSPF process after creation — you must remove the process and recreate it with the correct VRF binding. EIGRP uses similar syntax: router eigrp [as] with address-family ipv4 vrf [name] in named EIGRP mode.

9. What does adding the `global` keyword to the end of a VRF static route accomplish?

A. It advertises the route to all VRFs simultaneously, making it a shared global prefix B. It places the route in the global routing table instead of the specified VRF C. It tells IOS to resolve the next-hop IP address using the global routing table rather than the VRF's own routing table. This creates a controlled route leak — the destination prefix is placed in the VRF, but traffic is forwarded using the global table's path to the next-hop. Used for shared services (DNS, internet) accessible from a VRF via a next-hop that only exists globally D. It permanently fixes the route so it cannot be overridden by dynamic routing protocols in the VRF

Correct answer is C. The global keyword at the end of a VRF static route is one of IOS's route leaking mechanisms. Normally, the next-hop in a VRF static route must be reachable within the same VRF. Adding global tells IOS: "place this destination prefix in VRF X's routing table, but look up the next-hop in the global routing table." This is how a VRF can reach a shared resource (like an internet gateway or shared DNS server) that only has a path in the global table. The leak is asymmetric and surgical — only the specified prefix is leaked, and only in one direction. The reverse direction (global table reaching into the VRF) requires a separate ip route [prefix] [mask] [next-hop] vrf [name] entry in the global table.

10. A network engineer accidentally runs `ip route 0.0.0.0 0.0.0.0 203.0.113.2` (without the vrf keyword) intending to add a default route for CUSTOMER-A. What is the result?

A. IOS detects the interface 203.0.113.2 is in CUSTOMER-A and automatically places the route in the correct VRF B. The command is rejected because 203.0.113.2 is in a VRF interface and cannot be a global next-hop C. The route is placed in both the global table and CUSTOMER-A simultaneously D. The default route is placed in the global routing table, not CUSTOMER-A's VRF table. IOS accepts the command without error. CUSTOMER-A still has no default route — traffic from CUSTOMER-A hits a routing failure for unknown destinations. The fix is to remove the global route and add the correct VRF route: no ip route 0.0.0.0 0.0.0.0 203.0.113.2 then ip route vrf CUSTOMER-A 0.0.0.0 0.0.0.0 203.0.113.2

Correct answer is D. IOS does not infer the intended VRF from the next-hop's physical interface membership — it takes the command literally. Without the vrf [name] keyword, the route always goes to the global table. IOS will not generate an error or warning. This silent failure is particularly dangerous for default routes — the engineer may believe CUSTOMER-A has internet access, but pings and traffic from CUSTOMER-A hosts will fail for any destination beyond the directly connected subnets. The global table may now have an unexpected default route that could affect management traffic. Always verify after adding VRF routes: show ip route vrf CUSTOMER-A should show the default route, and show ip route (global) should not have an unintended entry.

Back to Home