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

[Saku Ytti]

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