Hi everyone,
Is it a way to inject routes learned in a vrf via the route-target statement into the global routing table ?
To resume, my vrf have learned a route via route-target import ASN:nn and that route is now present in the vrf routing table. I’m looking a good way to also have that route in the global routing table.
Thanks
Hello Thierry
Route leaking using the route-target command can only be used to leak routes between VRFs. In order to leak routes between the VRF and global routing tables, take a look at the following two documents from Cisco:
Take a look and if you have any further questions, let us know!
I hope this has been helpful!
Laz
Hard for me to understand what you are trying to teach in this article !
Why do you not show (in the schema) an example of shared service : DNS, DHCP, FTP, NTP, … ?
It would be more clear if you use PE1 and PE2 routers and BLUE and RED customers connected on each side of PE routers.
Using VRF-Lite, I’d like to configure a VRF “clients” and keep those networks separate from the GRT (eg. common traffic). However, I only have 1 gateway out to the Internet. Is it possible for the “clients” VRF to share the gateway of last resort used by the GRT? I would suspect this would be done by means of route leaking, but I haven’t been able to get things working. This entire config is present on the same router. Thnx.
Hello William
You are correct that in order to implement what you are looking for you will have to use route leaking. You can do this by either using static routes, or MP-BGP. Keep in mind that for the static routes option, static routing between VRFs is not supported. You will have to create a global routing table and route traffic from one VRF to the global routing table to the other VRF. This is described with examples in the following lesson:
You can also do it with muptiprotocol BGP where the routing protocol can redistribute routes from one VRF to another. This too is found in the lesson.
Go through the lesson and if you have any questions, let us know!
I hope this has been helpful!
Laz
1 Like
Hey Thanks Laz!
Via MP-BGP, would you say with my given topology that this would be the best practices scenario? We’re gonna give it a whurl today.
Best Wishes!
Hello William
It depends on what you want to achieve. If you only have a single router, using static routing may be a more straightforward and simpler to troubleshoot scenario. However, MP-BGP is equally correct, and may be more beneficial for you to learn more. In any case, let us know how you do and what your results are!
Laz
I think the vrfs of the routes in the example are reversed:
- I can only get the output that matches the
show ip route vrfcommand with the vrfs reversed. - Logically if you don’t tell vfr RED how to reach 1.1.1.1 how is it going to know? The same with vrf BLUE knowing how to reach 3.3.3.3 on Blue1. There is no routing protocol between the ISP router and either customer router, so you must have a static route to do it, and that static should tell the vrf how to reach the loopback in it’s own “color”.
If you put in the routes in the example without BGP, you have only the connected routes of the interfaces in the vrf routing tables. Neither vrf can reach it’s own loopback.
If you put in the static routes with the opposite vrf name and without BGP, you can ping 1.1.1.1 from vrf RED, and 3.3.3.3 from vrf BLUE.
I have spent quite a while studying this and I can’t make sense out of the example as posted.
Hello Bruce
Keep in mind that the VRF configurations are found only within the ISP router. The Red1 and Blue1 routers have no concept of what VRFs are, and simply have a routing table that includes all of their directly connected networks (including loopbacks) as well as a static route to the ISP router.
Hmm, that’s interesting. Can you verify your configurations? Take a look at the rest of this post, and see if it clarifies anything for you…
The answer is, it doesn’t need to know. Take a look at this step by step description of a ping from loopback to loopback:
- When Red1 pings 3.3.3.3, it will use the default route to get to the ISP router.
- The ISP router, which knows the packet should be routed using the RED VRF, will look up the IP address 3.3.3.3 in it’s RED VRF routing table and determine the next hop IP
- The ISP router will then look in its global routing table to see what interface it should exit from, and it will send it to Blue1
- Blue1 will receive the packet and send it to its final destination L0
- Blue1 will then respond to the ping, with a destination of 1.1.1.1 (the source of the ping). It will use the default gateway entry to be sent to the ISP router
- The ISP router, which knows the packet should be routed using the BLUE VRF, will look up the destination IP address 1.1.1.1 in it’s BLUE VRF routing table and determine the next hop IP
- The ISP router will then look in its global routing table to see what interface it should exit from, and it will send it to Red1
- The Red1 router will receive the packet and send it to its final destination L0.
The RED or BLUE VRFs in the ISP router don’t have to know how to get to the L0s on their respective routers simply because you will never need any direct communication from the ISP router to the L0s. Communication will always take place from customer router to customer router, since the ISP will only deal with transient traffic.
I hope this has been helpful!
Laz
1 Like
Bruce-config.txt (3.8 KB) Lesson-config.txt (3.8 KB)
I have uploaded the configurations and the show commands for each. One thing that is odd to me is that in both configurations the Red router can ping 3.3.3.3 with source 1.1.1.1 and traceroute looks identical as well.
In the step by step that you give I don’t see how the ISP router can use the global routing table for anything. When I show the global routing table there is nothing in it, since both interfaces are in VRFs. So when Blue sends the reply back to Red, it knows the next hop for 1.1.1.1 is in Red. Does the router hand the packet to Red to use it’s routing table, or does Blue just send the traffic out the Red interface on the 192.168.12.1 next hop?
Maybe I am thinking about this incorrectly, but doesn’t Red need to “leak” the route to 1.1.1.1 into Blue so that Blue can get across the VRF barrier?
Also, Blue has a BGP route to 192.168.12.0/24 via Ethernet0/0 in both configurations. My interpretation is that this is the route that permits Blue to send to the Red interface of Etherenet0/0.
I really appreciate the work that you have put into responding to this. I am no expert on VRFs, but if I can understand how the router is working then I can “think like a router” when troubleshooting issues.
Hello Bruce
The step by step that I gave had to do with the first situation using static routes. In this case the ISP router is configured with an entry that for any route to 3.3.3.3 or to 1.1.1.1, the router is directed to look at the global routing table. The global routing table in turn has been configured with the appropriate exit interfaces for the next hop IP addresses of Red1 and Blue1, routing is complete. So you should see entries in the global routing table.
In the second situation with MP-BGP, there is indeed no global routing table. In this case, we have redistribution between the VRFs directly.
Getting a closer look, I do believe you are correct. For the MP-BGP section of the lesson, the configuration should indeed be:
ISP(config)#ip route vrf RED1.1.1.1 255.255.255.255 192.168.12.1
ISP(config)#ip route vrf BLUE 3.3.3.3 255.255.255.255 192.168.23.3
This is confirmed with the fact that the resulting output of show ip route vrf RED bgp and show ip route vrf RED bgp match the output you have from your config rather than that shown in the lesson config that you shared.
I will get @ReneMolenaar to take a look and confirm to make any necessary changes.
It turns out that both will work in this topology. You are correct in your interpretation. It turns out that the routing tables for both VRFs for both your and the lesson’s configurations, are the same EXCEPT for the fact that the routes to the particular destinations are learned from different sources. However, the correct method of leaking does require that the config be as described above.
Thank you for your insistence, and your help in pointing this out!
Laz
Hello @grunewald.bruce
TLDR: You are correct, this is a typo. I just fixed this.
Let’s take a look though at what happened and why it works with both scenarios.
Scenario 1
Here is my (old) example with two static routes:
ISP#show run | incl ip route
ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1
ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3And MP-BGP:
ISP#show run | section bgp
router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
!
address-family ipv4 vrf BLUE
redistribute connected
redistribute static
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
redistribute static
exit-address-familyLet’s look at the end result. FIrst, we want to get to 3.3.3.3 from RED:
ISP#show ip cef vrf RED 3.3.3.3
3.3.3.3/32
nexthop 192.168.23.3 GigabitEthernet0/2ISP#show ip cef vrf RED 192.168.23.3
192.168.23.3/32
attached to GigabitEthernet0/2The ISP router knows we can get to 3.3.3.3 through 192.168.23.3. How did it learn this? Let’s see:
show ip route vrf RED 3.3.3.3
Routing Table: RED
Routing entry for 3.3.3.3/32
Known via "static", distance 1, metric 0
Redistributing via bgp 2
Advertised by bgp 2
Routing Descriptor Blocks:
* 192.168.23.3
Route metric is 0, traffic share count is 1ISP learned about 3.3.3.3 because of the static route. This is how it learned about 192.168.23.3:
ISP#show ip route vrf RED 192.168.23.3
Routing Table: RED
Routing entry for 192.168.23.0/24
Known via "bgp 2", distance 20, metric 0 (connected, via interface), type external
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/2
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: noneWe learned this through BGP.
Let’s check how we can get to 1.1.1.1 from BLUE:
ISP#show ip cef vrf BLUE 1.1.1.1
1.1.1.1/32
nexthop 192.168.12.1 GigabitEthernet0/1ISP#show ip cef vrf BLUE 192.168.12.1
192.168.12.1/32
attached to GigabitEthernet0/1This is how we learned about 1.1.1.1:
ISP#show ip route vrf BLUE 1.1.1.1
Routing Table: BLUE
Routing entry for 1.1.1.1/32
Known via "static", distance 1, metric 0
Redistributing via bgp 2
Advertised by bgp 2
Routing Descriptor Blocks:
* 192.168.12.1
Route metric is 0, traffic share count is 1We learned it because of the static route. This is how we learned about next hop 192.168.12.1:
ISP#show ip route vrf BLUE 192.168.12.1
Routing Table: BLUE
Routing entry for 192.168.12.0/24
Known via "bgp 2", distance 20, metric 0 (connected, via interface), type external
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/1
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: noneWe learned 192.168.12.1 through BGP. Ok, so far so good…this works, but technically it’s not how it should be.
Without BGP, the ISP router should be able to:
- Reach RED1 loopback0 within VRF RED.
- Reach BLUE1 loopback0 within VRF BLUE.
And when that works, we can “leak” information from RED into BLUE and vice versa.
Scenario 2
First, let’s get rid of BGP:
ISP(config)#no router bgp 2And get rid of the static routes:
ISP(config)#no ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3
ISP(config)#no ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1Add the correct static routes:
ISP(config)#ip route vrf RED 1.1.1.1 255.255.255.255 192.168.12.1
ISP(config)#ip route vrf BLUE 3.3.3.3 255.255.255.255 192.168.23.3Let’s make sure the ISP router can reach the loopback interfaces from WITHIN the VRFs:
ISP#ping vrf RED 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 msISP#ping vrf BLUE 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 msThis works, so now we can “leak” the routes between the VRFs. Add the exact same BGP configuration again:
ISP#show run | section bgp
router bgp 2
bgp router-id 2.2.2.2
bgp log-neighbor-changes
!
address-family ipv4 vrf BLUE
redistribute connected
redistribute static
exit-address-family
!
address-family ipv4 vrf RED
redistribute connected
redistribute static
exit-address-familyLet’s verify our work. How does the ISP router get to 3.3.3.3?
ISP#show ip cef vrf RED 3.3.3.3
3.3.3.3/32
nexthop 192.168.23.3 GigabitEthernet0/2ISP#show ip cef vrf RED 192.168.23.3
192.168.23.3/32
attached to GigabitEthernet0/2And how did we learn this?
ISP#show ip route vrf RED 3.3.3.3
Routing Table: RED
Routing entry for 3.3.3.3/32
Known via "bgp 2", distance 20, metric 0, type external
Last update from 192.168.23.3 00:03:14 ago
Routing Descriptor Blocks:
* 192.168.23.3 (BLUE), from 0.0.0.0, 00:03:14 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: noneThe ISP router learns about 3.3.3.3 through BGP, it’s what we redistributed.
Here’s how we get to the next hop:
ISP#show ip route vrf RED 192.168.23.3
Routing Table: RED
Routing entry for 192.168.23.0/24
Known via "bgp 2", distance 20, metric 0 (connected, via interface), type external
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/2
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: noneAlso learned through BGP.
Let’s check BLUE:
ISP#show ip cef vrf BLUE 1.1.1.1
1.1.1.1/32
nexthop 192.168.12.1 GigabitEthernet0/1ISP#show ip cef vrf BLUE 192.168.12.1
192.168.12.1/32
attached to GigabitEthernet0/1ISP router knows how to get to 1.1.1.1 in BLUE. How did we learn this?
ISP#show ip route vrf BLUE 1.1.1.1
Routing Table: BLUE
Routing entry for 1.1.1.1/32
Known via "bgp 2", distance 20, metric 0, type external
Last update from 192.168.12.1 00:04:35 ago
Routing Descriptor Blocks:
* 192.168.12.1 (RED), from 0.0.0.0, 00:04:35 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: noneWe learned about 1.1.1.1 through BGP. Here’s how we learned the next hop:
ISP#show ip route vrf BLUE 192.168.12.1
Routing Table: BLUE
Routing entry for 192.168.12.0/24
Known via "bgp 2", distance 20, metric 0 (connected, via interface), type external
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet0/1
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: noneAlso with BGP. This is how it should be. Let’s do a quick ping just to make sure:
RED1#ping 3.3.3.3 source 1.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/3 msAnd… it’s a wrap! 
I hope this helps, sorry for the confusion. You really thought this through so good job!
Rene
Hi Rene,
I am not clear what you say here,
"Static Routes
Let’s start with the static routes option. According to this Cisco document, static routes directly between VRFs are not supported. What does work, is routing traffic from a VRF to the global routing table and then to the destination VRF. "
I did one LAB and I had no need to push this to GLOBAL VRF, I don’t know if I am not wrong.
I setup same topology… Here is my all the three routers configurations,
ISP
===
ISP#sh ip route
Codes: 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
Gateway of last resort is not set
2.0.0.0/32 is subnetted, 1 subnets
C 2.2.2.2 is directly connected, Loopback0
ISP#
ISP#sh ip route vrf RED
Routing Table: RED
Codes: 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
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 [1/0] via 192.168.12.1
3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 192.168.23.3, FastEthernet0/1
ISP#
ISP#
ISP#sh ip route vrf BLUE
Routing Table: BLUE
Codes: 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
Gateway of last resort is not set
1.0.0.0/32 is subnetted, 1 subnets
S 1.1.1.1 [1/0] via 192.168.12.1, FastEthernet0/0
3.0.0.0/32 is subnetted, 1 subnets
S 3.3.3.3 [1/0] via 192.168.23.3
C 192.168.23.0/24 is directly connected, FastEthernet0/1
ISP#
ISP#
ISP#
ISP#sh run | in ip route
ip route vrf RED 1.1.1.1 255.255.255.255 192.168.12.1
ip route vrf RED 3.3.3.3 255.255.255.255 FastEthernet0/1 192.168.23.3
ip route vrf BLUE 1.1.1.1 255.255.255.255 FastEthernet0/0 192.168.12.1
ip route vrf BLUE 3.3.3.3 255.255.255.255 192.168.23.3
ISP#
RED1
=====
RED1#
RED1#sh ip route
Codes: 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
Gateway of last resort is 192.168.12.2 to network 0.0.0.0
C 192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/32 is subnetted, 1 subnets
C 1.1.1.1 is directly connected, Loopback0
11.0.0.0/32 is subnetted, 1 subnets
C 11.11.11.11 is directly connected, Loopback1
S* 0.0.0.0/0 [1/0] via 192.168.12.2
RED1#
RED1#
RED1#sh run | in ip route
ip route 0.0.0.0 0.0.0.0 192.168.12.2
RED1#
BLUE1
=====
Blue1#sh ip route
Codes: 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
Gateway of last resort is 192.168.23.2 to network 0.0.0.0
33.0.0.0/32 is subnetted, 1 subnets
C 33.33.33.33 is directly connected, Loopback1
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Loopback0
C 192.168.23.0/24 is directly connected, FastEthernet0/1
S* 0.0.0.0/0 [1/0] via 192.168.23.2
Blue1#
Blue1#
Blue1#
Blue1#sh run | in ip route
ip route 0.0.0.0 0.0.0.0 192.168.23.2
Blue1#
Verification
=========
RED1#ping 3.3.3.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 96/96/96 ms
RED1#
Blue1#ping 1.1.1.1 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 3.3.3.3
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 64/91/100 ms
Blue1#
Thanks
Manami
Hello Manami
It seems that in your ISP, you have configured the 1.1.1.1 and 3.3.3.3 destinations to be in both RED and BLUE VRFs. This is why you are able to ping directly between these destinations from both routers. Although what you are doing works, it is not considered VRF leaking. You can see that 1.1.1.1 and 3.3.3.3 are both found within the RED and BLUE VRF routing tables.
In order to achieve VRF leaking, the configuration in the lesson is necessary.
I hope this has been helpful!
Laz
Hi Laz,
Is that so… Thank you for clarifying me.
Thank you.
Manami
Hi,
I am trying to understand relation between ACL and VRF. The following statement threw me off - Can you please explain
“Cisco IOS, IOS-XR and Nexus Routers (5K, 7K, 9K), including ACLS and complex VRF architectures with VRF leakage”
what i mean is how are the router ACLs and VRF / VRF leaking impacts each other ?
Hello Surendra
ACLs and VRFs are two separate functions of layer 3 devices. They are generally unrelated, but can and do coexist in the specific devices and platforms. The statement seems to simply state that ACLs and VRFs are supported by the platforms. If we can learn more about where this statement was taken from and what its context is, we may be able to further help you understand what is being said.
I hope this has been helpful!
Laz
Hi
please check the context where this particular statement is used ? Refer to the - Supported Cisco Products and Services
Hello Surendra
Based on the document you shared, it simply states that AlgoSec supports security policy management on those particular IOS versions and platforms, and is capable of managing access list configurations, VRF configurations, and VRF leakage configurations. It doesn’t state that these are interrelated in any way.
I hope this has been helpful!
Laz
thanks for the reply Laz
So if the do the Security Assessment of the Router /Switch i should not be concerned with VRF’s and Route Leaking among VRF’s
I should only be focusing on the Routers ACL’s right ?