VRF Route Leak
As already we know that, Virtual Routing and Forwarding (VRF) is a technology for creating separate virtual routers on a single physical router. Router interfaces, routing tables, and forwarding tables are isolated on a VRF by VRF basis and therefore prevent traffic from one VRF interfering with another VRF.
As the name implies, VRF Leak or Route Leaking implies leaking routes or importing/exporting network prefixes between VRFs or between the global routing table and a VRF segment.
There are three primary methods which we are going to discuss here:
- Route Leaking between Global and VRF table
- Route Leaking between VRFs: Static Routing
- Route Leaking between VRFs: GRE Tunnel
Route Leaking between Global and VRF table
We can achieve this by using Static Route & Policy-Based Routing. Let’s consider the following topology
HQ configuration
ip vrf leak-route
!
interface FastEthernet1/0
ip address 10.0.12.2 255.255.255.0
no shutdown
!
interface FastEthernet1/1
ip vrf forwarding leak-route
ip address 10.0.23.1 255.255.255.0
no shutdown
!
!
We can clearly see here that 10.0.23.0/24 is not in the main routing table but in the routing table referencing VRF leak-route. This is expected since we’ve placed Fa1/1 under the VRF.
Let’s first create a default route on R1 and R3 to point to R2.
BO_1(config)# ip route 0.0.0.0 0.0.0.0 10.0.12.2
BO_2(config)# ip route 0.0.0.0 0.0.0.0 10.0.23.1
Nice…!!, our next step is to configure Policy-Based Routing on HQ(Head Quarter) and set our next-hop to be the far side of the VRF leak-route. We will also instruct Fa1/0 on HQ to receive prefixes from the VRF domain. Traffic is policy routed at that point.
R2(config)# access-list 100 permit ip any any
R2(config)# route-map vrf-leak permit 10
R2(config-route-map)# match ip address 100
R2(config-route-map)# set ip vrf leak-route next-hop 10.0.23.2
R2(config-route-map)# exit
R2(config)# interface fa1/0
R2(config-if)# ip policy route-map vrf-leak
R2(config-if)# ip vrf receive leak-route
R2(config-if)# end
Here, we’ve enabled Policy Based Routing (PBR) by creating a route-map and match on the interesting traffic from BO_1 to BO_2. Then we set the next hop to be the far side of the VRF domain. Also, notice that that the “ip vrf receive” command is used in conjunction with an access list or an interface to define the source address or source interface criteria for accepting packets into the VRF.
Route Leaking between VRFs: Static Routing
Let’s first create a default route on R2 and R3 to point to R1.
R2(config)# ip route 0.0.0.0 0.0.0.0 10.0.12.2
R3(config)# ip route 0.0.0.0 0.0.0.0 10.0.23.1
R1 Configuration
hostname R1
!
!
ip vrf ACCOUNTING
!
ip vrf ENGINEERING
!
interface Fa 1/0
ip vrf forwarding ENGINEERING
ip address 10.0.12.2 255.255.255.252
!
interface Fa1/1
ip vrf forwarding ACCOUNTING
ip address 10.0.23.1 255.255.255.252
Here, we have 2 VRFs (ENGINEERING & ACCOUNTING). The idea is to be able now to get to the loopback addresses. We now have Fa1/0 in VRF ENGINEERING and Fa1/1 in VRF ACCOUNTING.
This means that the main routing table on R2 is empty. In order to achieve end-to-end connectivity here, we will need to bounce into the global routing table before hoping to the far side VRF.
R1(config)#ip route vrf ENGINEERING 3.3.3.3 255.255.255.255 10.0.23.2 global
R1(config)#ip route vrf ACCOUNTING 1.1.1.1 255.255.255.255 10.0.12.1 global
Here we have 2 static routes:
- In VRF ENGINEERING, we’re saying in order to get to 3.3.3.3 then your next hop is 10.0.23.2 in the global routing table
- In VRF ACCOUNTING, we’re saying in order to get to 1.1.1.1 then your next hop is 10.0.12.1 in the global routing table
So basically, we’re routing from the VRFs to the main routing table. However, if you remember correctly there’s no routes in the main routing table. Let’s take a look.
As you can see, we’re pointing to the addresses that do not exist in the main routing table. In order for R2 to know how to get to 10.0.12.1 and 10.0.23.2, we need to add two more static routes and point them to their respective exit interface.
R1(config)#ip route 10.0.12.1 255.255.255.255 Fa1/0
R1(config)#ip route 10.0.23.2 255.255.255.255 Fa1/1
Route Leaking between VRFs: GRE Tunnel
The use of GRE tunnels make more sense if R1 and R3 are in their own VRFs. Let’s do that. Here, Fa0/0 on both R1 and R3 are in VRF ENGINEERING and VRF ACCOUNTING respectively.
Here is the R1, R2 and R3 configurations….
R1 Configuration
!
ip vrf engineering
! interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding engineering
ip address 10.0.12.1 255.255.255.0
no shutdown
!
R2 Configuration
!
interface FastEthernet0/0
ip address 10.0.12.2 255.255.255.0
no shutdown
!
interface FastEthernet1/0
ip address 10.0.23.1 255.255.255.0
no shutdown
R3 Configuration
!
ip vrf accounting
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding accounting
ip address 10.0.23.2 255.255.255.0
no shutdown
R1 Tunnel Configuration
interface Tunnel100
ip address 172.16.0.1 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 10.0.23.2
tunnel vrf engineering
R1(config)# ip route vrf engineering 10.0.23.2 255.255.255.255 FastEthernet0/0 10.0.12.2 global
R3 Tunnel Configuration
interface Tunnel100
ip address 172.16.0.2 255.255.255.0
tunnel source FastEthernet0/0
tunnel destination 10.0.12.1
tunnel vrf accounting
R3(conig)# ip route vrf accounting 10.0.12.1 255.255.255.255 FastEthernet0/0 10.0.23.1 global
Thank you very much..!!
-----------------------------------------------------The End----------------------------------------------------
