[j-nsp] MPLS Auto-BW experiences

Charlie Allom charlie at evilforbeginners.com
Tue Sep 17 03:27:46 EDT 2019


>
> From what I've seen, short timer intervals (statistics every 60s, adjust
> every 300-900s) and relatively low adjust thresholds pretty well obviate
> the need for overflow/underflow


On Junos it isn't just obviated, it is prevented from working.

https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/mpls-configuring-automatic-bandwidth-allocation-for-lsps.html

Hidden in there (and in the CLI if you dare):

> You cannot configure automatic bandwidth adjustments to occur more often
than every 300 seconds.

> The adjust-threshold-overflow-limit statement (aka overflow) is subject
to the same minimum value with regard to the minimum frequency of
adjustment allowed.
Therefore if your timers are on the floor already at 60s stats and 300s
intervals, overflow can't be used (as it's minimum is also 300s).

So if you have bursty traffic, you will drop within that 5 minute time
frame.

Unrelated, I got this response back from Juniper about `optimize-on-change
{ link-congestion; }`

"This knob is to move LSPs away from a congestion point – typically
congestion caused by link degradation or change in subscription.

Preemption aggressive + soft-preemption is the preferred way to handle this.

We do not recommend this knob at the ingress as this won’t necessarily move
LSPs in the order of setup priority.

It is really something to be handled at the congestion point/transit – to
move away precisely required no of LSPs emanating from various ingresses in
the order of priority.

 This knob should be looked at only if customer cant configure preemption
aggressive + soft preemption in the transit for some reason"


ಠ_ಠ



On Mon, Sep 16, 2019 at 8:52 AM Rob Foehl <rwf at loonybin.net> wrote:

> On Fri, 6 Sep 2019, Jared Mauch wrote:
>
> > What have you found are the most important parts of your settings, be it
> the underflow/overflow settings or otherwise.
>
> From what I've seen, short timer intervals (statistics every 60s, adjust
> every 300-900s) and relatively low adjust thresholds pretty well obviate
> the need for overflow/underflow, but I also haven't had any issues with
> the amount of resignaling that results.  YMMV.
>
> Other important stuff is running adaptive LSPs (to get make-before-break
> SE reservations and avoid double counting), and optimize timers (to avoid
> relying on auto-bw to clean up after link failures).
>
> This rabbit hole runs pretty deep...
>
> -Rob
>
> _______________________________________________
> 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