Sign in Subscribe
CCNP-ENARSI

Verifying VRF-Lite Configuration: Common Techniques

Comprehensive guide to verifying VRF-Lite configurations using systematic techniques including routing table verification, connectivity testing, and advanced validation methods for enterprise networks.

Jay Whale

• 4 min read
Verifying VRF-Lite Configuration: Common Techniques

When you've implemented VRF-Lite in your enterprise network, thorough verification becomes critical to ensure proper isolation and connectivity. Unlike basic VRF troubleshooting, comprehensive verification requires a systematic approach using multiple techniques and commands to validate both the control plane and data plane operations.

VRF Instance and Interface Verification

Start your verification process by confirming VRF instances are properly configured and interfaces are correctly assigned. The show vrf command provides the foundation for your verification workflow:

Router# show vrf
  Name                             Default RD            Interfaces
  CUSTOMER_A                                    Gi0/1
                                                         Gi0/2
  CUSTOMER_B                                    Gi0/3
                                                         Gi0/4
  MGMT                                          Gi0/0

This output confirms your VRF instances exist and shows interface assignments. For detailed interface verification, use show vrf detail to examine each VRF's configuration specifics, including any route import/export policies if you're transitioning toward MPLS VPNs later.

Verify interface VRF assignments individually with show ip interface brief | include vrf-name or check specific interfaces:

Router# show interface gi0/1
GigabitEthernet0/1 is up, line protocol is up 
  Hardware is iGbE, address is 0050.56a1.1234 (bia 0050.56a1.1234)
  Internet address is 192.168.10.1/24
  VRF forwarding is CUSTOMER_A

Routing Table Verification Techniques

Each VRF maintains its own routing table, requiring VRF-specific verification commands. The global routing table won't show VRF routes, making proper command syntax essential:

Router# show ip route vrf CUSTOMER_A
VRF: CUSTOMER_A
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C        10.1.1.0/24 is directly connected, GigabitEthernet0/1
L        10.1.1.1/32 is directly connected, GigabitEthernet0/1
S        10.2.0.0/16 [1/0] via 10.1.1.2
O        10.3.0.0/16 [110/2] via 10.1.1.3, 00:05:42, GigabitEthernet0/1

Compare this with another VRF to confirm proper isolation:

Router# show ip route vrf CUSTOMER_B
VRF: CUSTOMER_B
Gateway of last resort is not set

      192.168.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        192.168.20.0/24 is directly connected, GigabitEthernet0/3
L        192.168.20.1/32 is directly connected, GigabitEthernet0/3

Use show ip route vrf * summary for a quick overview of all VRF routing tables simultaneously, which helps identify routing inconsistencies across VRFs.

Connectivity Testing and Data Plane Verification

Routing table verification confirms control plane operation, but data plane testing ensures actual packet forwarding works correctly. VRF-aware ping testing requires specific syntax:

Router# ping vrf CUSTOMER_A 10.2.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Extended ping provides additional testing capabilities:

Router# ping
Protocol [ip]: 
Target IP address: 10.2.1.1
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y
Source address or interface: 10.1.1.1
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
VRF []: CUSTOMER_A

For comprehensive data plane verification, use traceroute with VRF specification to verify the complete path:

Router# traceroute vrf CUSTOMER_A 10.3.1.1
Type escape sequence to abort.
Tracing the route to 10.3.1.1
VRF info: (vrf in name/id, vrf out name/id)

  1 10.1.1.3 (CUSTOMER_A/0:CUSTOMER_A/0) 4 msec 0 msec 4 msec
  2 10.3.1.1 (CUSTOMER_A/0:CUSTOMER_A/0) 4 msec *  0 msec

Advanced Verification Methods

Beyond basic connectivity testing, several advanced verification techniques help identify subtle configuration issues. The show ip protocols vrf command reveals routing protocol operation within each VRF:

Router# show ip protocols vrf CUSTOMER_A
*** IP Routing is NSF aware ***

Routing Protocol is "ospf 1"
  VRF is CUSTOMER_A
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Router ID 10.1.1.1
  Number of areas in this router is 1. 1 normal 0 stub 0 nssa

Use show ip arp vrf vrf-name to verify ARP table entries are properly segregated:

Router# show ip arp vrf CUSTOMER_A
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.1.1.2               15   0050.56a1.5678  ARPA   GigabitEthernet0/1
Internet  10.1.1.1                -   0050.56a1.1234  ARPA   GigabitEthernet0/1

For BGP-based VRF implementations, verify neighbor relationships and routing information:

Router# show ip bgp vpnv4 vrf CUSTOMER_A summary
BGP router identifier 1.1.1.1, local AS number 65001
BGP table version is 12, main routing table version 12

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.1.2        4        65002      45      44       12    0    0 00:38:52        3

Configuration Validation Checklist

Implement a systematic verification checklist to ensure comprehensive coverage:

  • Verify VRF definitions exist with show vrf
  • Confirm interface assignments match design with show vrf detail
  • Check routing tables for each VRF contain expected routes
  • Test inter-VRF isolation by attempting cross-VRF communication
  • Validate routing protocol operation within each VRF context
  • Verify ARP table segregation between VRFs
  • Test data plane connectivity using VRF-aware ping and traceroute
  • Confirm route leaking configurations if implemented

Document any deviations from expected behavior and correlate with your network design requirements. Remember that VRF-Lite verification differs significantly from MPLS L3VPN verification, as you're working without route distinguishers and route targets in the pure VRF-Lite implementation.

What's Next

Now that you've mastered VRF-Lite verification techniques, the next logical step is exploring route leaking between VRFs. This advanced topic builds on your verification skills and introduces controlled connectivity between otherwise isolated routing domains, which becomes essential in complex enterprise designs where selective communication between VRFs is required.

🔧
For continuous VRF monitoring, use a network monitoring solution that can track VRF-specific routing tables and interface assignments automatically. This prevents configuration drift and alerts you to isolation issues before they impact customers. PRTG Network Monitor, SolarWinds NPM and ManageEngine OpManager.

Tools and resources for this topic