[c-nsp] ASR9000 QoS counters on LAG

Ross Halliday ross.halliday at wtccommunications.ca
Sat Jan 20 16:44:17 EST 2024


Hi Saku,


> Any syslog messages when you attach it?

Nope, though I'm quite ignorant as to whether I have the appropriate logging options turned on.

> 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.

I read that this is very much true for ingress queuing as it applies a priority across the fabric (apparently there's a separate mcast priority too). I believe this card supports four egress queues, which seems to be supported by my earlier failed commit checks! Regardless I would expect *something* to hit the counters, even if half of them are broken, no?

> 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.

Thanks for the tips, I'll have to investigate the use of "qos-group".

Thanks
Ross


More information about the cisco-nsp mailing list