05-04-2012 02:44 AM - edited 03-04-2019 04:15 PM
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.
05-04-2012 02:56 AM
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
05-04-2012 03:23 AM
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,
05-04-2012 04:27 AM
Hello Duncan,
your understanding is correct, I tested this feature some years ago on C7200 with NPE-G1
Hope to help
Giuseppe
05-04-2012 04:33 AM
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,
05-04-2012 06:14 AM
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,
05-04-2012 08:23 AM
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
05-04-2012 08:42 AM
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,
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide