On 24.07.2015 04:34, Paolo Lucente wrote:
Thanks for the patch; makes sense to me and i see the benefit but i > need some test in lab before committing as it has its potential >
danger ;-)
Just FYI - works here like a charm so far. No more starving sessions.
Btw, did you have a look to the config directives bgp_daemon_batch > and bgp_daemon_batch_interval? They allow to re-establish the BGP >
peerings in a more "controlled" fashion, ie. a defineable few at a >
time, precisely to tackle such scenarios.
Those help to throttle new incoming BGP sessions (startup scenario).
However, those settings will not help to prevent already established
sessions starving, when there are heavy routing updates.
In the worst case: If the first connected peer keeps on sending updates
for longer than the holdtime of any other session, this/these other
session/s might starve. True, unlikely and here the cut off point are
~23 sessions on startup, but we've indeed seen starving "later connected"
sessions because of ongoing heavy routing updates.
And a dropped session will delete the RIB for that peer - so I rather
prefer slower updates than reloading the full table. Or am I missing
something? My understanding (but only flew over the code) is, that if
there's no RIB for the peer, no BGP information can be attached (esp.
it's not looked up in any other RIB).
Cheers,
Markus
_______________________________________________
pmacct-discussion mailing list
http://www.pmacct.net/#mailinglists
