Hands-On Lab: Configuring Route Leaking Between VRFs

Lab Objective

Configure route targets on two customer VRFs and a shared services VRF, selectively leak a shared server's route into both customer VRFs, and verify each customer can reach the shared service while remaining isolated from each other.

Lab Purpose

The strict isolation demonstrated in the previous VRF-Lite lab is often too rigid for real deployments — many multi-tenant designs need customers isolated from each other while still sharing access to common resources like a shared DNS server or internet gateway. Route leaking using route targets provides controlled, selective exceptions to VRF isolation.

Lab Topology

R1
  VRF CUSTOMER-A: Gi0/0, 10.1.1.1/24
  VRF CUSTOMER-B: Gi0/1, 10.2.2.1/24
  VRF SHARED: Gi0/2, 10.99.99.1/24
              (shared DNS server here)

Goal: both CUSTOMER-A and CUSTOMER-B should
reach 10.99.99.0/24, but CUSTOMER-A and
CUSTOMER-B should still not reach each other

Task 1: Configure Three VRFs with Route Distinguishers and Targets

Configure CUSTOMER-A, CUSTOMER-B, and SHARED VRFs, each with a unique route distinguisher and appropriate route targets for leaking.

Task 2: Configure Each VRF to Export Its Own Routes

Configure each customer VRF to export its routes with a unique route target, and SHARED to export its routes with its own route target.

Task 3: Configure Each Customer VRF to Import SHARED's Routes

Configure both CUSTOMER-A and CUSTOMER-B to import SHARED's route target.

Task 4: Configure SHARED to Import Both Customer Route Targets

Configure SHARED to import both customer VRFs' route targets, allowing return traffic to reach them.

Task 5: Verify Selective Connectivity

Confirm both customers can reach the shared server, while still being unable to reach each other.

Solution and Verification

R1(config)# vrf definition CUSTOMER-A
R1(config-vrf)# rd 65001:1
R1(config-vrf)# address-family ipv4
R1(config-vrf-af)# route-target export 65001:1
R1(config-vrf-af)# route-target import 65001:99
R1(config-vrf-af)# exit-address-family

R1(config)# vrf definition CUSTOMER-B
R1(config-vrf)# rd 65001:2
R1(config-vrf)# address-family ipv4
R1(config-vrf-af)# route-target export 65001:2
R1(config-vrf-af)# route-target import 65001:99
R1(config-vrf-af)# exit-address-family

R1(config)# vrf definition SHARED
R1(config-vrf)# rd 65001:99
R1(config-vrf)# address-family ipv4
R1(config-vrf-af)# route-target export 65001:99
R1(config-vrf-af)# route-target import 65001:1
R1(config-vrf-af)# route-target import 65001:2

-- SHARED imports both customer route
-- targets, enabling it to route traffic
-- BACK to either customer, while each
-- customer only imports SHARED's route
-- target, never each other's

R1(config)# interface gigabitethernet0/0
R1(config-if)# vrf forwarding CUSTOMER-A
R1(config-if)# ip address 10.1.1.1 255.255.255.0
R1(config-if)# no shutdown
R1(config)# interface gigabitethernet0/1
R1(config-if)# vrf forwarding CUSTOMER-B
R1(config-if)# ip address 10.2.2.1 255.255.255.0
R1(config-if)# no shutdown
R1(config)# interface gigabitethernet0/2
R1(config-if)# vrf forwarding SHARED
R1(config-if)# ip address 10.99.99.1 255.255.255.0
R1(config-if)# no shutdown

R1# show ip route vrf CUSTOMER-A

Routing Table: CUSTOMER-A
C    10.1.1.0/24 is directly connected, GigabitEthernet0/0
B    10.99.99.0/24 [200/0] via ... (leaked from SHARED)

R1# show ip route vrf CUSTOMER-B

Routing Table: CUSTOMER-B
C    10.2.2.0/24 is directly connected, GigabitEthernet0/1
B    10.99.99.0/24 [200/0] via ... (leaked from SHARED)
-- Both customer VRFs now show the shared
-- subnet as a leaked route

R1# show ip route vrf CUSTOMER-A | include 10.2.2.0
-- (no output -- CUSTOMER-B's network never
--  appears, since neither customer imports
--  the other's route target)

CustomerA-Host> ping 10.99.99.10 (shared DNS)
!!!!!
Success rate is 100 percent (5/5)

CustomerB-Host> ping 10.99.99.10 (shared DNS)
!!!!!
Success rate is 100 percent (5/5)

CustomerA-Host> ping 10.2.2.10 (CustomerB's host)
.....
Success rate is 0 percent (0/5)
-- Exactly the intended result: shared
-- resource reachable by both, customers
-- still isolated from each other

Key Takeaway

Route leaking with route targets works through a simple, asymmetric import/export pattern: a VRF exports its routes tagged with its own identifier, and any VRF wanting to receive those routes must explicitly import that same tag — CUSTOMER-A and CUSTOMER-B never import each other's tags, so isolation between them remains completely intact even while both selectively import SHARED's routes, demonstrating that route leaking is precise and additive rather than an all-or-nothing relaxation of VRF isolation.