[j-nsp] Policing On LAG's

Mark Tinka mark.tinka at seacom.mu
Fri Apr 24 08:45:11 EDT 2015


Hi all.

I have an interesting one where a policer applied to a LAG interface
does different things:

    1. In some cases, it polices the ae-* port to the configured
bandwidth limit.

    2. In other cases, it doubles the configured bandwidth limit and
does not police the ae-* port until that double bandwidth is reached.

In case 1), above, this is expected (and desired) behaviour.

In case 2), above, reducing the bandwidth limit to half the CIR causes
the policer to limit bandwidth to the CIR for the ae-* port, i.e., if a
port is to be policed to 60Mbps, setting the policer to 30Mbps and
applying that to the ae-* port causes policing at 60Mbps. When you
observe the individual LAG member links, you notice that for the
corresponding ae-* port, half the bandwidth is equally policed on each
member link, which suggests that Junos logically applies the policer to
the member links wholesale.

I would be fine with the situation described above if it was uniform,
but what we find is that at certain high bandwidth levels, configuring
the correct CIR (instead of half the CIR) on the policer is the way to
go. While for lower bandwidth levels, configuring half the CIR is the
way to go. I have not yet confirmed whether my assumption is true, or at
which point this intersects.

This is on MX480 with Trio-based MPC's (high-end QoS cards) + 10Gbps
MIC's, running Junos 14.2.

The LAG is split across 2x MPC's.

Has anyone come across this issue, or something similar?

I have a case going to JTAC, but as always, reaching out to the
community is helpful.

Mark.


More information about the juniper-nsp mailing list