QoS Trust Boundary and DSCP Marking on Cisco Switches

QoS fails more often from bad trust decisions than from bad queuing. If access ports trust whatever the endpoint marks, a single misconfigured application can put its bulk transfer into the voice queue; if nothing is trusted, every packet arrives as best effort and the whole design is decorative. This guide explains where the trust boundary belongs on a Cisco access switch, how to mark with MQC instead of trusting client labels, how the CoS and DSCP maps tie the two together, and how to verify the result on real traffic.

Where the trust boundary goes

Access ports cannot trust CoS because there is no 802.1Q tag on an untagged frame - CoS only exists in a tagged frame. That single fact explains most "my trust configuration did nothing" tickets: on an access port, mls qos trust cos has nothing to read, so you must trust DSCP or classify with a policy.

Mark at the boundary with MQC

ip access-list extended VOICE-RTP
 permit udp any any range 16384 32767 dscp ef
ip access-list extended CALL-SIGNALING
 permit tcp any any eq 5060
class-map match-any CM-VOICE
 match access-group name VOICE-RTP
class-map match-any CM-SIGNALING
 match access-group name CALL-SIGNALING
class-map match-any CM-BULK
 match access-group name BULK-TRANSFER

policy-map ACCESS-MARK
 class CM-VOICE
  set dscp ef
  police 128000 conform-action transmit exceed-action drop
 class CM-SIGNALING
  set dscp cs3
 class CM-BULK
  set dscp af11
 class class-default
  set dscp default

Apply it, and handle the phone case

interface GigabitEthernet1/0/12
 description IP phone with PC behind
 switchport mode access
 switchport access vlan 10
 switchport voice vlan 20
 mls qos trust dscp
 service-policy input ACCESS-MARK
 spanning-tree portfast

interface GigabitEthernet1/0/20
 description Plain user port - never trust
 switchport mode access
 switchport access vlan 10
 no mls qos trust
 service-policy input ACCESS-MARK

Applying service-policy input replaces the interface-level mls qos trust statement for that port, so do not chase a conflict that is really a precedence rule. In a policy-map you can use either set or trust in a class, not both - to trust voice and mark data, split them into separate classes, as above.

The COS-to-DSCP maps

show mls qos maps cos-dscp
show mls qos maps dscp-cos
show mls qos maps dscp-mutation

! re-map CoS 5 so it becomes EF instead of CS5
mls qos map cos-dscp 0 8 16 24 32 46 48 56
show mls qos maps cos-dscp | include 5

The default COS-to-DSCP table maps CoS 5 to CS5 (DSCP 40), not to EF (46). Voice traffic marked CoS 5 by a phone will therefore arrive at the core as CS5 unless you either trust DSCP (the phone marks EF in the IP header) or adjust the map. Either is defensible; silently mixing both is not.

Verification

show mls qos interface GigabitEthernet1/0/12
show policy-map interface GigabitEthernet1/0/12 input
show mls qos interface statistics
show mls qos queue-set
show interfaces GigabitEthernet1/0/12 counters errors
show policy-map interface | include class-map|packets

Confirm three things: the interface shows the trust state you expect, the policy-map counters increment for each class, and the DSCP values survive to the next hop - check that on the uplink with show mls qos interface statistics or a SPAN capture. Related reading: voice VLAN configuration, Arista EOS QoS, IOS XR QoS policy shaping and Linux tc HTB shaping for the server side.

原文链接：https://www.cisco.com/c/en/us/support/docs/switches/catalyst-3750-series-switches/91862-cat3750-qos-config.html