Static Routes on 4430 with VPN not removing Static Routes from Routing Table when BGP Routes return

[redbarron]

I have an Adtran 4430 with many VPN connections going out the WAN interface as backup routes for a lot of the routes that are coming in via EBGP on the LAN interface over a GRE tunnel to our MPLS router.  In normal operation I have all /24 BGP routes in the routing table for the remote sites.  When a site fails on primary the BGP route is removed by the MPLS service provider which the EBGP neighbor then pulls from its routing updates to the 4430 forcing the floating static into the routing table.  All works great as traffic flows to the remote over the floating static /24 with AD of 100.  When the remote sites MPLS connection comes back up I get the /24 back in my BGP table but static route with the /24 remains in the routing table.  If I remove the static route from the 4430 config I can get the BGP route back in the routing table and then re-add the static route.  The BGP on the 4430 has networks statements for all of the static /24 routes.  The only redistribution I have into BGP is connected routes (had a problem in the past where redistribute static caused this issue which is why I went with all the /24 BGP network statements for the static routes).  Revere route injection is off on all VPN's on the 4430).  Any thoughts here?

[jayh]

Is BGP summarizing in any way so that your floating static is more specific? These are eBGP neighbors with AD of 20 and not iBGP with AD of 200, correct?

Kind of sounds like an AOS bug to me if all of the above check out. Just for grins what happens if you make the AD of the floating static 250 or anything >200 ?

[redbarron]

Auto summarization is off and no manual summarization is configured.  This router has only one BGP Peer that is in a different AS.  All the AD's for BGP show up as 20 in route table and BGP table, when a route sticks the static show up as an AD of 100 in the route table and the BGP route in the BGP table for the same network shows up as an AD of 20.

[jayh]

Sure sounds like a bug. I'd check for newer firmware and read release notes, open a case if no joy.

[Anonymous · Accepted solution]

This appears to be working as intended. Step 4 of BGP path selection defined in Configuring BGP in AOS 18.03/R10.1.0 or later‌ states:

"If the AS_PATH distance is identical, prefer the lower origin type (where routes originally injected via the network  mask  or network  command issued from BGP AF configuration mode or aggregation (IGP) are lower in origin than routes learned from a neighbor using eBGP. Routes originally injected by redistribution into BGP (incomplete) have the highest origin value)."

This means that once the static route is placed into the route table, it will not be displaced by a learned BGP route because it was locally originated assuming that the first 3 steps defined in BGP path selection are equal.

If the learned BGP route should always be preferred, an inbound route map can be applied to the neighbor to adjust the LOCAL_PREF value so BGP will prefer the learned route over the local static route. Example 5 in Configuring BGP in AOS 18.03/R10.1.0 or later shows how this can be done.

[jayh]

Jordanjms, I respectfully disagree. The BGP table is not the same as the routing table. In his case the static route isn't being injected or redistributed into BGP. There are two routes, an eBGP route with an AD of 20 and a floating static with an AD of 100. The BGP route should take precedence due to the shorter administrative distance assuming that the netmasks are of equal length.

[Anonymous]

jayh, BGP does not consider administrative distance in its selection process. You are correct in the fact that BGP is separate from the routing table which is precisely why the static route is being placed into the route table.These are two separate processes, so they must be thought of that way. First, BGP makes it's decision to determine what it thinks is the best route. That route is then sent to the route table where administrative distance is used to determine the best route when multiple routes exist for the same network/subnet mask. When you inject a prefix into BGP via the network command, BGP will look in the route table for an existing route for that prefix. If it finds one, it considers that to be a locally originated route. It then goes through it's decision making process outlined in Configuring BGP in AOS 18.03/R10.1.0 or later taking into account the locally originated route and any learned BGP routes to determine what it thinks is the best route. If the route that it determines is the best is locally originated, i.e. an existing static route or route learned via OSPF, that route maintains its AD. At that point, the route table is likely only going to have one route for the network/subnet mask in question (the original route that BGP pulled from the route table as a locally originated route), so that will be the route that gets used. On the other hand, if BGP determines that a non-locally originated route is best then that route is given to the route table, and, if the default AD is being used, that route will have an AD of 20. However, at this point the route table would have multiple routes for that exact network/subnet mask (the original locally originated route and the BGP route), so AD would be used to break that tie.