|
|
Foundation TopicsThe Need for QoS on the LANLAN quality of service (QoS) is often misunderstood and overlooked. Thanks to conventional wisdom, most network administrators think that they do not require LAN QoS. If your plans include the addition of real-time applications, such as IP telephony or video conferencing, you should include a strategy for LAN QoS while you are in the planning stages of your project. This up-front planning can result in the perceived success or failure of your project in the eyes of the end users. This chapter explores the need for LAN QoS and discusses the following options available to you:
Buffer Overflow (Overrun)Suppose that is it 8:30 on a Monday morning. All of your fellow employees report to work, simultaneously power on their computers, and begin their day. Their traffic flows through the access layer switches and converge on the uplink port to the distribution layer switch. In the event that the uplink port is smaller than the input port, or the uplink port is oversubscribed, the buffer on the uplink port begins to fill, as shown in Figure D-1. Figure D-1. Buffer Overflow
For an instant, the buffer of the uplink port can become full, potentially causing packets to drop. In a typical TCP/IP data-networking environment, this is not a concern because the packet is retransmitted. In an environment comprised of real-time applications, such as IP telephony and video conferencing, instantaneous buffer overruns (overflows) can affect the quality of the voice or video streams. In a Cisco IP telephony environment, a G.729 digital signal processor (DSP) can rebuild up to 30 ms of lost voice. If the Cisco standard 20 ms per packet has been deployed, a single packet can be dropped without degrading voice quality; if two consecutive voice packets are lost, resulting in 40 ms of lost voice conversation, however, the algorithm cannot compensate, and a clip is heard in the conversation. In the event that the Real Time Protocol (RTP) stream carries a fax or modem conversation, a single packet results in a modem retrain, whereas two consecutive packets result in a dropped connection. By classifying the real-time applications on your LAN and scheduling the desired level of priority for each real-time application, you can avoid these problems; however, you cannot remedy the problem by adding bandwidth. QoS tools are required to manage these buffers to minimize loss, delay, and jitter. You must properly enable and configure QoS to set priority by matching a traffic flow with a desired queue or threshold. Bandwidth is not a substitute for LAN QoS! LAN QoS is a buffer management issue. Marking and ClassificationAs discussed in Chapter 4, "Classification and Marking," marking at Layer 2 takes place in the 3-bit User Priority field called the Class of Service (CoS), which resides inside an Ethernet header. The CoS field only exists inside Ethernet frames when trunking (either 802.1Q or Inter-Switch Link [ISL]) is used. The field can be used to set eight different binary values, which the classification features of other QoS tools can use. Figure D-2 shows the general location of the CoS field inside the 802.1q and ISL headers. Figure D-2. Class of Service Fields
As discussed in Chapter 4, Layer 3 marking takes place in the Type of Service (ToS) or Differentiated Services (DS) field in the IP Header. The IP Precedence and Differentiated Services Code Point (DSCP) fields can be marked with any valid binary value of either 3 or 6 bits, respectively. Chapter 2, "QoS Tools and Architectures," contains detailed discussion of the recommended values used in these two fields. Figure D-3 outlines the two fields and their positions inside an IP header. Figure D-3. IP Precedence and IP DSCP Fields
Layer 3-to-Layer 2 Classification MappingLayer 2 switches perform QoS features based on the CoS field within the Ethernet headers without regard for the markings within the IP header. As discussed in Chapter 4, when a packet exits a router interface that is not configured as an 802.1Q trunk, a CoS value does not exist. The receiving switch marks the packet with the default CoS value configured on the receiving port, typically 0, although the DSCP value may be expedited forwarding (EF). If the switch receiving the packet cannot classify on DSCP markings, this packet is classified as a best-effort packet, even if the intent was to provide prioritization. To solve this problem, you must map the Layer 3 marking to Layer 2 marking on the router, and perform trunking between the switch and the router, so that the Layer 2 switch can properly classify the received traffic. Without remapping, L2 switches cannot differentiate between traffic flows. Example D-1 shows the configuration necessary to map IP DSCP to CoS that enables the Layer 2 switch to prioritize traffic. This example also shows a CoS-to-IP DSCP map that allows the router to match incoming CoS values with DSCP values. Example D-1. DSCP-to-CoS Mappingclass-map cos3 match cos 3 ! class-map cos5 match cos 5 ! class-map EF match ip dscp EF ! class-map AF31 match ip dscp AF31 policy-map map-cos-to-dscp class cos5 set ip DSCP EF class cos3 set ip dscp af31 class class-default set ip dscp default ! policy-map map-dscp-to-cos class EF set cos 5 class AF31 set cos 3 class class-default set cos 0 ! interface FastEthernet0/0 ! interface FastEthernet0/0.1 encapsulation dot1Q 102 service-policy input map-cos-to-dscp service-policy output map-dscp-to-cos ! interface FastEthernet0/0.2 encapsulation dot1Q 2 native After classification has been established, QoS tools can be used to differentiate the traffic and direct the desired classification to the proper queue. Layer 2 QueuesAlthough queues on LAN switches behave similarly as compared with router queues, a slightly different perspective helps with understanding the problems solved by queuing on a LAN switch. Think of a Layer 2 queue as a bucket that buffers packets until they are transported. The larger the bucket, the more packets it holds. In a switch that has one queue, refered to as 1q, for example, all traffic is placed in this queue regardless of traffic classification and traffic is serviced on a first-in, first-out (FIFO) basis. If a packet arrives at the queue during a period of congestion, the packet may be dropped if the queue cannot hold additional packets. Using multiple queues on a switch interface allocates some of the finite number of switch buffers in each queue. You can protect the voice queue against the possibility of running out of buffers by putting delay-sensitive voice into one queue, and all else into another. A switch that has two queues, refered to as 2q, for example, has the capability to direct traffic matching a specific classification, such as voice traffic with a CoS value of 5, into one queue while directing other traffic that does not meet this critera into the other queue. Because voice packets are smaller and more predictable than data packets, classifying and scheduling high-priority traffic into this second queue decreases the likelihood that the second queue will expreience buffer overrun and discard the high-priority traffic. Keep in mind that each port has a finite amount of buffer space to support the buckets. One queue will take all of the buffer space, for instance, two queues will divide the buffer space into two parts, three queues divide the buffer space into three parts, and so on. If the buffer space is too small, it will not be effective in momentarily holding the traffic before transport. Because nonpriority queues are serviced in either a round-robin or a Weighted Round-Robin manner, there is no guarantee that the traffic in the buffer is transported next. This limitation can lead to instaneous buffer overrun for the classified traffic of the last example due to the smaller buffer size available. One remmedy for this situation is the introduction of a single strict-priority queue, refered to as 1pmeaning "one-priority queue." In a 1p queue, all traffic within the priority queue is prioritized over the traffic in a standard queue by being transported as it is received. For example, a switch configured with one priority queue and one standard queue, called 1p1q, can be configured to direct traffic matching a specific classification, such as voice traffic with a CoS value of 5, into the priority queue, ensuring immediate transport, while directing other traffic that does not meet this critera into the standard queue. Table D-1 defines a few of the Layer 2 queues available in Cisco Catalyst switches.
It is highly recommended that you place real-time applications into the priority queue. Drop ThresholdsDrop thresholds define the amount of the total Layer 2 buffer use that must be reached before a specified class of traffic is dropped. In other words, this is how much the bucket needs to fill before a decision is made to begin dropping traffic of a specific class. Some switches have one priority queue and one standard queue, for instance, with four drop thesholds on the nonpriority queue, refered to as 1p1q4t. For the traffic placed into the nonpriority queue, the four drop thresholds indicate which class of traffic, based on CoS, should be dropped most agresssively in the event that a percentage of the bucket fills. Table D-3 illustrates a possible configuration of the theshold values from the previous example.
After the queue has reached 50 percent of capacity, any traffic classified with CoS of 0 or 1 becomes drop candidates to avoid congestion. If the queue continues to fill in spite of the drops, at 60 percent of capacity any traffic classified with a CoS of 0, 1, 2, or 3 becomes drop candidates to avoid congestion. If the queue still continues to fill in spite of the drops, at 80 percent of capacity any traffic classified with a CoS of 0, 1, 2, 3, 4, or 5 becomes drop candidates to avoid congestion. At 100 percent of capacity, all traffic, regardless of classification, becomes drop candidates. Figure D-4 illustrates the drop thresholds. Figure D-4. Drop Thresholds
Thesholds provide an alternative to dividing the buffer space to add more standard queues, eliminating the risk of starving one queue while flooding another. Setting a drop theshold allows the entire buffer space to be used, decreasing the potential for instaneous buffer overrun for higher-priority traffic in the standard queue. Trust BoundriesAs discussed in Chapter 4, trust boundaries represent the point in the network that you begin to trust the packet markings. Establishing a trust boundary becomes increasingly important as PC network interface cards (NICs) gain the capability to mark traffic and alter the desired QoS design of your network. Figure D-5 shows a network that uses a trust boundary at the IP Phone. A trust boundary can also be configured on an access switch in the event that an IP Phone is not present. Figure D-5. Trust Boundaries
This allows the network administrator to mark the packet as close to the end of the network without trusting all the applications on the PCs. You can gain more granular control of QoS tools by Specifying which devices are trusted. Cisco Catalyst Switch QoS FeaturesCisco Catalyst switches offer a wide array of QoS tools to help configure QoS in the LAN to support real-time applications. The following sections discuss the QoS capabilities, and hardware components if applicable, of these Cisco Catalyst switches:
Catalyst 6500 QoS FeaturesThis section is not intended to be an exhaustive look at the Cisco Catalyst 6500. Although many options exist for this product, the scope of this discussion covers only the Qos features of the Catalyst 6500 as they relate to the prioritization of real-time applications such as IP telepehony. The 6500 architecture distributes the QoS features among the line cards, the Supervisor card, and the Policy Feature Card (PFC). To appreciate what is really happening in the 6500, you must first have a basic understanding of the line cards and Supervisor cards. Supervisor and Switching EngineThe type of supervisor and switching engine installed in your Catalyst 6500 determines the QoS feature set. As of this writing, there are four supervisor/switching engine combinations. Table D-4 outlines these.
Enter the show module command for the supervisor engine to display your switching engine configuration. The next several examples just provide a reference so that you can determine which cards are in your particular 6500 switch. Example D-2, for instance, shows the response of a Catalyst 6500 configured with a Supervisor II card, which includes the Policy Feature Card (PFC2) Layer 3 switching engine. Example D-2. show module of Catalyst 6500 with a Supervisor IICat6500>(enable) show module Mod Slot Ports Module-Type Model Sub Status --- ---- ----- ------------------------- ------------------- --- -------- 1 1 2 1000BaseX Supervisor WS-X6K-SUP2-2GE yes ok 15 1 1 Multilayer Switch Feature WS-F6K-MSFC2 no OK 2 2 2 1000BaseX Supervisor WS-X6K-SUP2-2GE yes standby 16 2 1 Multilayer Switch Feature WS-F6K-MSFC2 no OK Mod Module-Name Serial-Num --- ------------------- ----------- 1 SAD051307ER 15 SAD050814J3 2 SAD0421058D 16 SAD042106PB Mod MAC-Address(es) Hw Fw Sw --- -------------------------------------- ------ ---------- ----------------- 1 00-01-64-75-eb-ce to 00-01-64-75-eb-cf 2.2 6.1(3) 6.2(2) 00-01-64-75-eb-cc to 00-01-64-75-eb-cd 00-05-5f-0f-ec-80 to 00-05-5f-0f-ec-bf 15 00-05-5e-da-ee-00 to 00-05-5e-da-ee-3f 1.2 12.1(8a)E5 12.1(8a)E5 2 00-01-64-f8-38-ac to 00-01-64-f8-38-ad 0.310 6.1(2) 6.3(3) 00-01-64-f8-38-ae to 00-01-64-f8-38-af 16 00-02-fd-b1-0f-00 to 00-02-fd-b1-0f-3f 1.1 12.1(8a)E5 12.1(8a)E5 Mod Sub-Type Sub-Model Sub-Serial Sub-Hw --- ----------------------- ------------------- ----------- ------ 1 L3 Switching Engine II WS-F6K-PFC2 SAD051405TV 1.3 2 L3 Switching Engine II WS-F6K-PFC2 SAD04110B5E 0.305 Example D-3 shows the response of a Catalyst 6500 configured with a Supervisor IA card and the optional PFC card. Example D-3. show module of Catalyst 6500 with a Supervisor IA and Layer 3 PFC Switching EngineCat6500> (enable) show show module Mod Slot Ports Module-Type Model Sub Status --- ---- ----- ------------------------- ------------------- --- -------- 1 1 2 1000BaseX Supervisor WS-X6K-SUP1A-2GE yes OK 15 1 1 Multilayer Switch Feature WS-F6K-MSFC2 no OK 2 2 2 1000BaseX Supervisor WS-X6K-SUP1A-2GE yes standby 16 2 1 Multilayer Switch Feature WS-F6K-MSFC2 no OK Mod Module-Name Serial-Num --- -------------------- ----------- 1 SAD0433088P 15 SAD04360AJ8 2 SAD05030UEW 16 SAD05030Z4W Mod MAC-Address(Es) Hw Fw SW --- -------------------------------------- ------ ---------- ----------------- 1 00-d0-d3-3d-d2-3a to 00-d0-d3-3d-d2-3b 3.2 5.3(1) 6.3(3) 00-d0-d3-3d-d2-38 to 00-d0-d3-3d-d2-39 00-30-7b-4e-64-00 to 00-30-7b-4e-67-ff 15 00-03-6b-f1-2a-40 to 00-03-6b-f1-2a-7f 1.1 12.1(8a)E5 12.1(8a)E5 2 00-02-7e-f5-c8-7e to 00-02-7e-f5-c8-7f 7.1 5.3(1) 6.2(2) 00-02-7e-f5-c8-7c to 00-02-7e-f5-c8-7d 16 00-04-dd-f1-f0-80 to 00-04-dd-f1-f0-bf 1.2 12.1(8a)E5 12.1(8a)E5 Mod Subtype Sub-Model Sub-Serial Sub-Hw --- ----------------------- ------------------- ----------- ------ 1 L3 Switching Engine WS-F6K-PFC SAD04330KWZ 1.1 2 L3 Switching Engine WS-F6K-PFC SAD050315AR 1.1 Example D-4 shows the response of a Catalyst 6500 configured with a Supervisor IA card, which includes the Layer 2 switching engine. Example D-4. show module of Catalyst 6500 with a Supervisor IA and Layer 2 Switching EngineCat6500>(enable) show module Mod Slot Ports Module-Type Model Sub Status --- ---- ----- ------------------------- ------------------- --- -------- 1 1 2 1000BaseX Supervisor WS-X6K-SUP1A-2GE yes ok 2 2 2 1000BaseX Supervisor WS-X6K-SUP1A-2GE yes standby Mod Module-Name Serial-Num --- ------------------- ----------- 1 SAD050404KM 2 SAD05040EC2 Mod MAC-Address(es) Hw Fw Sw --- -------------------------------------- ------ ---------- ----------------- 1 00-02-7e-27-17-f6 to 00-02-7e-27-17-f7 7.0 5.3(1) 5.5(9) 00-02-7e-27-17-f4 to 00-02-7e-27-17-f5 00-d0-03-8c-9c-00 to 00-d0-03-8c-9f-ff 2 00-01-64-75-80-16 to 00-01-64-75-80-17 7.0 5.3(1) 5.5(9) 00-01-64-75-80-14 to 00-01-64-75-80-15 Mod Sub-Type Sub-Model Sub-Serial Sub-Hw --- ----------------------- ------------------- ----------- ------ 1 L2 Switching Engine II WS-F6020A SAD05030WR5 2.0 2 L2 Switching Engine II WS-F6020A SAD05030VZH 2.0 Policy Feature CardCisco 6500 QoS features differ based on whether a PFC is installed and on other configuration options. For instance, the Layer 2 switching engine on the Supervisor I or Supervisor IA classifies, marks, and schedules traffic based on destination Media Access Control (MAC) address or VLAN tag information. Without the optional PFC, all marking of packets by the Layer 2 switching engine takes place in the CoS field. A Layer 2 switching engine does not examine the IP header, and so markings in the IP Precidence and DSCP fields are ignored. With the addition of the PFC, the Catalyst 6500 is capable of enabling advanced QoS tools such as packet classification and marking, scheduling, and congestion avoidance based on either Layer 2, 3, or 4 header information. Specifically, the PFC can perform classification and marking, and policing. The line cards perform queuing and packet-drop logic. The PFC performs the actual packetforwarding process, effectively making it a Layer 3 switching engine. The PFC can examine the Layer 2 and Layer 3 headers as the packet arrives. If the destination IP adress exists in the flow cache, for PFC cards, or the Cisco Express Forwarding (CEF) Forwarding Information Base (FIB), for PFC2 cards, the PFC can rewrite the following five header fields:
The Layer 2 (MAC) checksum (also called the frame checksum or FCS) allows the packet to retain the original Layer 2 and Layer 3 QoS markings. In the event that the IP destination does not exist in the flow cache, or CEF FIB, the first packet of the flow is forwarded to the Multilayer Switch Feature Card (MSFC) to route the packet to the correct interface. The routing decision populates the flow cache or CEF FIB for subsequent packets; however, the first routed packet loses the original CoS marking. All subsequent packets are switched by the PFC and retain their original Layer 2 and Layer 3 markings. Although the PFC and PFC2 are both Layer 3 switching engines, they differ in a few ways, as listed in Table D-5.
After a flow has been established, the PFC has the capability to use a QoS access list to police traffic to reduce the flow of traffic to a predefined limit. Traffic in excess of that limit can be dropped or have the DSCP value in the frame marked down to a lower value. A QoS access-control list (ACL), consisting of a list of acess-control entries (ACEs), defines a set of QoS rules that the PFC uses to process incoming frames. ACEs are similar to a router ACL. The ACE defines classification, marking, and policing criteria for an incoming frame. If an incoming frame matches the criteria set in the ACE, the QoS engine processes the frame. Ethernet InterfacesThe QoS role of Ethernet interfaces in a Catalyst 6500 includes the scheduling of packets and congestion management, as well as providing inline power to support the addition of real-time applications such as IP telephony. It is important to understand the capabilities of the Ethernet modules in your Catalyst to properly provision your network for the addition of real-time applications. Table D-6 illustrates the QoS advantage that the current generation of Ethernet modules, typically the WS-X65xx series of cards, offers over the past generation of Ethernet modules, typically the WS-X63xx series of cards. Table D-6 shows a comparision of the 48-port Ethernet modules.
The show port capabilities command enables you to display QoS information about a particular port or modules. Example D-5 displays the QoS capabilities of a supervisor IA card and a WSX6248-RJ-45 card. Example D-5. show port capabilities CommandCAT6K> (enable) show port capabilities 1/1 Model WS-X6K-SUP1A-2GE Port 1/1 Type 1000BaseSX Speed 1000 Duplex full Trunk encap type 802.1Q, ISL Trunk mode on, off, desirable, auto, nonegotiate Channel yes Broadcast suppression percentage(0-100) Flow control receive-(off, on, desired), send-(off, on, desired) Security yes Dot1x yes Membership static, dynamic Fast start yes QOS scheduling rx-(1p1q4t), tx-(1p2q2t) CoS rewrite yes ToS rewrite DSCP UDLD yes Inline power no AuxiliaryVlan no SPAN source, destination COPS port group 1/1-2 Link debounce timer yes CAT6K> (enable) CAT6K> (enable) show port capabilities 2/1 Model WS-X6248-RJ-45 Port 2/1 Type 10/100BaseTX Speed auto, 10,100 Duplex half, full Trunk encap type 802.1Q, ISL Trunk mode on, off, desirable, auto, nonegotiate Channel yes Broadcast suppression percentage(0-100) Flow control receive-(off, on), send-(off) Security yes Dot1x yes Membership static, dynamic Fast start yes QOS scheduling rx-(1q4t), tx-(2q2t) CoS rewrite yes ToS rewrite DSCP UDLD yes Inline power no AuxiliaryVlan 1..1000,1025..4094, untagged, dot1p, none SPAN source, destination COPS port group 2/1-48 Link debounce timer yes CAT6K> (enable) The WS-X65xx series of Ethernet cards introduce a priority queue and extend the buffer sizes to better accommodate traffic during times of congestion. In a side-by-side comparison, it is plain to see that the WS-65xx series of Ethernet line cards are the better choice for QoS. The uplink Gigabit Ethernet ports on the Supervisor I support a single receive queue with four thresholds (1q4t) and two transmit queues with two thresholds (2q2t). The uplink Gigabit Ethernet ports on the Supervisor IA and the Supervisor II cards include enhanced QoS features that provide an additional priority queue for both ingress (1p1q4t) and egress (1p2q2t) interfaces. These queues are serviced in a WRR method, except for the priority queue, which is always serviced as soon as frames have entered the queue. Table D-7 lists the TX and RX queues supported by each supervisor engine.
The addition of the priority queue on the Supervisor IA and Supervisor II offers an advantage for providing QoS for real-time applications over Supervisor I. Ingress and egress scheduling are always based on the CoS value associated with the frame. By default, higher CoS values are mapped to higher queue numbers. CoS 5 traffic, typically associated with Voice over IP (VoIP) traffic, is mapped to the strict-priority queue, if present. In addition to the different queues, each standard queue has one or more drop thresholds. There are two types of drop thresholds:
Enter the show qos info config [mod/port] command to determine whether your Catalyst switch port supports WRED. In Example D-6, the show qos info config command shows that port 2/1 does not support WRED. Example D-6. show qos info config CommandCat6500> show qos info config 2/1 QoS setting in NVRAM: QoS is enabled Port 2/1 has 2 transmit queue with 2 drop thresholds (2q2t). Port 2/1 has 1 receive queue with 4 drop thresholds (1q4t). Interface type:vlan-based ACL attached: The qos trust type is set to untrusted. Default CoS = 0 Queue and Threshold Mapping: Queue Threshold CoS ----- --------- --------------- 1 1 0 1 1 2 2 3 2 1 4 5 2 2 6 7 Rx drop thresholds: Rx drop thresholds are disabled for untrusted ports. Queue # Thresholds - percentage (abs values) ------- ------------------------------------- 1 50% 60% 80% 100% Tx drop thresholds: Queue # Thresholds - percentage (abs values) ------- ------------------------------------- 1 40% 100% 2 40% 100% Tx WRED thresholds: WRED feature is not supported for this port_type. Queue Sizes: Queue # Sizes - percentage (abs values) ------- ------------------------------------- 1 80% 2 20% WRR Configuration of ports with speed 1000MBPS: Queue # Ratios (abs values) ------- ------------------------------------- 1 100 2 255 QoS Flow on the Catalyst 6500Now that you have an understanding of the various hardware options available on the Catalyst 6500 as they relate to QoS, we can begin to discuss the QoS flow as the frames are received and forwarded through the switch. Figure D-6 shows the QoS flow overview. Figure D-6. QoS Flow Overview
The frame arrives at the switch Ethernet ingress port. The existing frame marking, Ethernet ingress queuing structure, and the current trust state of the ingress Ethernet port determine the level of service the frame receives. After the ingress queue and threshold have been determined, the ingress port forwards the frame to the Layer 2 switching engine, or the PFC Layer 3 switching engine if one is installed. When the supervisor does not have a PFC, the Layer 2 switching engine forwards the packet to the egress Ethernet port. The egress switch port uses the CoS marking on the frame to determine the queue that is used for the frame as it exits the switch. When the supervisor does have a PFC, the PFC consults its cache to determine whether it has a known path to the destination address. If the path exists in the cache, the PFC forwards the packet to the correct egress port. Because the PFC can operate at Layer 3, it has the capability to switch the packet between VLANs without losing the Layer 2 CoS markings, so the frame retains its CoS marking, and the packet retains its DSCP or IP precedence marking. In the event that the PFC does not have the path in cache, the packet is forwarded to the MSFC to determine which Ethernet egress port to use. When the MFSC makes a routing decision, and determines the correct Ethernet egress port needed to reach the destination address, the PFC populates its cache with this information for future use. This means the first packet in a flow loses the CoS value, because the first packet is routed at Layer 3 across the MSFC. However, subsequent packets are switched by the PFC and retain their original marked values. After the egress Ethernet port has been identified, the packet is assigned to the proper queue and threshold indicated by the Layer 2 or Layer 3 markings on the packet. Ingress Queue SchedulingThe first opportunity for applying any kind of QoS tool to an incoming frame occurs when the frame enters the switch. Even before the supervisor or PFC forwards the frame to the egress line card, ingress QoS features occur. For instance, ingress queue scheduling defines the treatment that a frame or packet receives as it enters the switch. If QoS has been enabled, and the ingress port is trusted, the switch uses receive queue drop thresholds to schedule the arriving frames. Figure D-7 shows the treatment received by the frame or packet in the ingress queue. Figure D-7. Ethernet Ingress Port Treatment
The first variable encountered as the frame enters the switch is trust. This asks the questions "Where is our trust boundary? Do we want to trust the markings on a frame as it enters the switch on this port?" If the port is untrusted, there is no need to continue to classify the frame. The ingress port just applies the configured port QoS value, typically 0, and forwards the frame to the switching engine. If the port is trusted, the next questions asked are "Is this an 802.1Q or ISL trunk port? Does the incoming frame have an 802.1Q or ISL header?" If this ingress Ethernet port is not a trunk port, the configured port CoS value is assigned to the frame. If this ingress Ethernet port is configured as a trunk port, the CoS value marked on the frame is trusted. The next question depends on the hardware installed in the switch. If a PFC has been installed, the switch has the capability to classify and mark traffic based on Layer 3 markings, and so the question is asked "Do we want to trust IP precedence or DSCP from packets entering this Ethernet ingress port?" If the answer is yes, the packet is forward to the PFC. If we do not want to trust the Layer 3 markings, the switch relies on the CoS value to determine the correct queue and threshold. After the proper queue and threshold has been identified, the question is asked "Is there room in the ingress queue for this frame, or has the drop threshold for this CoS value been met?" If the threshold has been met, the frame is dropped, otherwise the frame is forwarded on to the switching engine. If a PFC is not installed in the Catalyst switch, the frame flows to the Layer 2 switching engine, otherwise the frame is passed to the Layer 3 switching engine (PFC). Layer 2 Switching Engine QoS Frame FlowThe Layer 2 switching engine has few options for classification and marking because it operates on the Layer 2 network. Figure D-8 shows the options available. Figure D-8. Layer 2 Switching Engine Classification and Marking
The Layer 2 switching engine receives the frame from the ingress Ethernet port. The only variable that the Layer 2 switching engine has is the destination MAC address / VLAN match. If the arriving/ received frame matches this criteria, the CoS value can be overwritten. If the received frame does not match this criteria, the frame is forwarded to the egress Ethernet port, retaining the received CoS value. Layer 3 Switching Engine QoS Packet FlowThe PFC has the capability to classify, mark, and police traffic based on both Layer 2 and Layer 3 elements. The PFC also introduces the concept of QoS ACLs, which can be used for granular control over QoS configurations. Figure D-9 illustrates the flow of a frame or packet through a PFC. Figure D-9. Layer 3 Switching Engine Classification, Marking, and Policing
As the packet arrives at the PFC, the ingress interface or the ingress VLAN is examined to see whether an ACL is applied. If an ACL is not applied to either the ingress port or the ingress VLAN, the packet uses the default ACL. The default IP ACL consists of a single ACE that has a configurable marking rule and configurable policing rules. If the default ACL has not been configured, the ACE in the default ACL applies a DSCP value of 0 to all traffic passed from ingress ports configured with the untrusted port keyword. If an ACL is applied to the port or VLAN, the ACL examines the ACEs to see whether any entries match the arriving packet. The PFC uses a DSCP setting for each IP packet that it processes. The PFC asks itself, "Do we trust the DSCP, IP precedence, or CoS values on the frame?" If these values are not trusted, the DSCP value specified in the default ACL is used. If these values are trusted, the switch uses the DSCP values received. For IP precedence and CoS values, the PFC uses an internal DSCP value generated from the IP precedence-to-DSCP or the CoS-to-DSCP mappings, respectively. If policing has been enabled, the PFC determines the current traffic rate and decides to drop the packet, re-mark the packet, or place the packet in the egress queue unchanged. If the packet is destined for the egress queue, the CoS value is derived from the DSCP value before the packet is delivered. Egress Queue SchedulingEgress queue scheduling defines the treatment that a frame or packet receives as it exits the switch. Figure D-10 shows the treatment received by the frame or packet in the egress queue. Figure D-10. Ethernet Egress Port Treatment
As the frame arrives at the egress queue, the CoS value is examined to determine the proper queue and threshold for the egress interface type. In this example, the switch has three different queues that a frame can be placed in: 2q2t, 1p2q2t, and 1p3q1t. The CoS value determines the proper egress queue. After the proper queue and threshold has been identified, the question is asked "Is there room in the egress queue for this frame or has the drop threshold for this CoS value been met?" If the threshold has been met, the frame is dropped; otherwise the frame is placed in a queue to await transport. If the PFC has forwarded the frame into the egress queue, the IP DCSP value and CoS value is set as the frame is placed in the proper transmit queue. If the frame is an 802.1Q or ISL trunk frame, only the CoS value is set as the frame is placed in the proper transmit queue. Catalyst 6500 QoS SummaryThe numerous hardware options available on the Catalyst 6500 offer a wide range of customization. This section summarizes the impact of the hardware choices on the QoS performance of a Catalyst 6500 series switch. Table D-8 summarizes the QoS processes of the Catalyst 6500 and lists the component responsible for the function.
Table D-9 describes the supported receive queues of the Catalyst 6500.
Table D-10 describes the supported transmit queues of the Catalyst 6500.
Table D-11 lists the supported receive and transmit queues of the Ethernet modules for the Catalyst 6500.
Cisco Catalyst 4500/4000 QoS FeaturesThe Catalyst 4500 and 4000 series switches are modular and scalable, making these switches an excellent choice for wiring-closet installations, branch offices, Layer 3 distribution, or Layer 3 core installations for small and medium-sized networks. The modular design enables you to configure the switch based on the needs of your network. The addition of inline power positions the Catalyst 4500 and 4000 series switch as a natural choice for supporting devices that can take advantage of this feature, such as IP telephony and wireless access points. QoS configuration on a Catalyst 4500 or Catalyst 4000 series switch depends on the supervisor engine module installed in the switch. Four supervisor engine modules are currently available for the Catalyst 4500 and Catalyst 4000 series of switches. Table D-12 lists the 4500/4000 Catalyst switches that support each supervisor engine model.
Supervisor Engine I and IIThe Supervisor Engine I and Supervisor Engine II modules use the Cisco Catalyst operating system. With the Supervisor Engine I and Supervisor Engine II module, the Catalyst 4500 and 4000 series switches have a single receive queue serviced in a FIFO order. The transmit queue consists of two standard queues with a single drop threshold (2q1t). The two standard queues are scheduled on a round-robin basis. Admission to the queues is based on the 802.1p CoS value of the frame; however, the Catalyst switch with the Supervisor Engine I or the Supervisor Engine II module only examines 2 of the 3 CoS bits to determine the CoS value of a frame. This limitation means that CoS values must be mapped in pairs. To map a CoS value of 5 to the second queue, for instance, both CoS values of 4 and 5 must be mapped to Queue 2. When QoS is enabled globally, but without any other configuration, CoS values 0 though 7 are assigned to Queue 1, whereas broadcast and multicast traffic is assigned to Queue 2. This can lead to performance degradation, because most user traffic (unicast traffic) ends up in a single queue. Therefore, it is useful to configure the switch to put some unicast traffic in the second queue. (The configuration required to remap CoS values to the second queue is discussed in the "CoS-to-Egress Queue Mapping for the Catalyst OS Switch" section of this chapter.) Table D-13 lists the default queue assignment for the Catalyst 4500/4000 with a Supervisor I or II after QoS has been enabled.
Trust on a Catalyst 4500/4000 Supervisor I or II is based on the QoS state. If QoS is enabled, the switch trusts all CoS values received on all ports. Table D-14 lists the available QoS features of a Catalyst 4500/4000 with a Supervisor II Engine.
Supervisor Engine III and IVThe Supervisor Engine III and Supervisor Engine IV modules use the Cisco IOS operating system. The Supervisor Engine III and the Supervisor Engine IV modules introduce many enhanced QoS features to the Catalyst 4000 and Catalyst 4500 series switches. The transmit queue on both the Supervisor Engine III module and the Supervisor Engine IV module includes one priority queue and three standard queues with a single threshold (1p3q1t). By default, voice bearer traffic (typically marked as CoS 5 or DSCP 46) is mapped to the strict-priority queue, which resides in Queue 3. The standard queues are serviced on a WRR basis. Admission to the queues is based on internal IP DSCP values. The Supervisor Engine III and the Supervisor Engine IV modules support a global mapping of these internal DSCP valuesdetermined by input packet QoS state, port trust configuration, and policingto output queues. Table D-15 lists the default queue assignment for the Catalyst 4500/4000 with a Supervisor III or IV.
By default, all ports on a catalyst 4500/4000 are in the untrusted state after QoS has been enabled. Trust is enabled on a per-port basis, allowing more granular QoS control over the Supervisor I or II Engines. The Supervisor III and IV also add the capability to extend trust to the ASICs in the IP Phones, allowing the switch to trust the IP Phones, without having to trust the attached PC. Because the Catalyst 4500/4000 Supervisor III and IV use the Cisco IOS operating system, they have the capability to classify traffic based on standard and extended IOS ACLs. This allows the switch to define traffic flows based on characteristics other than CoS, IP DSCP, or IP precedence, such as TCP port number, source address, and destination address. The Supervisor Engine IV introduces an additional QoS feature called dynamic buffer limiting (DBL). DBL manages misbehaving traffic flows by tracking the buffering for each traffic flow and limiting the flow if excessive demands are placed on a buffer. A misbehaving flow is defined as a flow that uses all available bandwidth, consumes switch buffers, fills output queues, and does not respond to congestion feedback such as Random Early Detection (RED). A flow is defined as a source IP address, destination IP address, IP protocol, Layer 4 Transmission Control Protocol/User Datagram Protocol (TCP/UDP) ports, and VLAN. If the buffer usage of a flow exceeds a dynamically computed buffer limit, DBL constrains the flow's buffering until the flow reaches a lower threshold. DBL is implemented at wire speed on all ports in the Catalyst family with Supervisor Engine IV. The Supervisor Engine III and Supervisor Engine IV modules offer more granular control of QoS than their predecessors, which makes the newer modules a preferred choice for networks that carry real-time applications. Table D-16 lists the available QoS features of a Catalyst 4500/4000 with a Supervisor III of IV engine.
Cisco Catalyst 3550 QoS FeaturesThe Catalyst 3550 family of switches supports enhanced QoS features that can be used in the access and distribution layers. The transmit queue on the 3550 series of switches includes one priority queue, which resides in Queue 4, and three standard queues with a single threshold (1p3q1t). Scheduling is done on a WRR basis, where each queue is given a relative weight, while the priority queue is serviced exhaustively. The default is WRR only. If priority scheduling is required, it must be explicitly enabled. Admission to the queues is based on IP DSCP, 802.1p CoS, or port-priority CoS. Table D-17 describes the default queue admission criteria.
Similar to the Catalyst 4500/4000 Supervisor III or IV, all ports on the Catalyst 3550 are in the untrusted state after QoS has been enabled. Trust is enabled on a per-port basis. The Catalyst 3550 also has the capability to extend trust to the ASICs in the IP Phones, allowing the switch to trust the IP Phones without having to trust the attached PC. The Catalyst 3550 also has the capability to classify and mark traffic on ingress to the network using standard and extended IOS ACLs. The Catalyst 3550's capability to identify traffic flows at Layer 3 and Layer 4 using ACLs makes it very powerful as an access layer switch. Table D-18 lists the available QoS features of a Catalyst 3550.
Cisco Catalyst 3524 QoS FeaturesThe available inline power, ease of configuration, and priority queuing capabilities have made the Catalyst 3524 switch a popular Layer 2 switch for IP telephony deployments. Although the 3524 has been replaced with the 3550-24PWR for future deployments, the number of deployed 3524 switches warrants a brief discussion of its QoS features. QoS is enabled by default on the Catalyst 3524 switch. The transmit queue on the Catalyst 3524 series of switches includes one priority queue and one standard queue (1p1q). By default, voice bearer traffic (typically marked as CoS 5) is mapped to the strict-priority queue, which resides in Queue 2. Table D-19 describes the default queue admission criteria.
The 3524 trusts the CoS values received on each port by default and places the traffic in the appropriate queue based on the CoS value received. However, the Catalyst 3524 does offer the capability to extend the trust to the ASICs on IP Phones, thereby trusting the IP Phones without having to trust the attached PC. Table D-20 lists the available QoS features of a Catalyst 3524.
QoS Configurations on Catalyst SwitchesSeveral factors determine the configuration of a Cisco Catalyst switch. It is important to fully understand the QoS requirements that are needed to support the applications on your network before adding real-time applications such as voice and video. Ask yourself the following questions:
After you understand the QoS LAN requirements, you can begin to examine the configuration steps necessary to meet the requirements. The following configuration sections describe QoS configurations on Catalyst OS and IOS switches in both the distribution and access layer of your network. These configurations are based on Cisco QoS Solution Reference Network Design (SRND), which you can find on the Cisco website at the following link: www.cisco.com/warp/customer/771/srnd/qos_srnd.pdf Configuration of a Catalyst Switch Using Catalyst OSThis section explores the configuration of a Catalyst OS switch in the access and distribution layers. Assume that your IP telephony network is configured as depicted in Figure D-11. Figure D-11. Catalyst OS Switch
In this example, CallManager 1 is connected to port 5/1, CallManager 2 is connected to port 5/2, and 48 IP Phones are connected to ports 2/1 through 2/48, respectively. Each IP Phone has a PC attached to the IP Phone switch port. An IP video server is also connected to port 5/10. The Catalyst 6500 and 4000 with Supervisor I or II are examples of Catalyst OS switches. The QoS required to minimize delay, jitter, and packet drops for these switches can be broken down into the following tasks:
Configuring Auxiliary VLANs for a Catalyst OS SwitchThe first step in configuring QoS for the access layer is separating the voice traffic from the data traffic. Cisco IP Phones have the capability to use 802.1Q trunks to accomplish this task. The IP Phone can tag the voice traffic with a VLAN identifier, while leaving the data traffic in the native, or untagged, VLAN. The switch must be configured to participate in the 802.1Q trunk from the IP Phone. This is achieved with the set port auxiliaryvlan command. Example D-7 shows the auxiliary VLAN of 110 being set for ports 2/1 through 2/48. Example D-7. Creating Auxiliary VLANsCatOS> (enable) set port auxiliaryvlan 2/1-48 110 AuxiliaryVlan Status Mod/Ports 110 active 2/1-48 CatOS> (enable) In this example, switch ports 2/1 through 2/48 have been configured to participate in the 802.1Q trunk from the phones using VLAN 110 for the tagged VLAN that will carry the voice traffic. Configuring QoS for the Catalyst OS SwitchQoS must be enabled globally within the switch to use the multiple queues desired. This is achieved with the set qos enable command, as shown in Example D-8. Example D-8. Enabling QoSCatOS> (enable) set qos enable QoS is enabled. CatOS> (enable) In this example, QoS has been enabled on the Catalyst OS switch. After QoS has been enabled, it can be configured on a specific port or on a per-VLAN basis. Configuring QoS on a port applies QoS to only the specified port, whereas configuring QoS on a VLAN applies the QoS configuration to all ports that reside in that VLAN. The set port qos command is used to associate QoS configuration with a specific port or a VLAN. Example D-9 assigns VLAN QoS configuration to ports 2/1 through 2/48 based on VLAN membership. Example D-9. Associating QoS with a VLANCatOS> (enable) set port qos 2/1-48 vlan-based Hardware programming in progress... QoS interface is set to vlan-based for ports 2/1-48. CatOS> (enable) In Figure D-11, all IP Phones reside on ports 2/1 through 2/48. The set port qos 2/1-48 vlan-based command associates all QoS configuration for these ports on a per-VLAN basis. Any previous QoS configuration attached to the specific ports are removed. Enabling QoS based on VLAN membership works well for IP telephony because IP Phones typically share the same VLAN membership. However, what if you need to enable QoS for a separate device that does not share the same VLAN, yet needs to have QoS enabled, such as a video server in port 5/10? Example D-10 assigns QoS configuration to the specific port 5/10. Example D-10. Associating QoS with a Port
CatOS> (enable) set port qos 5/10 port-based
Qos interface is set to port-based for ports 5/10
CatOS> (enable)
CoS-to-Egress Queue Mapping for the Catalyst OS SwitchBy default, Cisco IP Phones mark voice bearer traffic with a CoS of 5 and voice signaling traffic with a CoS value of 3. The Catalyst 6500 places traffic marked with a CoS value of 5 into the priority queue on 1p2q2t interfaces and Queue 2 on 2q2t interfaces when QoS is enabled. However, you must perform the additional step of configuring the Catalyst 6500 CoS queue mapping to ensure that traffic with a CoS of 3 is placed into the second queue. Example D-11 maps call control traffic, a CoS value of 3, to Queue 2 threshold 1 on a 2q2t interface. Example D-11. Map CoS Value of 3 to Queue 2 Threshold 1 for 2q2t
Cat65k> (enable) set qos map 2q2t tx 2 1 cos 3
QoS tx priority queue and threshold mapped to cos successfully.
Cat65k> (enable)
Example D-12 shows call control traffic, a CoS value of 3, to Queue 2 threshold 1 on a 1p2q2t interface. Example D-12. Map CoS Value of 3 to Queue 2 Threshold 1 for 1p2q2t
Cat65k> (enable) set qos map 1p2q2t tx 2 1 cos 3
QoS tx priority queue and threshold mapped to cos successfully.
Cat65k> (enable)
Unlike the Catalyst 6500, the Catalyst 4000 places all packets, regardless of CoS values, in the first queue after QoS has been enabled. Also the Catalyst 4000 must map CoS values to a queue in pairs. In Example D-13, CoS values of 0 and 1 have been mapped to Queue 1, whereas CoS values of 2 through 7 have been mapped to Queue 2. Example D-13. Mapping CoS Values 2 Through & to Queue 2 Threshold 1Cat4k> (enable) set qos map 2q1t 1 1 cos 0-1 Cat4k> (enable) set qos map 2q1t 2 1 cos 2-3 Cat4k> (enable) set qos map 2q1t 2 1 cos 4-5 Cat4k> (enable) set qos map 2q1t 2 1 cos 6- Layer-2-to-Layer 3 MappingCisco follows the recommended standard for setting the DSCP classification values for both the VoIP call control traffic and VoIP bearer traffic. The recommended settings are DSCP = AF31 (or decimal 26) for VoIP call control and DSCP = EF (or decimal 46) for VoIP bearer traffic. By default, the CoS-to-DSCP mapping does not match this recommendation, as shown in Table D-21.
To map the Layer 2 CoS and Layer 3 IP precedence settings correctly to these DSCP values, you must modify the default CoS/ToS-to-DSCP mappings. Example D-14 demonstrates the configuration required for the CoS-to-DSCP mappings. Example D-14. Modifying the CoS-to-DSCP Mappings
CatOS> (enable) set qos cos-dscp-map 0 8 16 26 34 46 48 56
QoS cos-dscp-map set successfully.
CatOS> (enable)
Example D-15 demonstrates the configuration required for the IP precedence-to-DSCP mappings. Example D-15. Modifying the IP Precedence-to-DSCP Mappings
CatOS> (enable) set qos ipprec-dscp-map 0 8 16 26 32 46 48 56
QoS ipprec-dscp-map set successfully.
Console > (enable)
Configuring Trust Boundaries for a Catalyst OS SwitchTrust boundaries define the point in the network where CoS, IP precedence, or DSCP markings are trusted. Typically this trust is established at the ingress switch port of the access layer switch. After QoS has been enabled, all ports on a Catalyst 6500 are in the untrusted state. This means that any CoS value received by the switch is re-marked with a value of 0. By contrast, after QoS has been enabled on a Catalyst 4000 switch, all ports are in a trusted state, meaning that all CoS values received are trusted on every port. Therefore, the rest of this section discussing trust excludes the Catalyst 4000. Example D-16 demonstrates the configuration required to instruct the Catalyst 6500 access layer switch to trust the CoS values received on the 802.1Q trunks that connect to the IP Phones. Example D-16. Enabling Trust of CoSCatOS> (enable) set port qos 2/1-48 trust trust-cos Trust type trust-cos not supported on port(s) 2/1-48 Receive thresholds enabled on ports(s) 2/1-48 Trust type set to untrusted on port(s) 2/1-48 CatOS> (enable) On all 63xx series 10/100 Ethernet line cards with 1q4t ports, the trust-cos port keyword displays an error message stating that trust-cos is not supported. This configuration must be entered to activate the receive queue drop thresholds; however, the trust state of the ports will remain untrusted. You must configure a trust-cos ACL to match the ingress traffic to successfully apply the trust-cos trust state. This ACL is discussed in the "Configuring QoS Access Lists on a Catalyst OS Switch" section. The 65xx series 10/100 Ethernet line cards do not have this issue. A Layer 3 6500 switch offers the capability to classify traffic flows based on IP header information, such as IP precedence and DSCP markings. This can prove useful for end devices that do not have the capability to use 802.1Q or ISL trunks, but can manipulate the IP header fields. In Figure D-11, CallManager 1 is connected to port 5/1, and CallManager 2 is connected to port 5/2. Either of the following configurations shown in Examples D-17 or D-18 can be added to the switch to prioritize CallManager traffic using IP hearer information. Example D-17. Enabling Trust of DSCP
CatOS> (enable) set port qos 5/1-2 trust trust-dscp
Port 5/1-2 qos set to trust-dscp.
CatOS> (enable)
Example D-18. Enabling Trust of IP Precedence
CatOS> (enable) set port qos 5/1-2 trust trust-ipprec
Port 5/1-2 qos set to trust-ipprec.
CatOS> (enable)
The trust-ipprec and trust-dscp keywords are supported only with a Layer 3 switching engine. Although the trust command determines whether the received markings are trusted on the ingress switch port, the trust-ext command has little to do with the ingress switch port. The trust-ext command determines how the ASIC on the IP Phone handles the CoS value presented by the attached PC. If the trust-ext command is trusted, the original CoS value presented by the PC to the phone is passed to the switch intact. If the trust-ext command is untrusted, the CoS value presented by the PC is rewritten to a value of 0. In a typical IP telephony deployment, trust should not be extended to a PC. Be cautious if your design includes extending trust to a PC. If you trust one application on a PC, by default you trust all applications on that PC. This can lead to unintentional voice-quality degradation. Example D-19 shows the trust-ext configuration of a typical IP telephony deployment. Example D-19. Configuring trust-ext
CatOS> (enable) set port qos 2/1-48 trust-ext untrusted
Qos trust extension for ports 2/1-48 set to untrusted.
CatOS> (enable)
Configuring Untagged Frames for the Catalyst OS SwitchWhat if the end device does not support 802.1Q or ISL trunks? How do you prioritize the traffic of this device? The addition of a Layer 3 switching engine allows the Catalyst to use IP precedence or DSCP to classify this traffic, but what if you do not have a Layer 3 switching engine or you would still prefer to mark the traffic with a CoS value? You can achieve this by setting the CoS value on the ingress switch port. By doing this, you are telling the switch to mark any frame received on this port with a specific CoS value. Even though the actual received frame may not have even had an ISL or 802.1Q header, the switch can process the frame as if it had a CoS value set, based on configuration. In the sample network, for instance, CallManager 1 is connected to port 5/1, and CallManager 2 is connected to port 5/2. Example D-20's configuration can be added to the switch to prioritize CallManager traffic by setting any inbound traffic received on ports 5/1 or 5/2 to a CoS value of 3. Example D-20. Assigning a CoS Value to a Specific Port
CatOS> (enable) set port qos 5/1-2 cos 3
Port 5/1-2 qos cos set to 3
CatOS> (enable)
Because this CoS value is assigned to the port, there is no regard for the end device connected to this port. In other words, any device connected to ports 5/1 or 5/2 receive the configured CoS value. Additionally, all traffic from that end device receive this CoS value. In this configuration, for example, web browsing from the CallManager server receives the same priority across your network as call control traffic. For this reason, it is recommended just to trust DSCP on ports connected to a CallManager, allowing the CallManager to identify the proper QoS classification To remove the CoS value applied to a specific port, use the clear port qos command, as shown in Example D-21. Example D-21. Clearing a CoS Value from a Specific Port
CatOS> (enable) clear port qos 5/1-2 cos
Port 5/1-2 qos cos setting cleared.
CatOS> (enable)
Configuring QoS Access Lists in the Catalyst OS SwitchAs discussed in the "Configuring Trust Boundaries for a Catalyst OS Switch" section, the 63xx series line cards with 1q4t ports do not apply the trust-cos trust state to ingress traffic. An ACL must be configured to enable the port to trust the received CoS values. The set qos acl command is used to accomplish this task. Example D-22 demonstrates the configuration of a QoS ACL. Example D-22. Configuring a QoS ACL
Cat65k> (enable) set qos acl ip IP-PHONES trust-cos any
IP_PHONES editbuffer modified. Use 'commit' command to apply changes.
Cat65k> (enable)
In this example, a QoS access list named IP-PHONES was created. The IP-PHONES QoS ACL is configured to trust the CoS value from any device. After the ACL has been created, it must be committed to hardware. QoS ACLs reside in hardware ASICs for optimum performance. The commit qos acl command enables you to accomplish this task. Example D-23 demonstrates the configuration required to commit a QoS ACL to hardware. Example D-23. Committing a QoS ACL to the ASIC
Cat65k> (enable) commit qos acl IP-PHONES
QoS ACL 'IP_PHONES' successfully committed.
Cat65k> (enable)
After the QoS ACL has been committed to hardware, you can map it to the desired VLAN. This allows the 63xx 10/100 line cards to get around the trust state issue. The set qos acl map command enables you to accomplish this task. Example D-24 demonstrates the configuration of a QoS ACL map. Example D-24. Mapping the QoS ACL to a VLANCat65k> (enable) set qos acl map IP_PHONES 110 ACL IP_PHONES is successfully mapped to vlan 110. Cat65k> (enable) Connecting a Catalyst OS Switch to WAN SegmentsIn Figure D-11, a WAN router is connected to port 6/1. Typically, you will trust the Layer 3 markings from a WAN device. To configure QoS for a port that connects the distribution layer switch to a WAN segment, use port-based QoS with a trust state of trust-ipprec, as shown in Example D-25. Example D-25. Associating QoS with Port 6/1 and Enabling IP Precedence Trust Statecat6k-distrib> (enable) set port qos 6/1 port-based cat6k-distrib> (enable) set port qos 6/1 trust trust-ipprec Trust type trust-ipprec not supported on port(s) 6/1 Receive thresholds enabled on ports(s) 6/1 Trust type set to untrusted on port(s) 6/1As discussed in the "Configuring Trust Boundaries" section, with all 63xx series 10/100 Ethernet line cards with 1q4t ports, the trust-ipprec port keyword displays an error message stating that trust-ipprec is not supported. This configuration must be entered to activate the receive queue drop thresholds; however, the trust state of the ports remains untrusted. You must configure a trust-ipprec ACL to match the ingress traffic to successfully apply the trust-ipprec trust state. The 65xx series 10/100 Ethernet line cards do not have this issue. Example D-26 creates the trust state ACL, commits the ACL to hardware, and applies the ACL to port 6/1. Example D-26. Trust ACL for WAN SegmentscatOS> (enable) set qos acl ip ACL_TRUST-WAN trust-ipprec any catOS> (enable) commit qos acl ACL_TRUST-WAN catOS> (enable) set qos acl map ACL_TRUST-WAN 6/1 Displaying QoS Settings for the Catalyst OS SwitchSeveral show commands enable you to verify the QoS configuration of the Catalyst OS switch. The show port qos command provides a great deal of information about the QoS configuration of the specified port, as shown in Example D-27. Example D-27. show port qos CommandCatOS> (enable) show port qos 2/1 QoS is enabled for the switch. QoS policy source for the switch set to local. Port Interface Type Interface Type Policy Source Policy Source config runtime config runtime ----- -------------- -------------- ------------- ------------- 2/1 vlan-based vlan-based COPS local Port TxPort Type RxPort Type Trust Type Trust Type Def CoS Def CoS config runtime config runtime ----- ------------ ------------ ------------ ------------- ------- ------- 2/1 2q2t 1q4t trust-cos trust-cos* 0 0 Port Ext-Trust Ext-Cos ----- --------- ------- 2/1 untrusted 0 (*)Runtime trust type set to untrusted. Config: Port ACL name Type ----- -------------------------------- ---- No ACL is mapped to port 2/1. Runtime: Port ACL name Type ----- -------------------------------- ---- No ACL is mapped to port 2/1. CatOS> (enable) From the show port qos 2/1 commands, you can see that the QoS is enabled and applied to this port on a VLAN basis. This is a result of the command set port qos 2/1-48 vlan-based entered earlier in the examples to assign QoS to the IP Phones connected to ports 2/1 through 2/48. The TX port type and RX port type list the queues and thresholds in use for interface 2/1. The runtime trust state is currently untrusted. As discussed in the "Trust Boundaries" section, a QoS ACL resolves this issue. In the "Configuring QoS ACLs" section, a QoS ACL named IP-PHONES was created and associated with VLAN 110. Port 2/1 is a member of this VLAN, so why is the show port qos 2/1 saying that there is no ACL mapped to port 2/1? The answer to this question is that the IPPHONES ACL was mapped to the VLAN and not to port 2/1. An ACL is listed only if the ACL was mapped to the specific port selected. As seen in Example D-28, the show qos info runtime command provides much of the same information obtained with the show port qos command. Example D-28. show qos info runtime CommandCatOS (enable) show qos info runtime 2/1 Run time setting of QoS: QoS is enabled Policy Source of port 2/1: Local Tx port type of port 2/1 : 2q2t Rx port type of port 2/1 : 1q4t Interface type: vlan-based ACL attached: The qos trust type is set to trust-cos. Warning: Runtime trust type set to untrusted. Default CoS = 0 Queue and Threshold Mapping for 2q2t (tx): Queue Threshold CoS ----- --------- ---------------- 1 1 0 1 1 2 2 2 1 3 4 5 2 2 6 7 Queue and Threshold Mapping for 1q4t (rx): Queue Threshold CoS ----- --------- ---------------- 1 1 0 1 1 2 2 1 3 3 4 5 1 4 6 7 . . . CatOS> (enable) The commands have a few notable differences. The show qos info runtime command lists the default CoS, typically set to 0, and the active CoS to transmit and receive queue mappings. In this example, any frame that arrives with a CoS value of 3, 4, or 5 is placed in Queue 2, threshold 1. This matches the configuration from the "CoS-to-Egress Queue Mapping" section. The show qos statistics l3stats command shows a summary of all IP packets that have had their CoS/ToS fields modified by the Layer 3 switching engine as well as any packet drops resulting from policing, as shown in Example D-29. Example D-29. Show QoS Layer 3 Statistics
CatOS> (enable) show qos statistics l3stats
Packets dropped due to policing: 0
IP packets with ToS changed: 10473
IP packets with CoS changed: 4871
Non-IP packets with CoS changed: 0
CatOS> (enable)
The show qos statistics command displays detailed information about the number of packets that have been dropped from each queue and threshold. In Example D-30, all packets dropped are in the first drop threshold of TX Queue 1. Example D-30. show qos statistics CommandCatOS> (enable) show qos statistics 2/1 Tx port type of port 2/1 : 2q2t Q # Threshold #:Packets dropped --- ----------------------------------------------- 1 1:393210 pkts, 2:0 pkts 2 1:0 pkts, 2:0 pkts Rx port type of port 2/1 : 1q4t Q # Threshold #:Packets dropped --- ----------------------------------------------- 1 1:0 pkts, 2:0 pkts, 3:0 pkts, 4:0 pkts CatOS> (enable) The show qos map runtime command enables you to display the CoS/DSCP/IP precedence mappings within the Catalyst 6500. You can now display the mappings configured in the "Layer 2-to-Layer 3 Mapping" section of this chapter. Example D-31 show the CoS value of 3 is mapped to the DSCP decimal value of 26 (AF31), whereas the CoS value of 5 is mapped to the DSCP decimal value of 46 (EF). Example D-31. show qos map runtime cos-dscp-map CommandCat65k-Access> (enable) show qos map runtime cos-dscp-map CoS - DSCP map: CoS DSCP --- ---- 0 0 1 8 2 16 3 26 -> 26 = AF31 4 32 5 46 -> 46 = EF 6 48 7 56 Console > (enable) Example D-32 shows the DSCP decimal values 24 through 31 are mapped to the CoS value of 3, whereas the DSCP decimal values 40 through 47 are mapped to the CoS value of 5. Example D-32. show qos map runtime dscp-cos-map CommandCatOS> (enable) show qos map runtime dscp-cos-map DSCP - CoS map: DSCP CoS --- --- 0-7 0 8-15 1 16-23 2 24-31 3 -> 26 = AF31 32-39 4 40-47 5 -> 46 = EF 48-55 6 56-63 7 CatOS> (enable) Example D-33 shows the IP precedence value of 3 mapped to the DSCP value of 26 (AF31), whereas the IP precedence value of 5 is mapped to the DSCP value of 46 (EF). Example D-33. show qos map runtime ipprec-dscp-map CommandCat65k-Access> (enable) show qos map runtime ipprec-dscp-map IP-Precedence - DSCP map: IP-Prec DSCP ------- ---- 0 0 1 8 2 16 4 32 5 46 -> 46 = EF 6 48 7 56 Cat65k-Access> (enable) Configuration of a Catalyst Switch Using IOSThis section explores the configuration of a Catalyst IOS switch in the access and distribution layers. Assume that your IP telephony network is configured as depicted in Figure D-12. Figure D-12. Catalyst IOS Switch
In this example, CallManager 1 is connected to port 1, CallManager 2 is connected to port 2, and 10 IP Phones are connected to ports 11 through 20 respectively. Each IP Phone has a PC attached to the IP Phone switch port. And an IP video server is also connected to port 10. The Catalyst 6500, 4500 with the Supervisor III or IV Engine, 3550, and 3524 are examples of Catalyst IOS switches. The QoS required to minimize delay, jitter, and packet drops for these switches can be broken down into the following tasks:
Configuring Voice VLANs for a Catalyst IOS SwitchThe first step in configuring QoS for the access layer is separating the voice traffic from the data traffic. Cisco IP Phones have the capability to use 802.1Q trunks to accomplish this task. The IP Phone can tag the voice traffic with a VLAN identifier, while leaving the data traffic in the native, or untagged, VLAN. The switch must be configured to participate in the 802.1Q trunk from the IP Phone. Assuming that the voice VLAN has been configured for 110 and the data VLAN has been configured for 10, Example D-34 shows the configurations necessary on the Catalyst 6500, 4500, 3550, and 3524 switches. Example D-34. Creating Voice VLANsCatIOS (config)#interface FastEthernet0/11 CatIOS (config)#switchport access vlan 10 CatIOS (config)#switchport voice vlan 110 CatIOS (config)#spanning-tree portfast In this example, switch port 0/11, the first IP Phone port in Figure D-12, has been configured to participate in the 802.1Q trunk from the IP Phones using VLAN 110 for the tagged VLAN that will carry the voice traffic and VLAN 10 for the untagged traffic. Enabling QoS for the Catalyst IOS SwitchQoS must be enabled globally within the switch to use the multiple queues desired. The command to enable QoS depends on the Catalyst IOS switch. The Catalyst 6500 and 3550 both use the mls qos command to enable QoS, whereas the Catalyst 4500 uses the qos command. QoS on the catalyst 3524 is enabled by default. In this example, QoS has been enabled on the Catalyst IOS switch. Enabling Priority Queuing for the Catalyst IOS SwitchThe Catalyst 6500, with selected line cards that support priority queuing, and 3524 transmit frames with a CoS value of 5, typically voice traffic, using the priority queue by default. Although the Catalyst 4500 and the 3550 have a transmit priority queue, they are not configured when QoS is enabled. The priority queue on a 3550 interface resides in Queue 4. To enable this priority queue, use the priority-queue out interface command, as shown in Example D-35. Example D-35. Enabling the Priority Queue on a Catalyst 3550
3550 (config)#interface fastethernet 0/11
3550 (config-if)#priority-queue out
3550 (config-if)#wrr-queue cos-map 4 5
The priority queue on a 4500 interface resides in Queue 3. Example D-36 shoes how to configure this priority queue. Example D-36. Enabling the Priority Queue on a Catalyst 45004500 (config)# interface fastethernet 1/1 4500 (config-if-tx-queue)# tx-queue 3 4500 (config-if-tx-queue)# priority high Table D-22 summarizes the priority queues available on the Catalyst IOS switches.
CoS-to-Egress Queue Mapping for the Catalyst IOS SwitchBy default, Cisco IP Phones mark voice bearer traffic with a CoS of 5 and voice signaling traffic with a CoS value of 3. The Catalyst 3550 uses transmit Queue 4 for a priority queue; therefore, the CoS value of 5 needs to be mapped to Queue 4 for voice traffic to take advantage of the priority queue. Example D-37 shows the configuration needed to map the CoS value of 5 into the priority queue, which resides in Queue 4. Example D-37. Mapping CoS 5 to the Priority Queue in a Catalyst 3550
3550 (config)#interface fastethernet 0/11
3550 (config-if)#priority-queue out
3550 (config-if)#wrr-qwrr-queue cos-map 4 5
The Catalyst 6500 and 4500 place traffic marked with a CoS value of 5 into the priority queue when QoS is enabled and the priority queue has been activated. However, you must perform the additional step of configuring the Catalyst IOS switches' CoS queue mapping to ensure that traffic with a CoS of 3 is placed into the second queue on the Catalyst 6500 and 4500. Example D-38 shows the configuration needed to place the call control traffic (CoS 3) in Queue 2, threshold 1, of a Catalyst 6500 switch. CoS 4 is also placed in the same queue. Example D-38. Map CoS Value of 3 to Queue 2 Threshold 1
CatIOS (config)# interface fastethernet 0/11
CatIOS (config-if)#wrr-queue cos-map 2 1 3 4
The Catalyst 4500 Supervisor III or IV uses a slightly different configuration for this task. From the global configuration mode, the qos map dscp 3 to tx-queue 3 command is entered to direct frames with a CoS value of 3 to the high-priority queue, Queue 3, on a Catalyst 4500. The queue assignment on a Catalyst 3524 cannot be changed. Layer 2-to-Layer 3 MappingCisco follows the recommended standard for setting the DSCP classification values for both the VoIP call control traffic and VoIP bearer traffic. The recommended settings are DSCP = AF31 (or decimal 26) for VoIP call control and DSCP = EF (or decimal 46) for VoIP bearer traffic. By default the CoS-to-DSCP mapping does not match this recommendation, as shown in Table D-23.
To map the Layer 2 CoS and Layer 3 IP precedence settings correctly to these DSCP values, you must modify the default CoS/ToS-to-DSCP mappings. Example D-39 demonstrates the configuration required for the CoS-to-DSCP mappings in a Catalyst 6500 and 3550. Example D-39. Modifying the CoS-to-DSCP MappingsCatIOS (config)# mls qos map cos-dscp 0 8 16 26 32 46 48 56 Example D-40 demonstrates the configuration required for the CoS-to-DSCP mappings in a Catalyst 4500. Example D-40. Modifying the CoS-to-DSCP MappingsCat4500 (config)# qos map cos 3 to dscp 26 Cat4500 (config)# qos map cos 5 to dscp 46 After these command have been applied, the Catalyst 6500, 4500, and 3550 map a CoS value of 3 to IP DSCP 26 (AF31) and a CoS value of 5 to IP DSPC 46 (EF). The Catalyst 3524 operates on Layer 2 tags and does not have the capability to classify or mark based on IP DSCP. Configuring Trust Boundaries for a Catalyst IOS SwitchTrust boundaries define the point in the network where CoS, IP precedence, or DSCP markings are trusted. Typically this trust is established at the ingress switch port of the access layer switch. The Catalyst 6500, 4500, and 3550 switches establish trust on a per-port basis. By default all listed switches reside in the untrusted state. In other words, any CoS or DSCP value received by the switch is re-marked to a CoS or DSCP value of 0. In Figure D-12, CallManager 1 is connected to the Catalyst IOS switch on port 1. Assuming that the switch is a 6500 or a 3500, to configure the switch to trust the DSCP values received on port 1, you must place the mls qos trust dscp command on interface 1. If the switch is a 4500, the qos trust dscp command is configured on interface 1. These configurations allow the DSCP values received on the configured interface to be trusted by the switch. In the example, assume that the video server in port 10 can only use CoS values and does not have the capability to classify or mark based on IP DSCP. The Catalyst 6500 and 3550 can be configured to trust the receive CoS value by placing the mls qos trust cos command on interface 10. The Catalyst 4500 uses the qos trust cos command on interface 10 to accomplish the same goal. The switchport priority extend cos command enables you to overwrite the CoS value presented to an IP Phone from the attached PC. In a typical IP telephony deployment, any CoS value presented by an attached PC should be overwritten with a value of 0. Be cautious if your design includes extending trust to a PC. If you trust one application on a PC, by default, you trust all applications on that PC. This can lead to unintentional voice-quality degradation. Example D-41 shows the switchport priority extend cos configuration of a typical IP telephony deployment. Example D-41. Configuring trust-extCatIOS (config)#interface FastEthernet0/11 CatIOS (config)#switchport access vlan 10 CatIOS (config)#switchport voice vlan 110 CatIOS (config)#switchport priority extend 0 CatIOS (config)#spanning-tree portfast Configuring Untagged Frames for the Catalyst IOS SwitchWhat if the end device does not support 802.1Q trunks? How do you prioritize the traffic of this device? The addition of a Layer 3 switching engine allows the Catalyst to use IP precedence or DSCP to classify this traffic, but what if you do not have a Layer 3 switching engine or you would still prefer to mark the traffic with a CoS value? You can accomplish this by setting the CoS value on the ingress switch port. By doing this, you are telling the switch to mark any frame received on this port with a specific CoS value. Even though the actual received frame may not have even had an ISL or 802.1Q header, the switch can process the frame as if it had a CoS value set, based on configuration. In Figure D-12, for example, CallManager 1 is connected to port 1, and CallManager 2 is connected to port 2. The mls qos cos 3 command can be added to interface 1 and 2 on a Catalyst 6500 and a 3550 to mark all inbound traffic with a CoS value of 3. A Catalyst 4500 Supervisor III or IV can use the qos cos 3 command to accomplish the same results, whereas a Catalyst 3524 can use the switchport priority default 3 command. Because this CoS value is assigned to the port in this example, there is no regard for the end device connected to this port. In other words, any device connected to interface 1 or 2 receive the configured CoS value. Additionally, all traffic from that end device receive this CoS value. In this configuration, for example, web browsing from the CallManager server receives the same priority across your network as call control traffic. For this reason, it is recommended to trust IP DSCP whenever possible, allowing the CallManager to identify the proper QoS classification. Configuring QoS Access Lists in the Catalyst IOS SwitchThe Catalyst 6500, 4500, and 3550 IOS switches enable you to classify traffic based on standard or extended access lists typically deployed on routers. This allows the switches to classify traffic flows by examining Layer 3 and Layer 4 information, providing a much more granular control of QoS. In the Example D-42, three IP access lists (GOLD-DATA, VOICE, and VOICE-CONTROL) are created to specify interesting traffic flows. Example D-42. Creating the ACLCatIOS (config)#ip access-list extended GOLD-DATA CatIOS (config-ext-nacl)#remark Match IP Address of the application server CatIOS (config-ext-nacl)#permit ip any host 192.168.100.1 CatIOS (config-ext-nacl)#permit ip host 192.168.100.1 any CatIOS (config)#ip access-list extended VOICE CatIOS (config-ext-nacl)#remark Match the UDP ports that VoIP Uses for Bearer Traffic CatIOS (config-ext-nacl)#permit udp any any range 16384 32767 CatIOS (config)#ip access-list extended VOICE-CONTROL CatIOS (config-ext-nacl)#remark Match VoIP Control Traffic CatIOS (config-ext-nacl)#remark SCCP CatIOS (config-ext-nacl)#permit tcp any any range 2000 2002 CatIOS (config-ext-nacl)#remark H323 Fast Start CatIOS (config-ext-nacl)#permit tcp any any eq 1720 CatIOS (config-ext-nacl)#remark H323 Slow Start CatIOS (config-ext-nacl)#permit tcp any any range 11000 11999 CatIOS (config-ext-nacl)#remark H323 MGCP CatIOS (config-ext-nacl)#permit udp any any eq 2427 After the traffic flows have been specified, you use the class-map command to identify these traffic flows. Example D-43 shows a class-map for each of the IP access lists created in Example D-42. Example D-43. Create Classes Based on the ACLCatIOS (config)#class-map match-all GOLD-DATA CatIOS (config-cmap)#description Mission Critical Traffic CatIOS (config-cmap)#match access-group name GOLD-DATA CatIOS (config)#class-map match-all VOICE CatIOS (config-cmap)#description VoIP Bearer Traffic CatIOS (config-cmap)#match access-group name VOICE CatIOS (config)#class-map match-all VOICE-CONTROL CatIOS (config-cmap)#description VoIP Control Traffic (SCCP, H225, H254, MGCP) CatIOS (config-cmap)#match access-group name VOICE-CONTROL Next, the behavior of the traffic flow can be altered. In Example D-44, the policy-map command is used to overwrite the DSCP value of all traffic identified in the three classes. Example D-44. Set the DSCP Value for the Classes
CatIOS (config)#policy-map CAT-IOS-IN
CatIOS (config-pmap)#description Set DSCP Value for Each Class
CatIOS (config-pmap)#class VOICE-CONTROL
CatIOS (config-pmap-c)#set ip dscp 26
CatIOS (config-pmap)#class VOICE
CatIOS (config-pmap-c)#set ip dscp 46
CatIOS (config-pmap)#class GOLD-DATA
CatIOS (config-pmap-c)#set ip dscp 18
In this example, all traffic matching the GOLD-DATA access list is marked with a DSCP value of 18, all traffic matching the VOICE-CONTROL access list is marked with a DSCP value of 26, and all traffic matching the VOICE access list is marked with a DSCP value of 46. Finally, the service-policy command is used to assign the policy map to the input traffic on a specific interface. In Example D-45, the policy map configuration is applied to interface Gigabit Ethernet 0/2. Example D-45. Applying the Policy to the Interface
CatIOS (config)#int gigabitethernet 0/2
CatIOS (config-if)#service-policy input CAT-IOS-IN
Connecting a Catalyst IOS Switch to Distribution Switches or WAN SegmentsIn Figure D-12, a WAN router is connected to port 5. Typically you will trust the Layer 3 markings from a WAN device. Assuming that the switch is a 6500 or a 3500, to configure the switch to trust the DSCP values received on port 5, you must place the mls qos trust dscp command on interface 5. If the switch is a 4500, the qos trust dscp command is configured on interface 5. Displaying QoS Settings for the Catalyst IOS SwitchSeveral show commands enable you to verify the QoS configuration of the Catalyst OS switch. The show mls qos interface queueing command enables you to display the QoS queuing strategy for the Catalyst 3550 switch. In Example D-46, egress expedited queuing (priority queuing) has been enabled on interface gigabit 0/1, causing Queue 4 to become the priority queue. All frames with a CoS value of 5, 6, or 7 are placed in this queue. Example D-46. show mls qos interface queueing Command3550 #show mls qos interface queueing GigabitEthernet0/1 Ingress expedite queue: dis Egress expedite queue: ena wrr bandwidth weights: qid-weights 1 - 25 2 - 25 3 - 25 4 - 25 when expedite queue is disabled Dscp-threshold map: show mls qos interface queueing d1 : d2 0 1 2 3 4 5 6 7 8 9 ---------------------------- 0 : 01 01 01 01 01 01 01 01 01 01 1 : 01 01 01 01 01 01 01 01 01 01 2 : 01 01 01 01 01 01 01 01 01 01 3 : 01 01 01 01 01 01 01 01 01 01 4 : 01 01 01 01 01 01 01 01 01 01 5 : 01 01 01 01 01 01 01 01 01 01 6 : 01 01 01 01 Cos-queue map: cos-qid 0 - 1 1 - 1 2 - 2 3 - 2 4 - 3 5 - 4 6 - 4 7 - 4 Note that at the end of the command output, the CoS values' mapping to the four queues is listed. CoS 5 maps to Queue 4, the priority queue, automatically as a result of the configuration to use priority queuing. The show mls qos interface command enables you to display QoS information for a specified interface. In Example D-47, the QoS configuration of Fast Ethernet port 0/1 on a Catalyst 3550 switch displays. In the earlier example, interface Fast Ethernet 0/1 was configured to trust the DSCP values received. Example D-47. show mls qos interface Command F0/13550 t#show mls qos interface fastethernet0/1 FastEthernet0/1 trust state: trust dscp COS override: dis default COS: 0 DSCP Mutation Map: Default DSCP Mutation Map In Example D-48, the QoS configuration of Fast Ethernet 0/10 on the Catalyst 3550 switch displays. In the earlier example, interface Fast Ethernet 0/10 was configured to trust the CoS values received. Example D-48. show mls qos interface Command F0/103550 t#show mls qos int g0/10 GigabitEthernet0/10 trust state: trust cos COS override: dis default COS: 0 DSCP Mutation Map: Default DSCP Mutation Map The show qos interface command enables you to display the current QoS configuration information about the specified interface in a Catalyst 4500. In Example D-49, QoS has been enabled globally in the switch as well as on this port; however, the trust state for port 4/5 is configured for untrusted. Although QoS has been enabled, this port transmits packets without regard to the CoS or DSCP values on the packets. Example D-49. show qos interface Command: Untrusted4500 #show qos interface fastethernet 4/5 QoS is enabled globally Port QoS is enabled Port Trust State: 'untrusted' Default DSCP: 0 Default CoS: 0 Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1 N/A disabled N/A 240 2 N/A disabled N/A 240 3 N/A disabled high 240 4 N/A disabled N/A 24 In Example D-50, port 3/1 on a Catalyst 4500 has been configured to trust the DSCP values of packets. Any packet that matches the DSCP classification for admittance into the priority queue is transmitted immediately. Example D-50. show qos interface Command: Trust DSCP
4500 #show qos interface fastethernet 3/1
QoS is enabled globally
Port QoS is enabled
Port Trust State: 'dscp'
Default DSCP: 0 Default CoS: 0
Tx-Queue Bandwidth ShapeRate Priority QueueSize
(bps) (bps) (packets)
1 250000000 disabled N/A 1920
2 250000000 disabled N/A 1920
3 250000000 disabled high 1920
4 250000000 disabled N/A 1920
In Example D-51, port 3/2 on a Catalyst 4500 has been configured to trust the CoS values of frames. Any frame that matches the CoS classification for admittance into the priority queue is transmitted immediately. Example D-51. show qos interface Command: Trust CoS4500 #show qos interface fastethernet 3/2 QoS is enabled globally Port QoS is enabled Port Trust State: 'cos' Default DSCP: 0 Default CoS: 0 Tx-Queue Bandwidth ShapeRate Priority QueueSize (bps) (bps) (packets) 1250000000 disabled N/A 1920 2 250000000 disabled N/A 1920 3 250000000 disabled high 1920 4 250000000 disabled N/A 1920 The show mls qos map cos command on the Catalyst 6500 and 3550 enables you to display the current CoS-to-DSCP mapping in use by the switch. The show qos map cos command on the Catalyst 4500 displays the same results. In Example D-52, CoS values of 3, 4, and 5 have been mapped to the DSCP values of 26, 34, and 46, respectively. Example D-52. show qos map cos CommandCatIOS #show mls qos map cos CoS-DSCP Mapping Table CoS: 0 1 2 3 4 5 6 7 ------------------------------------------------------------- DSCP: 0 8 16 26 34 46 48 56  |
|
|
