Problem with static "hold-down" routes

derekgaeth · ‎10-02-2008

Hi

We appear to having some issues with the hold down routes on our c6509e border routers. We use a collapsed core model, so the border routers also act as IBGP route reflectors to the core routers.

The core routers advertise (IBGP) routes to the border routers, which then advertise (EBGP) upstream to the internets.

If the core stops advertising internal routes to the borders, the border router hold down routes[1] continue to advertise our networks upstream to the internets, without the risk of being dampened(if there is any flapping).

When this happens the IBGP routes learned from the core are removed from the border router FIB's, and replaced with static-hold down routes. The problem we are seeing is that when the BGP routes are re-learned from the core, they are placed into the RIB, but do not replace the static-hold down routes in the FIB table. The main issue is that any external ingress traffic destined for hosts in the core hit the border routers, but obviously goes no further.

As soon as I remove the static hold-down routes from the borders, the IBGP routes get added back into to the FIB, and external ingress traffic can reach hosts in the core. After I re-add the hold-down routes, the IBGP routes continue to remain in the FIB.

Has anyone else struck this problem before? Sounds almost like an IOS bug.

[1] e.g. â€œip route 192.168.0.0 255.255.252.0 loopback0 250â€ admin distance = 250

TIA

Giuseppe Larosa · ‎10-03-2008

Hello Derek,

usually these static routes are configured to null0 with AD > iBGP AD so 250 is fine.

in your case if you use as nexthop an HSRP VIP of the two core routers you should be able to forward traffic to the core switches

even if the iBGP routes are not installed.

However, to be sure that iBGP routes are correctly reinstalled you need to set a BGP weight to a value > 32768 because the locally originated routes have weight 32768.

so under router bgp do

neigh core1 weight 40000

neigh core2 weight 40000

this should be enough to have the iBGP paths reinstalled when they are advertised again.

in the BGP table only the BGP attributes + weight are used to choice the best path and AD plays no role: it is used by the process that mantains the IP routing table

Hope to help

Giuseppe

tf2-conky · ‎02-10-2009

Thanks for your help with this. This worked fine.

Note - Since we run a collapsed core/border I had to enable this on all ebgp neighbor peers as well. Adding the static weight entry to only ibgp neighbor peers had the effect of overriding local preference. This prevented some multihomed BGP customers from using local preference to determine path selection.