[j-nsp] JUNOS precision-timers for BGP

Olivier Benghozi olivier.benghozi at wifirst.fr
Fri Jul 29 19:03:18 EDT 2016


... Fine on SRX, MX, and older 12.3 on EX4200, at last.

Just started an EX3300 in 12.3R12-S1 today with precision-timers configured:
0 (zero) keepalives were sent, session flapped every 90 seconds. What a good job and a fine quality check...


> Le 25 avr. 2016 à 18:43, Olivier Benghozi <olivier.benghozi at wifirst.fr> a écrit :
> 
> 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
> 



More information about the juniper-nsp mailing list