Hello, As all of us know BGP was designed for scalability, thus slow convergence. But it was also when CPU was slow :-). What do you think about the standard eBGP hold timer of 180sec ? Conservative ? I'm asking because we see more and more peering partners which force the hold timer to a lower value, and when BGP negotiate the timer, the lowest hold timer is the winner. Shall we all decide that for global faster convergence we should ALL decrease the hold timer ? Or those guys which are lowering their (and our) timers on IX LAN play a dangerous game ? See a example of our peering router at AMS-IX (hold from 30s to 180s): ...... BGP neighbor is 193.239.116.13x, remote AS 12x54, external link Last read 00:00:42, last write 00:00:13, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.13x, remote AS 31x77, external link Last read 00:00:09, last write 00:00:03, hold time is 90, keepalive interval is 30 seconds BGP neighbor is 193.239.116.13x, remote AS 4x562, external link Last read 00:00:30, last write 00:00:07, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.14x, remote AS 4x350, external link Last read 00:00:01, last write 00:00:01, hold time is 30, keepalive interval is 10 seconds BGP neighbor is 193.239.116.14x, remote AS 341x1, external link Last read 00:00:09, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.14x, remote AS 2x028, external link Last read 00:00:00, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.15x, remote AS 41x52, external link Last read 00:00:27, last write 00:00:11, hold time is 90, keepalive interval is 30 seconds BGP neighbor is 193.239.116.18x, remote AS 1x041, external link Last read 00:00:20, last write 00:00:14, hold time is 90, keepalive interval is 30 seconds BGP neighbor is 193.239.116.18x, remote AS 162x8, external link Last read 00:00:28, last write 00:00:06, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.20x, remote AS 47x86, external link Last read 00:00:59, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds BGP neighbor is 193.239.116.21x, remote AS x3350, external link Last read 00:00:02, last write 00:00:01, hold time is 30, keepalive interval is 10 seconds BGP neighbor is 193.239.116.24x, remote AS x5133, external link Last read 00:00:24, last write 00:00:03, hold time is 90, keepalive interval is 30 seconds ..... I've somehow basically anonymized ip and AS just in case I'm not allowed to publish those details. Best Regards, -Marcel
BFD is your friend. Yes it's require both parties to understand it but it much better than 30sec hold time. BIRD already have support for BFD
On 27 окт. 2015 г., at 10:31, "marcel.duregards@yahoo.fr" <marcel.duregards@yahoo.fr> wrote:
Hello,
As all of us know BGP was designed for scalability, thus slow convergence. But it was also when CPU was slow :-).
What do you think about the standard eBGP hold timer of 180sec ? Conservative ?
I'm asking because we see more and more peering partners which force the hold timer to a lower value, and when BGP negotiate the timer, the lowest hold timer is the winner.
Shall we all decide that for global faster convergence we should ALL decrease the hold timer ? Or those guys which are lowering their (and our) timers on IX LAN play a dangerous game ?
See a example of our peering router at AMS-IX (hold from 30s to 180s):
...... BGP neighbor is 193.239.116.13x, remote AS 12x54, external link Last read 00:00:42, last write 00:00:13, hold time is 180, keepalive interval is 60 seconds
BGP neighbor is 193.239.116.13x, remote AS 31x77, external link Last read 00:00:09, last write 00:00:03, hold time is 90, keepalive interval is 30 seconds
BGP neighbor is 193.239.116.13x, remote AS 4x562, external link Last read 00:00:30, last write 00:00:07, hold time is 180, keepalive interval is 60 seconds
BGP neighbor is 193.239.116.14x, remote AS 4x350, external link Last read 00:00:01, last write 00:00:01, hold time is 30, keepalive interval is 10 seconds
BGP neighbor is 193.239.116.14x, remote AS 341x1, external link Last read 00:00:09, last write 00:00:27, hold time is 180, keepalive interval is 60 seconds
BGP neighbor is 193.239.116.14x, remote AS 2x028, external link Last read 00:00:00, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds
BGP neighbor is 193.239.116.15x, remote AS 41x52, external link Last read 00:00:27, last write 00:00:11, hold time is 90, keepalive interval is 30 seconds
BGP neighbor is 193.239.116.18x, remote AS 1x041, external link Last read 00:00:20, last write 00:00:14, hold time is 90, keepalive interval is 30 seconds
BGP neighbor is 193.239.116.18x, remote AS 162x8, external link Last read 00:00:28, last write 00:00:06, hold time is 180, keepalive interval is 60 seconds
BGP neighbor is 193.239.116.20x, remote AS 47x86, external link Last read 00:00:59, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds
BGP neighbor is 193.239.116.21x, remote AS x3350, external link Last read 00:00:02, last write 00:00:01, hold time is 30, keepalive interval is 10 seconds
BGP neighbor is 193.239.116.24x, remote AS x5133, external link Last read 00:00:24, last write 00:00:03, hold time is 90, keepalive interval is 30 seconds
.....
I've somehow basically anonymized ip and AS just in case I'm not allowed to publish those details.
Best Regards, -Marcel
On 27/10/2015 08:31, marcel.duregards@yahoo.fr wrote:
I'm asking because we see more and more peering partners which force the hold timer to a lower value, and when BGP negotiate the timer, the lowest hold timer is the winner.
You need to be careful with this. On larger IXPs, there will be a wide variety of kit with different capabilities, which will usually work well in most circumstances, but which may not have enough cpu power to handle edge cases like e.g. ixp maintenance or flaps when you get large amounts of bgp activity. A low bgp timer might be fine for, say an asr9k or an mx960 with the latest RE/RSP, but would be actively harmful if one of your peers is using an mx80 or a sup720. Nick
low bgp timers usually done to allow faster hsrp failover result colin Sent from my iPhone
On 27 Oct 2015, at 08:20, Nick Hilliard <nick@foobar.org> wrote:
On 27/10/2015 08:31, marcel.duregards@yahoo.fr wrote: I'm asking because we see more and more peering partners which force the hold timer to a lower value, and when BGP negotiate the timer, the lowest hold timer is the winner.
You need to be careful with this. On larger IXPs, there will be a wide variety of kit with different capabilities, which will usually work well in most circumstances, but which may not have enough cpu power to handle edge cases like e.g. ixp maintenance or flaps when you get large amounts of bgp activity. A low bgp timer might be fine for, say an asr9k or an mx960 with the latest RE/RSP, but would be actively harmful if one of your peers is using an mx80 or a sup720.
Nick
participants (4)
-
Colin Johnston -
marcel.duregards＠yahoo.fr -
Nick Hilliard -
Nikolay Shopik