Stripping weight 32768 from BGP redistribution. Danger?

[David Williams]

Good afternoon everyone!  I have an idea I would like some input on from others on here that involves using weighted static routes that get redistributed into bgp on a backup link.

So here is the scenario.  CPE-A connects to PE-1 via a T1.  This connection terminates into a client specific MPLS VPN using vrf blue.  BGP is being used to advertise LAN routes up to the ipv4 vrf address-family on PE-1 and PE-1 advertises a default route to CPE-A.  Pretty straight forward so far. 

Now the client wants to add in CPE-B with an internet connection and a PTP IPSEC tunnel back to vrf blue as a backup.  Great!  Normally we would probably just use IPSEC protected GRE tunnels and another BGP peer and use Local Pref to control the primary secondary path.  Well what if CPE-B doesn't run BGP?  In the past we tried to use floating statics with an AD of 250.  This worked when the primary failed but it would never fully fail back to the primary once it came back because, once redistributed into BGP, that floating static gets a weight of 32768 applied in BGP and that router doesn't give up the static.  So, what I'm thinking is creating a route-map that sets the weight to 0 and add a network statement to the ipv4 vrf address-family with that route-map applied to strip the weight.

So lets say I want to add a floating static to PE-2 for 10.10.20.0/24 to point down a backup connection.  I add the network statement and static route below.  Then on my primary link I up the local preference to 110 on prefixes learned from that CPE so that they will always be preferred as long as we are learning them. 

It's kind of a hack but does anyone see how this could break anything else? 

ip route vrf test 10.10.20.0 255.255.255.0 Multilink1 172.16.1.2 250

address-family ipv4 vrf test

no synchronization

redistribute connected route-map  CUSTOMER-Connected-Redistribute

redistribute static route-map CUSTOMER-Static-Redistribute

network 10.10.20.0 mask 255.255.255.0 route-map STRIP-WEIGHT-32768

default-information originate

exit-address-family

end

[Peter Paluch]

Hi David,

Your plan looks good. Personally, I do not see any outstanding issues with that. Effectively, you are deactivating the weight attribute evaluation for that network and you are letting other attributes decide which path is better.

Note, however, that zeroing the weight attribute alone might not be enough. The second parameter in the Cisco's BGP bestpath selection algorithm is the local preference, and the third is to prefer locally injected network. From this it follows that in addition to zeroing the weight, it will be probably necessary to decrease the local preference of this locally injected network and/or increase the local preference of the BGP-discovered network.

These are my thoughts - I hope other friends here will add their insight!

Best regards,

Peter

[Giuseppe Larosa]

Hello David,

>> This worked when the primary failed but it would never fully fail back to the primary once it came back because, once redistributed into BGP, that floating static gets a weight of 32768 applied in BGP and that router doesn't give up the static.

I solved the same problem years ago using neigh x.x.x.x weight 40000 in order to solve the problem of restore of primary link.

I'm not sure if this alternate solution can work it should work by also lowering local preference as noted by Peter.

But I liked your creativity.

Hope to help

Giuseppe

[David Williams]

This is encouraging guys. Thank you very much.  I am cautiously optimistic about this design.  I too am uncertain as to whether the primary route will be preferred when it comes back.  Since the primary link and the secondary link reside on separate PE routers if they each prefer different routes, they will advertise that upstream to the rest of the PE and Core routers, which gives me a whole slew of other things to contend with.  I like the idea of using the route map I am using to zero out the weight on the backup PE to also drop the Local Preference to 90.  That would put the preference lower than the default of 100 on the primary connection making it less preferred by the rest of the network, and thus it should receive the primary route.  It also eliminates any need to modify the primary BGP peering to support the backup scenario.  I'm still not sure if it will take the primary, it will have to go to the lab. 

I will post my results when I get them.  I probably won't get back to it until Tuesday though.  Thank you Gentlemen for your input.  I'm almost excited enough to go in over the holiday weekend and play with this...almost. 

Dave

[marikakis · Accepted solution]

Hi Dave,

You will probably try this in your lab anyway (since it's your baby ), but you might be happy to hear that I've tried this in GNS3 and it works.

Initially we have the BGP external route dominating and static with high distance is suppressed.

I shut the external peer on PE-1.

1) BGP external route disappears from the backbone

2) static gets into vrf blue table on PE-2

3) static gets redistributed into BGP (weight 0, local_pref 90) on PE-2

4) local_pref 90 BGP route reaches PE-1 and is installed there

I restore the external peer on PE-1.

1) BGP external route reaches PE-1

2) local_pref 100 wins the battle on PE-1

3) PE-1 advertises local_pref 100 route to PE-2

4) local_pref 100 route wins the battle with the local_pref 90 route on PE-2 (both have a weight of 0)

5) local_pref 100 route is installed in vrf blue table (distance 200 wins the battle with the static)

6) static is back to were it was before the failure

7) since static is out of the vrf blue table, redistribution of the static into BGP on PE-2 stops

Looks like billiards, doesn't it?

I wonder why you use the network command to set the weight and not do that at the point where you redistribute the statics. Anyway, it's not that important and both ways work. The weight must be set to 0 as you indicated, else locally sourced BGP route on PE-2 stays in BGP table and the static will not go away from the vrf table. The local preference must also be set somewhere (as all of you said), else the algorithm on PE-2 will go down and prefer locally sourced routes (it's needed for selection on PE-1 anyway). I can't think of any other (or at least more beautiful) solution to make the BGP route sourced from PE-2 to go away. Since client doesn't run BGP, we are pretending their routes are both local and non-local.

Kind Regards,

Maria

[shivlu jain]

I also got the same issue but in that case I increased the weight of the route by using route map.

check this:- http://www.mplsvpn.info/2009/04/bgp-as-pe-ce-with-backboor-link.html

regards

Shivlu Jain

[David Williams]

Fantastic Maria!  You are right, I will still build it in my lab, but the additional validation is very much appreciated! Very well laid too I might add.  It could not have been more clear.

As for the network statement, it was also my first instinct to make the modifications at the point of redistribution.  The motivator for trying the network statement is really to try and keep the solution as easy to understand for the support staff while minimizing the amount of config on the PE router.  If I perform the weight and LP modifications at redistribution, each client will need a custom route map and prefix or access lists to only match the backup route.  We currently utilize a standard route map for static redistribution that is used for management purposes. This approach allows me to

A.) leave the standard route map on the static redistribution (what support expects to see).

B.) create one route map for weight and LP modification that can be shared by all clients with this type of backup

C.) Hopefully, makes it clear what is happening simply by looking at the vrf address-family config and not having to trace down route maps and prefix lists

These things all benefit me because if there is a problem it will hopefully get resolved within the standard support group.

Thanks again for the input Maria! Very good stuff!

Dave