Just to want to bring this up to everyones attention - one more time.
The commits from proposed 5 branch are now in master and the BGP
keepalive/holdtimer
is now changed to 3s keepalive and 9s holdtime (from 60s keepalive and
180s holdtime)
As we don’t show the defaults in Quagga, this means that everyone
using the default
today and upgrading WILL CHANGE their keepalive/holdtimer.
(BGP negotiation takes the smaller value of what both sides propose
during the open)
If you run Quagga on a low-scale box and have a large BGP table, there
is a good
chance that BGP may not be able to keep up anymore. I worry about the
casual user
upgrading and using Quagga for full BGP - and after the upgrade
frequently loosing
BGP sessions with hold time expired because of CPU load. Specifically
the instances
where Quagga is used as a route-server/route-reflector and maintaining
many peers.
(The weak point in Quagga on scaling still was [and still is] the run to
completion on
various parts of BGP and during this time there are no keepalives sent.
This used to
limit the scale for Quagga on the number of peers/routes/updates it is
able to process)
I’ll expect multiple complains from users not being able to keep their
BGP sessions
up (and potentially assuming a Quagga bug as the change isn’t well
visible in the
config)
What do others feel about this?
As a workaround I would suggest users to specifically configure a
non-default
keepalive/holdtime (i.e. “timers bgp 60 181”) just to make sure this
is saved
in the config BEFORE the upgrade.
But even with some clear indication, I expect few users to read any
change notes
(and just to a “apt-get upgrade”)
Regards,
Martin Winter
[email protected]
(And sorry for bringing this up again - just wanted to make sure that
this is a
community decision and everyone is aware. I’ll expect severe backslash
on scale
with default config because of this)
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
