Hi Markus, Thanks for the feedback, good to know you are using it in production and i see how it can help after a session is started. To confirm that processing the patch is on my todo list and let me thank you a lot for the contribution :)
Cheers, Paolo On Fri, Jul 24, 2015 at 01:16:31PM +0200, Markus Weber wrote: > 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
