Ccvp.qos Quick Reference

Cisco Voice Quick Ref
View more...
   EMBED

Share

  • Rating

  • Date

    December 1969
  • Size

    674.3KB
  • Views

    607
  • Categories

Preview only show first 6 pages with water mark for full document please download

Transcript

QOS Quick Reference Sheets Why You Need Quality of Service (QoS) The networks of yesteryear physically separated voice, video, and data traffic. Literally, these traffic types flowed over separate media (for example, leased lines or fiber-optic cable plants). Today, however, network designers are leveraging the power of the data network to transmit voice and video, thus achieving significant cost savings by reducing equipment, maintenance, and even staffing costs. The challenge, however, with today’s converged networks is that multiple applications are contending for bandwidth, and some applications such as, voice can be more intolerant of delay (that is, latency) than other applications such as, an FTP file transfer. A lack of bandwidth is the overshadowing issue for most quality problems. When a lack of bandwidth exists, packets can suffer from one or more of the following symptoms: • Delay—Delay is the time that is required for a packet to travel from its source to its destination. You might witness delay on the evening news, when the news anchor is talking through satellite to a foreign news correspondent. Because of the satellite delay, the conversation begins to feel unnatural. • Jitter—Jitter is the uneven arrival of packets. For example, consider that in a Voice over IP (VoIP) conversation, packet 1 arrives. Then, 20 ms later, packet 2 arrives. After another 70 ms, packet 3 arrives, and then packet 4 arrives 20 ms behind packet 3. This variation in arrival times (that is, variable delay) is not dropping packets, but this jitter can be interpreted by the listener as dropped packets. • Drops—Packet drops occur when a link is congested and a buffer overflows. Some types of traffic, such as User Datagram Protocol (UDP) traffic (for example, voice), are not retransmitted if packets are dropped. Fortunately, quality of service (QoS) features that are available on Cisco routers and switches can recognize your “important” traffic and then treat that traffic in a special way. For example, you might want to allocate 128 kbps of bandwidth for your VoIP traffic and also give that traffic priority treatment. Why You Need Quality of Service (QoS) 129 Consider water that is flowing through a series of pipes with varying diameters. The water’s flow rate through those pipes is limited to the water’s flow rate through the pipe with the smallest diameter. Similarly, as a packet travels from its source to its destination, its effective bandwidth is the bandwidth of the slowest link along that path. Effective Bandwidth 1.544 Mbps 256 Kbps 1.544 Mbps 512 Kbps 10 Mbps 100 Mbps The weakest link between the two stations is the effective bandwidth between those stations. Because your primary challenge is a lack of bandwidth, the logical question is, “How do you increase available bandwidth?” A knee-jerk response to that question is often, “Add more bandwidth.” Although adding more bandwidth is the best solution, it comes at a relatively high cost. Compare your network to a highway system in a large city. During rush hour, the lanes of the highway are congested, but the lanes can be underutilized during other periods of the day. Instead of just building more lanes to accommodate peak traffic rates, the highway engineers add carpool lanes. Cars with two or more riders can use the reserved carpool lane. These cars have a higher priority on the highway. Similarly, you can use QoS features to give your mission-critical applications higher-priority treatment in times of network congestion. Some of the QoS features that can address issues of delay, jitter, and packet loss include the following: • Queuing—Queuing can send higher-priority traffic ahead of lower-priority traffic and make specific amounts of bandwidth available for those traffic types. Examples of queuing strategies that you consider later in these Quick Reference Sheets include the following: — Priority Queuing (PQ) — Custom Queuing (CQ) — Modified Deficit Round Robin (MDRR) queuing — Weighted Fair Queuing (WFQ) — Class-Based WFQ (CB-WFQ) — Low Latency Queuing (LLQ) • Compression—By compressing a packet’s header or payload, fewer bits are sent across the link. This effectively gives you more bandwidth. 130 QOS Quick Reference Sheets QoS Basics The mission statement of QoS could read something like “to categorize traffic and apply a policy to those traffic categories, in accordance with a QoS policy.” Specifically, QoS configuration involves the following three basic steps: Step 1 Determine network performance requirements for various traffic types. For example, consider the following design rules of thumb for voice, video, and data traffic: Voice: • • • No more than 150 ms of one-way delay No more than 30 ms of jitter No more than 1 percent packet loss Video: • • • No more than 150 ms of one-way delay for interactive voice applications (for example, video conferencing) No more than 30 ms of jitter No more than 1 percent packet loss Data: Applications have varying delay and loss characteristics. Therefore, data applications should be categorized into predefined “classes” of traffic, where each class is configured with specific delay and loss characteristics. Step 2 Categorize traffic into specific categories. For example, you can have a category named “Low Delay,” and you decide to place voice and video packets in that category. You can also have a “Low Priority” class, where you place traffic such as music downloads from the Internet. As a rule of thumb, Cisco recommends that you create no more that ten classes of traffic. Document your QoS policy, and make it available to your users. Then, for example, if a user complains that his network gaming applications are running slowly, you can point him to your corporate QoS policy, which describes how applications such as network gaming have “best-effort” treatment. Step 3 QoS Deployment Cisco offers the following four basic approaches for QoS deployment in your network: • Command-Line Interface (CLI)—The CLI is the standard IOS (or Cat OS) interface that configures routers or switches. CLI QoS features such as Priority Queuing (PQ) or Custom Queuing (CQ), which are configured through the CLI, have been available for many years. • Modular QoS CLI (MQC)—Instead of using the CLI to configure QoS parameters for one interface at a time, the three-step MQC process allows you to (1) place packets into different classes, (2) assign a policy for those classes, and (3) apply the policy to an interface. Because the approach is modular, you can apply a single policy to multiple interfaces. • AutoQoS—AutoQoS is a script that is executed on routers or switches that automates the process of QoS configuration. Specifically, this automatic configuration helps optimize QoS performance for VoIP traffic. • QoS Policy Manager (QPM)—QPM, in conjunction with CiscoWorks, centralizes QoS configuration. Policies that are created with QPM can be pushed out to routers throughout an enterprise, thus reducing the potential for misconfiguration. QoS Components 131 QoS Components Cisco offers a wealth of QoS resources on its switch and router platforms. These resources are classified into one of three categories, which are discussed in this section. The category of QoS resources used most often in production, however, is the Differentiated Services category, which offers greater scalability and flexibility than the resources found in the Best-Effort or Integrated Services categories. QoS Categories All of the Cisco QoS features are categorized into one of the following three categories: • Best-Effort—Best-Effort does not truly provide QoS, because there is no reordering of packets. Best-Effort uses the first-in first-out (FIFO) queuing strategy, where packets are emptied from a queue in the same order in which they entered it. • Integrated Services (IntServ)—IntServ is often referred to as “Hard QoS,” because it can make strict bandwidth reservations. IntServ uses signaling among network devices to provide bandwidth reservations. Resource Reservation Protocol (RSVP) is an example of an IntServ approach to QoS. Because IntServ must be configured on every router along a packet’s path, the main drawback of IntServ is its lack of scalability. • Differentiated Services (DiffServ)—DiffServ, as the name suggests, differentiates between multiple traffic flows. Specifically, packets are “marked,” and routers and switches can then make decisions (for example, dropping or forwarding decisions) based on those markings. Because DiffServ does not make an explicit reservation, it is often called “Soft QoS.” The focus of these Quick Reference Sheets is DiffServ, as opposed to IntServ or Best-Effort. QoS Categories BestEffort t No ict r St DiffServ ss Le rict St ric St t IntServ • Best-Effort does not perform reordering of packets. • DiffServ differentiates between flows and assigns policies to those flows. • IntServ makes a strict bandwidth reservation for an application. DiffServ Now that you understand the importance that marking plays in a DiffServ QoS solution, you can learn how packets can be marked. Inside an IPv4 header is a byte called the type of service (ToS) 132 QOS Quick Reference Sheets byte. You can mark packets, using bits within the ToS byte, with either IP Precedence or Differentiated Service Code Point (DSCP) markings. Type of Service (ToS) Byte IPv4 Packet ToS Byte Inside an IPv4 header is a Type of Service (ToS) byte. The three left bits in that byte can be used to mark the packet with an IP Precedence value (0–7). Alternatively, the six left bits in the ToS byte can be used to mark the packet with a DSCP value (0–63). 1 2 3 4 5 6 7 8 IP Precedence DSCP IP Precedence uses the 3 leftmost bits in the ToS byte. With 3 bits at its disposal, IP Precedence markings can range from 0 to 7. However, values 6 and 7 should not be used, because those values are reserved for network use. For more granularity, you can choose DSCP, which uses the 6 leftmost bits in the ToS byte. Six bits yield 64 possible values (0 to 63). The challenge with so many values at your disposal is that the value you choose to represent a certain level of priority can be treated differently by a router or switch under someone else’s administration. To maintain relative levels of priority among devices, the Internet Engineering Task Force (IETF) selected a subset of those 64 values for use. These values are called per-hop behaviors (PHBs), because they indicate how packets should be treated by each router hop along the path from the source to the destination. The four categories of PHBs are as follows: • Default—Traffic that only needs best-effort treatment can be marked with the Default PHB, which simply means that the 6 leftmost bits in the packet’s ToS byte (that is, the DSCP bits) are all 0 (that is, a DSCP value of 0). • Expedited Forwarding (EF)—The EF PHB has a DSCP value of 46. Latency-sensitive traffic, such as voice, typically has a PHB of EF. • Assured Forwarding (AF)—The broadest category of PHBs is the AF PHB. Specifically, 12 AF PHBs exist, as shown in the following table. Medium Drop Preference AF12 (12) 001100 AF22 (20) 010100 AF32 (28) 011100 AF42 (36) 100100 PHB Class 1 Class 2 Class 3 Class 4 Low Drop Preference AF11 (10) 001010 AF21 (18) 010010 AF31 (26) 011010 AF41 (34) 100010 High Drop Preference AF13 (14) 001110 AF23 (22) 010110 AF33 (30) 011110 AF43 (38) 100110 QoS Components 133 Notice that the Assured Forwarding PHBs are grouped into four classes. Examining these DSCP values in binary reveals that the 3 leftmost bits of all the Class 1 AF PHBs are 001 (that is, a decimal value of 1); the 3 leftmost bits of all the Class 2 AF PHBs are 010 (that is, a decimal value of 2); the 3 leftmost bits of all the Class 3 AF PHBs are 011 (that is, a decimal value of 3); and the 3 leftmost bits of all the Class 4 AF PHBs are 100 (that is, a decimal value of 4). Because IP Precedence examines these 3 leftmost bits, all Class 1 DSCP values would be interpreted by an IP Precedence–aware router as an IP Precedence value of 1. The same applies to the Class 2, 3, and 4 PHB values. Within each AF PHB class are three distinct values, which indicate a packet’s “drop preference.” Higher values in an AF PHB class are more likely to be discarded during periods of congestion. For example, an AF13 packet is more likely to be discarded than an AF11 packet. • Class Selector (CS)—To have backward compatibility with IP Precedence, you can use CS PHBs, because, just like IP Precedence, CS PHBs have 0s in the 4th, 5th, and 6th bits of the ToS byte. As an example, consider that your router uses DSCP markings, but you are sending packets to a router that only understands IP Precedence markings. That would be a great opportunity to use CS markings. You could send a packet marked with a DSCP value of 40, which is 101000 in binary. When that packet is received by the IP Precedence–aware router, its IP Precedence value is interpreted as 5, because only the 3 leftmost bits are considered, and because 101 in binary equals 5 in decimal. QoS Tools Now that you understand how markings can be performed with the DiffServ QoS model, realize that marking alone does not alter the behavior of packets. You must have a QoS tool that references those marking and alters the packets’ treatment based on those markings. Following are some of the QoS tools that are addressed later in these Quick Reference Sheets: • Classification—Classification is the process of placing traffic into different categories. Multiple characteristics can be used for classification. For example, POP3, IMAP, SMTP, and Exchange traffic could all be placed in an “EMAIL” class. Classification does not, however, alter bits in the frame or packet. • Marking—Marking alters bits (for example, bits in the ToS byte) within a frame, cell, or packet to indicate how the network should treat that traffic. Marking alone does not change how the network treats a packet. Other tools (for example, queuing tools) can, however, reference those markings and make decisions based on them. • Congestion management—When you hear the term congestion management, think queuing. These concepts are the same. When an interface’s output software queue contains packets, the interface’s queuing strategy determines how the packets are emptied from the queue. For example, some traffic types can be given priority treatment, and bandwidth amounts can be made available for specific classes of traffic. • Congestion avoidance—If an interface’s output queue fills to capacity, newly arriving packets are discarded (that is, “tail-dropped”), regardless of the priority that is assigned to the discarded packet. To prevent this behavior, Cisco uses a congestion avoidance technique called Weighted Random Early Detection (WRED). After the queue depth reaches a configurable level (that is, the minimum threshold) for a particular priority marking (for example, IP Precedence or DSCP), WRED introduces the possibility of discard for packets with those markings. As the queue depth continues to increase, the possibility of discard increases until a configurable maximum threshold is reached. After the queue depth has exceeded the maximum threshold for traffic with a specific priority, there is a 100 percent chance of discard for those traffic types. 134 QOS Quick Reference Sheets Queuing Priority Queue 1 Business Queue 2 3 1 2 4 Application Queue 3 Best-Effort Queue 4 4 4 4 3 3 2 4 1 3 2 1 Software Queue Queuing mechanisms determine in what order and in what quantity specific packets are emptied from a queue. • Policing and shaping—Sometimes, instead of making a minimum amount of bandwidth available for specific traffic types, you might want to limit the available bandwidth. Both policing and shaping tools can accomplish this objective. Collectively, these tools are called traffic conditioners. Policing can be used in either the inbound or outbound direction, and it typically discards packets that exceed the configured rate limit, which you can think of as a “speed limit” for particular traffic types. Because policing drops packets, resulting in retransmissions, it is recommended for use on higher-speed interfaces. Policing mechanisms also allow you to rewrite packet markings (for example, IP Precedence markings). Shaping can be applied only in the outbound direction. Instead of discarding traffic that exceeds the configured rate limit, shaping delays the exceeding traffic by buffering it until bandwidth becomes available. That is why shaping preserves bandwidth, as compared to policing, at the expense of increased delay. Therefore, shaping is recommended for use on slower-speed interfaces. Also, shaping does not have policing’s ability to rewrite packet markings. • Link efficiency—To make the most of the limited bandwidth that is available on slower-speed links, you can choose to implement compression or Link Fragmentation and Interleaving (LFI). Using header compression on smaller packets can dramatically increase a link’s available bandwidth. LFI addresses the issue of “serialization delay,” which is the amount of time required for a packet to exit an interface. A large data packet, for example, on a slower-speed link could create excessive delay for a voice packet because of the time required for the data packet to exit the interface. LFI fragments the large packets and interleaves the smaller packets among the fragments, reducing the serialization delay that the smaller packets experience. Basic QoS Configuration 135 Link Efficiency Mechanisms Compressed Header IP UDP RTP Headers 40 Bytes 2 - 4 Bytes Header Compression Voice Payload cRTP Voice Payload V V V V D V D V D V D V D Link Fragmentation and Interleaving (LFI) 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. Modular QoS CLI (MQC) Step #1: Classify Traffic Step #2: Assign Policies to the Traffic Classes Step #3: Apply the Policy to an Interface CLASS-MAP POLICY-MAP SERVICE-POLICY The 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 136 QOS Quick Reference Sheets match-any option, if any individual match condition is met, the packet is classified by the classmap. 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 mapclass, 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 Basic QoS Configuration 137 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 routerbased 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. 138 QOS Quick Reference Sheets To verify that AutoQoS is configured for a router interface, use the following command: Router#show auto qos [interface interface-identifier] Auto QoS s0/0 IP WAN interface serial 0/0 auto qos voip The 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 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 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. Traffic Classification and Marking 139 QoS Mechanism Classification Marking Congestion management Shaping Link efficiency Router Feature NBAR and DSCP CB-Marking LLQ CB-Shaping or FRTS Header Compression and LFI Switch Feature Port trust states CoS-to-DSCP remarking WRR — — Traffic Classification and Marking Classification and marking allow QoS-enabled networks to identify traffic types near the source and assign specific markings to those traffic types. This section addresses the need for and various approaches used to perform classification and marking. Classification and Marking Basics One of the first QoS mechanisms that you apply to your traffic is classification, which recognizes the types of traffic that are flowing across the network. For example, you might recognize Telnet, FTP, and HTTP traffic and categorize those applications together in a specific class of traffic. Although classification is great, you probably do not want to configure classification on every router. Therefore, after the traffic is classified, you can “mark” it. At that point, other routers and switches in the network can reference those markings and make decisions (for example, forwarding or dropping decisions) based on those markings. Some of these markings are Layer 2 (that is, the Data Link Layer) markings, whereas other markings are at Layer 3 (that is, the Network Layer). First, consider the Layer 2 markings. On an Ethernet trunk, you can mark frames with a class of service (CoS) value. A CoS value can range from 0 through 7, although Cisco recommends that you never use 6 or 7. The bits that create the CoS marking depend on the type of trunk that is being used, as follows: • IEEE 802.1Q trunk—Uses 3 bits in a Tag Control byte to mark a CoS value. (Note: This method is referred to as IEEE 802.1p.) • ISL trunk—Uses 3 bits in the ISL header to mark a CoS value. CoS Marking IEEE 802.1Q Frame Tag Control Information Bytes PRI CFI VLAN ID CoS Bits ISL Frame ISL Header Encapsulated Frame FCS VLAN CoS Bits 140 QOS Quick Reference Sheets Layer 2 markings also can extend to the WAN. Consider a Frame Relay network. Within a Frame Relay header is a bit called the Discard Eligible (DE) bit, which identifies frames that the service provider can drop during periods of congestion. You can leverage that DE bit to identify less important traffic that you send to the Frame Relay service provider. Similarly, you can mark the Cell Loss Priority (CLP) bit in an ATM cell to identify less important ATM traffic. Service providers often use Multiprotocol Label Switching (MPLS) to forward traffic. Three bits in the MPLS label can be used to identify priority for traffic that is flowing through the service provider’s cloud. As mentioned earlier, Layer 3 markings are made possible by using bits within an IPv4 header’s ToS byte. These markings are IP Precedence (which uses the 3 leftmost bits in the ToS byte) and DSCP (which uses the 6 leftmost bits in the ToS byte). A major design issue to keep in mind is that a CoS marking from a trunk does not survive a route processor hop. So, if you are only using CoS markings to identify the priority of your traffic, those CoS markings should be “remarked” to a Layer 3 marking before the traffic passes through a route processor. CoS Remarking ISL Trunk ISL Trunk CoS = 5 File Server CoS = 0 PC Although Cisco recommends marking traffic as close to the source as possible, you typically do not want users setting their own priority markings. Therefore, you can use Catalyst switches to create a trust boundary, which is a point in the network that does not trust incoming markings. An exception to having a wiring closet switch acting as a trust boundary would be a Cisco IP Phone that is connected to the switch. Because the Cisco IP Phone performs priority marking, you can extend the trust boundary to the phone. Modular Classification with MQC Recall the previous discussion about the Cisco three-step MQC process for configuring QoS mechanisms. You can leverage this MQC approach to do classification and marking. First, consider classification using MQC. In class-map configuration mode, you can use the match command to categorize traffic based on any of the following criteria: • Access control lists (ACLs) • Existing markings (for example, CoS, IP Precedence, or DSCP) • QoS group (a locally significant grouping of packets) • Protocol (using NBAR) • Traffic matching another class-map • Incoming interface • MAC address (source or destination) • Range of UDP port numbers In the following example, you are matching traffic based on a variety of the preceding criteria: Router(config)#class-map match-any INT Router(config-cmap)#match input-interface ethernet 0/0 Router(config-cmap)#match input-interface ethernet 0/1 Traffic Classification and Marking 141 Router(config-cmap)#exit Router(config)#class-map ACL Router(config-cmap)#match access-group 101 Router(config-cmap)#exit Router(config)#class-map COS Router(config-cmap)#match cos 0 1 2 3 Router(config-cmap)#exit Router(config)#access-list 101 permit tcp any any eq 23 In this example, the INT class-map matches traffic that came into the router on any of the specified interfaces. The ACL class-map matches traffic that is matched by access-list 101. Finally, the COS class-map categorizes traffic with a CoS marking of 0, 1, 2, or 3. Modular Marking with MQC After you have classified your traffic using class-maps, you can use a policy-map to mark the traffic. Following is a listing of supported markings and the corresponding syntax: • IP Precedence (set ip precedence value) • DSCP (set ip dscp value) • QoS group(set ip precedence value) • MPLS experimental bits (set mpls experimental value) • CoS value (set cos value) • Frame Relay DE bit (set fr-de) • ATM CLP bit (set atm-clp) In the following example, you use MQC to remark CoS values that are entering a router to DSCP values: CoS to DSCP Remarking ISL Trunk Fa 0/1 CoS = 5 File Server CoS = 2 CoS = 1 Fa 2/1 DSCP AF31 DSCP AF21 DSCP AF11 Router(config)#class-map HI-PRI Router(config-cmap)#match cos 5 6 7 Router(config-cmap)#exit Router(config)#class-map MED-PRI Router(config-cmap)#match cos 2 3 4 Router(config-cmap)#exit Router(config)#class-map LOW-PRI Router(config-cmap)#match cos 0 1 Router(config-cmap)#exit Router(config)#policy-map REMARK Router(config-pmap)#class HI-PRI Router(config-pmap-c)#set ip dscp af31 Router(config-pmap-c)#exit Router(config-pmap)#class MED-PRI Router(config-pmap-c)#set ip dscp af21 Router(config-pmap-c)#exit Router(config-pmap)#class-map LOW-PRI Router(config-pmap-c)#set ip dscp af11 Router(config-pmap-c)#exit 142 QOS Quick Reference Sheets Router(config-pmap)#exit Router(config)#interface fastethernet 0/1 Router(config-if)#service-policy input REMARK In this example, traffic marked with CoS values of 5, 6, or 7 is classified in the HI-PRI class-map, whereas traffic with CoS values of 2, 3, or 4 goes into the MED-PRI class-map. Finally, CoS values of 0 and 1 are placed in the LOW-PRI class-map. The REMARK policy-map assigns a DSCP value of AF31 to the HI-PRI traffic, a DSCP value of AF21 to the MED-PRI traffic, and a DSCP value of AF11 to the LOW-PRI traffic. The third step of MQC applies a policy-map to an interface. In this case, you are applying the REMARK policy-map to the FastEthernet 0/1 interface in the inbound direction. It is critical that you apply the policy-map in the inbound direction. By doing so, you are remarking the CoS values before the route processor strips them. As you learned earlier, to see what policies are applied to your class-maps, use the show policymap command. Or, to see interface-specific statistics for a policy-map, the show policy-map interface interface-identifier command is appropriate. Classifying with NBAR The most powerful and flexible approach to classifying traffic is the Network Based Application Recognition (NBAR) feature. NBAR can look beyond Layer 3 and Layer 4 information, all the way up to Layer 7. Protocols that change port number (that is, stateful protocols) can be tracked, and even URL strings can be matched with NBAR. Although the IOS comes with multiple NBAR application signatures, a continuing need exists for additional signature recognition. For example, even though your router might be able to recognize KaZaa traffic, it might not be able to recognize e-Donkey traffic. Fortunately, you can install Packet Description Language Modules (PDLMs) into the router’s flash, and these PDLMs extend the IOS’s ability to recognize traffic. PDLMs are available for download from http://www.cisco.com/cgi-bin/tablebuild.pl/pdlm. Note that this site requires a Cisco.com login. Also, note that the context-sensitive help in the IOS might define the PDLM as Protocol Description Language Module instead of Packet Description Language Module. Traffic Classification and Marking 143 In addition to NBAR’s usefulness in classifying, it can function as a protocol discovery tool. For example, NBAR protocol discovery could be enabled on an interface to determine the applications that are consuming the most bandwidth on that interface (that is, the “top talkers”). The following command configures NBAR protocol discovery: Router(config-if)#ip nbar protocol-discovery After NBAR has collected traffic statistics for an interface, use the following command to view the statistics: Router#show ip nbar protocol-discovery To use NBAR to classify traffic, as part of a class-map, use the keyword protocol in the match command, as follows: Router(config-cmap)#match protocol protocol You can reference the previously mentioned PDLM file with the following command: Router(config)#ip nbar pdlm pdlm-file In the following example, NBAR classifies KaZaa Version 2 traffic and HTTP traffic: NBAR Example E0/1 KaZaa Version 2 => Limit to 32 kbps Web => Allocate at Least 128 kbps NBAR can recognize stateful protocols (that is, protocols that change port numbers) and look beyond Layer 3 or Layer 4 information, including Layer 7 information. Router(config)#class-map MUSIC Router(config-cmap)#match protocol kazaa2 Router(config-cmap)#exit Router(config)#class-map WEB Router(config-cmap)#match protocol http Router(config-cmap)#exit Router(config)#policy-map NBARTEST Router(config-pmap)#class MUSIC Router(config-pmap-c)#police 32000 Router(config-pmap-c)#exit Router(config-pmap)#class-map WEB Router(config-pmap-c)#bandwidth 128 Router(config-pmap-c)#exit Router(config-pmap)#exit Router(config)#interface ethernet 0/1 Router(config-if)#service-policy output NBARTEST In this example, KaZaa version 2 traffic is classified by the MUSIC class-map, whereas http traffic is classified by the WEB class-map. Then, the NBARTEST policy-map limits the MUSIC class to 32 kbps while allocating 128 kbps of bandwidth for the WEB class. Finally, the policy-map is applied outbound to the ethernet 0/1 interface. 144 QOS Quick Reference Sheets Consider the priority that you should assign to web traffic. If you have an e-commerce site, as an example, web traffic might need varying levels of priority, depending on the content of the web traffic. The good news is that NBAR can recognize the content of web traffic using commands such as the following: Router(config-cmap)#match protocol http url url-string (Matches a string that is contained in the URL) As an example, you could match traffic that contains the word cisco in the URL with the following command: match protocol http url “*cisco*” The asterisks are acting as wildcards, matching any characters before or after the word cisco. QoS over Tunnel Connections Virtual private networks (VPNs) are gaining tremendous popularity because of their ability to provide secure connectivity through a public network, such as an ISP. VPNs are made possible thanks to tunneling. The challenge with QoS in a tunnel environment is that the tunnels encapsulate traffic, which hides the original information in a packet’s header. After packets enter a tunnel, they have a tunnel header. Therefore, all packets have the same level of priority, because the classification of encapsulated packets is based on the tunnel header. The Cisco pre-classify feature overcomes this issue by applying QoS features to packets before they enter the tunnel. Pre-classification, however, is only necessary when you are classifying based on a criterion other than a packet’s ToS byte. The IOS automatically copies bits from a packet’s ToS byte into the ToS byte of the tunnel header. Classification with Tunneling IP Header Payload Tunnel Header IP Header Payload After an IP packet is encapsulated in a tunnel, the original IP header is concealed, and QoS classifications reference the tunnel header. To enable the pre-classification feature, in tunnel-interface-configuration mode (or in crypto-map configuration mode for an IPSec tunnel), enter the following command: qos pre-classify QoS over BGP Networks In a service provider environment, you might not want to use access-lists or other classification mechanisms through the service provider’s network. An alternate option is to use QoS Policy Propagation Through BGP (QPPB). QPPB lets you encode QoS information by assigning BGP attributes such as an autonomous system number, community string, or an IP prefix. For example, instead of setting the IP Precedence marking to a 4 inside every packet, you could send the traffic with a certain community string. When the far-end autonomous system receives the traffic with that community string, it can mark those packets with an IP Precedence of 4. In the following example for router R1, the community attribute determines how the IP Precedence value is set. Specifically, traffic with a community string of 20:1 has its IP Precedence set to Traffic Classification and Marking 145 a 2, and traffic with a community string of 20:2 has its IP Precedence set to a 3. The bgp-policy source command applies this policy to interface Serial 0/1. QPPB S0/1 1.1.1.1 1.1.1.2 R2 R1 AS 100 AS 200 router bgp 100 table-map precedence-map neighbor 1.1.1.2 remote-as 200 neighbor 1.1.1.2 send-community ! route-map precedence-map permit 10 match community 1 set ip precedence 2 ! route-map precedence-map permit 20 match community 2 set ip precedence 3 ! ip community-list 1 permit 20:1 ip community-list 2 permit 20:2 ! interface serial 0/1 ip address 1.1.1.1 255.255.255.0 bgp-policy source ip-prec-map Catalyst-Based Classification and Marking You can perform classification and marking functions, not just on router platforms, but also on many Catalyst series switches. Even though QoS is considered primarily a WAN technology, proper QoS configuration in a enterprise network’s infrastructure is also critical. For example, a switch might have interfaces that run at different speeds (for example, 10 Mbps and 1 Gbps). Such a scenario could lead to a switch queue overflowing. Also, traffic can enter a switch marked with a Layer 2 CoS value. These Layer 2 values do not pass through a route processor. Therefore, a Catalyst switch is an excellent place to perform CoS-to-DSCP remarking. So, when the traffic reaches the route processor, it has a Layer 3 marking, which can pass successfully through the route processor. Applying QoS features at the edge of the network (for example, in a wiring closet) offers the following benefits: • Provides immediate traffic classification • Reduces congestion within the remainder of the network • Eases the processor burden on the distribution and core routers These Quick Reference Sheets primarily focus on the Catalyst 2950 Series of switches. You can configure the Catalyst 2950 ports to trust CoS or DSCP markings. However, by default, these ports are “untrusted,” meaning that they disregard priority markings on incoming traffic. When a port is untrusted, traffic is assigned the configurable CoS value of the port. The Catalyst 2950 can place frames in one of four queues. Later in these Quick Reference Sheets, you use these queues for Weighted Round Robin (WRR) queuing. For now, however, you should be 146 QOS Quick Reference Sheets familiar with how the switch places frames with various CoS markings into its four queues, as described in the following table. Default Queue Assignment CoS Value 0 and 1 2 and 3 4 and 5 6 and 7 Queue 1 2 3 4 For internal QoS processing, all traffic (even non-IP traffic) is assigned an internal DSCP number. The default CoS-to-DSCP mappings are shown in the following table. CoS-to-DSCP Mappings CoS Value 0 1 2 3 4 5 6 7 DSCP Value 0 8 16 24 32 40 48 56 Because the Catalyst 2950 uses CoS values to make queuing decisions, before the queuing process, the internal DSCP value is extrapolated to a CoS value. Although mappings are configurable, the default values are shown in the following table. DSCP-to-CoS Mappings DSCP Values 0 8 and 10 16 and 18 24 and 26 32 and 34 40 and 46 48 56 CoS Value 0 1 2 3 4 5 6 7 With your understanding of the default switch behavior, you can explore how to manipulate the trust settings and the CoS-to-DSCP mappings. The following command tells a port what to trust: Switch(config-if)#mls qos trust [cos [pass-through dscp] | device cisco-phone | dscp] Traffic Classification and Marking 147 The pass-through dscp option does not modify the DSCP values (that is, remark them based on CoS values). You can use the following command to assign a default CoS value for a port: Switch(config-if)#mls qos cos {default-cos | override} The override option applies the default CoS value to a frame, even though a frame might already have a CoS marking. The following commands allow you to manipulate the default CoS-to-DSCP and DSCP-to-CoS mappings: Switch(config)#mls qos map cos-dscp dscpvalue1 dscpvalue2 ... dscpvalue8 (Configures CoS-to-DSCP mapping) For example: Switch(config)#mls qos map cos-dscp 0 16 24 32 34 40 48 56 In this example, the eight DSCP values that are entered correspond to CoS values 0 through 7. Switch(config)#mls qos map dscp-cos dscp-list to cos (Configures DSCP-to-CoS mapping) For example: Switch(config)#mls qos map dscp-cos 16 28 24 26 to 1 DSCP to CoS Remarking ISL Trunk Fa 0/1 DSCP 16 DSCP 24 DSCP 26 Fa 2/1 CoS 1 CoS 1 CoS 1 You can associate up to 13 DSCP values with a single CoS value. The three-step MQC process can also be used on a Catalyst 2950 to perform classification and marking, without as many “match” options as are available on a router platform. Typically, you create a standard or extended IP access-list (or a Layer 2 MAC ACL for non-IP traffic). That access-list can then serve as the match criterion in a class-map. Note, however, that the extended IP access-lists that are available on the Catalyst 2950 do not have all the options that are available on a router. Specifically, you cannot use the access-list to match a range of port numbers. In the following example, an extended IP access-list matches traffic that is destined for IP address 192.168.0.101. A policy-map then marks traffic that is destined for that host with a DSCP value of 34. Finally, the policy is applied to interface Gigabit Ethernet 0/3 in the inbound direction. The example is as follows: Switch(config)#access-list 100 permit ip any host 192.168.0.101 Switch(config)#class-map CATCLASS Switch(config-cmap)#match access-group 100 Switch(config-cmap)#exit Switch(config)#policy-map CATPOLICY Switch(config-pmap)#class CATCLASS Switch(config-pmap-c)#set ip dscp 34 Switch(config-pmap-c)#interface gig 0/3 Switch(config-if)#service-policy input CATPOLICY 148 QOS Quick Reference Sheets A switch’s QoS interface configuration can be verified with the following command: Switch#show mls qos interface interface-identifier Use the following command to see how CoS and DSCP values are mapped to one another: Switch#show mls qos maps [cos-dscp | dscp-cos] Queuing Sometimes referred to as congestion management, queuing mechanisms identify how traffic from multiple streams is sent out of an interface that is currently experiencing congestion. This section examines various approaches to queuing and emphasizes the queuing approaches configured via MQC. Queuing Basics When a device, such as a switch or a router, is receiving traffic faster than it can be transmitted, the device attempts to buffer the extra traffic until bandwidth is available. This buffering process is called queuing. You can use queuing mechanisms to influence in what order various traffic types are emptied from the queue. Software Queuing Priority Queue 1 Business Queue 2 3 1 2 4 Application Queue 3 Best-Effort Queue 4 4 4 4 3 3 2 4 1 3 2 1 A software queuing mechanism is invoked only after an interface’s hardware queue overflows. Congestion occurs not just in the WAN but also in the LAN. Mismatched interface speeds, for example, could result in congestion on a high-speed LAN. Points in the network in which you have aggregated multiple connections can result in congestion. For example, perhaps multiple workstations connect to a switch at Fast Ethernet speeds (that is, 100 Mbps), and the workstations are simultaneously transmitting to a server that is also connected through Fast Ethernet. Such a scenario can result in traffic backing up in a queue. Although Cisco supports multiple queuing mechanisms, these Quick Reference Sheets primarily focus on CB-WFQ and LLQ. However, legacy queuing mechanisms are addressed first and include the following types: • FIFO queuing—First-in first-out (FIFO) queuing is not truly performing QoS operations. As its name suggests, the first packet to come into the queue is the first packet sent out of the queue. Queuing 149 • Priority Queuing (PQ)—This type of queuing places traffic into one of four queues. Each queue has a different level of priority, and higher-priority queues must be emptied before packets are emptied from lower-priority queues. This behavior can “starve out” lowerpriority traffic. • Round robin queuing—This type of queuing places traffic into multiple queues, and packets are removed from these queues in a round-robin fashion, which avoids the protocolstarvation issue that PQ suffered from. • Weighted Round Robin (WRR) queuing—This type of queuing can place a weight on the various queues, to service a different number of bytes or packets from the queues during a round-robin cycle. Custom Queuing (CQ) is an example of a WRR queuing approach. • Deficit Round Robin (DRR) queuing—This type of queuing can suffer from a “deficit” issue. For example, if you configured CQ to removed 1500 bytes from a queue during each roundrobin cycle, and you had a 1499-byte packet and a 1500-byte packet in the queue, both packets would be sent. This is because CQ cannot send a partial packet. Because the 1499-byte packet was transmitted and because another byte still had to be serviced, CQ would start servicing the 1500-byte packet. DRR keeps track of the number of extra bytes that are sent during a round and subtracts that number from the number of bytes that can be sent during the next round. A router has two types of queues: a hardware queue and a software queue. The hardware queue, which is sometimes referred to as the transmit queue (TxQ), always uses FIFO queuing, and only when the hardware queue is full does the software queue handle packets. Therefore, your queuing configuration only takes effect during periods of interface congestion, when the hardware queue has overflowed. With this basic understanding of queuing, you begin to examine several queuing methods in more detail. FIFO Using FIFO in the software queue works just like FIFO in the hardware queue, where you are not truly performing packet manipulation. FIFO is the default queuing method on interfaces that run at speeds of greater than 2.048 Mbps. Although FIFO is supported widely on all IOS platforms, it can starve out traffic by allowing bandwidth-hungry flows to take an unfair share of the bandwidth. WFQ Weighted Fair Queuing (WFQ) is enabled by default on slow-speed (that is, 2.048-Mbps and slower) interfaces. WFQ allocates a queue for each flow, for as many as 256 flows by default. WFQ uses IP Precedence values to provide a weighting to Fair Queuing (FQ). When emptying the queues, FQ does byte-by-byte scheduling. Specifically, FQ looks 1 byte deep into each queue to determine whether an entire packet can be sent. FQ then looks another byte deep into the queue to determine whether an entire packet can be sent. As a result, smaller traffic flows and smaller packet sizes have priority over bandwidth-hungry flows with large packets. In the following example, three flows simultaneously arrive at a queue. Flow A has three packets, which are 128 bytes each. Flow B has a single 96-byte packet. Flow C has a single 70-byte packet. After 70 byte-by-byte rounds, FQ can transmit the packet from flow C. After an additional 26 rounds, FQ can transmit the packet from flow B. After an additional 32 rounds, FQ can transmit the first packet from flow A. Another 128 rounds are required to send the second packet from flow A. Finally, after a grand total of 384 rounds, the third packet from flow A is transmitted. 150 QOS Quick Reference Sheets Fair Queuing 128 Bytes A3 128 Bytes A2 128 Bytes A1 96 Bytes B1 70 Bytes C1 Output Queue A3 A2 A1 B1 C1 With WFQ, a packet’s IP Precedence influences the order in which that packet is emptied from a queue. Consider the previous scenario with the addition of IP Precedence markings. In this scenario, flow A’s packets are marked with an IP Precedence of 5, whereas flow B and flow C have default IP Precedence markings of 0. The order of packet servicing with WFQ is based on sequence numbers, where packets with the lowest sequence numbers are transmitted first. The sequence number is the weight of the packet multiplied by the number of byte-by-byte rounds that must be completed to service the packet (just as in the FQ example). Cisco IOS calculates a packet’s weight differently depending on the IOS version. Prior to IOS 12.0(5)T, the formula for weight was as follows: Weight = 4096 /(IP Prec. + 1) In more recent versions of the IOS, the formula for weight is as follows: Weight = 32384 /(IP Prec. + 1) Using the pre-IOS 12.0(5)T formula, the sequence numbers are as follows: A1 = 4096 /(5 + 1) * 128 = 87381 A2 = 4096 /(5 + 1) * 128 + 87381 = 174762 A3 = 4096 /(5 + 1) * 128 + 174762 = 262144 B1 = 4096 /(0 + 1) * 96 = 393216 C1 = 4096 /(0 + 1) * 70 = 286720 Therefore, after the weighting is applied, WFQ empties packets from the queue in the following order: A1, A2, A3, C1, B1. With only FQ, packets were emptied from the queue in the order C1, B1, A1, A2, A3. Although WFQ has default settings, you can manipulate those settings with the following interface-configuration-mode command: Router(config-if)#fair-queue [cdt [dynamic-queues [reservable-queues]]] Queuing 151 IP Prec. Weighted Fair Queuing 128 Bytes 5 A3 128 Bytes A2 128 Bytes A1 96 Bytes 0 B1 70 Bytes B1 C1 A3 A2 A1 0 Output Queue C1 Sequence Number* = 4096/(IP Prec. + 1) * In IOS 12.0(5)T and later, the Sequence Number = 32768/(IP Prec. + 1). The cdt parameter identifies the Congestive Discard Threshold (CDT), which is the number of packets allowed in all WFQ queues before the router begins to drop packets that are attempting to enter the deepest queue (that is, the queue that currently has the most packets). The default CDT value is 64. With WFQ, each flow is placed in its own queue, up to a maximum number of queues as defined by the dynamic-queues parameter. The default number of queues that is created dynamically (that is, dynamic-queues) is 256. The reservable-queues parameter defines the number of queues that are made available to interface features such as RSVP. The default number of reservable queues is 0. Although WFQ is easy to configure (for example, it is enabled by default on interfaces that run at or below 2.048 Mbps), and although WFQ is supported on all IOS versions, it has its limitations. Specifically, WFQ cannot guarantee a specific amount of bandwidth for an application. Also, if more than 256 flows exist, by default, more than one flow can be forced to share the same queue. You can view statistics for WFQ with the show interface interface-identifier command. The output from this command not only verifies that WFQ is enabled on the specified interface, but it also shows such information as the current queue depth and the maximum number of queues allowed. CB-WFQ The WFQ mechanism made sure that no traffic was starved out. However, WFQ did not make a specific amount of bandwidth available for defined traffic types. You can, however, specify a minimum amount of bandwidth to make available for various traffic types using the CB-WFQ mechanism. CB-WFQ is configured through the three-step MQC process. Using MQC, you can create up to 63 class-maps and assign a minimum amount of bandwidth for each one. Note that the reason you cannot create 64 class-maps is that the class-default class-map has already been created. Traffic for each class-map goes into a separate queue. Therefore, one queue (for example, for CITRIX traffic) can be overflowing, while other queues are still accepting packets. Bandwidth allocations for various class-maps can be specified in one of three ways: bandwidth, percentage of bandwidth, and percentage of remaining bandwidth. The following paragraphs describe each of these allocations. 152 QOS Quick Reference Sheets You can make a specific amount of bandwidth available for classified traffic. To allocate a bandwidth amount, use the following command, noting that the units of measure are in kbps: Router(config-pmap-c)#bandwidth bandwidth Instead of specifying an exact amount of bandwidth, you can specify a percentage of the interface bandwidth. For example, a policy-map could allocate 25 percent of an interface’s bandwidth. Then, that policy-map could be applied to, for example, a Fast Ethernet interface and also to a slower-speed serial interface. To allocate a percentage of the interface bandwidth, use the following command: Router(config-pmap-c)#bandwidth percent percent As an alternative to allocating a percentage of the total interface bandwidth, you can also allocate a percentage of the remaining bandwidth (that is, after other bandwidth allocations have already been made). To allocate a percentage of the remaining interface bandwidth, use the following command: Router(config-pmap-c)#bandwidth remaining percent percent By default, each queue that is used by CB-WFQ has a capacity of 64 packets. However, this limit is configurable with the following command: Router(config-pmap-c)#queue-limit number_of_packets Although CB-WFQ queues typically use FIFO for traffic within a particular queue, the classdefault queue can be enabled for WFQ with the following command: Router(config-pmap-c)#fair-queue [dynamic-queues] As noted earlier, CB-WFQ is configured through MQC. Therefore, the standard MQC verification and troubleshooting commands, such as show policy-map interface interface-identifier, are applicable for CB-WFQ. By default, only 75 percent of an interface’s bandwidth can be allocated. The remaining 25 percent is reserved for nonclassified or overhead traffic (for example, CDP, LMI, or routing protocols). This limitation can be overcome with the max-reserved-bandwidth percentage interface-configuration-mode command, where the percentage option is the percentage of an interface’s bandwidth that can be allocated. CB-WFQ is therefore an attractive queuing mechanism, thanks to its MQC configuration style and its ability to assign a minimum bandwidth allocation. The only major drawback to CB-WFQ is its inability to give priority treatment to any traffic class. Fortunately, an enhancement to CBWFQ, called Low Latency Queuing (LLQ), does support traffic prioritization. LLQ Low Latency Queuing (LLQ) is almost identical to CB-WFQ. However, with LLQ, you can instruct one or more class-maps to direct traffic into a priority queue. Realize that when you place packets in a priority queue, you are not only allocating a bandwidth amount for that traffic, but you also are policing (that is, limiting the available bandwidth for) that traffic. The policing option is necessary to prevent higher-priority traffic from starving out lower-priority traffic. Note that if you tell multiple class-maps to give priority treatment to their packets, all priority packets go into the same queue. Therefore, priority traffic could suffer from having too many priority classes. Packets that are queued in the priority queue cannot be fragmented, which is a consideration for slower-speed links (that is, link speeds of less than 768 kbps). LLQ, based on all the listed benefits, is the Cisco preferred queuing method for latency-sensitive traffic, such as voice and video. Queuing 153 You can use either of the following commands to direct packets to the priority queue: Router(config-pmap-c)#priority bandwidth (Note that the bandwidth units of measure are in kbps.) Router(config-pmap-c)#priority percent percent (Note that the percent option references a percentage of the interface bandwidth.) Consider the following LLQ example. LLQ Example S 0/1 Web => Allocate 128 Kbps of Bandwidth Voice => Allocate 256 Kbps of “Priority” Bandwidth Whereas CB-WFQ allocates a specific bandwidth amount, LLQ can allocate “priority” bandwidth amounts for specified traffic classes. Router(config)#class-map SURFING Router(config-cmap)#match protocol http 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 SURFING Router(config-pmap-c)#bandwidth 128 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 In this example, NBAR is being used to recognize http traffic, and that traffic is placed in the SURFING class. Note that NBAR is invoked with the following command: Router(config-cmap)# match protocol Voice packets are placed in the VOICE class. The QOS_STUDY policy-map gives 128 kbps of bandwidth to the http traffic while giving 256 kbps of priority bandwidth to voice traffic. Then the policy-map is applied outbound to interface serial 0/1. Catalyst-Based Queuing Some Cisco Catalyst switches also support their own queuing method, called Weighted Round Robin (WRR) queuing. For example, a Catalyst 2950 switch has four queues, and WRR can be 154 QOS Quick Reference Sheets configured to place frames with specific CoS markings into certain queues. (For example, CoS values 0 and 1 are placed in Queue 1.) Weights can be assigned to the queues, influencing how much bandwidth the various markings receive. The queues are then serviced in a round-robin fashion. On the Catalyst 2950, queue number 4 can be designated as an “expedite” queue, which gives priority treatment to frames in that queue. Specifically, the expedite queue must be empty before any additional queues are serviced. This behavior can lead to protocol starvation. On a Catalyst 2950, frames are queued based on their CoS values. The following command can be used to alter the default queue assignments: Switch(config)#wrr-queue cos-map queue_number cos_value_1 cos_value_2 … cos_value_n For example, the following command would map CoS values of 0, 1, and 2 to queue number 1 on a Catalyst 2950: Switch(config)#wrr-queue cos-map 1 0 1 2 The weight that is assigned to a queue specifies how many packets are emptied from a queue during each round-robin cycle, relative to other queues. You can configure queue weights with the following command: Switch(config)#wrr-queue bandwidth weight_1 weight_2 weight_3 weight_4 Remember that queue number 4 on a Catalyst 2950 can be configured as an expedite queue (that is, a priority queue). To configure queue number 4 as an expedite queue, set its weight to 0. Following is an example of a WRR configuration. Weighted Round Robin (WRR) Queue 4 (Weight = 4) 5 Queue 3 (Weight = 3) 4 3 1 0 5 Queue 2 (Weight = 2) 3 CoS Values 3 2 4 4 5 5 5 5 Queue 1 (Weight = 1) 1 0 1 0 WRR “weights” queues to determine the relative amount of bandwidth available to each queue. In this example, Queue 4 has twice the available bandwidth of Queue 2. Switch(config)#interface gig 0/5 Switch(config-if)#wrr-queue bandwidth 1 2 3 4 Switch(config-if)#wrr cos-map 4 5 Weighted Random Early Detection (WRED) 155 In this example, the wrr-queue command is assigning the weights 1, 2, 3, and 4 to the switch’s four queues. The first queue, with a weight of 1, for example, only gets one-third the bandwidth that is given to the third queue, which has a weight of 3. The wrr cos-map 4 5 command is instructing frames that are marked with a CoS of 5 to enter the fourth queue. To verify how a Catalyst 2950 is mapping CoS values to DSCP values (or vice versa), use the following command: Switch#show mls qos maps [cos-dscp | dscp-cos] You can use the following command to view the weight that is assigned to each queue: Switch#show wrr-queue bandwidth Another useful WRR command, which shows how CoS values are being mapped to switch queues shows is as follows: Switch#show wrr-queue cos-map Finally, you can see the QoS configuration for an interface (for example, trust state and the interface’s default CoS value) with the following command: Switch#show mls qos interface [interface-identifier] Weighted Random Early Detection (WRED) Whereas queuing provides congestion management, mechanisms such as WRED provide congestion avoidance. Specifically, WRED can prevent an output queue from ever filling to capacity, which would result in packet loss for all incoming packets. This section examines the need for and the configuration of WRED on Cisco routers. How TCP Handles Drops Recall from your early studies of networking technology how Transport Control Protocol (TCP) windowing functions. A sender sends a single segment, and if the sender receives a successful acknowledgment from the receiver, it then sends two segments (that is, a “windows size” of 2). If those two segments were acknowledged successfully, the sender sends four segments, and so on, increasing the window size exponentially. However, if one of the segments is dropped, the TCP flow goes into TCP slow start, where the window size is reduced to 1. The TCP flow then exponentially increases its window size until the window size reaches half of the window size when congestion originally occurred. At that point, the TCP flow’s window size increases linearly. TCP slow start is relevant to QoS, because when an interface’s output queue is full, all newly arriving packets are discarded (that is, “tail dropped”), and all of those TCP flows simultaneously go into TCP slow start. Note that the process of multiple TCP flows simultaneously entering TCP slow start is called global synchronization or TCP synchronization. When TCP synchronization occurs, the link’s bandwidth is underutilized, resulting in wasted bandwidth. RED Basics The purpose of Random Early Detection (RED) is to prevent TCP synchronization by randomly discarding packets as an interface’s output queue begins to fill. How aggressively RED discards packets depends on the current queue depth. The following three parameters influence when a newly arriving packet is discarded: • Minimum threshold • Maximum threshold • Mark Probability Denominator (MPD) 156 QOS Quick Reference Sheets The minimum threshold specifies the number of packets in a queue before the queue considers discarding packets. The probability of discard increases until the queue depth reaches the maximum threshold. After a queue depth exceeds the maximum threshold, all other packets that attempt to enter the queue are discarded. However, the probability of packet discard when the queue depth equals the maximum threshold is 1/(MPD). For example, if the mark probability denominator were set to 10, when the queue depth reached the maximum threshold, the probability of discard would be 1/10 (that is, a 10 percent chance of discard). Random Early Detection (RED) As an output queue fills beyond the minimum threshold, RED begins to discard packets. Those packets are discarded more aggressively as the queue depth increases. When the queue depth exceeds the maximum threshold, all packets are discarded. Maximum Threshold Minimum Threshold Output Queue The minimum threshold, maximum threshold, and MPD comprise the RED profile. The following figure shows the three distinct ranges in a RED profile: no drop, random drop, and full drop. RED Drop Ranges Probability of Discard 100% The probability of discard at the maximum threshold equals 1/MPD. In this instance, the probability of discard with an average queue depth of 45 packet = 1/5 = 20 percent. Full Dropping Random Dropping 20% No Dropping MPD = 5 25 45 Average Queue Depth RED is most useful on router interfaces where congestion is likely. For example, a WAN interface might be a good candidate for RED. Weighted Random Early Detection (WRED) 157 CB-WRED Cisco does not support RED, but fortunately it supports something better: Weighted Random Early Detection (WRED). Unlike RED, WRED has a profile for each priority marking. For example, a packet with an IP Precedence value of 0 might have a minimum threshold of 20 packets, whereas a packet with an IP Precedence of 1 might have a minimum threshold of 25 packets. In this example, packets with an IP Precedence of 0 would start to be discarded before packets with an IP Precedence of 1. Although WRED can be configured from interface-configuration mode or from virtual-circuitconfiguration mode, these Quick Reference Sheets focus on an MQC-based WRED configuration. To enable WRED and to specify the marking that WRED pays attention to (that is, IP Precedence or DSCP), issue the following policy-map-class configuration-mode command: Router(config-pmap-c)#random-detect [dscp-based | prec-based] If neither dscp-based nor prec-based is specified, WRED defaults to prec-based. After WRED is configured, the IOS assigns default minimum threshold, maximum threshold, and MPD values. However, you can alter those default parameters with the following commands: Router(config-pmap-c)#random-detect precedence precedence_value minimumthreshold maximum-threshold mark-probability-denominator (Used for prec-based WRED) Router(config-pmap-c)#random-detect dscp dscp_value minimum-threshold maximumthreshold mark-probability-denominator (Used for dscp-based WRED) To reinforce this syntax, consider the following example, where the goal is to configure WRED for the WREDTEST class-map. After the class-map’s queue depth reaches 25 packets, a DSCP value of AF13 might be discarded. Packets that are marked with a DSCP value of AF12 should not be discarded until the queue depth reaches 30 packets, and finally, packets that are marked with a DSCP value of AF11 should have no chance of discard until the queue depth reaches 35 packets. If the queue depth exceeds 100 packets, there should be a 100 percent chance of discard for these three DSCP values. However, when the queue depth is exactly 100 packets, the chance of discard for these various packet types should be 25 percent. Also, CB-WRED requires that CB-WFQ be configured for the interface. So, as an additional requirement, you make 25 percent of the interface’s bandwidth available to the WREDTEST class of traffic. Probability of Discard 100% WRED Profiles Drop Profile for AF13 Drop Profile for AF12 Drop Profile for AF11 25% MPD = 4 25 30 35 Average Queue Depth 100 158 QOS Quick Reference Sheets Router(config-pmap)#class WREDTEST Router(config-pmap-c)#bandwidth percent 25 Router(config-pmap-c)#random-detect dscp-based Router(config-pmap-c)#random-detect dscp af13 25 100 4 Router(config-pmap-c)#random-detect dscp af12 30 100 4 Router(config-pmap-c)#random-detect dscp af11 35 100 4 Examine the solution, and notice that the MPD is 4. This value was chosen to meet the requirement of a 25 percent chance of discard when the queue depth equals the maximum threshold (that is, 1/4 = .25). Also, notice that a DSCP value of AF13 is dropped before a DSCP value of AF12, which is dropped before a DSCP value of AF11. This approach is consistent with the definition of the per-hop behaviors (PHBs), because the last digit in the Assured Forwarding (AF) DSCP name indicates its drop preference. For example, a value of AF13 would drop before a value of AF12. To view the minimum threshold, maximum threshold, and MPD settings for the various IP Precedence or DSCP values, you can issue the show policy-map interface interface-identifier command. ECN Configuration WRED discards packets, and that is one way for the router to indicate congestion. However, routers can now indicate a congestion condition by signaling, using an approach called Explicit Congestion Notification (ECN). ECN uses the 2 last bits in the ToS byte to indicate whether a device is ECN capable, and if so, whether congestion is being experienced. Explicit Congestion Notification (ECN) IPv4 Packet ToS Byte Bit Combination 1 2 3 4 5 6 7 8 00 ECT Bit ECT = ECN-Capable Transport CE = Congestion Experienced CE Bit 01 Meaning Router is not ECN capable. Router is ECN capable but is not experiencing congestion. Router is ECN capable but is not experiencing congestion. Router is ECN capable and is currently experiencing congestion. 10 11 Cisco routers can use ECN as an extension to WRED and mark packets that exceed a specified value, instead of dropping the packets. If the queue depth is at or below the WRED minimum threshold, the packets are sent normally, just as with WRED. Also, if the queue depth is above the WRED maximum threshold, all packets are dropped, just as with WRED. But if the queue depth is currently in the range from the minimum threshold through the maximum threshold, one of the following things can happen: • If both endpoints are ECN capable, the ECT and CE bits are set to a 1 and sent to the destination, indicating that the transmission rate should be reduced. • If neither endpoints supports ECN, the normal WRED behavior occurs. • A packet with its ECN and CE bits marked can reach a destination router that already has a full queue. In such an instance, the notification is dropped. Traffic Conditioners 159 Use the following command to enable ECN: Router(config-pmap-c)#random-detect ecn Note that although WRED also can be configured in interface-configuration mode, ECN must be configured through MQC. Because ECN is configured by the three-step MQC process, the same verification and troubleshooting commands apply. Specifically, you can use the show policy-map and show policy-map interface interface-identifier commands to verify the ECN configuration. Traffic Conditioners QoS mechanisms can not only provide for the allocation of a minimum amount of bandwidth for specific traffic but also limit the amount of bandwidth made available to that traffic. This section discusses how policing and shaping mechanisms limit traffic rates. Policing Versus Shaping Instead of allocating bandwidth for applications, in some instances, you might want to restrict the amount of bandwidth that is available for specific traffic. For example, you might want to set a “speed limit” for users on the network who are downloading music files from the Internet. QoS mechanisms that limit bandwidth are called traffic conditioners. The two categories of traffic conditioners are policing and shaping. Although both of these approaches limit bandwidth, they have different characteristics, as follows: • Policing—Policing typically limits bandwidth by discarding traffic that exceeds a specified rate. However, policing also can remark traffic that exceeds the specified rate and attempt to send the traffic anyway. Because policing’s drop behavior causes TCP retransmits, it is recommended for use on higher-speed interfaces. Also, note that policing can be applied inbound or outbound on an interface. • Shaping—Shaping limits excess traffic, not by dropping it but by buffering it. This buffering of excess traffic can lead to delay. Because of this delay, shaping is recommended for slowerspeed interfaces. Unlike policing, shaping cannot remark traffic. As a final contrast, shaping can be applied only in the outbound direction on an interface. The question becomes this: How do you send traffic out of an interface at a rate that is less than the physical clock rate of the interface? It is impossible for an interface to send at a rate that is slower than the line rate. However, you can send at an “average” rate that is less than the clock rate by using policing or shaping tools that do not transmit all the time. Specifically, these tools send a certain number of bits or bytes at line rate, and then they stop sending until a specific timing interval (for example, 1/8 of a second) is reached. When the timing interval is reached, the interface again sends a specific amount of traffic at line rate, it stops, and then it waits for the next timing interval to occur. This process continually repeats, allowing an interface to send an average bandwidth that can be below the physical speed of the interface. This average bandwidth is called the Committed Information Rate (CIR). The number of bits (the unit of measure that is used with shaping tools) or bytes (the unit of measure that is used with policing tools) that is sent during a timing interval is called the Committed Burst (Bc). The timing interval is written as Tc. For example, consider that you have a physical line rate of 128 kbps, but the CIR is only 64 kbps. Also consider that there are eight timing intervals in a second (that is, Tc = 1/8 of a second = 125 ms), and during each of those timing intervals, 8000 bits (that is, the committed burst parameter) 160 QOS Quick Reference Sheets are sent at line rate. Therefore, over the period of a second, 8000 bits were sent (at line rate) eight times, for a grand total of 64,000 bits per second, which is the CIR. Shaping Example Speed 8000 Bits Transmitted at Line Rate Line Rate 128 kbps Line Rate = 128,000 bps CIR = 64,000 bps Bc = 8000 bits Tc = 125 ms 8000 bits are sent at line rate eight times during a second. Therefore, the average transmission rate (that is, CIR) is 8 X 8000 = 64,000 bps. Time 125 ms 250 ms 375 ms 500 ms 625 ms 750 ms 875 ms 1000 ms However, if all the Bc bits (or bytes) were not sent during a timing interval, you have an option to “bank” those bits and use them during a future timing interval. The parameter that allows this storing of unused potential bandwidth is called the Excess Burst (Be) parameter. The Be parameter in a shaping configuration specifies the maximum number of bits or bytes that can be sent in excess of the Bc during a timing interval, if those bits are indeed available. For those bits or bytes to be available, they must have gone unused during previous timing intervals. Policing tools, however, use the Be parameter to specify the maximum number of bytes that can be sent during a timing interval. Therefore, in a policing configuration, if the Bc equals the Be, no excess bursting occurs. If excess bursting does occur, policing tools consider this excess traffic as exceeding traffic. Traffic that conforms to (that is, does not exceed) the specified CIR is considered by a policing tool to be conforming traffic. As part of your policing configuration, you can specify what action to take when traffic conforms to the CIR and what other action to take when the traffic exceeds the CIR. The relationship between the Tc, Bc, and CIR is given with the following formula: CIR = Bc / Tc Alternatively, the formula can be written as follows: Tc = Bc / CIR Therefore, if you want a smaller timing interval, you could configure a smaller Bc. To illustrate the operation of traffic conditioners, Cisco allows the metaphor of a “token bucket,” where you place Bc tokens in the bucket during each timing interval. Also, the bucket can hold a total of Be tokens. In a policing configuration, traffic that requires no more than the Bc number of bits or bytes to be transmitted is called conforming traffic. Traffic that requires more than the Bc number of bits or bytes is said to be exceeding traffic. Consider a policing example, where 500 bytes are currently in the token bucket. A packet comes through requiring 300 bytes. The bytes are removed from the bucket, and the packet is sent. Then, Traffic Conditioners 161 before the bucket has been replenished with more tokens, another 300-byte packet comes along. Because only 200 bytes remain in the bucket, the packet cannot be sent and is discarded. Token Bucket Bc tokens are placed in the token bucket during a timing interval. Be An “exceed” action occurs when more than Bc tokens are removed from the token ucket during a timing interval. Bc This illustration describes how policing functions with a single token bucket; however Cisco supports a dual token bucket. With a dual token bucket, two buckets exist. The first bucket has a depth of Bc, and the second bucket has a depth of Be. If a packet can be forwarded using bytes in the Bc bucket, it is said to be conforming. If the packet cannot be forwarded using the bytes in the Bc bucket, but it can be forwarded using the bytes in the Be bucket, it is said to be exceeding. If the packet cannot be forwarded using either of the buckets individually, it is said to be violating. Realize, however, that a violating packet can still be transmitted if it can be forwarded using the combined bytes in both the Bc and Be buckets. Dual Token Bucket Bc tokens are placed in the token bucket during a timing interval. Bc Be Tokens that overflow from the Bc bucket are placed in the Be bucket, until the Be bucket overflows. Instead of policing traffic to a single rate, Cisco also supports dual-rate policing. With dual-rate policing, you still have two token buckets. The first bucket is the Committed Information Rate (CIR) bucket, and the second bucket is the Peak Information Rate (PIR) bucket. These buckets are replenished with tokens at different rates, with the PIR bucket being filled at a faster rate. When a packet arrives, the dual-rate policer checks to see whether the PIR bucket has enough tokens (that is, bytes) to send the packet. If there are not sufficient tokens, the packet is said to be violating, and it is discarded. Otherwise, the policer checks to see whether the CIR bucket has enough tokens to forward the packet. If the packet can be sent using the CIR bucket’s tokens, the packet is conforming. If the CIR bucket’s tokens are not sufficient, but the PIR bucket’s tokens are 162 QOS Quick Reference Sheets sufficient, the packet is said to be exceeding, and the exceed action (for example, transmit with a DSCP value of AF11) is applied. Dual-Rate Token Bucket With a dual-rate token bucket, tokens are added to a CIR and a PIR bucket at different rates. When forwarding traffic, tokens (that is, bytes) can be allocated only from one bucket. CIR PIR With a policing mechanism, you can specify various actions to perform based on whether a packet is conforming, exceeding, or violating. Examples of these actions are as follows: • • • • Transmit—Send the packet on to the scheduler. Drop—Discard the packet. Mark—Set priority bits for the packet. Multiaction—Perform more than one action, such as mark the packet with a DSCP value of AF12 and set the CLP bit to a 1. CB-Policing Configuration First, consider the configuration of Class-Based Policing (CB-Policing) for a single rate. You can configure CB-Policing with the following command: Router(config-pmap-c)#police cir [bc [be]] [conform-action action] [exceedaction action] [violate-action action] Note that you do not have to specify the Bc or Be values. If you specify only the CIR, the IOS calculates Bc as CIR/32 or 1500 (whichever is higher). Also, the default Be value equals Bc, meaning that the token bucket never holds more than Bc bytes. In the following example, you want to limit web traffic to 100 kbps and Telnet traffic to 50 kbps on interface Ethernet 0/0. CB-Policing Router A E 0/0 HTTP (100 Kbps Max) Telnet (50 Kbps Max) Router B RouterA(config)#class-map WEB RouterA(config-cmap)#match protocol http Traffic Conditioners 163 RouterA(config-cmap)#exit RouterA(config)#class-map TELNET RouterA(config-cmap)#match protocol telnet RouterA(config-cmap)#exit RouterA(config)#policy-map POLICING_EXAMPLE RouterA(config-pmap)#class WEB RouterA(config-pmap-c)#police 100000 RouterA(config-pmap-c)#exit RouterA(config-pmap)#class-map TELNET RouterA(config-pmap-c)#police 50000 RouterA(config-pmap-c)#exit RouterA(config-pmap-c)#exit RouterA(config-pmap)#exit RouterA(config)#interface Ethernet 0/0 RouterA(config-if)#service-policy output POLICING_EXAMPLE As mentioned earlier, you can configure dual-rate CB-Policing, where you police to two distinct rates: the CIR and PIR. The following command configures dual-rate CB-Policing: Router(config-pmap-c)#police cir cir [bc bc] [pir pir] [be be] [conform-action action] [exceed-action action] [violate-action action] Similar to CB-WFQ and LLQ, dual-rate CB-Policing allows you to limit the bandwidth of specific traffic by a percentage of an interface’s bandwidth. This can be accomplished with the following command: Router(config-pmap-c)#police cir percent percent [bc bc] [pir percent percent] [be be] [conform-action action] [exceed-action action] [violate-action action] CB-Shaping Configuration One of two approaches can be used when configuring Class-Based Shaping (CB-Shaping): shaping to average and shaping to peak. When you configure CB-Shaping to shape to average, you only want to send traffic at the CIR. However, if you configure shaping to peak, you are attempting to send above the CIR, if bandwidth is available. Specifically, when you shape to peak, instead of just adding Bc bits to the token bucket during each timing interval, you are adding Bc + Be bits to the token bucket. The peak rate is given by the following formula: Peak Rate = CIR * [1 + (Be/Bc)] Although shaping to peak can squeeze out some extra bandwidth from a WAN connection, it also can lead to multiple packet drops. Therefore, you should judiciously choose between the average and peak options. Following is the command to configure CB-Shaping: Router(config-pmap-c)#shape {average | peak} cir [bc] [be] Like CB-Policing, CB-Shaping can specify its CIR as a percentage of interface bandwidth, with the following command: Router(config-pmap-c)#shape {average | peak} percent percent [bc] [be] Consider the following CB-Shaping example, where you are shaping one class-map to average and another class-map to peak: Router(config)#class-map AVERAGECLASS Router(config-cmap)#match protocol telnet Router(config-cmap)#exit Router(config)#class-map PEAKCLASS Router(config-cmap)#match protocol http Router(config-cmap)#exit Router(config)#policy-map AVERAGEPOLICY 164 QOS Quick Reference Sheets Router(config-pmap)#class AVERAGECLASS Router(config-pmap-c)#shape average 64000 Router(config-pmap-c)#exit Router(config-pmap)#exit Router(config)#policy-map PEAKPOLICY Router(config-pmap)#class PEAKCLASS Router(config-pmap-c)#shape peak 64000 In this example, the AVERAGEPOLICY policy-map is shaping Telnet traffic to average, meaning that Telnet traffic is shaped to the CIR of 64 kbps. However, that is not the case for the PEAKPOLICY policy-map. The PEAKPOLICY policy-map is shaping traffic to a peak rate of CIR * [1 + (Be/Bc)]. Because you let the IOS calculate the Bc and Be values, they are equal, which means that you are shaping to a rate of 64000 * (1 + 1) = 128 kbps. Enabling CB-Shaping for Frame Relay Networks On Frame Relay networks, you might need not only to shape your traffic, but you might also need your router to respond to congestion occurring in the service provider’s cloud, by reducing the CIR to a lower value. When a service provider becomes congested and needs to discard frames, it first discards frames with their Discard Eligible (DE) bit set to a 1. The service provider also can request that the sending router slow its transmission rate, by marking the Backward Explicit Congestion Notification (BECN) bit to a 1, in a frame going back to the sender. When this occurs, if the router is configured to respond to BECNs, the router reduces its CIR by 25 percent. If the router receives another BECN in the next time interval, it decreases its transmission rate by 25 percent of the current rate. This behavior can continue until the rate drops to the router’s configured minimum CIR. Backward Explicit Congestion Notification (BECN) (2) Frame forwarded to receiver. (1) Frame sent. Router A (4) Service provider marks frame with the BECN bit. Frame Relay Service Provider’s Cloud (3) Traffic sent back to sender. Router B When Router A receives a frame marked with a BECN bit, it reduces its CIR by 25 percent. You can, however, encounter a situation in which the vast majority of the traffic is from one router to another router (that is, with little, if any, return traffic). In such a situation, the service provider cannot mark the BECN bit in a frame going back to the sender, because no (or very few) frames are going back to the sender. To remedy this situation, the service provider can mark the Forward Explicit Congestion Notification (FECN) bit in a frame that is destined for the receiver. If the receiver is configured to respond to FECNs, it generates a Q.922 test frame and sends it back to the sender. This test frame gives the service provider the opportunity to mark a frame’s BECN bit, in an attempt to make the sender slow its transmission rate. QoS on Slow-Speed Links 165 Forward Explicit Congestion Notification (FECN) (2) Service provider marks frame with the FECN bit. (1) Frame sent. Router A Frame Relay Service Provider’s Cloud (4) Service provider marks Q.922 test frame with the BECN bit. (3) Q.922 test frame sent in response to the FECN message. Router B Instead of waiting for Router B to send traffic back to Router A, the service provider marks a frame going to Router B with a FECN bit. This bit causes Router B to send a Q.922 test frame back to Router A. The service provider marks the BECN bit in this frame to ask Router A to reduce its CIR. After a sender has slowed its transmission rate because of BECNs, 16 timing intervals must elapse before the sender begins to increase its transmission rate. When the sender does begin to increase its transmission rate, it does so at a much more cautious rate than when it reduced its rate. Specifically, the sender only increases its transmission rate by (Be + Bc) / 16 bits per timing interval. Consider the following example, where CB-Shaping is being combined with CB-WFQ to allocate at least one amount of bandwidth, while shaping (that is, limiting the traffic rate) to a higher bandwidth. Router(config)#policy-map FRAMESHAPE Router(config-pmap)#class FRAMECLASS Router(config-pmap-c)#shape average 128000 Router(config-pmap-c)#shape adaptive 96000 Router(config-pmap-c)#bandwidth 96 In this example, traffic classified by the FRAMECLASS class-map is shaped to an average rate of 128 kbps. Also, the shape adaptive mincir command is used to specify the minimum value to which the CIR can drop in the presence of BECNs. In this example, the router can reduce its transmission rate to a CIR of 96 kbps. (Note that the units of measure for the mincir parameter are bits per second.) Also, CB-WFQ specifies that at least 96 kbps of bandwidth is available for this class of traffic. Note that, as shown in the previous example, minimum CIR (as specified by the shape adaptive command) should not be less than the bandwidth that is allocated by CB-WFQ. QoS on Slow-Speed Links In this section, you make the most of your limited bandwidth on lower-speed WAN interfaces. Specifically, you are introduced to compression technologies, which send fewer bits across the link, and link fragmentation and interleaving technologies, which fragment large payloads to reduce the serialization delay that is experienced by smaller payloads. Tools for Using Bandwidth Efficiently The two broad categories of compression are as follows: • Payload compression—Reduces the payload size, using approaches such as STAC, Predictor, or MPPC. • Header compression—Reduces the size of the TCP and RTP headers. 166 QOS Quick Reference Sheets The goal of compression technologies is to increase the throughput over a WAN link while reducing the delay. However, particularly with payload-compression approaches, the time that is required by lower-end routers to run the compression algorithm can increase the overall delay. Fortunately, these routers can have hardware acceleration modules that you can add to dramatically improve the router’s ability to perform compression in a timely manner. For example, a Compression Advanced Integration Module (CAIM) is available to offload compression tasks from 2600 Series routers. These Quick Reference Sheets, however, focus on header compression. With header compression, a header typically is reduced from approximately 40 bytes in size to approximately 3 to 5 bytes [for Transport Control Protocol (TCP) header compression] or 2 to 4 bytes [for Real-Time Transport Protocol (RTP) header compression]. However, the routers technically are not doing compression. Rather, these routers cache information that does not change during a conversation, such as source and destination IP addresses and TCP/UDP port numbers. The compressed header then carries such information as UDP checksums and a session context ID (CID), which identifies which flow the packet is a part of. RTP Header Compression Compressed Header IP Headers 40 Bytes UDP RTP Voice Payload cRTP Voice Payload 2–4 Bytes Another QoS mechanism that is useful for slower link speeds is Link Fragmentation and Interleaving (LFI). Consider a 1500-byte data frame that is being sent out of a 64-kbps serial interface. The interface, in this case, needs 187 ms just to place that data frame on the wire. If a smaller packet were sitting behind that data frame (for example, a voice frame), that frame might have already experienced excessive “serialization” delay before it was ever placed on the wire. LFI mechanisms fragment larger payloads to specified fragment sizes and then interleave the smaller payloads in among the fragments, greatly reducing the serialization delay that is experienced by the smaller payloads. Link Fragmentation and Interleaving (LFI) V V V V D V D V D V D V D The three primary LFI mechanisms supported by Cisco are as follows: • Multilink PPP (MLP)—Used on PPP links • FRF.12—Used on Voice over IP over Frame Relay (VoIPovFR) links • FRF.11 Annex C—Used on Voice over Frame Relay (VoFR) links TCP and RTP Header Compression Although header compression has been supported in the IOS for some time, IOS 12.2(13)T introduced Class-Based Header (CB-Header) Compression, which allows you to configure compression using the three-step MQC approach. CB-Header Compression is the focus of these Quick Reference Sheets. QoS on Slow-Speed Links 167 Before configuring header compression, realize that header compression is most effective for slow links that are carrying packets with relatively small payloads, such as voice or Telnet traffic. CB-Header Compression can be configured from policy-map-class configuration mode with the following command: Router(config-pmap-c)#compression header ip [tcp | rtp] Note that if you do not specify tcp or rtp, this command performs both TCP and RTP header compression. Unlike previous versions of header compression, you do not need to specify the maximum number of simultaneous compressed sessions supported. With CB-Header Compression, the number of connections is determined automatically by the IOS. Consider the following CB-Header Compression example: Router(config)#class-map VOICE Router(config-cmap)#match protocol rtp Router(config-cmap)#exit Router(config)#policy-map COMPRESS Router(config-pmap)#class VOICE Router(config-pmap-c)#compression header ip rtp Router(config-pmap-c)#exit Router(config-pmap)#exit Router(config)#interface serial 0/1 Router(config-if)#service-policy output COMPRESS In this example, you are matching voice traffic (that is, RTP packets) using NBAR. Then, you are applying CB-Header Compression to those RTP packets with the COMPRESS policy-map. The policy-map is then applied outbound to interface serial 0/1. Because you configured header compression using the MQC approach, the same verification commands that you learned earlier (that is, show policy-map and show policy-map interface interface-identifier) are still applicable. Using MLP and FRF.12 for LFI The serialization delay goal that you have when configuring an LFI mechanism is in the range of 10 to 15 ms. To determine the serialization delay for a specific frame size on a specific link speed, use the following formula: Serialization Delay = (Frame_Size * 8) / Link_Speed The reason that you multiply the frame size by 8 is to convert bytes into bits. Consider a frame size of 512 bytes on a link speed of 128 kbps, as follows: Serialization Delay = (512 * 8) / 128 = 32 ms Although Cisco supports FRF.11 Annex C as an LFI mechanism for VoFR networks, these Quick Reference Sheets focus on the configuration of Multilink PPP (MLP) and FRF.12. First, consider the configuration of MLP. Multilink PPP, by default, fragments traffic. You can leverage that fact and run MLP, even over a single link. You perform the MLP configuration under a virtual multilink interface, and then you can assign one or more physical interfaces to the multilink group. The physical interface does not have an IP address assigned, but the virtual multilink interface does. Typically, you use a single interface as a member of the multilink group. Following is the syntax to configure MLP: Router(config)#interface multilink multilink_interface_number (Creates a virtual multilink interface.) Router(config-if)#ip address ip_address subnet_mask (Assigns an IP address to the virtual multilink interface.) Router(config-if)#ppp multilink 168 QOS Quick Reference Sheets (Configures fragmentation on the multilink interface.) Router(config-if)#ppp multilink interleave (Shuffles the fragments together.) Router(config-if)#ppp fragment-delay serialization_delay (Specifies how long it will take for a fragment to exit the interface, in milliseconds. Note that the IOS automatically calculates the appropriate packet size to meet the specified serialization delay.) Router(config-if)#encapsulation ppp (Enables ppp encapsulation on the physical interface.) Router(config-if)#no ip address (Removes the IP address from the physical interface.) Router(config-if)#multilink-group multilink_group_number (Associates the physical interface with the multilink group.) In the following example, the goal is to configure MLP on routers R1 and R2 so that you are achieving a serialization delay of 10 ms on their serial 0/0 interfaces. Multilink PPP S 0/0 S 0/0 R2 R1 10 ms Serialization Delay R1(config)#interface multilink 1 R1(config-if)#ip address 10.1.1.1 255.255.255.0 R1(config-if)#ppp multilink R1(config-if)#ppp multilink interleave R1(config-if)#ppp fragment-delay 10 R1(config-if)#exit R1(config)#interface serial 0/0 R1(config-if)#encapsulation ppp R1(config-if)#no ip address R1(config-if)#multilink-group 1 R2(config)#interface multilink 1 R2(config-if)#ip address 10.1.1.2 255.255.255.0 R2(config-if)#ppp multilink R2(config-if)#ppp multilink interleave R2(config-if)#ppp fragment-delay 10 R2(config-if)#exit R2(config)#interface serial 0/0 R2(config-if)#encapsulation ppp R2(config-if)#no ip address R2(config-if)#multilink-group 1 QoS on Slow-Speed Links 169 To verify the MLP configuration, you can use the show interfaces multilink interface-identifier command. The output from this command shows how many interleaves have been performed. Therefore, this is an excellent command to verify that MLP is indeed functioning. FRF.12 is configured as part of a Frame Relay map-class. Unlike MLP, where you can specify a desired serialization delay, with FRF.12, you must specify the size that you want to fragment frames to. As a rule of thumb, divide the line speed by 800 to get a fragment size that results in a 10-ms serialization delay. For example, on a 64,000-bps link, divide 64,000 by 800 to get 80. This means that if you specify a fragment size of 80, your fragments will have a serialization delay of 10 ms. Following is the syntax to configure FRF.12: Router(config)#map-class frame-relay name (Creates the map-class and enters map-class configuration mode.) Router(config-map-class)#frame-relay fragment fragment-size (Specifies the size to which FRF.12 will fragment frames. Note that the IOS does not automatically calculate the fragment size based on a specified delay, as the MLP mechanism did.) Router(config-if)#frame-relay traffic-shaping (Enables Frame Relay traffic shaping on the physical interface.) Router(config-if | config-subif)#frame-relay class name (Associates the map-class with an interface or a subinterface.) Router(config-fr-dlci)#class name (Associates the map-class with a Frame Relay DLCI.) In the following example, you configure FRF.12 to create a serialization delay of 10 ms on a link that is clocked at a rate of 64 kbps. The map-class then is applied to DLCI 101. Because FRF.12 is configured as a part of Frame Relay traffic shaping, you also specify a CIR of 64 kbps and a Bc of 640. FRF.12 Frame Relay Cloud R1 S 0/1.1 DLCI 101 CIR = 64 Kbps R1(config)#map-class frame-relay FRF12-EXAMPLE R1(config-map-class)#frame-relay cir 64000 R1(config-map-class)#frame-relay bc 640 R1(config-map-class)#frame-relay fragment 80 R1(config-map-class)#exit R1(config)#interface serial 0/1 R1(config-if)#frame-relay traffic-shaping R1(config-if)#interface serial 0/1.1 point-to-point R1(config-subif)#frame-relay interface-dlci 101 R1(config-fr-dlci)#class FRF12-EXAMPLE 170 QOS Quick Reference Sheets You can use the show frame-relay fragment command to view the fragment size that is being used. Also, use the show frame-relay pvc command to view the fragment size that is used on a particular DLCI. QoS Design Guidelines This section reviews, in a design context, many of the concepts presented earlier in these Quick Reference Sheets. For example, voice, data, and video applications each have unique design guidelines. These guidelines are examined in this section. Classification Review As a review, recall how you performed classification and marking early on in these Quick Reference Sheets. Using the three-step MQC approach, you saw how to classify traffic by such characteristics as an incoming interface, an access-list match, or an NBAR. The Network Based Application Recognition (NBAR) classification mechanism offered the most granular classification, because NBAR can look beyond Layer 3 or Layer 4 information, all the way up to Layer 7. Marking could then be done at Layer 2 or Layer 3 using markings such as CoS (at Layer 2), IP Precedence (at Layer 3), or DSCP (at Layer 3). Type of Service (ToS) Byte IPv4 Packet ToS Byte Inside an IPv4 header is a Type of Service (ToS) byte. The three left bits in that byte can be used to mark the packet with an IP Precedence value (0–7). Alternatively, the 6 left bits in the ToS byte can be used to mark the packet with a DSCP value (0–63). 1 2 3 4 5 6 7 8 IP Precedence DSCP Queuing Review Marking traffic alone does not change the behavior of the traffic. To influence the traffic’s behavior, you can use the following other QoS mechanisms: Queuing (for example, LLQ, CB-WFQ, and WRR) Congestion avoidance (for example, WRED and ECN) Compression (for example, TCP and RTP CB-Header Compression) Traffic conditioning (for example, CB-Policing and CB-Shaping) Link efficiency (for example, Link Fragmentation and Interleaving mechanisms such as MLP and compression mechanisms, such as RTP) With the coverage of each of these QoS mechanisms, you can now select the appropriate tool or tools for a specific application. For example, if you wanted to give specific traffic priority treatment, you could use LLQ on a router or WRR on certain Catalyst switch platforms. On a lower-speed WAN link, where bandwidth is scarce, you might choose to use TCP or RTP CB-Header Compression. In addition, you enable the appropriate LFI mechanism for the media that you are working with to reduce serialization delay that smaller payloads experience. • • • • •