08-08-2012 02:40 AM - edited 03-04-2019 05:12 PM
Hi,
I set up Catalyst6500 Quad-SUP VSS system.
I have a problem with slow BGP convergence(80sec) on VSS switchover.
Each chassis has a bgp peer and "bgp graceful-restart" is disabled.
I investigated BGP behavior with "debug ip bgp events" and "debug ip bgp update".
I found that BGP process waited a peer to reply until timeout and after the timeout BGP table was calculated.
I guess this timer makes the convergence slow.
How can I adjust this timer value?
----------------- debug message ------------------
*Aug 8 14:56:09.989 JST: BGP(0): 1.1.1.1 was the first peer to be established for IPv4 Unicast
*Aug 8 14:56:09.989 JST: BGP: nopeerup-delay post-boot, set to default, 60s
*Aug 8 14:56:09.989 JST: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up
*Aug 8 14:56:09.989 JST: BGP(IPv4 Unicast): waiting on established peer 1.1.1.1 EOR
*Aug 8 14:56:09.993 JST: BGP(0): 1.1.1.1 rcvd UPDATE w/ attr: nexthop 1.1.1.1, origin i, metric 100, merged path 11111, AS_PATH 11111
*Aug 8 14:56:09.993 JST: BGP(0): 1.1.1.1 rcvd 0.0.0.0/0
*Aug 8 14:56:10.509 JST: BGP(IPv4 Unicast): waiting on non-established peer 2.2.2.2 for 70s (initial peer up)
*Aug 8 14:56:10.785 JST: BGP(IPv4 Unicast): waiting on non-established peer 2.2.2.2 for 70s (initial peer up)
*Aug 8 14:56:11.533 JST: BGP(IPv4 Unicast): waiting on non-established peer 2.2.2.2 for 70s (initial peer up)
*Aug 8 14:56:12.557 JST: BGP(IPv4 Unicast): waiting on non-established peer 2.2.2.2 for 70s (initial peer up)
*Aug 8 14:56:13.581 JST: BGP(IPv4 Unicast): waiting on non-established peer 2.2.2.2 for 70s (initial peer up)
- snip -
*Aug 8 14:57:19.117 JST: BGP(IPv4 Unicast): waiting on non-established peer 2.2.2.2 for 70s (initial peer up)
*Aug 8 14:57:20.141 JST: BGP(IPv4 Unicast): computed bestpaths, table version went from 10 to 34
----------------- debug message end ------------------
08-08-2012 03:12 AM
Hi Jun,
please find these references:
http://ieoc.com/forums/p/6115/21381.aspx
and
http://stack.nil.com/ipcorner/DesigningBGPNetworks/
but keep in mind that BGP has been designed to be slow and it is NOT a good protocol to replace the job of an IGP.
Hope it helps
Alessio
08-08-2012 11:03 PM
Hi Alessio,
thank you for your reply.
I didn't write that all BGP peers are directly connected EBGP neighbors.
And I've checked that "fast-external-fallover" is enabled by default.
In this case, a BGP initialization occurs on the routing engine(supervisor) switchover.
Why does the BGP process wait the peer connected to rebooting chassis in the BGP initialization process?
Is there any workaround?
08-08-2012 05:00 AM
You can adjust your timers globally or per neighbor:
router bgp 1
timers bgp 7 21
OR
router bgp 1
neighbor x.x.x.x timers 7 21
I wouldn't recommend anything lower than 7 for a keepalive if this is an ebgp peer. For ibgp, I set mine to 5 and 15. The lower of the of the 2 timers is used between the peer, but the peer needs to be cleared before the new timer goes into effect.
HTH,
John
08-08-2012 11:14 PM
Hi John,
thank you for your reply.
I set BGP timers to "10 30", but this didn't solve the problem.
08-13-2012 01:43 AM
Hi,
I solved this problem by setting "bgp update-delay xx".
09-20-2012 10:20 PM
What bgp update-delay value did you set to improve convergence time?
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