Route leakage between VRF and Global with virtual interface

In the following post I will describe how to do route leakage between global and VRF routing tables where we have tunnel interface.

Here is the lab scenario:

Objectives:

R4 LAN address (192.168.41.0/24) should reach R3 LAN address (192.168.31.0/24)

R1 basic configuration:

interface Tunnel14  ip vrf forwarding RED  ip address 10.0.14.1 255.255.255.0  tunnel source FastEthernet1/0  tunnel destination 10.0.24.4  tunnel vrf RED ! interface FastEthernet1/0  ip vrf forwarding RED  ip address 10.0.12.1 255.255.255.0  duplex full  speed 100 ! interface FastEthernet1/1  ip address 10.0.13.1 255.255.255.0  duplex full  speed 100 ! router ospf 14 vrf RED  log-adjacency-changes  network 10.0.14.1 0.0.0.0 area 0 ! ip route 192.168.31.0 255.255.255.0 10.0.13.3 ip route vrf RED 10.0.24.0 255.255.255.0 10.0.12.2 name STATIC_TO_R2-R4

R1 has static route to 192.168.31.0/24 through the global routing table and static route to 10.0.24.0/24 through VRF RED routing table. All other router configured with default static route to R1.

R1 also learns network 192.168.41.0/24 through OSPF which runs on GRE tunnel between R1 and R4.

Now in order to leak routes from the VRF to global routing table we use static routes with next-hop pointing the interface instead of IP.

ip route vrf RED 192.168.31.0 255.255.255.0 FastEthernet1/1 10.0.13.3 name VRF_RED_TO_GLOBAL !

This allows the hosts on VRF RED to reach 192.168.31.0/24 which reside on the global routing table.

Now we need to leak routes from the VRF to the global but unlike normal leakage we can’t use static route pointing the interface because the interface is virtual (tunnel).

The solution – using PBR with route-map

Create an access-list which matches the destination on the VRF routing table:

ip access-list extended ACL_VRF_RED_LAN  permit ip any 192.168.41.0 0.0.0.255 !

Remember that the direction is from the global to the VRF so source is any and destination is the desired network.

Configure a route-map with match and set:

route-map RM_GLOBAL_TO_VRF_RED permit 10  match ip address ACL_VRF_RED_LAN  set vrf RED ! route-map RM_GLOBAL_TO_VRF_RED deny 999 !

Note the set VRF command.

And finally apply this route-map as policy based route on the inbound interface:

interface FastEthernet1/1  ip address 10.0.13.1 255.255.255.0  ip policy route-map RM_GLOBAL_TO_VRF_RED !

The result:

R3#ping 192.168.41.1 source lo1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.41.1, timeout is 2 seconds: Packet sent with a source address of 192.168.31.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 80/128/176 ms R3# *Oct  9 14:58:20.367: ICMP: echo reply rcvd, src 192.168.41.1, dst 192.168.31.1 *Oct  9 14:58:20.475: ICMP: echo reply rcvd, src 192.168.41.1, dst 192.168.31.1 *Oct  9 14:58:20.635: ICMP: echo reply rcvd, src 192.168.41.1, dst 192.168.31.1 *Oct  9 14:58:20.755: ICMP: echo reply rcvd, src 192.168.41.1, dst 192.168.31.1 *Oct  9 14:58:20.835: ICMP: echo reply rcvd, src 192.168.41.1, dst 192.168.31.1 R3#

And:

R1# *Oct  9 14:58:22.491: IP: s=192.168.31.1 (FastEthernet1/1), d=192.168.41.1, len 100, FIB policy match *Oct  9 14:58:22.639: IP: s=192.168.31.1 (FastEthernet1/1), d=192.168.41.1, len 100, FIB policy match *Oct  9 14:58:22.779: IP: s=192.168.31.1 (FastEthernet1/1), d=192.168.41.1, len 100, FIB policy match *Oct  9 14:58:22.903: IP: s=192.168.31.1 (FastEthernet1/1), d=192.168.41.1, len 100, FIB policy match *Oct  9 14:58:23.007: IP: s=192.168.31.1 (FastEthernet1/1), d=192.168.41.1, len 100, FIB policy match