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?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: