From the beginning, IP packets have always had a type of service (ToS) byte that can be used to mark packets. This byte is divided into a 3-bit IP Precedence value and a 4-bit ToS value. This offers a rather limited mechanism for QoS because only the 3 bits of IP Precedence are used to describe the per-hop QoS behavior.
The DiffServ model keeps the existing IP ToS byte but uses it in a more scalable fashion. This byte also is referred to as the Differentiated Services (DS) field, with a different format, as shown in Figure 14-3. The 6-bit DS value is known as the Differentiated Service Code Point (DSCP) and is the one value that is examined by any DiffServ network device.
Don’t be confused by the dual QoS terminology—the ToS and DS bytes are the same, occupying the same location in the IP header. Only the names are different, along with the way the value is interpreted. In fact, the DSCP bits have been arranged to be backward compatible with the IP precedence bits so that a non-DiffServ device still can interpret some QoS information.
Figure 14-3 ToS and DSCP Byte Formats
The DSCP value is divided into a 3-bit class selector and a 3-bit Drop Precedence value. Refer to Table 14-4 to see how the IP precedence, DSCP per-hop behavior, and DSCP codepoint names and numbers relate.
Table 14-4 Mapping of IP Precedence and DSCP Fields IP Precedence (3 Bits) DSCP (6 Bits)
Name Value Bits
Per-Hop Behavior
Class Selector
Drop Precedence
Codepoint Name
DSCP Bits (Decimal)
Routine 0 000 Default Default 000 000 (0)
Priority 1 001 AF 1 1: Low AF11 001 010 (10)
2: Medium AF12 001 100 (12)
3: High AF13 001 110 (14)
Immediate 2 010 AF 2 1: Low AF21 010 010 (18)
2: Medium AF22 010 100 (20)
3: High AF23 010 110 (22)
ToS Byte:
DS Byte:
P2 P1 P0 T3 T2 T1 T0 Zero
DS5 DS4 DS3 DS2 DS1 DS0 ECN1 ECN0
(Class Selector) (Drop Precedence)
DiffServ QoS 371
The three class selector bits (DS5 through DS3) coarsely classify packets into one of seven classes:
■ Class 0, the default class, offers only best-effort forwarding.
■ Classes 1 through 4 are called Assured Forwarding (AF) service levels. Higher AF class numbers indicate the presence of higher-priority traffic.
Packets in the AF classes can be dropped, if necessary, with the lower-class numbers the most likely to be dropped. For example, packets with AF Class 4 will be delivered in preference to packets with AF Class 3.
■ Class 5 is known as Expedited Forwarding (EF), with those packets given premium service. EF is the least likely to be dropped, so it always is reserved for time-critical data such as voice traffic.
■ Classes 6 and 7 are called Internetwork Control and Network Control, respectively, and are set aside for network control traffic. Usually, routers and switches use these classes for things such as the Spanning Tree Protocol and routing protocols. This ensures timely delivery of the packets that keep the network stable and operational.
IP Precedence (3 Bits) DSCP (6 Bits)
Name Value Bits
Per-Hop Behavior
Class Selector
Drop Precedence
Codepoint Name
DSCP Bits (Decimal)
Flash 3 011 AF 3 1: Low AF31 011 010 (26)
2: Medium AF32 011 100 (28)
3: High AF33 011 110 (30)
Flash Override
4 100 AF 4 1: Low AF41 100 010 (34)
2: Medium AF42 100 100 (36)
3: High AF43 100 110 (38)
Critical 5 101 EF EF 101 110
(46)*
Internetwork Control
6 110 (48–55)
Network Control
7 111 (56–63)
*IP precedence value 5 (DSCP EF) corresponds to the range of DSCP bits 101000 through 101111, or 40–47. However, only the value 101110 or 46 is commonly used and is given the EF designation.
Table 14-4 Mapping of IP Precedence and DSCP Fields (Continued)
372 Chapter 14: IP Telephony
Each class represented in the DSCP also has three levels of drop precedence, contained in bits DS2 through DS0 (DS0 is always zero):
■ Low (1)
■ Medium (2)
■ High (3)
Within a class, packets marked with a higher drop precedence have the potential for being dropped before those with a lower value. In other words, a lower drop precedence value gives better service.
This gives finer granularity to the decision of what packets to drop when necessary.
Implementing QoS for Voice
To manipulate packets according to QoS policies, a switch somehow must identify which level of service each packet should receive. This process is known as classification. Each packet is classified according to the type of traffic (UDP or TCP port number, for example), according to parameters matched by an access list or something more complex, such as by stateful inspection of a traffic flow.
Recall that IP packets carry a ToS or DSCP value within their headers as they travel around a network. Frames on a trunk also can have CoS values associated with them. A switch then can decide whether to trust the ToS, DSCP, or CoS values already assigned to inbound packets. If it trusts any of these values, the values are carried over and used to make QoS decisions inside the switch.
If the QoS values are not trusted, they can be reassigned or overruled. This way, a switch can set the values to something known and trusted, and something that falls within the QoS policies that must be met. This prevents nonpriority users in the network from falsely setting the ToS or DSCP values of their packets to inflated levels so that they receive priority service.
Every switch must decide whether to trust incoming QoS values. Generally, an organization should be able to trust QoS parameters anywhere inside its own network. At the boundary with
TIP The DSCP value can be given as a codepoint name, with the class selector providing the two letters and a number followed by the drop precedence number. For example, class AF Level 2 with drop precedence 1 (low) is written as AF21. The DSCP commonly is given as a decimal value. For AF21, the decimal value is 18. The relationship is confusing, and Table 14-2 should be a handy aid.
You should try to remember a few codepoint names and numbers. Some common values are EF (46) and most of the classes with low drop precedences: AF41 (34), AF31 (26), AF21 (18), and AF11 (10). Naturally, the default DSCP has no name (0).
DiffServ QoS 373
another organization or service provider, QoS typically should not be trusted. It is also prudent to trust only QoS values that have been assigned by the network devices themselves. Therefore, the QoS values produced by the end users should not be trusted until the network can verify or override them.
The perimeter formed by switches that do not trust incoming QoS is called the trust boundary.
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.
Figure 14-4 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 GigabitEthernet2/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 FastEthernet0/1 is a special case because it supports its own voice traffic and an end user’s PC. Therefore, the trust boundary can’t be clearly defined on that switch port.
Figure 14-4 A QoS Trust Boundary Example
TIP Every switch and router within a network must be configured with the appropriate QoS features and policies, so that a trust boundary is completely formed. The BCMSN course and exam limit QoS coverage to the switches at the access layer, where the trust boundary is configured and enforced. Other more involved QoS topics are dealt with in the “Implementing Cisco Quality of Service (QoS)” course, as well as these Cisco Press books: Cisco Catalyst QoS: Quality of Service in Campus Networks (ISBN 1587051206) and Cisco DQOS Exam Certification Guide (ISBN 1587200589).
Catalyst B
Cisco IP Phone
gig0/1 fa0/1
gig2/2
fa0/2
Catalyst A
PC
PC VLAN 200
VLAN 100
gig2/1
Trust Boundary
Untrusted Untrusted
Trust Boundary Public
Network
IP
374 Chapter 14: IP Telephony
Configuring a Trust Boundary
When a Cisco IP Phone is connected to a switch port, think of the phone as another switch (which it is). If you install the phone as a part of your network, you probably can trust the QoS information relayed by the phone.
However, remember that the phone also has two sources of data:
■ The VoIP packets native to the phone—The phone can control precisely what QoS information is included in the voice packets because it produces those packets.
■ The user PC data switch port—Packets from the PC data port are generated elsewhere, so the QoS information cannot necessarily be trusted to be correct or fair.
A switch instructs an attached IP Phone through CDP messages on how it should extend QoS trust to its own user data switch port. To configure the trust extension, use the following configuration steps:
Step 1 Enable QoS on the switch:
Switch(config)# mls qos
By default, QoS is disabled globally on a switch and all QoS information is allowed to pass from one switch port to another. When you enable QoS, all switch ports are configured as untrusted, by default.
Step 2 Define the QoS parameter that will be trusted:
Switch(config)# iiiinnnnttettereerrrffffaacaacecceee type mod/num
Switch(config-if)# mls qos trust {cos | ip-precedence | dscp}
You can choose to trust the CoS, IP precedence, or DSCP values of incoming packets on the switch port. Only one of these parameters can be selected.
Generally, for Cisco IP Phones, you should use the cos keyword because the phone can control the CoS values on its two-VLAN trunk with the switch.
Step 3 Make the trust conditional:
Switch(config-if)# mls qos trust device cisco-phone
You also can make the QoS trust conditional if a Cisco IP Phone is present.
If this command is used, the QoS parameter defined in step 2 is trusted only if a Cisco phone is detected through CDP. If a phone is not detected, the QoS parameter is not trusted.
Step 4 Instruct the IP Phone on how to extend the trust boundary:
Switch(config-if)# switchport priority extend {cos value | trust}
Normally, the QoS information from a PC connected to an IP Phone should not be trusted. This is because the PC’s applications might try to spoof CoS or Differentiated Services Code Point (DSCP) settings to gain premium
DiffServ QoS 375
network service. In this case, use the cos keyword so that the CoS bits are overwritten to value by the IP Phone as packets are forwarded to the switch.
If CoS values from the PC cannot be trusted, they should be overwritten to a value of 0.
In some cases, the PC might be running trusted applications that are allowed to request specific QoS or levels of service. Here, the IP Phone can extend complete QoS trust to the PC, allowing the CoS bits to be forwarded through the phone unmodified. This is done with the trust keyword.
By default, a switch instructs an attached IP Phone to consider the PC port as untrusted. The phone will overwrite the CoS values to 0.
What about switch ports that don’t connect to end-user or phone devices? Switch uplinks always should be considered as trusted ports—as long as they connect to other trusted devices that are within the QoS boundary. QoS parameters are trusted or overwritten at the network edge, as packets enter the trusted domain. After that, every switch inside the trusted boundary can implicitly trust and use the QoS parameters in any packet passing through.
You can configure a switch uplink port to be trusted with the following commands:
Switch(config)# iiiinnnnttetteeerrfrrfffaacaacccee type mod/numee Switch(config-if)# mmmmllsllsss qqqqoooossss ttttrrrruuuusssstttt ccccoosoosss
Here, the trust is not conditional. The switch will trust only the CoS values that are found in the incoming packets.
Using Auto-QoS to Simplify a Configuration
You can also configure Cisco switches to support a variety of other QoS mechanisms and parameters. The list of features and configuration commands can be overwhelming, and the actual configuration can be quite complex. This is one reason why the bulk of QoS topics are no longer covered in the BCMSN course and exam.
Courses and testing aside, you will sometimes need to configure some advanced QoS features on a switch. To reduce the complexity, Cisco introduced the Auto-QoS feature on most switch platforms. By entering only a couple of configuration commands, you can enable the switch to automatically configure a variety of QoS parameters.
TIP A Cisco switch also has a CoS-to-DSCP map that is used to convert inbound CoS values to DSCP values. The CoS information is useful only on trunk interfaces because it can be carried within the trunk encapsulation. CoS must be converted to DSCP or IP precedence, which can be carried along in the IP packet headers on any type of connection.
Switches use a default CoS-to-DSCP mapping, which can be configured or changed. However, this is beyond the scope of the BCMSN course and exam.
376 Chapter 14: IP Telephony
Auto-QoS is actually handled by a macro command, which in turn enters many other configuration commands as if they were entered from the command-line interface. Because of this, Auto-QoS is best used on a switch that still has the default QoS configuration. Otherwise, any existing QoS commands could be overwritten or could interfere with the commands produced by the Auto-QoS macro.
The configuration commands resulting from Auto-QoS were developed from rigorous testing and Cisco best practices. Auto-QoS handles the following types of QoS configuration:
■ Enabling QoS
■ CoS-to-DSCP mapping for QoS marking
■ Ingress and egress queue tuning
■ Strict priority queues for egress voice traffic
■ Establishing an interface QoS trust boundary Use the following steps to configure Auto-QoS:
Step 1 Select an interface at the QoS boundary:
Switch(config)# interface type mod/num
Step 2 Enable Auto-QoS with the appropriate trust:
Switch(config-if)# auto qos voip {cisco-phone | cisco-softphone | trust}
If the switch port is connected to a Cisco IP Phone, you should use the cisco-phone keyword. Once that is enabled, the switch will trust the class of service information presented by the phone, if a phone is detected by CDP. If no phone is connected, the port is considered untrusted.
If a PC running the Cisco SoftPhone application is connected, choose the cisco-softphone keyword. Packets that are received with DSCP values of 24, 26, or 46 will be trusted; packets with any other value will have their DSCP values set to zero.
TIP The Auto-QoS feature is designed to automatically configure many more advanced QoS parameters, in specific applications. For example, Auto-QoS can be used on switch interfaces where Cisco IP Phones are connected. Auto-QoS is not meant to be used on all switches in a network. Therefore, you should consider using it in access layer switches and not necessarily the network core.
DiffServ QoS 377
On a switch port acting as an uplink to another switch or router, you should use the trust keyword. All packets received on that port will be trusted, and the QoS information will be left intact.
Remember that the auto qos voip command is actually a macro that executes many other configuration commands for you. The auto qos voip command will appear in the switch configuration, along with the other commands it enters. You won’t see the additional commands until you show the running configuration. However, using the debug auto qos EXEC command displays the additional commands in the resulting debug messages. (Don’t forget to disable the debugging with no debug auto qos when you’re finished with it.)
Example 14-5 shows what Auto-QoS is doing behind the scenes. By entering one interface configuration command, you can effectively configure many QoS parameters—even if you don’t understand their functions. The commands are shown here as a demonstration; the BCMSN course and exam don’t cover their meaning or use.
Interface fastethernet 0/37 normally has a Cisco IP Phone connected to it. Therefore, the auto qos voip cisco-phone command is used. Notice that among the many mls qos and wrr-queue QoS- related commands are two shaded commands that enable trust for CoS values coming from a Cisco phone. Interface gigabitethernet 0/1 is an uplink to another trusted switch, so the auto qos voip trust command is used on it. The shaded mls qos trust cos command causes the CoS information to be implicitly trusted.
TIP If you have already configured Auto-QoS on an interface by using the cisco-phone, cisco-softphone, or trust keyword, you won’t be allowed to use the auto qos voip command again on the same interface. Instead, first remove any existing Auto-QoS by entering the no auto qos voip command. Then use the auto qos voip command with the desired keyword to enable Auto-QoS.
Example 14-5 Auto-QoS Commands Revealed
Switch#ddeddeeebbbbuuuugggg aaaauutuutttoooo qqqqoosoosss AutoQoS debugging is on
Switch# ccccoooonnnnffffiigiiggg tttteeeerrrrmmmm
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# iiiinnnntttteereerrrffaffaaacccceeee ffaffaaasstssttteeteettthhhheereerrrnnenneeett tt 0000//3//3337777 Switch(config-if)# aauaauuuttottooo qqqqooooss ss vvovvoooiipiippp ccicciiisscsscccoo-oo---pppphhohhooonnenneee Switch(config-if)#
*Sep 7 04:14:41.618 EDT: mls qos map cos-dscp 0 8 16 26 32 46 48 56
*Sep 7 04:14:41.622 EDT: mls qos min-reserve 5 170
*Sep 7 04:14:41.622 EDT: mls qos min-reserve 6 85
*Sep 7 04:14:41.622 EDT: mls qos min-reserve 7 51
continues
378 Chapter 14: IP Telephony
Verifying Voice QoS
A switch port can be configured with a QoS trust state with the connected device. If that device is an IP Phone, the switch can instruct the phone on whether to extend QoS trust to an attached PC.
To verify how QoS trust has been extended to the IP Phone itself, use the following EXEC command:
Switch#sssshhhhoowoowww mmmmllsllsss qqqqoooossss iiiinnnntttteeeerrrrffaffaaaccecceee type mod/num
If the port is trusted, all traffic forwarded by the IP Phone is accepted with the QoS information left intact. If the port is not trusted, even the voice packets can have their QoS information overwritten by the switch. Example 14-6 demonstrates some sample output from the show mls
*Sep 7 04:14:41.626 EDT: mls qos min-reserve 8 34
*Sep 7 04:14:41.626 EDT: mls qos
*Sep 7 04:14:42.598 EDT: interface FastEthernet0/37
*Sep 7 04:14:42.598 EDT: mls qos trust device cisco-phone
*Sep 7 04:14:42.602 EDT: mls qos trust cos
*Sep 7 04:14:42.606 EDT: wrr-queue bandwidth 10 20 70 1
*Sep 7 04:14:42.610 EDT: wrr-queue min-reserve 1 5
*Sep 7 04:14:42.618 EDT: wrr-queue min-reserve 2 6
*Sep 7 04:14:42.626 EDT: wrr-queue min-reserve 3 7
*Sep 7 04:14:42.634 EDT: wrr-queue min-reserve 4 8
*Sep 7 04:14:42.642 EDT: no wrr-queue cos-map
*Sep 7 04:14:42.646 EDT: wrr-queue cos-map 1 0 1
*Sep 7 04:14:42.650 EDT: wrr-queue cos-map 2 2 4
*Sep 7 04:14:42.654 EDT: wrr-queue cos-map 3 3 6 7
*Sep 7 04:14:42.658 EDT: wrr-queue cos-map 4 5
*Sep 7 04:14:42.662 EDT: priority-queue out
Switch(config-if)# iiniinnnttetteeerrrrffffaaaaccecceee ggggiigiigggaaaabbibbiiittetteeetthtthhheeeerrnrrnnneeteettt 0000////1111 Switch(config-if)# aauaauuuttottooo qqqqooooss ss vvovvoooiipiippp ttrttrrruusuussstttt
Switch(config-if)#
*Sep 7 15:05:50.943 EDT: interface GigabitEthernet0/1
*Sep 7 15:05:50.947 EDT: mls qos trust cos
*Sep 7 15:05:50.951 EDT: wrr-queue bandwidth 10 20 70 1
*Sep 7 15:05:50.955 EDT: wrr-queue queue-limit 50 25 15 10
*Sep 7 15:05:50.959 EDT: no wrr-queue cos-map
*Sep 7 15:05:50.963 EDT: wrr-queue cos-map 1 0 1
*Sep 7 15:05:50.967 EDT: wrr-queue cos-map 2 2 4
*Sep 7 15:05:50.971 EDT: wrr-queue cos-map 3 3 6 7
*Sep 7 15:05:50.975 EDT: wrr-queue cos-map 4 5
*Sep 7 15:05:50.979 EDT: priority-queue out Example 14-5 Auto-QoS Commands Revealed (Continued)