Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Catalyst 4500 Supervisor Engine 7 Ether-Channel Egress Queueing (QoS) Restrictions


while configuring Egress Queueing on a Catalyst 4500E (Sup7 3.4.1SG) Ether-Channel (with tagged VLANs = Trunk and two physical member ports) I found out that you can use only one marking field type for egress queue selection.

This is also described in (heading "Qos Policy merging).



The following policy-map configuration restrictions are imposed on an EtherChannel:

• only policing and marking actions are supported at the logical EtherChannel level

• only queuing actions are supported at the physical member port level

A packet can be marked (dscp or cos fields) by the EtherChannel policy. If the physical member port policy uses a classification based on dscp or cos fields, it must be based on the marked (modified) value.

To ensure proper operation, the following restriction is placed on the EtherChannel:

The classification (queueing) criteria for the policy-map on the physical member ports has to based only on one type of field:

• dscp

• precedence

• cos

• any non-marking field (no dscp or cos based classification)

Classification criteria for the policy-map on the physical member ports cannot be based on a combination of fields. This restriction ensures that if the EtherChannel policy is marking down dscp or cos, the marked (modified) value-based classification can be implemented in hardware.



That means in my case I can only use DSCP-to-queue because we use DSCP for packet marking.

Does anybody know how in this case software generated layer 2 traffic (from the Sup itself, see also Software QoS ->

as STP, LLDP, CDP etc. is treated?

I only found the following passage in the Packet Marking section of the Config Guide (



For non-IP packets, classification involves  assigning an internal DSCP to the packet, but because there is no DSCP  in the non-IP packet, no overwrite occurs. Instead, the internal DSCP is  used both for queueing and scheduling decisions and for writing the CoS  priority value in the tag if the packet is being transmitted on either  an ISL or 802.1Q trunk port.



So maybe self generated layer 2 traffic will be selected to the queues by the internal dscp value if I use dscp-to-queue?

On normal physical ports I configured dscp (cs6/7) and cos (cos 6/7) to select the correct queue for the layer3 and layer2 control traffic; so this problem only exists on Ether-Channel interfaces.

Many thanks in advance