QoS on Cat4500-E with a Sup 6/7-E is more aligned to the Modular QoS CLI (MQC) known from router platforms then on a Cat6500, even though it still got restrictions based on the architecture compared to routers. The Cat4500-E switches perform all QoS actions on the supervisor engine, therefore the line cards do not add to the QoS complexity with their own queueing structure. The whole chassis uses an 1P7Q1T (1 Priority queue, 7 normal Queues, 1 Threshold) queueing structure. But there is a gotcha for QoS on Etherchannel (how surprising 😉 ), the QoS documentation shows the following restrictions:
- Queuing actions are only allowed in the egress direction and only on the physical port.
- Percentage-based actions like policer cannot be configured on a VLAN, Port and VLAN (PV) and EtherChannel.
- Port channel or VLAN configuration can only have a policing or a marking action, not a queueing action.
The example configuration below shows what this means in terms of configuration. The priority queue has to be defined on the physical ports while the policing action is configured on the port-channel interface.
class-map match-any PRIORITY-QUEUE match dscp ef ! policy-map EGRESS-QUEUING-PHYSICAL class PRIORITY-QUEUE priority class class-default policy-map EGRESS-QUEUING-LOGICAL class PRIORITY-QUEUE police cir 2g ! int po 1 service-policy output EGRESS-QUEUING-LOGICAL ! int te1/1 service-policy output EGRESS-QUEUING-PHYSICAL ! int te1/2 service-policy output EGRESS-QUEUING-PHYSICAL
Cisco is now using a more MQC like QoS configuration with the Sup2T Supervisor Engine which is called C3PL (Cisco Common Classification Policy Language). C3PL is not only used for QoS configuration but also for other tasks:
Cisco Common Classification Policy Language is a structured replacement for feature-specific configuration commands. C3PL allows you to create traffic policies based on events, conditions, and actions
If you know MQC you´ll find it more confortable to use the new C3PL instead of the old mls QoS configuration but the Cat6500 architecture still plays a role. If you want to configure egress QoS on an etherchannel, you have to configure the egress queuing policies on the physical port members of the etherchannel, it cannot be configured on the logical Etherchannel interface. If you try to, you´ll get an error message like this:
MQC features are not supported in output direction for this interface
The documentation for this can be found in the Cat6500 Supervisor 2T Qos Design At-a-Glance Guide.
As explained above you have to configure egress queueing policies on the physical port members to make use of egress queueing policies on an etherchannel:
class-map type lan-queuing PRIORITY-QUEUE match dscp ef ! policy-map type lan-queueing EGRESS-QUEUING-PHYSICAL class PRIORITY-QUEUE priority class class-default ! int te1/1 channel-group 10 mode active service-policy type lan-queueing output EGRESS-QUEUING-PHYSICAL ! int te1/2 channel-group 10 mode active service-policy type lan-queueing output EGRESS-QUEUING-PHYSICAL
I really don’t like QoS on Cisco Switches, its too complicated and totally depends on the chassis or even on the line card in chassis based switches. What made things worse is how QoS and VSS is implemented on the Cat6500 (and documented). I recently had to create a QoS design for a customer which had VSS on Cat6500 with SUP2T and 16-port 10GE line cards. The VSL Links were on the SUP using the two 10GE ports and I had to configure QoS towards the WAN on two out of the three 1GE ports on the SUP.