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 <[email protected]> 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 [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
