The perimeter formed by switches that do not trust incoming QoS is called the trustboundary. Usually, the trust boundary exists at the farthest reaches of the enterprise network (access-layer switches and WAN or ISP demarcation points). When the trust boundary has been identified and the switches there are configured with untrusted ports, everything else inside the perimeter can be configured to blindly trust incoming QoS values.
The above diagram shows a simple network in which the trust boundary is defined at the edges, where the network connects to end users and public networks. On Catalyst A, port Gigabit Ethernet2/1 is configured to consider inbound data as untrusted. Catalyst B’s port FastEthernet0/2 connects to a PC that also is untrusted. The Cisco IP Phone on Catalyst B port Fast Ethernet0/1 is a special case because it supports its own voice traffic and an end user’s PC. Therefore the trust boundary cannot be clearly defined for that switchport.
A Cisco Phone has a 3 port switch in it. Generally the Cisco phone is considered to be inside the trust boundary and how it should trust the PC attached to its PC port (QoS perspective) is configurable in the switchport the Cisco phone is plugged into. The phone has two streams of data: the VoIP packets it generates itself and the data it relays to the attached PC. VoIP data generated by the phone is trusted as the phone can control the DSCP markings to the packets it is generating. Also, the trust can be extended to the data from the PC by extending the trust on the switch port as below:
1 – Enable QoS
#conf t #mls qos
2 – Enable trust on the switchport to which the cisco phone is connected (e.g. fa0/1) – options are to trust CoS, IPP or DSCP
#int fa0/1 #mls qos trust qos | ip-precedence | dscp
3 – Make the trust conditional i.e. only trust the QoS markings if a cisco phone is connected. Markings will not be trusted in case a PC is connected directly to the switchport
#mls qos trust device cisco-phone
4 – To extend the trust to the PC attached to the cisco phone
#switchport priority extend cos <value> | trust
Use trust keyword if you want to trust all markings being sent by the PC. You can also re-mark the CoS by using the cos option.
What about trunks and up-link ports in the trusted boundary?
These can be configured to unconditionally trust the CoS markings, as below
#int Gi0/0 #mls qos trust cos
A Cisco Switch has a CoS-to-DSCP (and vice-versa) map. Trunks can only pass the CoS values in the encapsulated frames so the CoS values arriving in frames through a trunk or up-link/down-link must be mapped to DSCP (or IPP) values.
To see the CoS-to-DSCP map on a switch
#show mls qos maps cos-dscp Cos-dscp map: cos: 0 1 2 3 4 5 6 7 -------------------------------- dscp: 0 8 16 24 32 46 48 56
#show mls qos maps dscp-cos Dscp-cos map: d1 : d2 0 1 2 3 4 5 6 7 8 9 --------------------------------------- 0 : 00 00 00 00 00 00 00 00 01 01 1 : 01 01 01 01 01 01 02 02 02 02 2 : 02 02 02 02 03 03 03 03 03 03 3 : 03 03 04 04 04 04 04 04 04 04 4 : 05 05 05 05 05 05 05 05 06 06 5 : 06 06 06 06 06 06 07 07 07 07 6 : 07 07 07 07
Some other useful show options | commands are:
#show mls qos int fa1/0/42 ? buffers buffers keyword policers policers keyword queueing queueing keyword statistics statistics keyword | Output modifiers <cr> for example: #show mls qos int fa1/0/42 FastEthernet1/0/42 Attached policy-map for Ingress: AutoQoS-Police-CiscoPhone trust state: trust cos trust mode: trust cos trust enabled flag: ena COS override: dis default COS: 0 DSCP Mutation Map: Default DSCP Mutation Map Trust device: cisco-phone qos mode: port-based
In case the device connected to the switchport is not a cisco phone but a PC or some other node (cisco calls it an appliance) and you want to check the kind of trust being extended to the appliance, you can use
#show interface fa1/0/42 switchport ... ... Appliance trust: none