Cisco QoS Exam Certification Guide: MQC, QPM, and AutoQoS

This chapter is from the book

Cisco QOS Exam Certification Guide (IP Telephony Self-Study), 2nd Edition

Learn More Buy

This chapter is from the book

This chapter is from the book 

Cisco QOS Exam Certification Guide (IP Telephony Self-Study), 2nd Edition

Learn More Buy

Cisco AutoQoS Feature

AutoQoS is a feature on some Cisco routers and switches that enables you to configure QoS on a device with only a few auto qos commands. By following some restrictions, and using the auto qos command, you can cause the router or switch to have a valid, working QoS configuration. Best of all, you do not have to know anything about how the QoS features work to use AutoQoS!

Because routers and switches do different tasks, QoS differs slightly between them. To get an idea about what AutoQoS does, consider that AutoQoS on routers works to classify packets into three service classes:

• Voice payload

• Voice signaling

• All other traffic

If you look in the router IOS documentation, AutoQoS is actually called AutoQoS VoIP, in reference to the design goal behind AutoQoS that is to provide good performance for voice traffic. That is true on both routers and switches.

AutoQoS provides some great advantages. AutoQoS automatically classifies traffic, generating the MQC QoS commands, as well as QoS commands for a couple of other QoS features. The configurations are indeed consistent if AutoQoS is used throughout the network. You can modify the automatically generated configurations as well, so you can have AutoQoS do the hard work, and then come behind it and tweak the configuration. AutoQoS also re-marks all non-voice traffic that has DSCP EF, AF31, or CS3 to DSCP 0, which helps prevent data applications from attempting to get the same treatment as voice. And AutoQoS conforms to the Cisco current Best Practices for Voice QoS, so you can be confident the voice traffic will be treated well.

AutoQoS is supported on routers, on IOS-based switches, and in Cat-OS on 6500 switches. The next three sections take a look at AutoQoS in each of these three contexts.

AutoQoS VoIP for Routers

The beauty of AutoQoS is that you need to configure only a simple command or two, and AutoQoS does the rest. This section starts with some explanation of how to configure AutoQoS on a router, followed by an explanation of what AutoQoS automatically configured on the router.

AutoQoS VoIP Default Configuration

Before configuring AutoQoS VoIP, you should refer to the IOS 12.3 QoS Configuration Guide, which lists several considerations and conditions for the right environment for enabling this feature. For QOS exam purposes, repeating the full list here is not helpful; however, considering a couple of the most common considerations can help. For instance

• AutoQoS VoIP requires that CEF be enabled first.

• AutoQoS VoIP cannot be used if the interface already has a service-policy command configured.

• Because AutoQoS VoIP relies on the bandwidth settings configured in the bandwidth command, the routers should be configured with correct bandwidth settings on each interface before enabling AutoQoS VoIP. (If you change the bandwidth after enabling AutoQoS VoIP, AutoQoS VoIP does not react and does not change the QoS configuration.)

• Supports only point-to-point subinterfaces on Frame Relay interfaces.

• Supports HDLC, PPP, Frame Relay, and ATM data link protocols.

None of these considerations poses a big problem in most networks. Having met those requirements, configuring AutoQoS VoIP is quite easy. For reference, Table 3-4 lists the commands related to AutoQoS VoIP, followed by an example configuration.

Table 3-4 Command Reference for AutoQoS VoIP (for Routers)

To begin, look at Figure 3-3 and Example 3-7. Figure 3-3 shows R1 and R3 connected over a serial link, with 2950 switches attached to each router. As noted earlier, AutoQoS VoIP on routers supports serial link protocols (such as PPP), but it does not support LAN interfaces. This example begins with the pertinent configuration before enabling AutoQoS VoIP and then shows the configuration command.

Figure 3-3 AutoQoS VoIP: Example Network with PPP

Example 3-7 AutoQoS Configuration with PPP

R3#show running-config
! portions omitted for brevity
ip cef
!
interface Serial0/1
 ip address 192.168.12.3 255.255.255.0
 encapsulation ppp
!
r3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int s 0/1
R3(config-if)#auto qos voip
R3(config-if)#end
R3#
R3#show int s 0/1
Serial0/1 is up, line protocol is up
 Hardware is PowerQUICC Serial
 Internet address is 192.168.12.3/24
 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
   reliability 255/255, txload 1/255, rxload 1/255

In this example, the configuration already uses CEF, as shown in the ip cef command. Also, interface Serial0/1 does not have a service-policy command. Next, the auto qos voip command enables AutoQoS VoIP on the interface. AutoQoS VoIP is supposed to be easy to configure—and it is. That is all there is to the typical configuration.

Of course, if you are willing to dig into QoS enough to pass the QOS exam, you are probably curious as to what the router just did for you (or to you, depending on your perspective). Example 3-8 lists the output of two show commands that list the new configuration generated by AutoQoS VoIP.

Example 3-8 show auto qos Commands

R3#show auto qos
!
! First ACL matches Voice payload, second match Voice signaling
!
 ip access-list extended AutoQoS-VoIP-RTCP
  permit udp any any range 16384 32767
 ip access-list extended AutoQoS-VoIP-Control
  permit tcp any any eq 1720
  permit tcp any any range 11000 11999
  permit udp any any eq 2427
  permit tcp any any eq 2428
  permit tcp any any range 2000 2002
  permit udp any any eq 1719
  permit udp any any eq 5060
!
! Next class-map matches voice payload
!
 class-map match-any AutoQoS-VoIP-RTP-UnTrust
  match protocol rtp audio
  match access-group name AutoQoS-VoIP-RTCP
!
! Next class-map matches voice control traffic
!
 class-map match-any AutoQoS-VoIP-Control-UnTrust
  match access-group name AutoQoS-VoIP-Control
!
! This one matches all non-voice that was already marked like voice
!
 class-map match-any AutoQoS-VoIP-Remark
  match ip dscp ef
  match ip dscp cs3
  match ip dscp af31
!
! Policy-map performs low latency queuing for voice payload, CBWFQ for
! Voice signaling, re-marks non-voice packets that are marked like voice,
! and queues all non-voice in class-default.
!
  policy-map AutoQoS-Policy-UnTrust
  class AutoQoS-VoIP-RTP-UnTrust
   priority percent 70
   set dscp ef
  class AutoQoS-VoIP-Control-UnTrust
   bandwidth percent 5
   set dscp af31
  class AutoQoS-VoIP-Remark
   set dscp default
  class class-default
   fair-queue

 Serial0/1 -
 !
 interface Serial0/1
  service-policy output AutoQoS-Policy-UnTrust
!
! Sends rmon events for packet drops for voice to the SNMP manager
!
 rmon event 33333 log trap AutoQoS description "AutoQoS SNMP traps for Voice Dr
ops" owner AutoQoS
 rmon alarm 33333 cbQosCMDropBitRate.1161.1163 30 absolute rising-threshold 1 3
3333 falling-threshold 0 owner AutoQoS
R3#show auto qos int s 0/1

 Serial0/1 -
 !
 interface Serial0/1
  service-policy output AutoQoS-Policy-UnTrust

Of the two commands shown, show auto qos shows all the configuration generated by AutoQoS VoIP. Had any changes been made to the configuration, they would not be shown in the output of this command—a show running-config command would be required to see those changes. The show auto qos interface serial0/1 command simply shows the policy map enabled on the interface with the service-policy command.

You have not read enough of the book to appreciate the details of the configuration, but by the end of the book, you should be able to easily understand the configuration shown in Example 3-8.

More AutoQoS Configuration Options

To remove the AutoQoS configuration, you simply use the no form of the command—in other words, no auto qos voip. However, if you happened to change the QoS configuration manually, this command will not necessarily remove all the configuration. In that case, you have to remove the configuration manually.

The auto qos voip command comes with two optional parameters, trust and fr-atm. The trust parameter tells AutoQoS VoIP to trust the incoming DSCP markings. So, the automatically configured QoS commands will not look for voice payload and voice signaling. Instead, following best practices, the commands look for packets with DSCP EF as voice payload, and DSCPs AF31 and CS3 as voice signaling. This option makes sense if you know that the packets have already been marked close to the edge of the network. By leaving off the trust option, you are essentially telling the router that you do not trust the markings, so AutoQoS VoIP generates configurations that classify based on other packet headers besides DSCP.

The fr-atm option is used with Frame Relay permanent virtual circuits (PVCs) when the PVC is using ATM service interworking. Service interworking means that one end of the VC is Frame Relay and the other end is ATM. AutoQoS VoIP configures Frame Relay Fragmentation by default, which is not supported with service interworking VCs. The fr-atm parameter makes AutoQoS VoIP use another fragmentation tool, called Multilink Point-to-Point Protocol (MLP) over Frame Relay and ATM, to perform fragmentation.

Ignoring the details of the configuration that AutoQoS VoIP generates, it is easy to choose the right parameters. If all packets have not been marked by the time they arrive at the router, do not use the trust option; if they have already been marked, use the trust option. If using Frame Relay and the VC uses service interworking, use the fr-atm option. Make sure you configure bandwidth correctly and look at the list of considerations in the QoS configuration guide.

Although making AutoQoS VoIP work is easy, it is important to understand what it is trying to do. The next section takes a closer look at what AutoQoS is actually trying to accomplish on a router.

AutoQoS VoIP for Router PHBs

The key to appreciating what AutoQoS VoIP configures is to focus on two facts:

• It is oriented toward making VoIP traffic work well.

• It follows Cisco best practices for the various QoS tools in regard to VoIP.

By reading the rest of the chapters in this book, including the material in Chapter 10, "Cisco QoS Best Practices," you will learn more about what is best to use for QoS. However, any time someone suggests the best way to do something with technology, there can always be some points of disagreement. Table 3-5 shows the PHBs that can be configured by AutoQoS VoIP on a router and some comments about its choices.

Table 3-5 PHBs Generated by AutoQoS VoIP Configuration (for Routers)

This table actually summarizes a lot of the best practices for QoS in an enterprise network. It is difficult to appreciate the details until you read the remaining chapters, so as a suggestion, go ahead and read through the rest of the chapters of the book. Chapter 10 reminds you to come back to this section of Chapter 3 and review what AutoQoS VoIP thinks of as best practices. You will have a much better appreciation for what it does for you at that point.

If you do take this suggestion, you might enjoy looking through a Frame Relay configuration as well. Example 3-9 shows how to configure AutoQoS VoIP on a Frame Relay interface, along with the resulting QoS configuration. After reading the rest of the book, working through this configuration can be an interesting exercise, both for reviewing what you learned and for solidifying your understanding of the PHBs created by AutoQoS VoIP.

Example 3-9 Low-Bandwidth (256 kbps) Frame Relay AutoQoS Configuration

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#int s 0/0.1
R3(config-subif)#bandwidth 256
R3(config-subif)#frame-relay interface-dlci 143
R3(config-fr-dlci)#auto qos voip
R3(config-fr-dlci)#^Z
R3#
R3#sh auto qos
 !
 ip access-list extended AutoQoS-VoIP-RTCP
  permit udp any any range 16384 32767
 !
 ip access-list extended AutoQoS-VoIP-Control
  ended IP access list AutoQoS-VoIP-Control
  permit tcp any any eq 1720
  permit tcp any any range 11000 11999
  permit udp any any eq 2427
  permit tcp any any eq 2428
  permit tcp any any range 2000 2002
  permit udp any any eq 1719
  permit udp any any eq 5060
 !
 class-map match-any AutoQoS-VoIP-RTP-UnTrust
  match protocol rtp audio
  match access-group name AutoQoS-VoIP-RTCP
 !
 class-map match-any AutoQoS-VoIP-Control-UnTrust
  match access-group name AutoQoS-VoIP-Control
 !
 class-map match-any AutoQoS-VoIP-Remark
  match ip dscp ef
  match ip dscp cs3
  match ip dscp af31
 !
  policy-map AutoQoS-Policy-UnTrust
  class AutoQoS-VoIP-RTP-UnTrust
   priority percent 70
   set dscp ef
  class AutoQoS-VoIP-Control-UnTrust
   bandwidth percent 5
   set dscp af31
  class AutoQoS-VoIP-Remark
   set dscp default
  class class-default
   fair-queue

! Serial0/0.1: DLCI 143 -
 !
 interface Serial0/0
  frame-relay traffic-shaping
 !
 interface Serial0/0.1 point-to-point
  frame-relay interface-dlci 143
  class AutoQoS-VoIP-FR-Serial0/0-143
  frame-relay ip rtp header-compression
 !
 map-class frame-relay AutoQoS-VoIP-FR-Serial0/0-143
  frame-relay cir 256000
  frame-relay bc 2560
  frame-relay be 0
  frame-relay mincir 256000
  service-policy output AutoQoS-Policy-UnTrust
  frame-relay fragment 320
 !
 rmon event 33333 log trap AutoQoS description "AutoQoS SNMP traps for Voice Dr
ops" owner AutoQoS
 rmon alarm 33338 cbQosCMDropBitRate.1619.1621 30 absolute rising-threshold 1 3
3333 falling-threshold 0 owner AutoQoS

AutoQoS VoIP for Cisco IOS Switches

Cisco supports AutoQoS VoIP on 2950 (Enhanced Image), 3550, 4500, and 6500 Series switches. It is similar to AutoQoS VoIP for routers in philosophy but different in the details. For instance, for both switches and routers, AutoQoS VoIP does the following:

• Automatically configures QoS settings based on simple configuration commands

• Classifies based on voice payload, voice signaling, and other traffic

• Follows Cisco Best Practices for QoS

AutoQoS VoIP for Cisco IOS switches differs from routers in terms of both what PHBs are configured and the configuration commands created by AutoQoS. Even though IOS-based Cisco switches support MQC-style commands, many of the core QoS features are not configured with MQC commands. Also, different QoS tools are used on the switches (as compared to routers) but the ultimate goal is still the same—to ensure VoIP traffic works well, with minimal configuration.

As with AutoQoS VoIP for routers, this section begins with some discussion of the configuration and then moves on to discuss the PHBs created by the automatically configured QOS commands.

AutoQoS VoIP Configuration for IOS Switches

IOS switches use the same basic interface subcommand as routers, but with a couple of different options. The full syntax is as follows:

auto qos voip {cisco-phone | trust}

Note that you must choose either cisco-phone or trust. To appreciate which one to use, consider a typical campus switch design, as shown in Figure 3-4.

Figure 3-4 Typical Campus Switch Design

Figure 3-4 shows that for switch ports connected to end-user devices, the cisco-phone option is suggested. Alternatively, for trunks between two switches, the trust option is suggested. But why? Figure 3-5 shows the explanation against the same diagram, with the explanation following.

Figure 3-5 Two Settings, Three Actions, for Classification and Marking

The cisco-phone parameter tells the switch to use CDP version 2 to recognize whether a phone is currently attached to the port. If a Cisco IP Phone is there, the switch can trust the QoS markings from the phone. If a phone is not there, the switch simply does not trust the QoS markings on the frames entering that interface and treats all traffic as BE traffic.

In effect, the cisco-phone option tells the switch to extend the trust boundary down to the Cisco IP Phone.

As a result of the actions at SW3 and SW4, SW1 and SW2 can simply trust the CoS values of the incoming frames. For frames that come in from an untrusted device or port, as with Client1 and SW3, SW3 forwards the frame to SW1 with a CoS of 0, because SW3 did not trust the device off that port. However, SW4 trusted the IP Phone to mark the CoS value correctly, so frames forwarded by SW4 to SW2 have CoS 5 (voice payload), CoS 3 (voice signaling), or CoS 0 (traffic from PC Client2).

To summarize, configure the cisco-phone setting on ports connected to end users, and the trust setting when connecting to other switches, assuming the CoS values will be marked correctly.

Example 3-10 shows a configuration for SW3, with both cisco-phone and trust configured.

Example 3-10 2950 (EI) Configuration for AutoQoS VoIP

SW3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW3(config)#int fa 0/3
SW3(config-if)#auto qos voip cisco-phone
SW3(config-if)#int fa 0/4
SW3(config-if)#auto qos voip trust
SW3(config-if)#^Z
SW3#show auto qos
Initial configuration applied by AutoQoS:
wrr-queue bandwidth 20 1 80 0
no wrr-queue cos-map
wrr-queue cos-map 1 0 1 2 4
wrr-queue cos-map 3 3 6 7
wrr-queue cos-map 4 5
mls qos map cos-dscp 0 8 16 26 32 46 48 56
!
interface FastEthernet0/3
 mls qos trust device cisco-phone
 mls qos trust cos
!
interface FastEthernet0/4
 mls qos trust cos
SW3#

The configuration itself is easy. On ports known to be end-user ports, such as FastEthernet0/3, the auto qos voip cisco-phone interface subcommand is used. On trunk ports, assuming the frames will be marked with correct CoS values, the auto qos voip trust interface subcommand is used.

The resulting configuration shown in the show auto qos voip command is difficult to understand until you have learned more about QoS configuration on a 2950 switch. You might want to return to this section of Chapter 3 after reading Chapter 9, "LAN QoS," after which the output of the show auto qos voip command should be more meaningful.

AutoQoS VoIP for IOS Switch PHBs

It is important to understand what the AutoQoS VoIP configured, at least in terms of the meaning behind the commands. As with routers, two key points help in understanding the PHBs created on the switches:

• It is oriented toward making VoIP traffic work well.

• It follows Cisco Best Practices for the various QoS tools in regard to VoIP.

The list of PHBs created by AutoQoS VoIP on a 2950 switch differs from routers and is summarized in Table 3-6.

Table 3-6 PHBs Generated by AutoQoS VoIP Configuration (for 2950 EI Switches)

Chapter 9 provides details of the underlying QoS commands created by AutoQoS.

Next, this chapter ends with a short description of AutoQoS for Cat-OS on the 6500 Series switches.

AutoQoS VoIP for 6500 Cat-OS

The Cisco 6500 series switches support Cat-OS when running the Catalyst Operating System (Cat-OS). Like AutoQoS on routers and IOS-based switches, AutoQoS uses simple commands to initiate the automatic configuration of QoS commands, with settings that help ensure good performance of VoIP traffic.

The Cisco QoS course and exam tend to focus on switch examples using IOS-based switches and mostly ignores commands on Cat-OS. The one exception to that rule in the Cisco QoS course is the coverage of the AutoQoS commands in Cat-OS. So, for the purposes of this book, this short section explains the commands and their meaning.

Table 3-7 lists the Cat-OS commands related to AutoQoS VoIP.

Table 3-7 Command Reference for AutoQoS VoIP (for 6500 Cat-OS)

To configure AutoQoS on a 6500 switch, you first need to use the set qos autoqos command. Afterward, you need to use a set port qos autoqos command covering each port, choosing either trust cos, trust dscp, voip ciscoipphone, or voip ciscosoftphone as options. To appreciate each of the four options, consider Figure 3-6, which demonstrates the implementation of all four options.

Figure 3-6 AutoQoS Options on 6500 Cat-OS

Some of the options for the 6500 switch are the same as for IOS-based switches such as the 2950. For instance, if frames have already been marked with the correct CoS value on a trunk, as is the case on port 2/1 in Figure 3-6, the command set port qos autoqos 2/1 trust cos tells the switch to trust CoS on that port. That is the same action as with the switch IOS command auto qos voip trust.

Another option that works like AutoQoS on an IOS switch is the ciscoipphone option. If a port might have an IP Phone, or it might not, such as on ports 1/2 and 1/3 in Figure 3-6, the command set port qos autoqos 1/2 voip ciscoipphone is the correct setting. As with the switch IOS command auto qos voip cisco-phone, this set command tells the switch to use CDP V2 to discover if a Cisco IP Phone is on the port. If a Cisco IP Phone is on the port, trust CoS and extend the trust boundary down to the Cisco IP Phone, marking CoS 0 for all traffic sent by the PC attached to the phone. If no Cisco IP Phone is on the port, treat all traffic as CoS 0.

Of the other two options, using the command set port qos autoqos 2/2 trust dscp is the most obvious. If the DSCP has already been set correctly, you should use this command to tell the switch to trust the incoming DSCP setting.

Finally, the command set port qos autoqos 1/1 voip ciscosoftphone is recommended on port 1/2 in Figure 3-6. The PC attached to that port is running the Cisco SoftPhone application, which in effect creates an IP Phone via software running on the PC. However, the Cisco SoftPhone marks DSCP correctly (EF for payload, AF31 for signaling), but it does not mark CoS—in fact, trunking is not even needed on this port. You could just trust DSCP on this port, but the danger is that the PC could set DSCP EF or AF31 for other IP packets, hoping to get good performance from the network. To prevent such abuse, the set port qos autoqos 1/1 voip ciscosoftphone command also enables policing at a rate of 320 kbps for DSCP EF traffic and 32 kbps for DSCP AF31 traffic. Cisco SoftPhone can use up to 256 kbps for a single call, although it typically uses less. So, rather than just trusting DSCP, the ciscoipphone option lets you trust DSCP, but it reduces the impact if the end user is marking other packets as DSCP EF or AF31.

Table 3-8 lists the four competing options for AutoQoS settings on each port.

Table 3-8 Comparing Options for set port Command with AutoQoS