Mailing List Archive: ASR9000 QoS counters on LAG

ASR9000 QoS counters on LAG

Jan 18, 2024, 7:09 PM

Post #1 of 5 (156 views)

Hello,

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!

config:

interface Bundle-Ether4
mtu 9200
service-policy output LLQ-Outbound
!
interface BE4.3892
vrf iptv
ipv4 mtu 1500
ipv4 address 9 255
ipv4 verify unicast source reachable-via rx allow-self-ping
encapsulation dot1q 3892
!

class-map match-any DSCP-Network
match dscp cs6 cs7
match cos 6 7
end-class-map
!
class-map match-any DSCP-Voice
match dscp cs5 ef
end-class-map
!
class-map match-any DSCP-TV
match dscp cs4 af41
end-class-map
!
class-map match-any DSCP-Management
match dscp cs3 af31
end-class-map
!

policy-map LLQ-Outbound
class DSCP-Network
priority level 1
police rate 100 mbps
conform-action transmit
exceed-action drop
!
!
class DSCP-Voice
priority level 2
police rate 200 mbps
conform-action transmit
exceed-action drop
!
!
class DSCP-TV
priority level 3
police rate 8000 mbps
conform-action transmit
exceed-action drop
!
!
class DSCP-Management
priority level 3
police rate 200 mbps
conform-action transmit
exceed-action drop
!
!
class class-default
!
end-policy-map
!
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: ASR9000 QoS counters on LAG [ In reply to ]

cisco-nsp at puck

Jan 19, 2024, 12:00 AM

Post #2 of 5 (156 views)

Permalink

On Fri, 19 Jan 2024 at 05:10, Ross Halliday via cisco-nsp
<cisco-nsp@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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: ASR9000 QoS counters on LAG [ In reply to ]

cisco-nsp at puck

Jan 20, 2024, 1:44 PM

Post #3 of 5 (154 views)

Permalink

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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: ASR9000 QoS counters on LAG [ In reply to ]

cisco-nsp at puck

Jan 20, 2024, 5:17 PM

Post #4 of 5 (154 views)

Permalink

Moving to qos-group for egress classes got me the result I was looking for. Thank you very much!

Cheers
Ross

-----Original Message-----
From: cisco-nsp <cisco-nsp-bounces@puck.nether.net> On Behalf Of Ross Halliday via cisco-nsp
Sent: Saturday, January 20, 2024 4:44 PM
To: Saku Ytti <saku@ytti.fi>
Cc: cisco-nsp@puck.nether.net
Subject: Re: [c-nsp] ASR9000 QoS counters on LAG

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
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Re: ASR9000 QoS counters on LAG [ In reply to ]

cisco-nsp at puck

Jan 20, 2024, 11:40 PM

Post #5 of 5 (146 views)

Permalink

On Jun, 21 Jan 2024 at 03:17, Ross Halliday
<ross.halliday@wtccommunications.ca> wrote:

> Moving to qos-group for egress classes got me the result I was looking for. Thank you very much!

I'm happy that you got the results you wanted, but that shouldn't have
fixed it. The 'priority level 3' is the only thing that I can think of
which might cause it to fail to program.

Just to continue on the priority level, if you set it on ingress,
it'll still carry the values on egress. But you receive a lot more
protection, because you ensure that fabric isn't being congested by
less important traffic, causing more important traffic to drop during
fabric congestion.

--
++ytti
_______________________________________________
cisco-nsp mailing list cisco-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/