QoS issue with qos-groups on ASR903 with RSP3 processor

[JBlanchon]

Hello,

I have to take a look at an ASR903 I didn't configure myself, and there's something I don't understand regarding the QoS. Here are the relevant configuration parts:

Here is the egress policy-map 

policy-map pm-egress-default
 class cm-qos5
  priority level 1 percent 80
 class cm-qos3
  bandwidth remaining percent 40
 class cm-qos2
  bandwidth remaining percent 50
 class class-default

And here's the configuration of the class-maps called by the egress policy-map

class-map match-any cm-qos5
 match qos-group 5
class-map match-any cm-qos2
 match qos-group 2
class-map match-any cm-qos3
 match qos-group 3

The qos-groups are configured here, in the ingress policy-map:

policy-map pm-ingress-default
 class cm-cos2
  set qos-group 2
 class cm-cos3
  set qos-group 3
 class cm-cos5
  set qos-group 5

The class-maps in this policy-map are defined here:

class-map match-any cm-cos5
 match dscp ef
 match cos 5
 match dscp cs5
 match precedence 5
class-map match-any cm-cos2
 match dscp af21
 match dscp cs2
 match precedence 2
 match cos 2
class-map match-any cm-cos3
 match dscp af31
 match dscp cs3
 match precedence 3
 match cos 3

So, looking at this, everything seems OK: we have an ingress policy-map called "pm-ingress-default" applied on the ingress interfaces, that put packets in different qos-groups depending on their DSCP/precedence. Then, these qos-groups are used on the "pm-egress-default" policy map on the egress interfaces to shape traffic.

The only problem is, the "pm-ingress-default" policy-map is not applied anywhere. In fact, there is no policy-map at all used on the ingress interfaces, and the qos-groups are only set on the configuration part I showed you, and nowhere else. 

But, when I look at the "pm-egress-default" policy, I see that traffic is classified as expected, qos-groups are matched as if "pm-ingress-default" was applied on ingress traffic, even though it's not.

And I don't understand this behaviour, it's almost as if the router saw that qos-groups were called on the egress policy-map, and decided to classify packets using the only place where qos-groups were configured - even though it's in a policy-map not applied on any interface.

I've spent some time trying to check the QoS documentation for RSP3, but didn't manage to find what I am missing here. Can someone explain this QoS logic, please?

Julien

[Joseph W. Doherty]

Interesting!

I didn't find anything specific to your platform, but in https://community.cisco.com/t5/service-providers-documents/asr9000-xr-understanding-qos-default-marking-behavior-and/ta-p/3128709/page/16, we find:

Default Marking behavior of the ASR9000

If you don't configure any service policies for QOS, the ASR9000 will set an internal cos value based on the IP Precedence, 802.1 Priority field or the mpls EXP bits.

So, I wonder if your platform has similar behavior.

If you look at your class-maps, for matching ToS's first 3 bits or a (L2) CoS, all map that value to same number for the qos-group, so this being a "default" would provide the answer why everything seems to be working correctly.

If you revised the one class-map as follows:

class-map match-any cm-cos2
match dscp af21
match dscp cs2
match precedence 2
match precedence 1
match cos 2

You might find IPPrec 1 isn't treated as qos-group 2 (without having an interface ingress service-policy).

BTW, for matching purposes, these two statements:

match dscp af#1
match dscp cs#

are redundant with:

match precedence #

[JBlanchon]

Hi Joseph,

This looks interesting, I wouldn't be surprised if there was something like this happening in the background.
Unfortunately I don't have any ASR903 with RSP3 processor available for tests, the few I have are all live devices. I'll try and see if I can manage to do some tests without disrupting anything.

Julien