04-05-2024 04:01 AM
Hi Team ,
Please let me know the BGP convergence time and if its 240 secs then why its very slow protocol.
Thanks
Jay
Solved! Go to Solution.
04-05-2024 08:48 AM
Firstly, what do consider convergence? Reason I ask, full convergence is, I believed considered when the WHOLE network has a correct knowledge of the WHOLE network.
So, if you go by that convergence definition, what's the topology and what has changed?
Next, there are parameters that can vary between BGP routers that impact convergence timing. What are they for all the BGP routers in your topology?
Next, much BGP processing, for exactly an identical configuration, will likey vary between platforms. What are the specs for your platforms?
We also have situations that impact convergence which cannot be exactly predicted. For example, say your waiting on a 10 second timer. In one situation the peer dies .1 seconds after sending I'm alive message. In another situation, peer dies .1 second before it would send the I'm alive message. I.e. almost a 10 second difference for convergence to even start. (There are lots of variants on timers, like "dampening", that might impact actual convergence time.)
Given all the above, cannot provide a minimum convergence time without a lot more information, and even with such information, a minimum would be the best possible case, very often not the usual case.
If fast convergence is a must (like for supporting VoIP, etc.), then you (work to) design around these issues. (I think the earlier reference I provided touches on that.)
04-05-2024 04:34 AM
BGP doesn't have a specific fixed convergence time. BGP convergence time, like most, if not all, other routing protocols, depends on many factors.
Perhaps one factor that can slow BGP convergence is the often common amount of time used for dead peer detection.
You might fine this interesting: https://www.noction.com/blog/bgp-convergence
As to why BGP isn't, by default, designed for faster convergence, that probably has much to do with the kinds of network traffic and router hardware at the time of BGP's design. (Much like how manual typewriters keyboard layouts were designed to SLOW typing speed, to avoid jamming keys.)
04-05-2024 06:44 AM - edited 04-05-2024 06:47 AM
Hello @js726u ,
BGP is thought to handle many routes up to millions in devices that support it.
The BGP convergence is not the main goal of the protocol.
BGP convergence involves:
- neighbor peer timers
- BGP scanning timer
- BGP timer to propagate updates
BGP timers can be reduced and also you can use features like eBGP fast external fallover that will tear a BGP session if the WAN interface goes down.
the BGP scanning timer and the propagation timers are specific for every address family.
for BGP ipv4 unicast address family the BGP scanner is 60 seconds. What this means ?
BGP scans the BGP table every 60 seconds to check for routes and their associated BGP next-hop.
BGP does not propagate a change immediately but it waits for a timer before sending updates. This is done for efficiency, it is better to wait some seconds to collect all affected prefixes and to send a single BGP update listing multiple prefixes instead of sending out a packet for each prefix.
So if you have a network with BGP Route Reflectors the time it takes to propagate changes needs to take in account all the timers described above.
Other features that can help are BGP next-hop tracking, BGP update-groups ( for efficiency).
Fine tuning BGP convergence is possible , by default the protocol is rather slow.
Hope to help
Giuseppe
04-05-2024 07:35 AM
BGP scans for 60 secs for update , it means keepalive is 60 secs . Hold down timer is 180 secs . So minimum convergence is 180 secs . Is that correct ? Please let me know .
Thanks
Jaychandran S
04-05-2024 07:48 AM
Hello @js726u ,
the BGP scanning timer is not related to a specific BGP session but to the BGP table.
The default timers for a BGP peer are 60 seconds of keepalive and 180 seconds so it can take 180 seconds to declare a BGP neighbor down.
This time can be compressed by using lower timers, by using ebgp fallover or by using BFD to detect failures in the path to the BGP neighbor.
However, the BGP scanning timer and the BGP update interval have to be added to the time to detect a BGP peer is down. This is the sense of my previous post. BGP convergence is not limited to BGP session timers.
Hope to help
Giuseppe
04-05-2024 07:55 AM
Still the answers is not clear , Please let me know the minimum time to take convergence and forward the routes to peer , at least approximate time .
Thanks
Jay
04-05-2024 08:48 AM
Firstly, what do consider convergence? Reason I ask, full convergence is, I believed considered when the WHOLE network has a correct knowledge of the WHOLE network.
So, if you go by that convergence definition, what's the topology and what has changed?
Next, there are parameters that can vary between BGP routers that impact convergence timing. What are they for all the BGP routers in your topology?
Next, much BGP processing, for exactly an identical configuration, will likey vary between platforms. What are the specs for your platforms?
We also have situations that impact convergence which cannot be exactly predicted. For example, say your waiting on a 10 second timer. In one situation the peer dies .1 seconds after sending I'm alive message. In another situation, peer dies .1 second before it would send the I'm alive message. I.e. almost a 10 second difference for convergence to even start. (There are lots of variants on timers, like "dampening", that might impact actual convergence time.)
Given all the above, cannot provide a minimum convergence time without a lot more information, and even with such information, a minimum would be the best possible case, very often not the usual case.
If fast convergence is a must (like for supporting VoIP, etc.), then you (work to) design around these issues. (I think the earlier reference I provided touches on that.)
04-05-2024 09:16 AM
Hi Joseph ,
Thank You for your response , so BGP no specific convergence and no time line to fix it and i accepted your message as solution .
Thanks
Jay
04-05-2024 09:57 AM
Well, in any situation, there would be specific BGP convergence time, but it depends on many variables.
I think (?) generally, you'll not see convergence times under 30 seconds, and multi-minutes certainly possible; your mileage might vary.
Another example of interaction between BGP and hardware.
Years (decades), had a pair of 3660s routers with a T3 line on each. Each with its connection to a different ISP. Took the full Internet route table (at that time, about 15 million routes for the Internet, I recall) from both providers. (I.e. so each router had two full Internet route tables, one directly from its directly connected ISP peer, the one, indirectly, via iBGP, from its 3660 peer.)
The BGP scanner process (that Giuseppe mentioned), running once a minute, itself, consumed over half the CPU capacity of those routers. Overall the routers were struggling with the load placed on them.
Moved from full Internet BGP tables to default route, from each ISP, with OER providing best performing ISP to any destination. Overall CPU load fell to about 40% CPU and obtained optimal per flow performance too.
04-05-2024 07:35 PM
Hi Doherty ,
Thank you for your response ! is there any other internet gateway protocols exists in networking . Please let me know .
Thanks
Jay
04-05-2024 08:44 PM
Instead of BGP, for Internet routing, non-experimental? None I'm aware of. Even if you found one, who would also use it for complete Internet routing?
What are your routing needs?
04-06-2024 01:51 AM
Thank You for your response ! i got it !
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