[j-nsp] auto b/w mpls best practice -- cpu spikes

[Saku Ytti]

I think 16.1 was first.

ps Haux|grep rpd should show multiple rpd lines.

Also
ytti at r41.labxtx01.us.bb> show task io |match {
 KRT IO task                          0       0       0       0
0         {krtio-th}
 krtio-th                             0       0       0       0
0         {krtio-th}
 krt ioth solic client                0       0     869       0
0         {krtio-th}
 KRT IO                               0       0       0       0
0         {krtio-th}
 bgpio-0-th                           0       0       0       0
0         {bgpio-0-th}
 rsvp-io                              0       0       0       0
0         {rsvp-io}
 jtrace_jthr_task                     0       0       0       0
0         {TraceThread}

I'd just go latest and greatest.
On Thu, 13 Sep 2018 at 12:13, tim tiriche <tim.tiriche at gmail.com> wrote:
>
> .o issues with convergence or suboptimal paths.  The noc is constantly seeing high cpu alerts and that was concerning.  Is this normal in other networks?
>
> Running 14.1R7.4 with mx480/240 mix.
> I usually follow the code listed here: https://kb.juniper.net/InfoCenter/index?page=content&id=KB21476
>
> Which code version have these optimization happened in?
>
>
> On Wed, Sep 12, 2018 at 2:11 AM Saku Ytti <saku at ytti.fi> wrote:
>>
>> Hey Tim,
>>
>> I'd optimise for customer experience, not CPU utilisation. Do you have
>> issues with convergence time, suboptimal paths?
>>
>> Which JunOS you're running? There are quite good reasons to jump in
>> recent JunOS for RSVP, as you can get RSVP its own core, and you can
>> get make-before-break LSP reoptimisation, which actually works
>> event-driven rather than timer based (like what you have, causing LSP
>> blackholing if LSP convergence lasts longer than timers).
>>
>>
>>
>>
>> On Wed, 12 Sep 2018 at 08:05, tim tiriche <tim.tiriche at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > Attached is my MPLS Auto B/w Configuration and i see frequent path changes
>> > and cpu spikes.  I have a small network and wanted to know if there is any
>> > optimization/best practices i could follow to reduce the churn.
>> >
>> > protocols {
>> >     mpls {
>> >         statistics {
>> >             file mpls.statistics size 1m files 10;
>> >             interval 300;
>> >             auto-bandwidth;
>> >         }
>> >         log-updown {
>> >             syslog;
>> >             trap;
>> >             trap-path-down;
>> >             trap-path-up;
>> >         }
>> >         traffic-engineering mpls-forwarding;
>> >
>> >         rsvp-error-hold-time 25;
>> >         smart-optimize-timer 180;
>> >         ipv6-tunneling;
>> >         optimize-timer 3600;
>> >         label-switched-path <*> {
>> >             retry-timer 600;
>> >             random;
>> >             node-link-protection;
>> >             adaptive;
>> >             auto-bandwidth {
>> >                 adjust-interval 7200;
>> >                 adjust-threshold 20;
>> >                 minimum-bandwidth 1m;
>> >                 maximum-bandwidth 9g;
>> >                 adjust-threshold-overflow-limit 2;
>> >                 adjust-threshold-underflow-limit 4;
>> >             }
>> >             primary <*> {
>> >                 priority 5 5;
>> >             }
>> >         }
>> > _______________________________________________
>> > juniper-nsp mailing list juniper-nsp at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>>
>>
>> --
>>   ++ytti



-- 
  ++ytti