[c-nsp] ASR9000 QoS counters on LAG

[Saku Ytti]

On Fri, 19 Jan 2024 at 05:10, Ross Halliday via cisco-nsp
<cisco-nsp at puck.nether.net> wrote:


> We've inherited some older ASR9000 systems that we're trying to support in-place. The software version on this one router is fairly old at 6.1.4. Driving it are a pair of RSP440-SE. The line cards are A9K-MOD160-SE with A9K-MPA-8X10GE in each.
>
> I haven't had any issues until trying to apply a policy map in the egress direction on a LAG. The counters simply don't increase. I'm aware of the complexities of policing, but right now I just want to see packets match a class - any class - even class-default doesn't increment as expected. Everything works as expected on a non-LAG port. Ingress works fine, as well - this is just egress on a LAG.
>
> IOS-XR is not my strong point at all. I'm not sure if I'm missing something very obvious, but this seems so weird that it feels like a display bug.
>
> The LAG members are split between the two linecards.
>
> Any suggestions would be greatly appreciated!


Any syslog messages when you attach it?

I don't think the device supports 'priority level 3', there is only
default, 2 and 1 . Default being the worst and 1 the best (well in
CLI, in NPU they are reversed to make debugging less boring).
Practically all the utility of priority level has already been used,
by the time egress policy is considered, so they don't much here, you
should set them on ingress.

Not related, but I can't help myself, you shouldn't classify and
schedule on egress, you classify on ingress, and schedule/rewrite on
egress. That is 'your match dscp/cos' should be on ingress, with 'set
qos-group N', and on 'egress' you do 'match qos-group N'. Not only
will this separation of concerns make things a lot easier to rationale
and manage, but it's the only way you can do QoS on many other
platforms, so you don't have re-invent policies for different
platforms.

Do remember that by default 'police X' in LAG in ASR9000 means X in
each interface, for total LAG capacity of X*interfaces_up (variant).
There is no way to configure shared policer in any platform at all,
but there is a way to tell platform to divide X by active member count
for each member, so aggregate cannot be more than X, but no single
interface can burst more than X/member_count.

-- 
  ++ytti