726 Chapter 10: LAN QoS

In Figure 10-11, all IP Phones reside on ports 2/1 through 2/48. The set port qos 2/1-48 vlan-based command associates all QoS configuration for these ports on a per-VLAN basis. Any previous QoS configuration attached to the specific ports are removed.

Enabling QoS based on VLAN membership works well for IP telephony because IP Phones typically share the same VLAN membership. However, what if you need to enable QoS for a separate device that does not share the same VLAN, yet needs to have QoS enabled, such as a video server in port 5/10? Example 10-10 assigns QoS configuration to the specific port 5/10.

Example 10-10 Associating QoS with a Port

CatOS> (enable) set port qos 5/10 port-based

Qos interface is set to port-based for ports 5/10

CatOS> (enable)

CoS-to-Egress Queue Mapping for the Catalyst OS Switch

By default, Cisco IP Phones mark voice bearer traffic with a CoS of 5 and voice signaling traffic with a CoS value of 3. The Catalyst 6500 places traffic marked with a CoS value of 5 into the priority queue on 1p2q2t interfaces and Queue 2 on 2q2t interfaces when QoS is enabled.

However, you must perform the additional step of configuring the Catalyst 6500 CoS queue mapping to ensure that traffic with a CoS of 3 is placed into the second queue.

Example 10-11 maps call control traffic, a CoS value of 3, to Queue 2 threshold 1 on a 2q2t interface.

Example 10-11 Map CoS Value of 3 to Queue 2 Threshold 1 for 2q2t

Cat65k> (enable) set qos map 2q2t tx 2 1 cos 3

QoS tx priority queue and threshold mapped to cos successfully.

Cat65k> (enable)

Example 10-12 shows call control traffic, a CoS value of 3, to Queue 2 threshold 1 on a 1p2q2t interface.

Example 10-12 Map CoS Value of 3 to Queue 2 Threshold 1 for 1p2q2t

Cat65k> (enable) set qos map 1p2q2t tx 2 1 cos 3

QoS tx priority queue and threshold mapped to cos successfully.

Cat65k> (enable)

Unlike the Catalyst 6500, the Catalyst 4000 places all packets, regardless of CoS values, in the first queue after QoS has been enabled. Also the Catalyst 4000 must map CoS values to a queue in pairs. In Example 10-13, CoS values of 0 and 1 have been mapped to Queue 1, whereas CoS values of 2 through 7 have been mapped to Queue 2.

QoS Configurations on Catalyst Switches 727

Example 10-13 Mapping CoS Values 2 Through & to Queue 2 Threshold 1

Cat4k> (enable) set qos map 2q1t 1 1 cos 0-1

Cat4k> (enable) set qos map 2q1t 2 1 cos 2-3

Cat4k> (enable) set qos map 2q1t 2 1 cos 4-5

Cat4k> (enable) set qos map 2q1t 2 1 cos 6-

Layer-2-to-Layer 3 Mapping

Cisco follows the recommended standard for setting the DSCP classification values for both the VoIP call control traffic and VoIP bearer traffic. The recommended settings are DSCP = AF31 (or decimal 26) for VoIP call control and DSCP = EF (or decimal 46) for VoIP bearer traffic. By default, the CoS-to-DSCP mapping does not match this recommendation, as shown in Table 10-21.

Table 10-21 Default CoS-to-DSCP Mapping

To map the Layer 2 CoS and Layer 3 IP precedence settings correctly to these DSCP values, you must modify the default CoS/ToS-to-DSCP mappings.

Example 10-14 demonstrates the configuration required for the CoS-to-DSCP mappings.

Example 10-14 Modifying the CoS-to-DSCP Mappings

CatOS> (enable) set qos cos-dscp-map 0 8 16 26 34 46 48 56

QoS cos-dscp-map set successfully.

CatOS> (enable)

728 Chapter 10: LAN QoS

Example 10-15 demonstrates the configuration required for the IP precedence-to-DSCP mappings.

Example 10-15 Modifying the IP Precedence-to-DSCP Mappings

CatOS> (enable) set qos ipprec-dscp-map 0 8 16 26 32 46 48 56

QoS ipprec-dscp-map set successfully.

Console > (enable)

Configuring Trust Boundaries for a Catalyst OS Switch

Trust boundaries define the point in the network where CoS, IP precedence, or DSCP markings are trusted. Typically this trust is established at the ingress switch port of the access layer switch. After QoS has been enabled, all ports on a Catalyst 6500 are in the untrusted state. This means that any CoS value received by the switch is re-marked with a value of 0. By contrast, after QoS has been enabled on a Catalyst 4000 switch, all ports are in a trusted state, meaning that all CoS values received are trusted on every port. Therefore, the rest of this section discussing trust excludes the Catalyst 4000.

Example 10-16 demonstrates the configuration required to instruct the Catalyst 6500 access layer switch to trust the CoS values received on the 802.1Q trunks that connect to the IP Phones.

Example 10-16 Enabling Trust of CoS

CatOS> (enable) set port qos 2/1-48 trust trust-cos

Trust type trust-cos not supported on port(s) 2/1-48

Receive thresholds enabled on ports(s) 2/1-48

Trust type set to untrusted on port(s) 2/1-48

CatOS> (enable)

On all 63xx series 10/100 Ethernet line cards with 1q4t ports, the trust-cos port keyword displays an error message stating that trust-cos is not supported. This configuration must be entered to activate the receive queue drop thresholds; however, the trust state of the ports will remain untrusted. You must configure a trust-cos ACL to match the ingress traffic to successfully apply the trust-cos trust state. This ACL is discussed in the “Configuring QoS Access Lists on a Catalyst OS Switch” section. The 65xx series 10/100 Ethernet line cards do not have this issue.

A Layer 3 6500 switch offers the capability to classify traffic flows based on IP header information, such as IP precedence and DSCP markings. This can prove useful for end devices that do not have the capability to use 802.1Q or ISL trunks, but can manipulate the IP header fields. In Figure 10-11, CallManager 1 is connected to port 5/1, and CallManager 2 is connected to port 5/2. Either of the following configurations shown in Examples 10-17 or 10-18 can be added to the switch to prioritize CallManager traffic using IP hearer information.

QoS Configurations on Catalyst Switches 729

Example 10-17 Enabling Trust of DSCP

CatOS> (enable) set port qos 5/1-2 trust trust-dscp

Port 5/1-2 qos set to trust-dscp.

CatOS> (enable)

Example 10-18 Enabling Trust of IP Precedence

CatOS> (enable) set port qos 5/1-2 trust trust-ipprec

Port 5/1-2 qos set to trust-ipprec.

CatOS> (enable)

The trust-ipprec and trust-dscp keywords are supported only with a Layer 3 switching engine.

Although the trust command determines whether the received markings are trusted on the ingress switch port, the trust-ext command has little to do with the ingress switch port. The trust-ext command determines how the ASIC on the IP Phone handles the CoS value presented by the attached PC. If the trust-ext command is trusted, the original CoS value presented by the PC to the phone is passed to the switch intact. If the trust-ext command is untrusted, the CoS value presented by the PC is rewritten to a value of 0.

In a typical IP telephony deployment, trust should not be extended to a PC. Be cautious if your design includes extending trust to a PC. If you trust one application on a PC, by default you trust all applications on that PC. This can lead to unintentional voice-quality degradation. Example 10-19 shows the trust-ext configuration of a typical IP telephony deployment.

Example 10-19 Configuring trust-ext

CatOS> (enable) set port qos 2/1-48 trust-ext untrusted

Qos trust extension for ports 2/1-48 set to untrusted.

CatOS> (enable)

Configuring Untagged Frames for the Catalyst OS Switch

What if the end device does not support 802.1Q or ISL trunks? How do you prioritize the traffic of this device? The addition of a Layer 3 switching engine allows the Catalyst to use IP precedence or DSCP to classify this traffic, but what if you do not have a Layer 3 switching engine or you would still prefer to mark the traffic with a CoS value?

You can achieve this by setting the CoS value on the ingress switch port. By doing this, you are telling the switch to mark any frame received on this port with a specific CoS value. Even though the actual received frame may not have even had an ISL or 802.1Q header, the switch can process the frame as if it had a CoS value set, based on configuration. In the sample network, for instance, CallManager 1 is connected to port 5/1, and CallManager 2 is connected to port 5/2. Example 10-20’s configuration can be added to the switch to prioritize CallManager traffic by setting any inbound traffic received on ports 5/1 or 5/2 to a CoS value of 3.

730 Chapter 10: LAN QoS

Example 10-20 Assigning a CoS Value to a Specific Port

CatOS> (enable) set port qos 5/1-2 cos 3

Port 5/1-2 qos cos set to 3

CatOS> (enable)

Because this CoS value is assigned to the port, there is no regard for the end device connected to this port. In other words, any device connected to ports 5/1 or 5/2 receive the configured CoS value. Additionally, all traffic from that end device receive this CoS value. In this configuration, for example, web browsing from the CallManager server receives the same priority across your network as call control traffic. For this reason, it is recommended just to trust DSCP on ports connected to a CallManager, allowing the CallManager to identify the proper QoS classification

To remove the CoS value applied to a specific port, use the clear port qos command, as shown in Example 10-21.

Example 10-21 Clearing a CoS Value from a Specific Port

CatOS> (enable) clear port qos 5/1-2 cos

Port 5/1-2 qos cos setting cleared.

CatOS> (enable)

Configuring QoS Access Lists in the Catalyst OS Switch

As discussed in the “Configuring Trust Boundaries for a Catalyst OS Switch” section, the 63xx series line cards with 1q4t ports do not apply the trust-cos trust state to ingress traffic. An ACL must be configured to enable the port to trust the received CoS values. The set qos acl command is used to accomplish this task. Example 10-22 demonstrates the configuration of a QoS ACL.

Example 10-22 Configuring a QoS ACL

Cat65k> (enable) set qos acl ip IP-PHONES trust-cos any

IP_PHONES editbuffer modified. Use 'commit' command to apply changes.

Cat65k> (enable)

In this example, a QoS access list named IP-PHONES was created. The IP-PHONES QoS ACL is configured to trust the CoS value from any device.

After the ACL has been created, it must be committed to hardware. QoS ACLs reside in hardware ASICs for optimum performance. The commit qos acl command enables you to accomplish this task. Example 10-23 demonstrates the configuration required to commit a QoS ACL to hardware.