CCNP 642-811 BCMSN Exam Certification Guide - Cisco press

416 Chapter 17: DiffServ QoS Configuration

NOTE Packets with CoS 5 are always placed in the strict-priority or egress expedite queue, but that queue cannot be used until it is enabled. Use the following interface configuration command to enable the strict-priority queue:

Switch(config-if)# priority-queue out

Avoiding Congestion by Using Tail Drop

For standard tail-drop behavior, WRR must be disabled on an interface. After the egress queue fills, tail drop causes newly queued packets to be dropped instead. This occurs at the 100 percent mark of the queue. Normally, tail drop should not be used because it can adversely affect the network performance of TCP sessions.

NOTE The strict-priority queue is never a candidate for WRR-based queue scheduling. In the event that the queue fills to capacity, new packets will be dropped, following standard tail-drop behavior.

To enable tail-drop operation for an egress queue, use the following interface configuration command:

Switch(config-if)# no wrr-queue random-detect queue-id

Avoiding Congestion by Using WRED

By default, each switch interface has WRED enabled. If tail drop is being used instead, WRED has been disabled. To revert back to WRED, it must be re-enabled. Note that WRED is used on a perqueue basis and that it must be enabled on each of the interface’s queues individually. To enable WRED for a specific queue number, use this interface configuration command:

Switch(config-if)# wrr-queue random-detect queue-id

Setting WRED Thresholds

WRED keeps two thresholds per queue for most types of interfaces—a minimum threshold and a maximum threshold. If the queue level is below the minimum, WRED cannot drop any packets. While the level is between the minimum and maximum values, WRED is allowed to randomly drop packets at a rate proportional to the queue level. When the queue level rises above the maximum threshold, all new packets will be dropped. To set the WRED thresholds, use the following interface configuration command:

Switch(config-if)# wrr-queue random-detect {max-threshold | min-threshold} queue-id threshold-percent-1 ... threshold-percent-N

A QoS Configuration Example 417

By default, queue 1 (the lowest-priority standard queue) has a minimum threshold of 0 and a maximum threshold of 40 percent. Queue 2 (the next-higher priority standard queue) has a minimum of 0 and a maximum of 100 percent.

The low-priority standard queue will always be susceptible to random drops (minimum is 0 percent). When the low-priority standard queue fills to 40 percent, all new packets will be dropped. The higher-priority queue is also susceptible to random drops (its minimum is also 0 percent); however, this queue’s level must reach 100 percent before all packets are dropped.

NOTE The strict-priority queue is never a candidate for WRED-based drops. Instead, all packets queued are guaranteed to be delivered. Only when the queue fills to capacity will new packets be dropped, following standard tail-drop behavior.

A QoS Configuration Example

QoS configuration within a single switch can be confusing and complex. To properly implement QoS policies in a common QoS domain (your entire network, for example), you must configure the QoS policies on each and every switch. This example is designed to help solidify the many topics presented in this chapter so that you can identify trust boundaries and configure QoS in a logical fashion.

Figure 17-2 shows a simple network consisting of two Catalyst multilayer switches. Catalyst A sits at the edge of the QoS domain, where this network joins another “public” network. Catalyst B, on the other hand, sits inside the QoS domain and interfaces to some end user devices. One port connects to a user PC and another port connects to a Cisco IP Phone. Another user PC connects to the IP Phone’s data port.

Figure 17-2 Network Diagram for the QoS Example

418 Chapter 17: DiffServ QoS Configuration

To configure QoS in this network, you must first define the QoS domain, where QoS information will be known and trusted. The edge of this domain lies at the points where QoS information is no longer trusted—at the trust boundaries. In Figure 17-2, a trust boundary exists where Catalyst A connects to the public network. Another trust boundary exists where Catalyst B meets the end users. The user PC should not be trusted because it might have applications that try to spoof or elevate the QoS information to bogus values in an effort to get better service. The IP Phone itself can be trusted because it is just another network device that can be configured and controlled. However, it lies at another trust boundary where another user PC connects. (The details of QoS trust with an IP Phone are discussed in Chapter 18 “IP Telephony.”)

Configuring QoS Trust

First, you should configure Catalyst A for its trust boundary on interface GigabitEthernet 2/1. Any QoS information coming from the public network should be untrusted because you have no control over the values being sent or who is sending them. You can use the following configuration commands to accomplish this:

mls qos

interface gigabitethernet 2/1 no mls qos trust

Notice that the first command enabled QoS on the switch. Do not forget this important first step. The interface is configured to consider all inbound QoS information as untrusted. As a result, any inbound CoS (assuming this interface is a trunk) and DSCP values are set to 0, the default.

Notice also that this interface configuration command is not necessary because all switch ports are configured as untrusted by default. This also means that all of Catalyst A’s ports that are inside the QoS domain (the trusted side) will not trust QoS information that should be known and valid. Do not forget to configure the trusted ports—every switch port that connects to another switch inside your network. If you configure QoS consistently throughout your network, you can always trust the QoS information as it moves about.

For this network, inbound DSCP information will be used as the trusted quantity. This is possible because all the switches are multilayer switches and can understand and work with DSCP as an IP or Layer 3 quantity. Catalyst A’s GigabitEthernet 2/2 interface is then configured as a trusted port with the following configuration commands:

interface gigabitethernet 2/2 mls qos trust dscp

A QoS Configuration Example 419

NOTE Remember that only inbound QoS information can be trusted. Outbound QoS information is simply sent on to the next-hop switch or router where it will be evaluated against another trust relationship there. Any DSCP information that Catalyst A accepts from the internal network will also be forwarded out toward the public network on interface GigabitEthernet 2/1. Does the network on the other side of the QoS boundary have to accept or trust the QoS information you send? Only if it wants to. It is up to the network administrators on that end to decide what sort of trust relationship to configure on their switches.

Next, you must configure Catalyst B for its trust boundary. Interface GigabitEthernet 0/1 is on the inside or trusted side of the QoS domain. Therefore, DSCP information can be trusted:

mls qos

interface gigabitethernet 0/1 mls qos trust dscp

Interface FastEthernet 0/2 connects to an end user’s PC and should not trust any QoS information. The following configuration commands set the trust boundary and force any inbound CoS and DSCP values to 0 (by default):

interface fastethernet 0/2 no mls qos trust

Interface FastEthernet 0/1 presents an interesting case. Here, a Cisco IP Phone is connected, transporting Voice over IP (VoIP) traffic, as well as normal data from the attached PC. As Chapter 18 discusses, a Catalyst switch can detect an IP Phone via Cisco Discovery Protocol (CDP) and can instruct the phone to extend a trust boundary to its auxiliary data port. The voice traffic from the phone should be implicitly trusted because the phone is both a Cisco device and a small switch that can be configured and controlled.

The PC connected to the phone, however, should normally be untrusted and have all inbound CoS values set to 0. This is mentioned here to show how trust boundaries also exist at any connected IP Phones. The following configuration commands for the phone trust boundary are fully explained in Chapter 18:

interface fastethernet 0/1 switchport voice vlan 200 switchport priority extend cos 0

Configuring a QoS Class to Classify Traffic

In this example, suppose you need to make sure some types of traffic receive premium service within your network. These types of traffic are classified at the QoS domain boundary, at Catalyst A. HTTP traffic from a server at 10.1.1.1 is considered to contain important, time-critical market data for your

Verifying and Troubleshooting QoS 423

Example 17-1 provides sample output from the show mls qos interface command.

Example 17-1 show mls qos interface Command Output

Switch# show mls qos interface gigabitethernet 0/1

GigabitEthernet0/1 trust state: trust cos trust mode: trust cos COS override: dis default COS: 0

DSCP Mutation Map: Default DSCP Mutation Map trust device: none

The show mls qos interface queueing command shows the following information about an interface:

■Current state of the strict-priority (expedite) queue

■WRR transmit queue weighting (bandwidth)

■Egress queue ratios (qid-weights)

■Egress queue scheduling (CoS-to-queue mapping)

Example 17-2 shows sample output from the show mls qos interface queueing command.

Example 17-2 show mls qos interface queueing Command Output

continues