Showing results for 
Search instead for 
Did you mean: 
David Williams

Stripping weight 32768 from BGP redistribution. Danger?

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 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 Multilink1 250

address-family ipv4 vrf test

no synchronization

redistribute connected route-map  CUSTOMER-Connected-Redistribute

redistribute static route-map CUSTOMER-Static-Redistribute

network mask route-map STRIP-WEIGHT-32768

default-information originate




Accepted Solutions

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,


View solution in original post

Peter Paluch
Hall of Fame Cisco Employee