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. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp