Why doesn't the following HQoS policy work on the cat9500

[jerrymunster]

Why doesn't the following HQoS policy work on the cat9500 when the service-policy is applied to an outbound L3 interface:

class-map match-any REALTIME
match dscp ef
match precedence 5
class-map match-all VIDEO
match ip dscp af41
class-map match-all SIGNALING
match ip dscp cs3 af31 af32 cs5
class-map match-all NETWORK-CTRL
match ip dscp cs6

policy-map QOS-001
class REALTIME
priority level 1 percent 10
class NETWORK-CTRL
bandwidth percent 5
class SIGNALING
bandwidth percent 5
class VIDEO
bandwidth percent 10
class class-default
bandwidth percent 70
queue-limit 1000 packets
random-detect
random-detect precedence 0 250 300
random-detect precedence 5 250 300

policy-map SHAPE-100MB-QOS
class class-default
shape average 100000000
service-policy QOS-001

[Joseph W. Doherty]

I'm unfamiliar with a 9500's QoS features, but often switches' QoS features are much more limited than those a router will support.

Are you getting any error message when you try to apply the policy, either at the console and/or in the log?

BTW, some things I noticed (which shouldn't impact whether you can use the QoS polices, or not) . . .

"match precedence 5", in your REALTIME class-map would also match DSCP EF.  I.e. you don't need "match dscp ef" except, perhaps, if you looking to obtain separate match stats.

"random-detect precedence 5 250 300" found in policy-map QOS-001's class-default, shouldn't have any effect as you're matching IPPrec 5 in REALTIME.

In general, unless you're a QoS expert, I recommend to avoid using WRED, at all.  It's actually rather complicated to configure it ideally.  (It has other issues too, both in general, and in Cisco's implementation [NB: not bugs, just their approach].  There's a reason there are so many RED variants, all to "improve or fix" issues with earlier/other variants.)

[jerrymunster]

The policy applies without error.  It simply doesn't work.  There's no traffic matches at all in the show policy map interface x.  It appears the policy map is configured for the values/thresholds I configured but no traffic matches nor any drops from the shaper as if the policy is not applied at all.  I'm aware of the EF/Pres 5 matching but I did this on purpose for now.

[jerrymunster · Accepted solution]

The issue with the policy is indeed WRED.  Once WRED configuration is removed in the default class the policy works as expected.  I have no idea if this is a bug or WRED is simply no longer supported.   This issue is in all versions of code I've tested.  It would have been nice if I got an error that WRED was not supported but no such luck"?"

[Joseph W. Doherty]

I'm a bit surprised switch takes policy without any errors at all (in either configuration interaction or syslog) but device is still early in its lifecycle, so lack of any error indication might be a bug.

[jerrymunster]

As it turns out this is an issue with WRED being configured at the same time a queue-limit is set.  If I remove WRED the policy works if I remove the queue-limit the policy works you just can't configure both at the same time.  I'd assume this is a bug or at least not support and should throw a log message but WRED does work if the queue-limit setting is removed.

[Joseph W. Doherty]

I agree, not showing any kind of error, anywhere, would, to me, appear to be a bug.

I believe I recall seeing routers enforce both WRED and queue-limit, concurrently.  Perhaps doing so on a switch, with such tied to ASIC capabilities, exceeds what the hardware can support.

One might argue, having both queue limits (WRED and queue-limit) doesn't make any sense, or perhaps argue both are needed.  As I noted, this might be a "Cisco implementation" issue, as I don't recall Dr. Floyd's original (and revised) RED papers mentioning both tail queue limits.