[j-nsp] JUNOS precision-timers for BGP

[Olivier Benghozi]

This knob has been in all our confs for years (from 12.3 to 14.2).
At least it doesn't seem to do anything bad.

> Le 25 avr. 2016 à 17:16, Adam Chappell <adam.chappell at gmail.com> a écrit :
> 
> Does anyone have positive or negative experience with this feature in 14.1
> please?
> 
> Currently in a situation troubleshooting consequences of high CPU usage
> with a number of aggravating factors. Most sensitive to the scarcity of CPU
> resources however is a number of BGP sessions with aggressive timers.
> 
> Quite often a commit operation seems to make rpd block sufficiently enough
> (or indeed it's already starved out by other processes) to neglect
> keepalives for these unforgiving BGP sessions and we end up losing them.
> 
> Juniper have recommended to us consideration of "precision-timers", a
> global BGP knob which, if I understand it well, offloads all of the crucial
> BGP session management functionality to a different rpd thread in order to
> leave the main thread able to handle config requests etc. - not too
> dissimilar to the session management separation in openbgpd etc.
> 
> The Juniper documentation says this feature is recommended for low hold
> timers, and from what we can ascertain rpd is able to transition to
> off-thread session management without a down/up which is pretty neat.
> 
> I'm aware of PR1044141 which apparently causes pain when used in
> conjunction with traceoptions, but I'm keen to understand if others have
> operational experience.
> 
> We're also making inroads to lower CPU demands through the use of
> distributed PPM etc., but the regular pattern I tend to see there is that
> this doesn't fly once the PPM'd protocol has a security knob added, eg.
> adding authentication to BFD, VRRP etc.
> 
> -- Adam.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp