iBGP Neighbor Teardown

[DuncanM2008]

Hello,

I've got an issue with an pair of iBGP neighbors communicating via loopback's reachable via Gi0/2.

When Gi0/2 drops it takes 3 minutes (180 Sec holdown timer) for the iBGP routes to dissappear from the RIB, I want to improve the convergence time considerably to almost instant, the way I see it I have two options:

A) Adjust BGP timers for Keepalive & Holdown for the iBGP neighbor to the point it converges faster.

B) Use an EEM CLI statement to manually destroy the iBGP session.

I currently have a HSRP group on Gi0/2 which uses a Track object for Gi0/2 line-protocol, there's also an EEM script already in place to alert when the Track & HSRP failover so I could just add another action that runs "clear ip bgp x.x.x.x"

Obviously option B is the fastest option in terms of convergence.

Thanks,

Duncan.

[Giuseppe Larosa]

Hello Duncan,

if you have an IGP running to advertise loopbacks between iBGP peers you could take advantage of BGP next-hop tracking

see

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t14/feature/guide/gt_bnht.html#wp1027258

it should give IGP convergence speed instead of relying on BGP session timers

Hope to help

Giuseppe

[DuncanM2008]

Hi,

That's excellent I'll do some reading up on that, you're correct the iBGP loopbacks are advertised via OSPF (Area 0) and naturally the OSPF neighbor dies as soon as Gi0/2 goes down.

So in theory the iBGP Neighbor should die at the same time as the OSPF Neighbor does if I understand correctly?

Thanks,

[Giuseppe Larosa]

Hello Duncan,

your understanding is correct, I tested this feature some years ago on C7200 with NPE-G1

Hope to help

Giuseppe

[DuncanM2008]

I'll give it a test and let you know how it works, should post back results in a few hours, Interestingly enough I'm running this environment on a C7206 with an NPE-G2.

IOS 15.0(1)M5

Many Thanks,

[DuncanM2008]

Hello,

Just tested this and it didn't seem to work, I took the following output from the "sh ip bgp neigh x.x.x.x":

"Address tracking is enabled, the RIB does not have a route to x.x.x.x"

At this point the interface was down as was the Track state, HSRP & OSPF.

So no route was availble to x.x.x.x and the next-hop address would also be unavailable.

Have I configured it wrong?

"address-family ipv4 unicast"

"bgp next-hop trigger enable"

Thanks,

[Giuseppe Larosa]

Hello Duncan,

it looks like correct and desired behaviour: it has to detect the BGP next-hop failure.

Are the iBGP routes removed from RIB and IP routing table before BGP timers expire ?

This is the key point: the feature is effective if iBGP routes are timely withdrawn without waiting for BGP session hold time timer expiration.

Hope to help

Giuseppe

[DuncanM2008]

Hi,

I think I've mis-understood the feature I was expecting the Neighbor relationship to drop, I never even thought to see if the iBGP routes we're still present in the RIB.

User error, say no more.

I'll organise a re-test hopefully tommorow and I'll implement next-hop-tracking on other iBGP peer to make sure both routers remove iBGP routes.

I'll post my results again tommorow, many thanks for your prompt response and helpful answers!

Dunc,