I am getting the following error on a WS-C3850-48P running 16.6.9 after entering service-policy ouput PM-QOS on the uplink. I'm not trusting any end point markings so the trust boundary begins at the uplink.
Invalid queuing class-map!!! Queuing actions supported only with dscp/cos/qos-group/precedence/exp based classification!!!
Below is my config:
class-map match-any CM-MCRITICAL
match access-group name MCRITICAL
match access-group name MCRITICAL_IPV6
class-map match-any CM-I-VIDEO
match access-group name I-VIDEO
class-map match-any CM-VOICE
match access-group name VOICE
class-map match-any CM-BULK_DATA
match access-group name BULK_DATA
class-map match-any CM-TRAN_DATA
match access-group name TRAN_DATA
Policy Map PM-QOS
bandwidth 25 (%)
set dscp af31
priority level 2 23 (%)
set dscp af41
priority level 1 10 (%)
set dscp ef
bandwidth 5 (%)
set dscp af11
bandwidth 5 (%)
set dscp af21
bandwidth 32 (%)
set dscp default
I think that HW different than SW queue,
for HW refer to link below how you can config HW queue.
You are matching traffic in ACL due to which the switch is generating this error. Try either of the following-
a. Match traffic on basis of DSCP value, or
b. In input policy-map set qos-group label on traffic and then match it in output policy-map.
set qos-group qos-group-value
QoS group value can be from 0 to 99.
In output policy-map you can match the traffic using qos-group value in class-map.
match qos-group qos-group-value
I may not be reading your snippet correctly. The snippet shows ACL based classification the same as my config for 9000, 3850,3650?
Or do I have to upgrade to 16.8.1+ for this to work?
In 3850 by default the packets are trusted (the L2/L3 QoS marking is preserved). You can use ACL to identify traffic but here you are using a queuing action (bandwidth in policy-map) that is supported with dscp/cos/qos-group/precedence/exp based classification!!!
I do not have 3850 available as of now so I can't test this but if you remove bandwidth from policy-map (just for testing purposes) the policy-map should get applied without error.
I think I get it now. I can't use the bandwidth commands in my policy map because they are referencing ACLs. Rather I have to remove the bandwidth commands and apply them at the next hop referencing the dscp markings?
It's not, I believe, "bandwidth commands". It's, I believe, whether your using a CBWFQ policy for ingress ("IN") or egress ("OUT"). Various commands are restricted to ingress (any?) or egress (some). For example (in general, i.e. might be platform exceptions), bandwidth and shape commands might only be used within an egress policy, but police commands can be used in ingress or egress policies.
Since the error message mentions "queuing", that's an egress policy only issue.
How, for example, is the actual service-policy command configured on the interface?
"Invalid queuing class-map!!! Queuing actions supported only with dscp/cos/qos-group/precedence/exp based classification!!!"
I suspect, as also already noted by @ashishr, it's the combination of ACL matching and(/with) (egress) queuing that's the problem. (Such appears to also be the meaning of the error message.)
If that's the situation, you should be able to ACL match within an ingress policy and than use "ToS/.../exp based classification" (as noted in error message) to match within your egress policy. (I.e. you shouldn't be required to use a QoS group, as @ashishr shows, but that should be a way for it to work too.)
(NB: BTW, because of limited hardware QoS support, in switches, they often have quirks/restrictions in their MQC support. Also BTW, the later IOS version QoS classification features, noted by @MHM Cisco World, are also likely only supported within an ingress policy. [I do wonder, though, how extensive the NBAR2 support is, and if extensive, if it's all supported in dedicated hardware. Years ago, the sup32-PISA has extra matching hardware support, but is was very limited.])
Lets say I do away with ACL classification since it isn't a supported queueing action ( I get the same error whether I use input or output on the uplink) and build the class maps using NBAR. I would apply the policy map on the uplink for ingress traffic, that means I have to apply the egress policy map to the switchport interfaces since only one policy can be applied per interface correct? The egress policy map is where the bandwidth commands can be places correct?
"The egress policy map is where the bandwidth commands can be places correct?"
Yes and no. A policy map using class bandwidth command can only be used for egress, but some policy maps can be written such that they can be used for ingress or egress.
". . . since only one policy can be applied per interface correct? "
Cannot say for sure for a 3850, but generally an interface can have ingress and/or egress policies.
"( I get the same error whether I use input or output on the uplink)"
Same exact error? Your original posted policy would be invalid for an ingress policy, as it uses priority and bandwidth commands.
". . . and build the class maps using NBAR."
I suspect, if you use an IOS version that supports NBAR, restrictions will be similar as with using an ACL. (Understand, for some matching, NBAR is just a "pretty face" on an ACE, but NBAR can offer deeper packet inspection. For example, an ACL matching port 80 might be used for identifying HTTP traffic, and NBAR matching protocol HTTP might only do that, or it might look deeper into the packet, ignoring the port and determine whether contents of packet appears to be HTTP commands. [Where NBAR might have an issue, doing deep packet content inspection, i.e. beyond matching standard port numbers, is when packet contents is encrypted, e.g. HTTPS.])
With NBAR not able to inspect encrypted traffic that rules it out for me then. Back to ACL classification, I confirmed the error is the same when I apply the service-policy to the trunked interface for input and output. Below is a snippet, applying it to an etherchannel member was intentional.
"With NBAR not able to inspect encrypted traffic . . ."
That's sort of the point with encrypted traffic, i.e. you're not supposed to be able to "see" clear text, beyond at the source or destination. (If you work for the NSA, their NBAR probably can.)
Is your PM-QOS policy unchanged from OP?
If so, again, it's invalid for ingress usage as there are queuing related commands. It so, again, it's also invalid for egress as you cannot use an ACL for egress matching on that platform.
For an Etherchannel, you might need to either apply policy to port-channel interface, for all member interfaces (assuming there's not additional restrictions on using QoS policies for Etherchannels).
BTW, although you should be able to have an ingress and egress policy on the same interface, you do realize, for your purpose, your ingress and egress policies likely wouldn't be on the same physical interfaces, except, if being used on both ingress and egress interfaces for your two way traffic.
host 1 port - use ingress policy to classify and remark packet's ToS, as needed/desired
host 2 port - ditto
host # port - ditto
uplink port - use egress policy - match against ToS - allocate queues as desired - policed if desired