[j-nsp] Policing On LAG's

[Mark Tinka]

Hi all.

So just an update on this - Junos has a mechanism that divides the
policer parametres equally across the member links in a LAG. Juniper
call this a "carve-up factor".

In the case of 2x member links in a LAG, the carve-up factor is 0.5,
regardless of whether the member links are on the same or different MPC.

When looking at the PFE programming of the policer on each MPC, I
noticed that the carve-up factor was 1.0. This means each MPC was
policing at the CIR, meaning any customers attached to that LAG were
getting double the bandwidth.

The only solution was to delete, commit, re-configure and re-commit the
policer on the affected customer ports. This, then, correctly programmed
the PFE with the right carve-up factor.

Theories abound as what triggers application of the wrong carve-up
factor, and that is what Juniper and we are investigating.

For the archives in case anyone hits this issue.

Mark.

On 24/Apr/15 17:18, Mark Tinka wrote:
>
> On 24/Apr/15 16:07, Tima Maryin wrote:
>> Hi Mark,
>>
>>
>> So which steps make the box to 2nd scenario?
>>
>>
>> p.s. https://prsearch.juniper.net/PR1056098
> The changes are random, but I had a feeling it could be something like
> this, where the router ignores the configuration due to a change. So I
> did a "commit full" just to be sure, but that didn't help.
>
> My next step was to restart the MPC's so that the PFE can be freshly
> re-programmed, but that would require a maintenance window.
>
> At any rate, I have also randomly changed policer settings on the one
> which is working as expected, so while I suspect it could be a PFE issue
> to some extent, it's not yet clear what steps lead to it.
>
> That said, it may be an issue in my release of code (which is an
> engineering version of 14.2), and the fix could be in 14.2R3 as
> indicated in the PR. Will ping JTAC on this.
>
> Many thanks, Tima.
>
> Mark.