MPLS L3 VPN update problem

[major133-ac9365513dd]

@Network_Eric
Hi

in this topology i`ve configured R1 PE-1 and R4 PE-2 with

neighbor x.x.x.x as-overrode

which means R5 should advertise lo1 55.5.5.0/24 to R1 PE-1 as an ebgp update. and then R1 advertise that route to R4 as an ibgp update with AS-PATH 56 . and R4 advertise 55.5.5.0/24 to R6 as an ebgp update .

when R4 advertise 55.5.5.0/24 to R6 as an ebgp update,and because i configured R4 with (neighbor 6.6.6.6 as-override) R6 should get this update like this :-

55.5.5.0/24 AS-PATH= 14 14 (56 this happened because R4 configured as-override).

but look here

R4# show ip bgp vpnv4 all
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 14:14 (default for vrf vrf-c)

• i 55.5.5.0/24 1.1.1.1 0 100 0 56 i
  *> 6.6.6.6 0 56 i

R6#show ip bgp Network Next Hop Metric LocPrf Weight Path *>i 55.5.5.0/24 5.5.5.5 0 100 0 i

R6 get ibgp update from R5 . but the question is, why R6 didn`t get ebgp update from R4 like that 55.5.5.0/24 AS_PATH=14 14 ?

R5(config)#interface loopback 1
R5(config-if)#shutdown

R5(config)#interface loopback 1
R5(config-if)#shutdown

PCAP-between-R4-and-R6-after-i-no-shut-lo1-on-R5 hosted at ImgBB

MPLS L3 VPN Configuration.rar

this is my MPLS L3 VPN configuration for R1 R4 R5 R6

[Network_Eric]

Hey Major,

I haven’t had a chance to review your attached configuration files, but assuming everything is correct with your as-override and MPLS configuration, then this is behaving how you’d expect. AS override doesn’t REMOVE an autonomous system from a route, it REPLACES it with your own. So in this case, NWLLA OMNI OLL. The AS Path is no longer 14 56, but rather 14 14.

Now when router 6 receives the route, it checks if it has network reachability, which it does. It then checks weight, that’s the same. Then local preference, that’s the same. It’s not a locally originated route, so now we get to AS Path length. The path through the MPLS network is longer so it doesn’t get added to the routing table.

Now it gets more fun, because the iBGP route is the best route, router 6 will now advertise the route back up to router 4, which because there is only a single AS in the path, as opposed to the one it learned from router 1, router 4 will favor the path through router 6 to get to the destination, so while your layer 3 VPNv4 is properly forwarding traffic, they are both advertising the same routes at each other. Since each side has a better route through their direct connection to the AS, they don’t install the routes they learn from MPLS in to their tables, so they don’t advertise them back out as eBGP routes.

This is an interesting situation you’ve created for your lab, and is fun to look over, but as long as you follow the rules for each device, you’ll see why it gets the results it does. If you shutdown your connection between R5 and R6, you should see R6 learning the route via eBGP. You could also change the Route Distinguisher for only one VRF, which would allow multiple routes to be learned by both sides of the VPNv4 network. At that point it should at least advertise the route to R6, but it still won’t install it due to the issues mention above. But keep in mind, your R5 will also then learn the route coming back from R6, which could cause some recursion issues. I could imagine the route bouncing in and out of the table. R5 loses the locally connected route, stops advertising it to R6, R6 then tries to update R4, but R5 just learned the route from R1, which it then advertises to R6, which it then tells to router 4, and round and round you go.

But that’s just me throwing out ideas to play with. At the end of the day, the behavior you’re seeing is due to AS-Path Length in this case.

[major133-ac9365513dd]

@Network_Eric

@Network_Eric

Now it gets more fun, because the iBGP route is the best route, router 6 will now advertise the route back up to router 4, which because there is only a single AS in the path, as opposed to the one it learned from router 1, router 4 will favor the path through router 6 to get to the destination, so while your layer 3 VPNv4 is properly forwarding traffic, they are both advertising the same routes at each other. Since each side has a better route through their direct connection to the AS, they don’t install the routes they learn from MPLS in to their tables, so they don’t advertise them back out as eBGP routes.

thats really hard . again please i dont understand that .
first of all, you mentioned

@Network_Eric

Now it gets more fun, because the iBGP route is the best route, router 6 will now advertise the route back up to router 4, which because there is only a single AS in the path, as opposed to the one it learned from router 1, router 4 will favor the path through router 6 to get to the destination,

that is really weird for me. PE-2 R4 gets 55.5.5.0/24 via R1 PE-1 with AS-PATH=56 . and at the same time R4 is also get 55.5.5.0/24 via R6 with AS-PATH=56. why you said empty AS-PATH via R6 ?

the tie breaker here is NWLLA OM , N (which is the neighbor type ebgp has AD=20 is better than iBGP has AD=200 )so R4 prefer the eBGP update over the iBGP update.

@Network_Eric

, so while your layer 3 VPNv4 is properly forwarding traffic, they are both advertising the same routes at each other. Since each side has a better route through their direct connection to the AS, they don’t install the routes they learn from MPLS in to their tables, so they don’t advertise them back out as eBGP routes.

no i don`t understand that. again please

[major133-ac9365513dd]

@Network_Eric

This is an interesting situation you’ve created for your lab, and is fun to look over, but as long as you follow the rules for each device, you’ll see why it gets the results it does. If you shutdown your connection between R5 and R6, you should see R6 learning the route via eBGP. You could also change the Route Distinguisher for only one VRF, which would allow multiple routes to be learned by both sides of the VPNv4 network. At that point it should at least advertise the route to R6, but it still won’t install it due to the issues mention above. But keep in mind, your R5 will also then learn the route coming back from R6, which could cause some recursion issues. I could imagine the route bouncing in and out of the table. R5 loses the locally connected route, stops advertising it to R6, R6 then tries to update R4, but R5 just learned the route from R1, which it then advertises to R6, which it then tells to router 4, and round and round you go.

But that’s just me throwing out ideas to play with. At the end of the day, the behavior you’re seeing is due to AS-Path Length in this case.

what is that ? what are you saying ? again please

[Network_Eric]

Hey Major,

Let me try breaking it down. There are two ways things can happen, they both lead to the exact same result.

1. Router 5 creates a neighbor relationship to router 6 and router 1
2. Router 5 shares the subnet 55.5.5.0/24 to both neighbors.
3. It makes the AS Path just a single item long, 56 to both neighbors.
4. Router 1 receives the route and this is the best route it has to that destination, so it installs it in the routing table.
5. Router 1 takes that route, and overrides the original AS number making it 14 14. It then forwards this across the MPLS to router 4
6. Router 4 receives the route and installs it in to the local table because it is the best route it currently has to get to the destination.
7. Router 4 advertises the route to router 6.
8. Router 6 receives the route from router 4 and installs it in the routing table
9. After having installed the route, it finally receives the route from router 5 over the iBGP connection.
10. Because of NWLLA, the route through router 5 is considered the better route (AS path length is a single hop instead of 2 hops).
11. Router 6 only keeps the best route, so it removes the route it learned from router 4 and then installs the route from router 5
12. Router 6 advertises this route to router 4
13. Router 4 receives the route from router 6 and sees that with NWLLA, the AS path is shorter through router 6 than it is through router 1, so it now removes the route it learned from router 1 and installs the route from router 5 into the routing table.
14. Router 4 now advertises the route to router 1, but it also overrides the AS path making it 14 14.
15. Router 1 receives the route from router 4, but it has a longer AS path length than the one it is receiving from router 5, so it ignores the route and does not place it in the routing table.

The other option, is router 6 learns the route over iBGP before router 4 advertises it to router six, which skips the steps of router six ever learning the route from router 4, but everything else plays the same.