How does a switch mark non-IP frames when 'mls qos trust dscp' is set on a trunk port?

[smdonovan]

Hello Networkers!

I would like to know how a switch handles marking of non-IP frames when 'mls qos trust dscp' is set on a trunk port.

DSCP is contained in an IP header and is thus not present in frames carrying layer 2 protocols.

Here are some basic definitions for clarity:

mls qos trust cos - on the ingress port of a switch the COS value in the ISL or 802.1q VLAN tag, if set, is preserved. The switch maps COS to DSCP values using internal tables and uses DSCP to proritize the packet internally. If no COS value exists, the default COS value is assigned and mapped to internal DSCP value. On the egress port, the DSCP value is mapped to a COS value which is assigned to the frame as it exists the switch.

mls qos trust dscp - on the ingress port of a switch the DSCP value, if set, is preserved and used to prioritize the packet internally. On the egress port, the DSCP value is mapped to a COS values which is then assigned to the frame as it exits the switch.

Here are my questions:

What if a frame carries a layer 2 protocol like ARP or LLDP which does not contain a DSCP value but does have a COS value, and a switch ingress port has 'mls qos trust dscp' assigned? When the frame is recieved on the port, is the COS value overwritten?

Is a default DSCP value assing for internal use by the switch as the frame is processed through it?

What COS value is assigned on the egress port as the frame leaves the switch?

[Peter Paluch]

Hi,

The documentation for the Catalyst 2960 (and consequently, for 3560, 3750 and the other derived platforms) has a nice flowchart that explains this nicely (taken from the Configuration Guide here):

What if a frame carries a layer 2 protocol like ARP or LLDP which does not contain a DSCP value but does have a COS value, and a switch ingress port has 'mls qos trust dscp' assigned? When the frame is recieved on the port, is the COS value overwritten?

According to this flowchart, if mls qos trust dscp is configured on a port but a non-IP packet comes in, the switch first checks whether the non-IP packet carries a VLAN tag. If it does then the CoS in this VLAN tag will be trusted, mapped to the internal DSCP value (using a cos-dscp map table), and this internal DSCP value would then be used to represent the non-IP packet with respect to QoS operations.

Just to explain the process completely, if the non-IP packet does not contain a VLAN tag then the switch will use the value of the per-interface mls qos cos command (by default 0) to assign a default CoS to the non-IP packet which will then be again mapped to the internal DSCP value using a cos-dscp map table, and this internal DSCP value would be used further on.

Is a default DSCP value assing for internal use by the switch as the frame is processed through it?

It is actually called an internal DSCP value. These switches (2960/3560/3750) represent the QoS marking of any frame, whether it carries an IP or a non-IP packet, as a DSCP value called the internal DSCP as obviously, frames with non-IP packets don't have their own DSCP but can always be assigned a CoS (either through their VLAN tag or via a mls qos cos per-interface command) which subsequently gets mapped to internal DSCP. Even if you do mls qos trust cos, the CoS will still be mapped to an internal DSCP and that one will be used.

To put it succintly, a frame is always accompanied by its internal DSCP value on Catalyst 2960/3560/3750, and the switch just uses different methods to infer that internal DSCP.

What COS value is assigned on the egress port as the frame leaves the switch?

This question is relevant only to egress ports configured for trunking as otherwise, there is no VLAN tag to write the CoS marking into. If the trunking is in use, the internal DSCP value will be mapped back to a CoS value using a dscp-cos map, and this resulting CoS will be written into the frame's tag on the egress port.

Best regards,
Peter

P.S.: Check out the document at https://supportforums.cisco.com/document/31581/egress-qos. Unfortunately, figures in that document did not survive the migration into the current CSC web platform so the readibility is impaired but you still can read it.