What’s a blog called “RouteLeak” without a Route Leaking post. As the name implies, route leaking implies leaking routes or importing/exporting network prefixes between VRFs or between the global routing table and a VRF segment. I will show you different methods to get it configured as follow:
- Route Leaking between Global and VRF table: Static Route & Policy-Based Routing
- Route Leaking between VRFs: Static Routing
- Route Leaking between VRFs: GRE Tunnel
- Route Leaking between VRFs: MP-BGP
We will be working with the following setup.
Here, 10.2.2.0/30 is in a VRF called ROUTELEAK and 10.1.1.0/30 is in the main routing table. The goal here is to be able to ping R3 from R1.
Let me show you what the preliminary configuration looks like.
You can see here that we’ve placed R2’s Eth0/1 in vrf ROUTELEAK. Let’s dive deep into the CLI and see how we can use static routes to achieve end to end reachability.
R2#sh ip route | b Gateway
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.1.0/30 is directly connected, Ethernet0/0
L 10.1.1.1/32 is directly connected, Ethernet0/0
R2#
R2#sh ip route vrf ROUTELEAK | b Gateway
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.2.2.0/30 is directly connected, Ethernet0/1
L 10.2.2.1/32 is directly connected, Ethernet0/1
We can clearly see here that 10.2.2.0/30 is not in the main routing table but in the routing table referencing VRF ROUTELEAK. This is expected since we’ve placed Eth0/1 under the VRF.
Let’s first create a default route on R1 and R3 to point to R2.
R1(config)#ip route 0.0.0.0 0.0.0.0 10.1.1.1
R3(config)#ip route 0.0.0.0 0.0.0.0 10.2.2.1
Great, our next step is to run Policy-Based Routing on R2 and set our next-hop to be the far side of the ROUTELEAK VRF. We will also instruct Eth0/0 on R2 to receive prefixes from the VRF domain. Traffic is policy routed at that point.
Let me show you what it looks like.
R2#sh run int Ethernet0/0
Building configuration...
Current configuration : 124 bytes
!
interface Ethernet0/0
ip vrf receive ROUTELEAK
ip address 10.1.1.1 255.255.255.252
ip policy route-map LEAK-ROUTE
!
interface Ethernet0/1
ip vrf forwarding ROUTELEAK
ip address 10.2.2.1 255.255.255.252
!
route-map LEAK-ROUTE permit 10
match ip address 100
set ip vrf ROUTELEAK next-hop 10.2.2.2
!
!
access-list 100 permit ip host 10.1.1.2 host 10.2.2.2
Here, we’ve enabled PBR by creating a route-map and match on the interesting traffic (R1 to R3). We’ve then set the next hop to be the far side of the VRF domain. Also, note 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.
Let’s now check if we can ping across.
R1#ping 10.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Great ! Mission accomplished. Let’s move on to the next one !
We will be working with the below diagram in this section.
Here, we have 2 VRFs (ENG & ACCOUNTING). The idea is to be able now to get to the loopback addresses. Let me show you what the preliminary configuration looks like on R2. Everything else remains the same on R1 and R3.
hostname R2
!
!
ip vrf ACCOUNTING
!
ip vrf ENG
!
interface Ethernet0/0
ip vrf forwarding ENG
ip address 10.1.1.1 255.255.255.252
!
interface Ethernet0/1
ip vrf forwarding ACCOUNTING
ip address 10.2.2.1 255.255.255.252
We now have Eth0/0 in VRF ENG and Eth0/1 in VRF ACCOUNTING. This means that the main routing table on R2 is empty. As of the day of this post, route leaking from VRF to VRF is not supported. 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. Let me show you what the configuration looks like.
R2(config)#ip route vrf ENG 3.3.3.3 255.255.255.255 10.2.2.2 global
R2(config)#ip route vrf ACCOUNTING 1.1.1.1 255.255.255.255 10.1.1.2 global
Here we have 2 static routes:
- In VRF ENG, we’re saying in order to get to 3.3.3.3 then your next hop is 10.2.2.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.1.1.2 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.
R2#sh ip route
Codes: L – local, C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route, H – NHRP, l – LISP
a – application route
+ – replicated route, % – next hop override
Gateway of last resort is not set
R2#
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.1.1.2 and 10.2.2.2, we need to add two more static routes and point them to their respective exit interface. Let’s do that.
R2(config)#ip route 10.1.1.2 255.255.255.255 Eth0/0
R2(config)#ip route 10.2.2.2 255.255.255.255 Eth0/1
R2(config)#
R2(config)#
R2(config)#do sh ip route | b Gateway
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 2 subnets
S 10.1.1.2 is directly connected, Ethernet0/0
S 10.2.2.2 is directly connected, Ethernet0/1
R2(config)#
Hello I'm Pape. My friends call me Pop. I'm CCIE #48357. I enjoy my field and love to share it with others. I love to write so I'm sharing my blog with you.
Hello Papy, Nice post c’est Clair et Concis.
A noter que sur les ASR100 et ISR 4K tu as aussi la possibilité de faire du leaking de vrf en s’appuyant sur la technologie Vasi (vrf aware software infrastructure), ça permet par exemple de pouvoir fournir des services partagés type « INTERNET: VRF INTERNET » à différents types de populations type « GUEST:VRF GUEST ».
Hello Said. Tu as parfaitement raison; En effet, je prendrais le temps d’écrire un post là-dessus. Je pense que ce serait intéressant de mettre en évidence les différentiels vis-à-vis de IOS-XE.
Nice article. In scenario 1, how does R2 have a route for the ICMP reply from 10.2.2.2 in the route leak VRF to 10.1.1.1 in the default VRF?
OK, I figured out the question in my last comment. ip vrf receive actually adds the connected route of the interface the command is applied to, to the VRF specified. So, in this case, 10.1.1.0/24 is actually added to the ROUTELEAK VRF, which makes sense.
I think you have a typo then in the explanation of that command. Thanks!
Hello I realize this is a little dated but still very useful in my opinion. Need some clarification if you don’t mind. I don’t quite follow the first example. First, For traffic going from R1 to R3 why would you need to policy route anything if you have already leaked the routes into the Global routing table via the command ? Wouldn’t that mean that the ICMP traffic sourced from R1 10.1.1.2 and destined to 10.2.2.2 would find the route to 10.2.2.2 in R2’s Global Route table? Second, for ICMP traffic returning from 10.2.2.2 destined 10.1.1.2, how would R2 be able to route that to 10.1.1.2 if the interface between R2 and R3 is in a VRF? From the configuration it doesn’t look like we have done anything to address the return traffic from R3 destined to R1. I’m sure I am missing something. Thank you for any clarification.
Correct ! 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.
Question 1: First, For traffic going from R1 to R3 why would you need to policy route anything if you have already leaked the routes into the Global routing table via the command ?
Answer: From which command ? We have not leaked the routes here
Question 2: Wouldn’t that mean that the ICMP traffic sourced from R1 10.1.1.2 and destined to 10.2.2.2 would find the route to 10.2.2.2 in R2’s Global Route table?
Answer: On R2, you have 2 interfaces, 1 in the global routing table and the other in the ROUTELEAK vrf
Question 3: For ICMP traffic returning from 10.2.2.2 destined 10.1.1.2, how would R2 be able to route that to 10.1.1.2 if the interface between R2 and R3 is in a VRF?
Answer: On R2, I’m using the “ip vrf receive ROUTELEAK” command subsequently allowing the injection of R1 route into the VRF. This command is applied on the interface pointing to R1 from R2