Routing Problems with Floating routes not kicking back.

hks10 · ‎10-12-2005

Experiencing static routes not kicking back from floating routes in different PE's.

Scenario:

We have a static route in PE1 pointing to an interface for a leased line. We also have the same subnet with a admin distance of 220 route in another PE2 for a fail over. When the main static route in PE1 fails the floating route in PE2 kicks in right away but then will not go away out of the routing tables in all the PE's when the main static route comes back up. I have to manually go into PE2 and remove the floating route to remedy this. Is there another way or am I missing something to remedy this between PE's? Any help would be appreciated.

nz-ipv6 · ‎10-12-2005

Hi hks,

I am assuming you are redistributing floating static into BGP on PE2.

I had the same problem and I have sorted it out by making sure that the flotaing static routes being redistruted have set their weight to 0 and advertise them with AS-Path prepend.

Here is my config at PE2.

router bgp 65001

redistribute static route-map sw

neighbor EBGPpeer route-map SM out

!

route-map sw permit 10

set weight 0

!

route-map SM permit 10

match ip address prefix-list SM

set as-path prepend 65001 65001 65001

!

route-map SM permit 20

!

ip prefix-list SM seq 10 permit x.x.x.0/24

!

ip route x.x.x.0 255.255.255.0 g9/45 10.128.0.241 220

Please let me know in case you need more info.

Cheers

Trib

olorunloba · ‎10-12-2005

I think the problem is that admin distance configured on the static route only has local significance on PE2. Once the backup kicks in, it will stay in because to the remote BGP routers, the routes have the same properties (metrics). The answer lies in modifying a BGP attribute so that other routers can see which is preffered.

I will not advice weight, because it is not propagated to peers. Rather than increasing the AS-Path, I feel local preference would be a neater and better solution.

hks10 · ‎10-12-2005

Hi olorunoba your assistance is much appreciated as well. I will need your assistance with this as well. How would I go about achieving this change to a specific vrf and it's routes.

hks10 · ‎10-12-2005

Hi nz-ipv6 thanks for your help with this situation. I actually need a little more assistance. My question to you would be how would I go about addressing this situation to a specific vrf?

nz-ipv6 · ‎10-12-2005

Hi hks,

I think, All you need to do is make it relevant for for a specific vrf.

If you can send me the relevant config, I will try and send you the modified one.

Thanks

Trib

olorunloba · ‎10-12-2005

you can try this

ip route vrf vpn x.x.x.x y.y.y.y z.z.z.z 220

route-map red

set local-preference 50

router bgp x

address-family ipv4 vrf vpn

red static route-map red

If you want a subset of the vrf routes to be mathed, then you might have to create an access-list or profix list to match in the route-map.

The solution would work also, for ipv4 routes.

nz-ipv6 · ‎10-12-2005

This will not work on PE2.

PE2 will still use the local floating static route.The reason is that static routes are redistributed with weight of 32768.

And for the BGP Best path alogrithm weight is before Local Preference.

olorunloba · ‎10-13-2005

Haaa, I see your point. The weight is for the local router.

hks10 · ‎10-13-2005

Hi nz-ipv6 I've been trying to get this going but if you could give a helping hand I would appreciate it.

I tried to apply the route-map with the local preference but could not apply it to the specific address family for the vrf. I won't be able to prepend using the AS because of all the other vrf's we have. I just need to be specific for a particular vrf. I tried to look for commands and how to apply it all over the place but could not find any. Can you assist?

router bgp xxxxx

no synchronization

no bgp default ipv4-unicast

bgp log-neighbor-changes

neighbor pe-bgp peer-group

neighbor pe-bgp remote-as xxxxx

neighbor pe-bgp update-source Loopback0

neighbor x.x.x.x peer-group pe-bgp

no auto-summary

!

address-family ipv4 multicast

no auto-summary

no synchronization

exit-address-family

!

address-family vpnv4

neighbor pe-bgp activate

neighbor pe-bgp next-hop-self

neighbor pe-bgp send-community extended

neighbor x.x.x.x peer-group pe-bgp

no auto-summary

exit-address-family

!

address-family ipv4 vrf cust1

redistribute connected

redistribute static

no auto-summary

no synchronization

exit-address-family

!

ip route vrf cust1 10.11.0.0 255.255.255.0 10.253.3.30 210

!

route-map cust1 permit 10

set local-preference 50

attrgautam · ‎10-13-2005

We solve these issues always using local pref ( We redistribute the 2ndry route using a lower local pref). We dont prefer weight at all somehow as it has only a local significance.

olorunloba · ‎10-13-2005

Yes, setting a local preference would ensure that the other routers sees it as a backup route. But the router on which it is configured (PE2 in this situation) would still prefer it, as it was rightly pointed out that the redistributed routes have a weight of 32678 and weight are considered before local preference in the path selection.

Hence the weight configuration is to ensure that the local router also uses the route as a backup. Both the weight and local preference is needed for a comprehensive solution.

attrgautam · ‎10-13-2005

But if my route in PE2 has an AD of 220 , then it should not create an isue, as it will learn 200 AD from PE1, that should work right. Jus a thought

olorunloba · ‎10-13-2005

Yes, thats the initial thought, but you find it does not work exactly like. During initial configuration, the static route does not kick in. But after failing over, the route is not injected out. It seems to me that once the route has been redistributed into BGP, the AD is not used anymore. Someone might want to give a more technical explanation.

attrgautam · ‎10-13-2005

No i believe that was the behavour for an entire network and i think it is an issue because the comparison is between 2 BGP routes across the network so AD doesnt even come into the picture. But adding a 220 AD with a lower local pref may jus solve the issue. What do u think ;-)