QoS Trust Boundary on Cisco Switches: DSCP vs CoS - 夜莺博客

QoS Trust Boundary on Cisco Switches: DSCP vs CoS

The trust boundary is the point in the network up to which you believe the markings on arriving packets and frames. Everything upstream is trusted implicitly; everything downstream must be classified and marked by a switch. Moving that boundary is the single decision that determines whether your QoS design works end to end, because marking at the endpoint scales far better than re-marking at every hop — but a trust boundary placed too far out lets a user laptop claim EF priority for its file share.

Where the boundary can sit

Boundary position Who marks Typical use
IP phone Phone marks voice; switch rewrites the attached PC's traffic Most common campus voice deployment
Access switch Switch classifies everything arriving on access ports No trusted endpoint, or no phones
Distribution switch Access layer untrusted entirely Access switches managed by a different team

In the phone-boundary design, the PC attached to the phone's data port sits outside the trust boundary: the phone can re-mark the PC's traffic to best effort. That is the whole point of the arrangement.

Step 1: enable QoS globally, and understand what that does

3560Switch(config)# mls qos

QoS is disabled by default on most Catalyst platforms and no trust setting has any effect until it is enabled. Enabling it also activates the default rewrite behaviour: the switch clears the DSCP value of every packet it receives before internally classifying it. If you are trusting incoming markings, that rewrite destroys them.

3560Switch(config)# no mls qos rewrite ip dscp

Enter no mls qos rewrite ip dscp whenever the design depends on retaining DSCP values set upstream — which is most designs that place the trust boundary at the phone or at the WAN edge. This one command is the difference between "trust worked in the lab" and "trust silently did nothing in production".

Step 2: inspect the current trust state

3560Switch# show mls qos interface fastEthernet 0/1
FastEthernet0/1
  trust state: not trusted
  trust mode: not trusted
  COS override: dis
  default COS: 0
  DSCP Mutation Map: Default DSCP Mutation Map
  Trust device: none

not trusted is the default on every port. Note the two other fields that matter: default COS: 0 is the value assigned to untagged or unmarked traffic, and the DSCP mutation map is what defines any transformation applied between trust domains.

Step 3: choose the trust mode

3560Switch(config-if)# mls qos trust cos
3560Switch(config-if)# mls qos trust dscp
3560Switch(config-if)# mls qos trust device cisco-phone
3560Switch(config-if)# mls qos trust cos pass-through
  • trust cos trusts the Layer 2 CoS field of arriving frames. Appropriate for a port facing a phone or a switch that marks at Layer 2 only.
  • trust dscp trusts the Layer 3 DSCP field. This is the recommended mode for routed boundaries and for uplinks, and it is the mode that survives the L3 hop where CoS is lost.
  • trust device cisco-phone makes trust conditional on CDP/LLDP identity: trust is applied only while a Cisco phone is detected. This is the correct configuration for an access port serving a phone with a PC behind it, because the PC traffic is re-marked while the phone's markings are honoured.
  • trust cos pass-through is the subtle one. By default, when the interface trusts CoS, the switch converts CoS to DSCP using the cos-to-dscp map and overwrites the packet's DSCP. pass-through keeps the DSCP value untouched while still using CoS for internal queue selection — required when different parts of the network use CoS and DSCP for different purposes.

Verify with the interface view again

3560Switch# show mls qos interface fastEthernet 0/1
  trust state: trust cos
  trust mode: trust cos
  COS override: dis
Trust device: none

trust state confirms the applied state; trust device shows whether conditional trust (for example from trust device cisco-phone) is currently engaged. If trust is conditional and no phone is detected, trust state will read not trusted even though the configuration looks right — never conclude the config failed without checking the detected device.

Design rules that avoid the usual mistakes

  • Enable QoS globally first, then remove the DSCP rewrite if you intend to trust upstream markings. Skipping either step makes the entire boundary a no-op.
  • Trust DSCP on routed uplinks and trunk ports; trust CoS only where you control both ends at Layer 2.
  • Trust IP phones conditionally (CDP/LLDP), never trust generic access ports — a host can set EF on every packet it sends.
  • Classify and re-mark at the access edge for anything arriving on an untrusted port; use a scavenger class for known low-value traffic (peer-to-peer, backup) so it yields to everything else.
  • Remember that CoS is 3 bits and DSCP is 6 bits: any CoS-to-DSCP conversion is lossy, so converting twice through the network destroys your classification.

For the H3C equivalent of the same design see H3C Comware priority trust and QoS mapping, and for Layer 2 port configuration on which trust is applied see Cisco IOS private VLAN configuration.

原文链接:https://networklessons.com/quality-of-service/how-to-configure-qos-trust-boundary-on-cisco-switches