This chapter is from the book
This chapter is from the book
This chapter is from the book
Basic QoS Configuration
Cisco continues to improve the ease and efficiency with which QoS mechanisms can be configured. This section addresses two of the Cisco more recent developments: MQC and AutoQoS.
Using MQC
One of the most powerful approaches to QoS configuration is the Modular Quality of Service Command-Line Interface (MQC). After you master the three basic steps of MQC, you can use them to configure a wide range of QoS tools, including queuing, policing, shaping, header compression, WRED, and marking.
)
Figure
6The first step of MQC is to create class-maps, which categorize traffic types. The following command enters you into class-map configuration mode:
Router(config)#class-map [match-any | match-all] class-name
After you are in class-map configuration mode, you can specify multiple match statements to match traffic, and all traffic that meets the criteria that you specified with the match commands is categorized under the class-map. If multiple match statements are specified, by default, all match statements must be met before a packet is classified by the class-map. However, if you use the match-any option, if any individual match condition is met, the packet is classified by the class-map. After the class-maps are defined, the first step of MQC is complete. The second step is to create a policy-map, which assigns characteristics (for example, marking) to the classified traffic.
To enter policy-map configuration mode, issue the following command:
Router(config)#policy-map policy-name
From policy-map configuration mode, enter policy-map-class configuration mode with the following command:
Router(config-pmap)#class class-name
From policy-map-class configuration mode, you can assign QoS policies to traffic that is classified by the class-map. You can also have a situation in which a packet matches more than one class-map. In that case, the first class-map that is identified in the policy-map is used. Up to 256 class-maps can be associated with a single policy-map.
Finally, in the third step of MQC, the policy-map is applied to an interface, Frame Relay map-class, or Asynchronous Transfer Mode (ATM) virtual circuit with the following command:
Router(config-if)#service-policy {input | output} policy-map-name
Following is an MQC example in which you are classifying various types of e-mail traffic (for example, SMTP, IMAP, and POP3) into one class-map. The KaZaa protocol, which is used frequently for music downloads, is placed in another class-map. Voice over IP (VoIP) traffic is placed in yet another class-map. Then, the policy-map assigns bandwidth allocations or limitations to these traffic types. The MQC example is as follows:
Router(config)#class-map match-any EMAIL Router(config-cmap)#match protocol pop3 Router(config-cmap)#match protocol imap Router(config-cmap)#match protocol smtp Router(config-cmap)#exit Router(config)#class-map MUSIC Router(config-cmap)#match protocol kazaa2 Router(config-cmap)#exit Router(config)#class-map VOICE Router(config-cmap)#match protocol rtp Router(config-cmap)#exit Router(config)#policy-map QOS-STUDY Router(config-pmap)#class EMAIL Router(config-pmap-c)#bandwidth 128 Router(config-pmap-c)#exit Router(config-pmap)#class MUSIC Router(config-pmap-c)#police 32000 Router(config-pmap-c)#exit Router(config-pmap)#class-map VOICE Router(config-pmap-c)#priority 256 Router(config-pmap-c)#exit Router(config-pmap)#exit Router(config)#interface serial 0/1 Router(config-if)#service-policy output QOS-STUDY
Notice that the QOS-STUDY policy-map makes 128 kbps of bandwidth available to e-mail traffic. However, KaZaa version 2 traffic bandwidth is limited to 32 kbps. Voice packets not only have access to 256 kbps of bandwidth, but they also receive “priority” treatment, meaning that they are sent first (that is, ahead of other traffic) up to the 256-kbps limit.
The next logical question is, “What happens to all of the traffic that you did not classify?” Interestingly, the IOS created the class-default class-map, which categorizes any traffic that is not matched by one of the defined class-maps. Finally, in the previous example, the policy-map is applied in the outbound direction on the Serial 0/1 interface.
The following show commands can be used for verification and troubleshooting of an MQC configuration:
Router#show class-map [class-map-name]
(Used to view what a class-map is matching)
Router#show policy-map [policy-map-name]
(Used to view the policy that is applied to the classes within a policy-map)
Router#show policy-map interface interface-identifier [input | output]
(Used to view policy-map statistics for packets that are crossing a specific interface)
Using AutoQoS
Optimizing a QoS configuration for VoIP can be a daunting task. Fortunately, Cisco added a feature called AutoQoS to many of its router and switch platforms to automatically generate router-based or switch-based VoIP QoS configurations.
The following router platforms support AutoQoS:
1700 Series
2600 Series
3600 Series
3700 Series
7200 Series
Cisco also supports the AutoQoS feature on the following Catalyst switch series:
2950 (EI)
3550
4500
6500
On a router platform, the following command enables AutoQoS from either interface-configuration mode or from DLCI-configuration mode (for a Frame Relay circuit):
Router(config-if)#auto qos voip [trust] [fr-atm]
The trust option indicates that Auto QoS should classify voice traffic based on DSCP markings, instead of using NBAR. The fr-atm option enables the AutoQoS feature for Frame Relay–to–ATM links and is issued from DLCI-configuration mode.
Before enabling AutoQoS on a router interface, consider the following prerequisites:
Cisco Express Forwarding (CEF) must be enabled, because AutoQoS uses NBAR, which requires the CEF feature.
A QoS policy must not be attached to the interface.
The correct bandwidth should be configured on the interface.
An IP address must be configured on an interface if its speed is less than 768 kbps.
The interface must not be administratively shut down.
Note that the interface’s bandwidth determines which AutoQoS features are enabled. If an interface’s bandwidth is less than 768 kbps, it is considered a low-speed interface. On a low-speed interface, AutoQoS configures Multilink PPP (MLP), which requires an IP address on the physical interface. AutoQoS takes that IP address from the physical interface and uses it for the virtual multilink interface that it creates.
To verify that AutoQoS is configured for a router interface, use the following command:
Router#show auto qos [interface interface-identifier]
)
Figure
7The Catalyst 6500 running in Hybrid mode (that is, using the Cat OS for switch functions) also supports AutoQoS. To enable AutoQoS on a Hybrid mode Catalyst 6500, you must first enable AutoQoS globally and then for a specific port. Following are the required commands:
Switch#set qos autoqos
(Globally enables AutoQoS)
Switch#set qos autoqos <mod/port> trust [cos | dscp]
(Enables AutoQoS for a specific port)
Note that the Catalyst 6500 can trust either CoS or DSCP values for its queuing decision. If the port is trusting DSCP markings, you can add the following command, which recognizes that the port is connected to a Cisco IP Phone or a Cisco SoftPhone (software that runs on a PC):
Switch#set port qos <mod/port> autoqos voip [ciscosoftphone | ciscoipphone]
The port must have Cisco Discovery Protocol (CDP) version 2 enabled to recognize an attached Cisco IP Phone. Although some switches do not recognize a Cisco SoftPhone, AutoQoS can be configured on Catalyst 2950 (EI) and 3550 switches, and the AutoQoS feature on these switches does recognize a Cisco IP Phone. To configure AutoQoS on these platforms, issue the following commands from interface-configuration mode:
Switch(config-if)#auto qos voip trust
(Configures the interface to trust CoS markings for classifying VoIP traffic)
Switch(config-if)#auto qos voip cisco-phone
(Detects the presence of a Cisco IP Phone, using CDP)
To troubleshoot and verify AutoQoS on a Catalyst switch, use the following commands:
Switch#show auto qos [interface interface-identifier]
(Displays the configuration that is applied by AutoQoS)
Switch#show mls qos interface [interface-identifier]
(Displays interface-level QoS statistics)
This section has broadly addressed the features that are enabled by AutoQoS. The specific features are shown in the following table.
|
QoS Mechanism |
Router Feature |
Switch Feature |
|
Classification |
NBAR and DSCP |
Port trust states |
|
Marking |
CB-Marking |
CoS-to-DSCP remarking |
|
Congestion management |
LLQ |
WRR |
|
Shaping |
CB-Shaping or FRTS |
— |
|
Link efficiency |
Header Compression and LFI |
— |