VRF Lite Route Leaking

Lessons Discussion
83

Dear Team,

I have been experiencing issue on my lab demonstration that my edge router having one VRF RED and other is a global route table.

From my router to firewall ASA is directly connected link using sub interfaces.

Router side:
Sub interface Gig0/1 .253
Ip address 10.253.8.66/24

Sub interface Gig0/1.254
Ip address 10.254.8.66/24

Asa firewall side:
Sub interface gig0/1.253
Ip address 10.253.8.65/24

Sub interface gig0/1.254
Ip address 10.254.8.65/24

Router and ASA firewall running EIGRP routing.

Router side:

Under vrf RED 
EIGRP 100 is running 
Autonomous system vrf RED 7
Network 10.254.8.64.0/24

Ip Route 0.0.0.0/0 via isp rtr ip 
Ip route 10.73.8.0/24 via 10.253.8.65

(asa firewall sub interface ip)

Asa firewall side:

EIGRP 7 is running
network 10.254.8.64/24
redistribute static
Exit

Route 10.73.9.0 /24 via 10.73.5.5

(core switch ip address for vlan1 )

The issue here is when I show ip route from edge router I can see two different paths to single destination that is to 10.73.8.0/24 subnet

Via 10.253.8.65
D EX 10.254.8.65

It takes two paths. I am not able to ping the ip address of 10.73.8.254 ip which is the SVI of vlan 8 in core switch.

Also pc connected to switch port access vlan 8 doesn’t get internet or not able to reach gateway ip address of edge router or firewall interface ip .

Is the redistribution creating asymmetric route issue or something else.

Appreciate your support on this lab.

Thanks
Mahesh

85

Hi Laz,

Thank you so much for this insight and article I appreciate it!

1 Like
86

Hello Maheshwaran

I am not quite clear on your configuration and your topology. You mention that you see two paths to the single destination. Are both paths learned from EIGRP? And if so, are both paths in the same VRF? It’s not clear in your explanation.

Also, if you cannot ping either from or to the intended host, you should also examine the firewall rules that have been configured. Sometimes although routing may be working correctly, you may find that the ASA may be blocking some of the traffic.

Can you share with us a little more information about your topology? Also, can you share the output of the show ip route command so we can see the routing table? This will help us help you further.

I hope this has been helpful!

Laz

87

It seems the statement has not been fixed.

88

Thanks Sathish, I’ll let @ReneMolenaar know…

Laz

89

Hi @sathish84be

I’m going through the lesson. Which one do you refer to?

Rene

90

Hi Team ,
the course is great. I have a question if an internet link was connected to a G0/3 port of the ISP router. how I configure the ISP router to allow clients of the RED and cient of BLUE router to access the internet on ISP router

91

Hello Ioac

If you have a third interface Gi0/3 on the ISP Router that connects to the Internet, then you can route traffic to the Internet using the global routing table. Let’s assume that we have a router connected to that Gi0/3 interface with an IP address of 10.10.10.1. Then you would create two static routes within the ISP router like so:

ISP(config)#ip route vrf RED 0.0.0.0 0.0.0.0 10.10.10.1 global
ISP(config)#ip route vrf BLUE 0.0.0.0 0.0.0.0 10.10.10.1 global

This would route all traffic from both the RED and BLUE VRFs to the global routing table that routes traffic to the router connected to Gi0/3. Does that make sense?

I hope this has been helpful!

Laz

2 Likes
92

Hi Laz ,
Thank you for your reply.

2 Likes
93

Hi,

In BGP Local RIB are four routes with “*>” symbol (both Red, and Blue VRF). Despite that, only two BGP routes are in routing table. Why?

94

Hello Quirik

In the ISP router, we look at two BGP tables, one for RED and one for BLUE. Without the redistribution of static and directly connected (and the related RD/RT configurations) you would only see two routes in each BGP table. But now you see four, the two that belong to the local VRF and the other two that were redistributed from the other VRF.

When you then look at the routing tables of each VRF, and you look at ONLY the BGP routes, you only see the redistributed routes.

So for the routing table of VRF RED, the only BGP routes you see are 3.3.3.3/32 and 192.168.23.0/24, which are the redistributed routes from VRF Blue.

Similarly, for the routing table of VRF BLUE, the only BGP routes you see are 1.1.1.1/32 and 192.168.12.0/24, which are the redistributed routes from VRF Red.

The other two routes that are in the local VRF in each case are not BGP routes, but directly connected or static, which means they have a better Administrative Distance than the routes in the BGP table, thus they are used instead of the BGP routes. Does that make sense?

I hope this has been helpful!

Laz

95

Hi,

But why they have ‘*>’ symbol in BGP routing table? Shouldn’t they have RIB failure symbol if there are routes with better administrative distance?

96

Hello Quirik

I did a bit more digging and labbed this one up to see the behavior… It turns out that this behavior has nothing to do with the VRFs. It has everything to do with the source of the BGP information.

I created a BGP instance in a router, created a static route, and redistributed that static route into BGP. The result is that the static route appears in the routing table, and the static route also appears as a valid and best path (*>) in the BGP table.

Why? If you have a static route to a particular destination, and you then redistribute that static route into BGP using the redistribute static command under the BGP configuration mode, that installed static route is not considered to be “in conflict” with the information provided by BGP. This is because BGP received that info from that particular static route. So even though the static route does have a lower AD than the BGP route, it is not considered a RIB failure. Does that make sense?

I hope this has been helpful!

Laz

97

Hello Lazarus - this one had me really scratching my head. Before I saw this post I built the model for a second time just to verify the configuration steps one at a time.

I saw this comment initially which left me really perplexed:

So after performing the configuration per the NetworkLessons instructions and confirming that everything worked ( I had connectivity), I replaced the static routes with those suggested by the subscriber comment. Interestingly, those static routes also work. I don’t really have an explanation as to why but they still provide connectivity - although the output looks slightly different. Probably is due to all the routes being ex/imported and redistributed - you could almost put anything in there for a static route.

In any case, this was an excellent lab exercise that I found very helpful.

This lab prompted me to wonder how we would accomplish selective inter-VRF route leaking — presumably with a route map. The VRF-2-GLobal is fairly straight forward but VRF-2-VRF looks like it is more involved when you try to select only certain routes. Is there an example lab for this on the website?

Regards,

Sandro

98

Hello Sandro

Hmm, that’s an interesting experiment you performed, and thanks for sharing your results.

Indeed, the correct configuration is that in the lesson. But if you tried to do it this way:

ISP(config)#ip route vrf BLUE 1.1.1.1 255.255.255.255 192.168.12.1
ISP(config)#ip route vrf RED 3.3.3.3 255.255.255.255 192.168.23.3

You would be trying to “learn” the 1.1.1.1 route inside VRF BLUE, even though the real customer for 1.1.1.1 lives in RED. Similarly, you’d try to learn 3.3.3.3 inside VRF RED, even though it belongs in BLUE.

Redistribution would then export these wrong routes from the wrong VRFs, which would be conceptually wrong and operationally confusing. In this particular case, it seems to be working because MP-BGP is advertising/redistributing these routes throughout your VRFs. If a next-hop address still resolves correctly within the VRF routing table, you can end up with connectivity in both scenarios. So it may work, but it breaks the logic of source VRF ownership and messes up the route targeting.

I may try to lab this up to see it for myself at some point, it does look like an interesting experiment.

Yes, you are correct, using a combination of route maps with BGP (assuming you’re using MP-BGP) and route targets. As far as I know there isn’t currently a lesson on more advanced VRF route leaking and filtering, but you can make a suggestion at the member ideas page below:

I hope this has been helpful!

Laz

1 Like
99

Hi, for the below will there be any issue if I use the next-hop IP address instead of using exit interfaces Gi 0/1 and Gi 0/2 of the ISP Router ?

I setup a similar lab using Cisco CML, somehow it will not work if I use the next-hop IP instead of exit interfaces.

ISP(config)#ip route 192.168.12.1 255.255.255.255 GigabitEthernet 0/1
ISP(config)#ip route 192.168.23.3 255.255.255.255 GigabitEthernet 0/2

Regards,

Desmond

100

Hello Desmond

This behavior is expected, so not to worry. The important thing is to understand why, and I’ll attempt to explain.

As you know, VRFs create completely isolated routing tables. When you configure a static route in the global routing table pointing to a next-hop IP, the router must perform a recursive lookup to determine the exit interface it must use to reach that next-hop. This is standard behavior whether you have VRFs or not. However, in this particular case, the recursive lookup fails. Why?

When you try ip route 192.168.12.1 255.255.255.255 192.168.12.1, the router checks the global routing table for a route to next-hop 192.168.12.1. If interface GigabitEthernet0/1 belongs to a VRF (and it does), the connected route for network 192.168.12.0/24 exists only in that VRF’s routing table, not in the Global table. Since the Global table has no path to 192.168.12.1, it marks the static route as unresolvable and doesn’t install it.

There’s an additional issue to consider. These static routes are meant to tell the ISP router how to reach the next-hop IP addresses of the Red and Blue routers. In this case, we’re trying to route traffic to the host address 192.168.12.1 and 192.168.23.3.

However, if you configure the routes like this:

ISP(config)# ip route 192.168.12.1 255.255.255.255 192.168.12.1
ISP(config)# ip route 192.168.23.3 255.255.255.255 192.168.23.3

…you run into a fundamental problem: the destination IP and the next-hop IP are the same. The router is essentially being told to reach an address by forwarding traffic to that very same address.

This creates a classic chicken-and-egg situation. Since the router must already know how to reach the next hop in order to resolve the route, these commands provide no usable forwarding information. As a result, this specific configuration cannot work and does not resolve the issue.

So in summary, the fundamental problem of using the next hop IP from the global routing table is that recursive routing will attempt to find the next hop IP in the global routing table, and not in the appropriate VRF. But secondly, for this particular setup, the next hop IP is the same as the original destination we’re trying to reach!

I hope this has been helpful!

Laz