Hands-On Lab: Configuring VRF-Lite

This hands-on lab configures VRF-Lite on a router to maintain two completely separate routing tables for two different customer networks sharing the same physical router, verifying each VRF's traffic remains isolated despite using overlapping IP address space.

VRF-Lite ConfigurationOverlapping Address SpacePer-VRF Routing Table

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۲ مهر ۱۴۰۵

Lab Objective

Configure two separate VRFs on a single router, assign interfaces to each, configure overlapping IP address space between the two VRFs, and verify each VRF maintains a completely independent routing table with no leakage between them.

Lab Purpose

A single router with a single global routing table can only support one instance of any given IP subnet — two customers both wanting to use 192.168.1.0/24 on the same physical router would normally be impossible. VRF-Lite creates multiple logically separate routing tables on one router, allowing genuinely overlapping address space to coexist safely.

Lab Topology

R1
  Gi0/0 (Customer-A VRF): 192.168.1.1/24
  Gi0/1 (Customer-B VRF): 192.168.1.1/24
  -- Identical subnet used in both VRFs,
     something impossible without VRF-Lite

Task 1: Create Two VRFs

Create VRF CUSTOMER-A and VRF CUSTOMER-B.

Task 2: Assign Interfaces to Each VRF

Associate Gi0/0 with CUSTOMER-A and Gi0/1 with CUSTOMER-B.

Task 3: Configure Identical Overlapping IP Addresses

Configure both interfaces with the same 192.168.1.1/24 address, demonstrating the address isolation VRFs provide.

Task 4: Verify Separate Routing Tables Exist

Confirm each VRF maintains its own independent routing table.

Task 5: Verify Traffic Isolation Between VRFs

Confirm a device in Customer-A's VRF cannot reach a device in Customer-B's VRF, despite the router forwarding traffic for both.

Solution and Verification

R1(config)# vrf definition CUSTOMER-A
R1(config-vrf)# address-family ipv4
R1(config-vrf-af)# exit-address-family
R1(config-vrf)# exit

R1(config)# vrf definition CUSTOMER-B
R1(config-vrf)# address-family ipv4
R1(config-vrf-af)# exit-address-family

R1(config)# interface gigabitethernet0/0
R1(config-if)# vrf forwarding CUSTOMER-A
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# no shutdown

-- Applying vrf forwarding requires the IP
-- address to be re-entered, since assigning
-- an interface to a VRF clears its existing
-- IP configuration

R1(config)# interface gigabitethernet0/1
R1(config-if)# vrf forwarding CUSTOMER-B
R1(config-if)# ip address 192.168.1.1 255.255.255.0
R1(config-if)# no shutdown

-- Identical address to Gi0/0's VRF --
-- accepted without conflict, since the two
-- VRFs maintain entirely separate address
-- spaces

R1# show ip route vrf CUSTOMER-A

Routing Table: CUSTOMER-A
C    192.168.1.0/24 is directly connected, GigabitEthernet0/0

R1# show ip route vrf CUSTOMER-B

Routing Table: CUSTOMER-B
C    192.168.1.0/24 is directly connected, GigabitEthernet0/1
-- Two entirely separate routing tables,
-- each showing the identical 192.168.1.0/24
-- network mapped to a different interface

R1# ping vrf CUSTOMER-A 192.168.1.1 source gigabitethernet0/1

-- Attempting to reach Customer-A's VRF
-- using Customer-B's interface as source
Sending 5, 100-byte ICMP Echos...
.....
Success rate is 0 percent (0/5)
-- No leakage between VRFs -- Customer-B's
-- interface cannot reach Customer-A's
-- network at all, despite the identical
-- IP address existing there too

Key Takeaway

VRF-Lite provides Layer 3 traffic isolation on a single physical router using entirely separate routing tables per VRF, allowing genuinely overlapping IP address space between different customers or departments to coexist safely on shared hardware — this is the router-based counterpart to the VLAN-based Layer 2 isolation covered earlier in this series, extended specifically to the routing table itself rather than switched traffic.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه