QoS in an AVVID-Enabled Campus Network

Transcription

1 CHAPTER 3 This chapter provides information about implementing QoS in an AVVID-enabled campus network. It includes the following: Overview QoS Toolset Server Farm Switch Selection Selecting an Access-Layer Switch Selecting a Distribution-Layer Switch Summary Note This chapter contains references to other documents. These references are included as tips in the text. The URL for each referenced document is located in Appendix A, Reference Information. In some cases, an internal document is referenced. For copies of internal documents, please see your Cisco Systems representative. Overview Until recently, the conventional wisdom has been that QoS was not an issue in an enterprise campus network where bandwidth is plentiful. As applications like IP telephony and video-conferencing, and mission-critical data applications have been implemented in the campus, it has become evident that buffer management, not just bandwidth, is an issue that must be addressed. QoS functions, such as classification, scheduling, and provisioning, are required to manage bandwidth and buffers to minimize loss, delay, and delay variation. Throughout this chapter VoIP traffic will be used to illustrate how QoS can limit loss, delay, and delay variation because it is easy to illustrate how network performance can adversely affect voice quality. Delay-sensitive applications, like video-conferencing over IP, and mission critical applications, like ERP applications or mainframe SNA applications, have similar requirements of the network and are adversely affected by packet loss, delay, and delay variation. This chapter focuses strictly on the campus components of the Cisco AVVID Network Infrastructure (as shown in Figure 3-1), specifically the: Access routers Distribution routers For general information about using QoS for voice and video, see Chapter 1, Overview. 3-1

2 Overview Chapter 3 Figure 3-1 Campus Infrastructure IP IP IP IP IP IP phones Access Si Si Si Distribution Core WAN aggregator Si WAN IP IP IP Branch router Access IP phones Delay Variation Transmit Buffer Congestion In campus local area networks (LANs), serialization delay is not a significant concern. The amount of time required for LAN interfaces to serialize the bits of packets onto the physical media is negligible; it is not significant enough to affect delay-sensitive applications. Additionally in LANs, propagation delay is of little concern because LANs by their very nature are not geographically dispersed. The type of delay that is present in LANs is variation in delay, or jitter (as explained in the following sections). This can adversely affect voice and video quality by introducing packet loss through jitter buffer over-runs and under-runs. An additional contributor to packet loss in campus networks is TX buffer congestion. Transmit buffer congestion can happen if a rate change occurs or if many interfaces are aggregated into a single uplink, resulting in an oversubscription of the uplink s capacity to buffer packets. The bits of a traffic flow that runs through a high-speed campus network serialize into and out of switches at different rates depending on the link speed of the physical interfaces they are traversing. When traffic serializes into a campus switch at gigabit speeds and is switched to a one hundred megabit interface, the switch must have buffering capabilities in order to hold, or queue, the bits while it waits to transmit them. When a transmit buffer fills, ingress interfaces are not able to place new traffic into the transmit buffer of the target interface. When the switch cannot place a packet into the transmit queue because of TX buffer congestion/exhaustion, packet drops will occur (as shown in Figure 3-2). 3-2

3 Chapter 3 Overview Figure 3-2 Bits serialize IN at 1Gbps Transmit Congestion Ethernet switch 1Gbps RX TX 100 Mbps Bits serialize OUT at 100Mbps. TX queue buffers to compensate for rate change. Additional flows, including voice, can not get access to TX queue when it becomes full and packets are dropped There are many points in a campus network where QoS mechanisms are required to manage loss, delay, and delay variation. Figure 3-3 illustrates areas where TX buffer congestion can become an issue.. Figure 3-3 QoS in the Campus Network Ethernet switch Queue assignment based on CoS/ToS classification Data RX Mission critical data RX Video RX TX To core Voice RX Put voice and video into "delay and drop" sensitive queue Using multiple queues on the transmit interfaces minimizes the potential for dropped or delayed traffic caused by TX buffer congestion. By separating voice, video, and mission-critical data (which are all sensitive to loss, delay, and delay variation) into their own queues, you can prevent flows from being dropped at the ingress interface even when TX buffer congestion is experienced. You can also minimize delayed transmission due to non-qos sensitive traffic congestion by servicing the QoS sensitive queues in a priority fashion. (Scheduling algorithms are discussed in the Scheduling Tools section on page 1-17.) 3-3

4 QoS Toolset Chapter 3 Figure 3-4 illustrates the placement of separate TX buffers. As the transmit queues begin to fill, traffic is dropped from the non-mission-critical buffer first. This protects voice, video, and mission-critical data from packet loss. Figure 3-4 Using Separate TX Buffers Core Si TX TX TX TX Distribution Si TX TX Si Areas where QoS maybe a concern TX TX Access TX IP QoS Toolset The challenges of loss, delay, and delay variation can be addressed through the application of various QoS tools. This section provides information about the use of QoS tools in a campus environment. For general information about the QoS Toolset, see the What is the Quality of Service Toolset? section on page Classification Within a campus AVVID network, you should classify voice and video bearer traffic, signaling traffic, and mission-critical data traffic. For general recommendations for classification, see Classification Recommendations section on page

5 Chapter 3 QoS Toolset Scheduling In access-layer switches, the number of queues is not as important as how those queues and their various drop thresholds are configured and serviced. As few as two queues might be adequate for wiring closet access switches, where buffer management is less critical than at other layers. How these queues are serviced (RR, WRR, Priority Queuing, or a combination of Priority Queuing and WRR or WRED) is less critical than the number of buffers because the scheduler process is extremely fast when compared to the aggregate amount of traffic. Distribution-layer switches require much more complex buffer management due to the flow aggregation occurring at that layer. Not only are priority queues needed, but thresholds within the standard queues should also be specified. It is important to note that Cisco has chosen to use multiple thresholds within queues instead of continually increasing the number of interface queues. As discussed earlier, each time a queue is configured and allocated, all of the memory buffers associated with that queue can be used only by frames meeting the queue entrance criteria. For example, assume that a Catalyst /100 Ethernet port has two queues configured, one for VoIP (VoIP bearer and control traffic) and the default queue, which is used for Hypertext Transfer Protocol (HTTP), , FTP, logins, Windows NT Shares, and Network File System (NFS). The 128 KB voice queue is split into a 7:1 transmit and receive ratio. The transmit buffer memory is then further separated into high and low priority partitions in a 4:1 ratio. If the default traffic (the web, , and file shares) begins to congest the default queue, which is only 24 KB, then packets are dropped at the ingress interfaces. This happens regardless of whether or not the VoIP control traffic is using any of its queue buffers. The dropped packets of the TCP-oriented applications cause each of these applications to send the data again, aggravating the congested condition of the network. If this same scenario were configured with a single queue, but with multiple thresholds used for congestion avoidance, then the default traffic would share the entire buffer space with the VoIP control traffic. Only during periods of congestion, when the entire buffer memory approaches saturation, would the lower priority traffic (HTTP and ) be dropped. This discussion does not imply that multiple queues are to be avoided in Cisco AVVID networks. As discussed earlier, the VoIP bearer streams must use a separate queue to eliminate the adverse affects that packet drops and delays have on voice quality. However, every single CoS or DSCP value should not get its own queue because the small size of the resulting default queue will cause many TCP resends and will actually increase network congestion. In addition, the VoIP and video bearer channel is a bad candidate for queue congestion avoidance algorithms such as WRED. Queue thresholding uses the WRED algorithm to manage queue congestion when a preset threshold value is specified. Random Early Detection (RED) works by monitoring buffer congestion and discarding TCP packets before they are admitted to the queue if the congestion begins to increase. The result of the drop is that the sending endpoint detects the dropped traffic and slows the TCP sending rate by adjusting the window size. A WRED drop threshold is the percentage of buffer utilization at which traffic with a specified CoS value is dropped, leaving the buffer available for traffic with higher-priority CoS values. The key is the word Random in the algorithm name. Even with weighting configured, WRED can still discard packets in any flow; it is just statistically more likely to drop them from the lower CoS thresholds. 3-5

6 Server Farm Switch Selection Chapter 3 Server Farm Switch Selection Figure 3-5 shows a typical server farm design, with a Catalyst 6500 (Layer 3 aware using the Policy Feature Card [PFC]) at the access layer. A Catalyst 6500 with the PFC is able to classify traffic using ACLs and Services Policies to apply CoS, IP Precedence, or DSCP markings to traffic on ingress to the network. Both can be used to ensure admission of traffic into the appropriate queue. The Catalyst 4006 with Supervisor III, and the Catalyst 3550 are also excellent server farm switches with advanced QoS features. The tradeoffs between a Catalyst 6500, a Catalyst 4000 Supervisor III, and a Catalyst 3500 are primarily switching capacity and modularity. Tip For a comparison of the features of each of the Catalyst switches, see the Cisco Products Quick Reference Guide: February The example configurations for policy-based classification in this section leverage each of these types of switches for a portion of the configuration. Figure 3-5 Server Farm Switch Selection Si Core Si Catalyst 6500 Si Distribution Layer 3 aware server farm switch Access Video conference CallManager (TFTP) V H.323 Gateway V MGCP Gateway Tip For more information about designing server farms, see the Designing Small Scale Server Farms white paper (internal). 3-6

7 Chapter 3 Server Farm Switch Selection Voice Bearer Traffic Voice traffic can be identified in many ways. The easiest way to identify voice traffic is to have the end device (the IP phone or gateway) mark its traffic appropriately. Cisco IP phones tag their bearer traffic at Layer 2 with a CoS of 5 and set the Layer 3 DSCP marking to EF. Voice application servers, such as Personal Assistant, IP IVR, and Unity - Unified Messaging, are not as far along as the hardware devices and may not mark their bearer and control traffic with the appropriate Layer 3 tagging. And, because current voice application servers do not support 802.1Q configurations for the network interface, they are not capable of Layer 2 CoS classification. To classify voice application traffic at the edge of the network for voice application servers, you must use a switch that has Layer 3 awareness and a service policy that uses Layer 3 and Layer 4 (TCP or UDP ports) as its admission criteria. The following configuration example uses a Catalyst In this example, the switch recognizes and classifies voice bearer and signaling traffic on ingress into the network. Enable switch-wide QoS. 3550G-Access#config t Enter configuration commands, one per line. End with CNTL/Z. 3550G-Access(config)#mls qos To verify, enter the following command (shown with its associated output): 3550G-Access#show mls qos QoS is enabled Modify the default CoS-to-ToS mapping table. You must setup a translation between CoS and DSCP because there at only 8 CoS labels and 64 possible DSCP labels. The default mapping table looks like the following: 3550G-Access#show mls qos maps Cos-dscp map: cos: dscp: Change the defaults so that: CoS 3 maps to AF31 (26) CoS 4 maps to AF41 (34) CoS 5 to EF (46) 3550G-Access#config t Enter configuration commands, one per line. End with CNTL/Z. 3550G-Access(config)#mls qos map cos-dscp To verify, enter the following command (shown with its associated output): 3550G-Access#show mls qos maps Cos-dscp map: cos: dscp:

8 Server Farm Switch Selection Chapter 3 Step 3 Turn on priority queuing and move CoS 5 traffic to queue 4, which is the priority queue in the Catalyst 3500 family. The default queuing looks like the following: 3550G-Access#show mls qos interface queueing GigabitEthernet0/1 Ingress expedite queue: dis Egress expedite queue: dis wrr bandwidth weights: qid-weights when expedite queue is disabled Dscp-threshold map: d1 : d : : : : : : : Cos-queue map: cos-qid Change the defaults: 3550G-Access#config t Enter configuration commands, one per line. End with CNTL/Z. 3550G-Access(config)#interface range g 0/ G-Access(config-if-range)#priority-queue out 3550G-Access(config-if-range)#wrr-queue cos-map 4 5 To verify, issue the following command (shown with its associated output): 3550G-Access#show mls qos interface queueing GigabitEthernet0/1 Ingress expedite queue: dis Egress expedite queue: ena wrr bandwidth weights: qid-weights when expedite queue is disabled Dscp-threshold map: d1 : d : : : : : : :

9 Chapter 3 Server Farm Switch Selection Cos-queue map: cos-qid Step 4 Step 5 Step 6 Step 7 Create an ACL that identifies voice bearer and control traffic. 3550G-Access (config)#ip access-list extended VOICE 3550G-Access (config-ext-nacl)#remark Match the UDP ports that VoIP uses for Bearer Traffic 3550G-Access (config-ext-nacl)#permit udp any any range G-Access (config)#ip access-list extended VOICE-CONTROL 3550G-Access (config-ext-nacl)#remark Match VoIP Control Traffic 3550G-Access (config-ext-nacl)#remark SCCP 3550G-Access (config-ext-nacl)#permit tcp any any range G-Access (config-ext-nacl)#remark H323 Fast Start 3550G-Access (config-ext-nacl)#permit tcp any any eq G-Access (config-ext-nacl)#remark H323 Slow Start 3550G-Access (config-ext-nacl)#permit tcp any any range G-Access (config-ext-nacl)#remark H323 MGCP 3550G-Access (config-ext-nacl)#permit udp any any eq 2427 Create classes that use the ACLs as admission criteria (as shown below). 3550G-Access (config)#class-map match-all VOICE 3550G-Access (config-cmap)#description VOIP Bearer Traffic 3550G-Access (config-cmap)#match access-group name VOICE 3550G-Access (config)#class-map match-all VOICE-CONTROL 3550G-Access (config-cmap)#description VOIP Control Traffic (SCCP, H225, H254, MGCP) 3550G-Access (config-cmap)#match access-group name VOICE-CONTROL Create a service policy that uses the classes as admission and sets the DSCP PHB labels. 3550G-Access (config)#policy-map ACCESS-C3550-LAN-EDGE-IN 3550G-Access (config-pmap)#description Set DSCP PerHopBehavior Label for VOIP Control and Bearer Traffic 3550G-Access (config-pmap)#class VOICE-CONTROL 3550G-Access (config-pmap-c)#set ip dscp G-Access (config-pmap)#class VOICE 3550G-Access (config-pmap-c)#set ip dscp 46 Apply the policy to an interface so that traffic entering the network through this port is classified with the appropriate DSCP PHB Label EF and AF31 for VoIP bearer and control respectively. 3550G-Access#ct Enter configuration commands, one per line. End with CNTL/Z. 3550G-Access(config)#int g 0/2 550G-Access(config-if)#service-policy input ACCESS-C3550-LAN-EDGE-IN To verify, issue the following command (shown with its associated output): 3550G-Access#show pol int g 0/2 service-policy input: ACCESS-C3550-LAN-EDGE-IN class-map: VOICE-CONTROL (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: access-group name VOICE-CONTROL 3-9

10 Server Farm Switch Selection Chapter 3 class-map: VOICE (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: access-group name VOICE class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps match: any 0 packets, 0 bytes 5 minute rate 0 bps Voice over IP Call Control The current release of Cisco CallManager includes the ability to configure the CoS and ToS values for all VoIP control and management traffic from CallManager, the IP phones, H.323, Skinny Protocol, and MGCP gateways. With this user-configurable classification, network element access lists are no longer required to mark VoIP control traffic. However, some network managers may choose to enforce policy at the edge of their network and not trust the markings that end devices provide. The following configuration example uses a Catalyst 6500 with Multilayer Switch Feature Card 2 (MSFC2) and Policy Feature Card (PFC2) and Catalyst Operating System (Catalyst OS). In this example, the switch recognizes and classifies VoIP control traffic upon ingress to the network. Skinny Protocol Cisco CallManager communicates with IP phones and gateways using TCP ports The example below marks all Skinny Protocol traffic from IP phones and gateways (VLAN 110) and Cisco CallManager (4/2) with a DSCP of AF31, which is backwardly compatible with IP Precedence 3. Step 3 Step 4 Step 5 Step 6 Enable switch-wide QoS. cat6k-access> (enable) set qos enable Create an ACL (ACL_IP-PHONES) to mark all Skinny Client and Gateway Protocol traffic from the IP phones and from Skinny Protocol gateways with a DSCP value of AF31 (decimal of 26). cat6k-access> (enable) set qos acl ip ACL_IP-PHONES dscp 26 tcp any any range Add an entry to the ACL_IP-PHONE access list to trust all DSCP markings from the IP phone so that the RTP traffic with ToS of is not rewritten. cat6k-access> (enable) set qos acl ip ACL_IP-PHONES trust-cos ip any any Create an ACL (ACL_VOIP_CONTROL) to mark all Skinny Client and Gateway Protocol traffic from Cisco CallManager with a DSCP value of AF31. cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any range Accept incoming Layer 2 CoS classification. cat6k-access> (enable) set port qos 5/1-48 trust trust-cos Inform the port that all QoS associated with the port will be done on a VLAN basis to simplify the configuration. cat6k-access> (enable) set port qos 5/1-48 vlan-based 3-10

11 Chapter 3 Server Farm Switch Selection Step 7 Step 8 Step Instruct the IP phone to rewrite CoS from the PC to CoS of 0 within the IP phone Ethernet ASIC. cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted Inform the Cisco CallManager port (4/2) that all QoS associated with the port will be done on a port basis cat6k-access> (enable) set port qos 4/2 port-based Write the ACL to hardware. cat6k-access> (enable) commit qos acl all Map the ACL_IP-PHONE ACL to the auxiliary VLAN. cat6k-access> (enable) set qos acl map ACL_IP-PHONES 110 Map the ACL_VOIP_CONTROL ACL to the Cisco CallManager port. cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2 H.323 Protocol Cisco CallManager communicates with H.323 gateways using TCP ports 1720 (H.225) and 11xxx (H.245). The example below marks H.323 control traffic from Cisco CallManager (4/2) and from H.323 gateways (4/3) with a DSCP of AF31. Step 3 Step 4 Step 5 Add entries to the ACL_VOIP_CONTROL access list to mark all traffic from H.323 gateways with a DSCP value of AF31. cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any eq 1720 cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 tcp any any range Inform the Cisco CallManager port (4/2) that all QoS associated with the port will be done on a port basis cat6k-access> (enable) set port qos 4/2 port-based Inform the Cisco H.323 gateway port (4/3) that all QoS associated with the port will be done on a port basis cat6k-access> (enable) set port qos 4/3 port-based Write the ACL to hardware. cat6k-access> (enable) commit qos acl ACL_VOIP_CONTROL Map the ACL_VOIP_CONTROL ACL to the Cisco CallManager port and the H.323 gateway port. cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2 cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/3 MGCP Cisco CallManager communicates with MGCP gateways using User Datagram Protocol (UDP) port The example below classifies MGCP control traffic from Cisco CallManager (4/2) and from the MGCP gateway (4/4) as DSCP AF31, which is backward compatible with IP Precedence

12 Server Farm Switch Selection Chapter 3 Step 3 Step 4 Step 5 Add an entry to the ACL_VOIP_CONTROL access list to marking all traffic from MGCP gateways with a DSCP value of AF31. cat6k-access> (enable) set qos acl ip ACL_VOIP_CONTROL dscp 26 udp any any eq 2427 Inform the Cisco CallManager port (4/2) that all QoS associated with the port will be done on a port basis cat6k-access> (enable) set port qos 4/2 port-based Inform the Cisco MGCP gateway port (4/4) that all QoS associated with the port will be done on a port basis cat6k-access> (enable) set port qos 4/4 port-based Write the ACL to hardware. cat6k-access> (enable) commit qos acl ACL_VOIP_CONTROL Map the ACL_VOIP_CONTROL ACL to the Cisco CallManager port and the MGCP gateway port. cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/2 cat6k-access> (enable) set qos acl map ACL_VOIP_CONTROL 4/4 Verifying the ACLs Use the following show command and its associated output for verifying that the ACLs are associated with the correct VLANs and ports. cat6k-access> (enable) sh qos acl map run all ACL name Type Vlans ACL_IP-PHONES IP 110,111,112 ACL name Type Ports ACL_IP-PHONES IP ACL name Type Vlans ACL_VOIP_CONTROL IP ACL name Type Ports ACL_VOIP_CONTROL IP 4/2,4/3,4/4 Mission-Critical Data As discussed earlier, the classification of any type of traffic as mission-critical could be a controversial move. Take care when classifying mission-critical data. The following configuration example uses a Catalyst 4006 with Supervisor III. In this example, the switch marks IP traffic to and from a specific TCP/IP address with a DSCP of AF21. Enable switch-wide QoS SUPIII-Access(config)#qos 3-12

13 Chapter 3 Server Farm Switch Selection To verify, issue the following command (shown with its associated output): 4006-SUPIII-Access#show qos QoS is enabled globally The default CoS-to-DSCP maps must be modified to allow us to trust CoS and maintain DSCP EF and AF31 for VoIP bearer and control traffic respectively SUPIII-Access#show qos map cos CoS-DSCP Mapping Table CoS: DSCP: Change the default CoS-to-DSCP mapping so that CoS 5 equates to EF, CoS 3 equates to AF31, and CoS 4 equates to AF SUPIII-Access(config)#qos map cos 3 to dscp SUPIII-Access(config)#qos map cos 4 to dscp SUPIII-Access(config)#qos map cos 5 to dscp 46 To verify, issue the following command (shown with its associated output): 4006-SUPIII-Access#show qos map cos CoS-DSCP Mapping Table CoS: DSCP: SUPIII-Access#show qos map dscp tx-queue DSCP-TxQueue Mapping Table (dscp = d1d2) d1 : d : : : : : : : Step 3 Turn on priority queuing. The default admission to the priority queue is sufficient for our requirements SUPIII-Access(config-if-tx-queue)#tx-queue SUPIII-Access(config-if-tx-queue)#priority high To verify, issue the following command (shown with its associated output): 4006-SUPIII-Access#show qos inter fa 3/4 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 N/A disabled N/A N/A disabled high N/A disabled N/A

14 Selecting an Access-Layer Switch Chapter 3 Step 4 Step 5 Step 6 Step 7 Create an ACL to identify the traffic to be marked SUPIII-Access(config)#ip access-list extended GOLD-DATA 4006-SUPIII-Access(config-ext-nacl)#remark Match IP Address of the application server 4006-SUPIII-Access(config-ext-nacl)#permit ip any host SUPIII-Access(config-ext-nacl)#permit ip host any Create classes that use the ACL as admission criteria SUPIII-Access(config)#class-map match-all GOLD-DATA 4006-SUPIII-Access(config-cmap)#description Mission Critical Traffic 4006-SUPIII-Access(config-cmap)#match access-group name GOLD-DATA Create a service policy that uses the classes for admission criteria and sets the appropriate DSCP label SUPIII-Access(config)#policy-map ACCESS-C4006-LAN-EDGE-IN 4006-SUPIII-Access(config-pmap)#description Set DSCP PerHopBehavior Label for Mission Critical Traffic 4006-SUPIII-Access(config-pmap)#class GOLD-DATA 4006-SUPIII-Access(config-pmap-c)#set ip dscp 18 Apply the service policy to an interface SUPIII-Access#ct Enter configuration commands, one per line. End with CNTL/Z SUPIII-Access(config)#int fa 3/ SUPIII-Access(config-if)#service-policy input ACCESS-C4006-LAN-EDGE-IN To verify, issue the following command (shown with its associated output): 4006-SUPIII-Access#show pol int fa 3/4 service-policy input: ACCESS-C4006-LAN-EDGE-IN class-map: GOLD-DATA (match-all) 0 packets match: access-group name GOLD-DATA set: ip dscp 18 class-map: class-default (match-any) 0 packets match: any 0 packets Selecting an Access-Layer Switch The Cisco portfolio of Catalyst switches offers a rich selection of access-layer devices. There are many criteria involved when selecting a device for this layer of your network. When AVVID solutions are involved, there is a base set of features required to support IP telephony, which is a major component of the AVVID solution. The switch must support multiple VLANs on the access port to which the IP phone is attached. This is currently supported via the voice VLAN command for IOS-based switches and the auxiliary VLAN command for Catalyst OS-based switches. The switch must be able to manipulate the IP phones trust boundary and marking capabilities. This functionality is supported via the switchport priority command in IOS-based switches and the trust-ext command in Catalyst OS-based switches. 3-14

15 Chapter 3 Selecting an Access-Layer Switch The switch must be able trust the CoS or DSCP marking that the IP phones provide. This is currently supported via the mls QoS trust CoS and mls QoS trust DSCP commands for IOS-based switches and the trust-cos and trust-dscp commands for Catalyst OS-based switches. As mentioned before (in the Server Farm Switch Selection section on page 3-6), there are times when the devices attached to an AVVID network do not classify their traffic with the appropriate Layer 2 and Layer 3 markings. When considering your choices for access-layer devices, consider the switch s ability to classify and mark traffic at the edge of the network via ACLs and service policies. This will allow QoS to be offered as a service throughout the network and administered at the edge of the network where CPU resources are plentiful, rather than at the distribution and core aggregation points where enforcement of QoS classification and marking could adversely affect network performance. Catalyst 6500 as an Access-Layer Switch One of the most popular campus configurations for Cisco AVVID solutions is to use Catalyst 6500 switches in both the wiring closet and the distribution and core layers. There are several compelling reasons for this: The Catalyst 6500 supports dual supervisor engines providing the highest availability of access solutions. The Catalyst 6500 can provide in-line power to the IP phones. The current 10/100 boards for the Catalyst 6500 support integrated inline power and are standard. The Catalyst 6500 offers the highest growth potential. The Catalyst 6500 supports advanced Layer 2/3 campus QoS tools. Figure 3-6 shows a general model for the Catalyst 6500 as an access device (as illustrated in the QoS configurations discussed in this chapter). 3-15

16 Selecting an Access-Layer Switch Chapter 3 Figure 3-6 General Model for Catalyst 6500 QoS Configurations Core Si Distribution Si Si Catalyst 6500 Access Catalyst 6500 w/ PFC VVID=110 IP VLAN= With the addition of the PFC, the Catalyst 6500 is capable of handling Layer 2, 3, and 4 QoS tasks. The PFC can be used to enable advanced QoS tools, such as packet classification and marking, scheduling, and congestion avoidance, based on either Layer 2 or Layer 3 and 4 header information. You can configure multiple receive and transmit queues with thresholds that can be used according to the QoS policy rules configured in the switch. There are also many versions of Catalyst 6500 line cards with varying QoS capabilities. (See Appendix A, Reference Information for a list of linecards and queuing mechanisms available for the Catalyst 6500.) The newest cards include enhanced QoS features that provide priority queuing capabilities for both ingress and egress interfaces. With the exception of the priority queue, which is always serviced as soon as frames are present, the queues are serviced in the WRR method. Each queue is given a user-configurable weight. By default, the high queue is given 98% of the scheduler time and the low queue is given 2%. This ratio is conducive to ensuring that packets with a low delay-tolerance are not delayed in a queue. This is also the reason behind giving the low queue a much higher percentage of the overall interface buffer. Note Because the Catalyst OS is designed for switches that operate in the closet and Native IOS is designed for switches that operate at the distribution layer of the network, a Catalyst 6500 that is functioning as an access-switch should be equipped with Catalyst OS. To see how a port is configured, issue the show port capabilities mod/port Catalyst OS command. The default QoS capabilities of the port can be changed using the set qos map and set qos wred-threshold commands. When modifying the queue thresholds, it is important to remember that the higher priority queue has a higher numerical value. 3-16

17 Chapter 3 Selecting an Access-Layer Switch After you have connected the IP phone to the access-layer switch, it is time to configure the QoS parameters on the switch. This includes setting up multiple queues on all ports, configuring access to the queues, setting thresholds for congestions avoidance, and connecting the switch to the distribution or core layer. For the Catalyst 6500, QoS requires the following changes to the configuration of the access switch: 1. Enable switch-wide QoS. 2. Configure the IP phone port queuing. 3. Configure the uplink interface to the distribution switch, including enabling trust for Ethernet frames coming into the trunk port, manipulating the CoS-to-queue mapping entrance criteria, and mapping the CoS and IP Precedence values to the appropriate DSCP value. Enabling QoS To enable QoS on the access-layer Catalyst 6500, do the following: Enable switch-wide QoS. cat6k-access> (enable) set qos enable Configuring IP Phone Port Queuing If you use a single cable to connect an IP phone, the access port is configured to trust the IP phone and not the attached PC. The port is also configured to use multiple transmit queues, one being a priority queue for voice traffic. Figure 3-7 Connecting an IP phone to a Catalyst 6500 Auxilary VLAN = 110 PC VLAN = 10 IP Catalyst 6500 w/ PFC IP Phone = IP Subnet 110 To configure IP phone port queuing, do the following: Desktop PC: IP Subnet Step 3 Step 4 Inform the port that all QoS associated with the port will be done on a VLAN basis. cat6k-access> (enable) set port qos 5/1-48 vlan-based Instruct the IP phone to rewrite CoS from the PC to CoS of 0 within the IP phone Ethernet ASIC. cat6k-access> (enable) set port qos 5/1-48 trust-ext untrusted Accept incoming Layer 2 CoS classification. (Current 10/100 version 1 linecards must still have trust-cos enabled even though the parser returns an error.) cat6k-access> (enable) set port qos 5/1-48 trust trust-cos Create an access list that accepts incoming Layer 3 ToS classification (necessary only on 10/100 ports). cat6k-access> (enable) set qos acl ip ACL_IP-PHONES trust-cos any 3-17

18 Selecting an Access-Layer Switch Chapter 3 Step 5 Step 6 Write the ACL to hardware. cat6k-access> (enable) commit qos acl ACL_IP-PHONES Map the access list to the Auxiliary VLAN. cat6k-access> (enable) set qos acl map ACL_IP-PHONES 110 Once QoS has been enabled on the Catalyst 6500 access-layer switch, you can use the following command to place all traffic with a CoS of 3 (VoIP control) into the second transmit queue (with a low drop threshold), to ensure successful call control during periods of heavy congestion. All traffic with a CoS of 5 (VoIP RTP Bearer) is placed into the second queue by default. cat6k-access> (enable) set qos map 2q2t tx 2 1 cos 3 Configuring the Uplink to the Distribution Switch Configuring Transmit Queues Once you have configured the access port queuing, you must also configure the uplink interfaces to the distribution, or core, switch. This involves enabling trust for Ethernet frames coming into the trunk port (1/1 in this example), manipulating the CoS-to-queue mapping entrance criteria, and mapping the CoS and IP Precedence values to the appropriate DSCP value. All VoIP (CoS of 5) traffic will be placed into the egress interface priority queue on 1p2q2t interfaces and queue 2 on 2q2t interfaces as soon as you enable QoS. However, you must perform the additional step of configuring the Catalyst 6500 CoS queue admission rules to ensure that traffic with a CoS of 3 (VoIP control) is placed into the second queue. Place CoS of 3 in queue 2 for 1p2q2t. cat6k-access> (enable) set qos map 1p2q2t tx 2 1 cos 3 Place CoS of 3 in queue 2 for 2q2t. cat6k-access> (enable) set qos map 2q2t tx 2 1 cos 3 Modifying CoS-to DSCP and IP Precedence-to-DSCP Mappings Cisco follows the IETF recommendations for setting the DSCP classification values for both the VoIP control plane traffic and VoIP bearer or media plane traffic. The recommended settings are DSCP of AF31 for VoIP control plane and DSCP of EF for VoIP bearer plane. To map the Layer 2 CoS and Layer 3 IP Precedence settings correctly to these DSCP values, you must modify the default CoS/IP Precedence-to-DSCP mappings. Modify the CoS-to-DSCP mappings. cat6k-access> (enable) set qos cos-dscp-map Modify the IP Precedence-to-DSCP mappings. cat6k-access> (enable) set qos ipprec-dscp-map

19 Chapter 3 Selecting an Access-Layer Switch Verifying the Configuration One of the fundamental processes of implementing QoS is verifying that the configurations are correct and are performing as expected. On the Catalyst 6500 access-layer switch, you can verify the configuration and performance during periods of high congestion by examining the output of the following commands: Command Description See show port qos mod/port Displays the QoS settings for the specified Example 3-1 port. show qos info runtime mod/port Displays QoS runtime information for the Example 3-2 specified port. show mac mod/port Displays Media Access Control TX ringmac) Example 3-3 information for the specified port. show qos statistics l3 Displays summary QoS statistics for all ports. Example 3-4 show qos stat mod/port Displays detailed QoS statistics for the Example 3-5 specified port. show qos map run cos-dscp-map Displays the CoS-to-DSCP mappings. Example 3-6 show qos map run ipprec-dscp-map Displays the IP Precedence-to-DSCP mappings. Example 3-7 Example 3-1 Displaying QoS Settings for a Port cat6k-access> (enable) show port qos 5/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 /1 vlan-based vlan-based COPS local Port TxPort Type RxPort Type Trust Type Trust Type Def CoS Def CoS config runtime config runtime /1 2q2t 1q4t trust-cos trust-cos* 0 0 Port Ext-Trust Ext-Cos /1 untrusted 0 (*)Runtime trust type set to untrusted. Config: Port ACL name Type No ACL is mapped to port 5/1. ACL is mapped to VLAN Runtime: Port ACL name Type No ACL is mapped to port 5/

20 Selecting an Access-Layer Switch Chapter 3 Example 3-2 Displaying QoS Runtime Information cat6k-access>(enable) show qos info run 5/1 Run time setting of QoS: QoS is enabled Policy Source of port 5/1: Local Current 10/100 "1" linecards support 2q2t/1q4t only Tx port type of port 5/1 : 2q2t Rx port type of port 5/1 : 1q4t Interface type: vlan-based ACL is mapped to VLAN 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 Queue and Threshold Mapping for 1q4t (rx): Queue Threshold CoS Example 3-3 Displaying MAC Information cat6k-access> (enable) show mac 5/1 Port Rcv-Unicast Rcv-Multicast Rcv-Broadcast / Port Xmit-Unicast Xmit-Multicast Xmit-Broadcast / Port Rcv-Octet Xmit-Octet / "Out-Discards" are packets drooped due to congestion in the tx interface buffers MAC Dely-Exced MTU-Exced In-Discard Out-Discard / Example 3-4 Displaying QoS Summary Statistics cat6k-access> (enable) show qos stat l3 VoIP Control packets that have been re-written with CoS=3/DSCP=26 (AF31) Packets dropped due to policing: 0 IP packets with ToS changed: 1885 IP packets with CoS changed: 781 Non-IP packets with CoS changed:

21 Chapter 3 Selecting an Access-Layer Switch Example 3-5 Displaying QoS Detailed Statistics cat6k-access> (enable) show qos stat 5/1 All packets dropped are in the 1st drop threshold of queue #1 Tx port type of port 5/1 : 2q2t Q # Threshold #:Packets dropped : pkts, 2:0 pkts 2 1:0 pkts, 2:0 pkts Rx port type of port 5/1 : 1q4t Q # Threshold #:Packets dropped :0 pkts, 2:0 pkts, 3:0 pkts, 4:0 pkts Example 3-6 Displaying CoS-to-DSCP Mappings cat6k-access> (enable) show qos map run cos-dscp-map CoS - DSCP map: CoS DSCP = AF31 Voice Control = AF41 IP Video Conferencing = EF Voice Bearer Example 3-7 Displaying IP Precedence-to-DSCP Mappings cat6k-access> (enable) show qos map run ipprec-dscp-map IP-Precedence - DSCP map: IP-Prec DSCP = AF31 Voice Control = AF41 IP Video Conferencing = EF Voice Bearer Catalyst 4000 as an Access-Layer Switch Another popular campus configuration for Cisco AVVID networks uses the Catalyst 2948G, the Catalyst 2980G, and the Catalyst 4000 family of switches in the wiring closets. There are several compelling reasons for this, including: The Catalyst 4006 can provide in-line power to the IP phones. The Catalyst 4000 offers a very low price per port. These switches provide extremely scalable, high-speed switching. Starting with Catalyst OS Release 5.2, the Catalyst 4000 switches support dual-transmit queues on every interface. Admission to the queues is based on Layer 2 CoS markings and is configurable in 802.1p user priority pairs. 3-21

22 Selecting an Access-Layer Switch Chapter 3 Note From a configuration perspective, the Catalyst 2948G, the Catalyst 2980G, and the Catalyst 4000 family of switches are the same. Therefore, the configuration of only one, the Catalyst 4000, is shown in this section. Catalyst 4000 with Supervisor III The Catalyst 4000 Supervisor III introduces many enhanced QoS features to the Catalyst 4000, including four queues per port with a configurable priority queue. Figure 3-8 shows a general model for the Catalyst 4000 with Supervisor III as an access device (as illustrated in the QoS configurations discussed in this chapter). Figure 3-8 General Model for Catalyst 4000 with Supervisor III QoS Configurations Core Si Distribution Si Si Catalyst 6500 Access Catalyst 4000 VVID=111 IP VLAN= This section presents suggested configurations for port scheduling and queuing on the Catalyst 4000 with Supervisor III. In general: The recommended configuration for the receive interface is FIFO one standard FIFO queue. The recommended configuration for the transmit interface is 1P3Q1T one priority queue (when configured) and three queues with a single threshold. Scheduling is done on a WRR basis. Admission to the queues is based on IP DSCP value and is user configurable. 3-22

23 Chapter 3 Selecting an Access-Layer Switch For the Catalyst 4000 with Supervisor III, QoS requires the following changes to the configuration of the access switch: 1. Enable QoS globally. 2. Modify the default CoS-to-DSCP mapping so that CoS 3 = AF31, CoS 4 = AF41, and CoS 5 = EF. 3. Enable priority queuing (per port). The default admission criteria for the priority queue matches our requirements. 4. Configure an ACL to identify traffic to be marked, associate it with a service policy, and apply the service policy to the interface. 5. Configure a port to support an IP phone. 6. Configure uplink scheduling and trust (CoS or DSCP). Enabling QoS To enable QoS on the access-layer Catalyst 4000 with Supervisor III, do the following: Enable switch-wide QoS SUPIII-Access(config)#qos Modifying the CoS-to-DSCP Mappings There are 8 CoS labels and 64 possible DSCP labels. To trust the CoS markings, the default CoS-to-DSCP mapping table must be modified to equate CoS 3 (VoIP control traffic) to AF31, CoS 5 (VoIP bearer traffic) to EF, and CoS 4 (video conferencing) to AF41. The default CoS-to-DSCP mappings are as follows: 4006-SUPIII-Access#show qos map cos CoS-DSCP Mapping Table CoS: DSCP: Change the default mapping table so that CoS 3 = AF31, CoS 4 = AF41, and CoS 5=EF.Remember to use the decimal equivalents SUPIII-Access(config)#qos map cos 3 to dscp SUPIII-Access(config)#qos map cos 4 to dscp SUPIII-Access(config)#qos map cos 5 to dscp 46 Enabling Priority Queuing To enable priority queuing, do the following: Note In the Catalyst 4000 with Supervisor III, only queue number 3 can be enabled for priority queuing. 3-23

24 Selecting an Access-Layer Switch Chapter 3 Specify the transmit queue SUPIII-Access(config-if-tx-queue)#tx-queue 3 Set the priority to high SUPIII-Access(config-if-tx-queue)#priority high Configuring ACLs There are times when classification of traffic by the access-layer switch is required. The Catalyst 4000 with Supervisor III has a powerful set of features that allow traffic to be classified as it enters the network. To classify VoIP bearer and control traffic as it enters the network, do the following: Step 3 Create an ACL to match the traffic to be prioritized SUPIII-Access(config)#ip access-list extended GOLD-DATA 4006-SUPIII-Access(config-ext-nacl)#remark Match IP Address of the application server 4006-SUPIII-Access(config-ext-nacl)#permit ip any host SUPIII-Access(config-ext-nacl)#permit ip host any 4006-SUPIII-Access(config)#ip access-list extended VOICE 4006-SUPIII-Access(config-ext-nacl)#remark Match the UDP ports that VoIP Uses for Bearer Traffic 4006-SUPIII-Access(config-ext-nacl)#permit udp any any range SUPIII-Access(config)#ip access-list extended VOICE-CONTROL 4006-SUPIII-Access(config-ext-nacl)#remark Match VoIP Control Traffic 4006-SUPIII-Access(config-ext-nacl)#remark SCCP 4006-SUPIII-Access(config-ext-nacl)#permit tcp any any range SUPIII-Access(config-ext-nacl)#remark H323 Fast Start 4006-SUPIII-Access(config-ext-nacl)#permit tcp any any eq SUPIII-Access(config-ext-nacl)#remark H323 Slow Start 4006-SUPIII-Access(config-ext-nacl)#permit tcp any any range SUPIII-Access(config-ext-nacl)#remark H323 MGCP 4006-SUPIII-Access(config-ext-nacl)#permit udp any any eq 2427 Create classes based on the ACL SUPIII-Access(config)#class-map match-all GOLD-DATA 4006-SUPIII-Access(config-cmap)#description Mission Critical Traffic 4006-SUPIII-Access(config-cmap)#match access-group name GOLD-DATA 4006-SUPIII-Access(config)#class-map match-all VOICE 4006-SUPIII-Access(config-cmap)#description VoIP Bearer Traffic 4006-SUPIII-Access(config-cmap)#match access-group name VOICE 4006-SUPIII-Access(config)#class-map match-all VOICE-CONTROL 4006-SUPIII-Access(config-cmap)#description VoIP Control Traffic (SCCP, H225, H254, MGCP) 4006-SUPIII-Access(config-cmap)#match access-group name VOICE-CONTROL Create a policy to set the DSCP PHB label for the classes SUPIII-Access(config)#policy-map ACCESS-C4006-LAN-EDGE-IN 4006-SUPIII-Access(config-pmap)#description Set DSCP PerHopBehavior Label for VOIP Control and Bearer Traffic 4006-SUPIII-Access(config-pmap)#class VOICE-CONTROL 4006-SUPIII-Access(config-pmap-c)#set ip dscp SUPIII-Access(config-pmap)#class VOICE 4006-SUPIII-Access(config-pmap-c)#set ip dscp SUPIII-Access(config-pmap)#class GOLD-DATA 4006-SUPIII-Access(config-pmap-c)#set ip dscp

25 Chapter 3 Selecting an Access-Layer Switch Step 4 Apply the policy to a physical interface SUPIII-Access(config)#int fa 4/ SUPIII-Access(config-if)#service-policy input ACCESS-C4006-LAN-EDGE-IN Configuring Access-Layer Phone Support When the Catalyst 4000 with Supervisor III is connected to an IP phone, do the following: Step 3 Step 4 Configure the switch to trust CoS from the IP Phone SUPIII-Access(config)#int fa 4/ SUPIII-Access(config-if)#qos trust cos Enable the voice and data VLANs SUPIII-Access(config-if)#switchport voice vlan SUPIII-Access(config-if)#switchport access vlan 11 Set the IP Phones trust boundary SUPIII-Access(config-if)#switchport priority extend cos 0 While in interface configuration mode, enable priority queueing on the port. Note In the Catalyst 4000 with Supervisor III, only queue number 3 can be enabled for priority queuing SUPI(config-if-tx-queue)#tx-queue SUPI(config-if-tx-queue)#priority high Configuring the Uplink to the Distribution Switch The ports attached to the distribution layer require a slightly different configuration. These ports must be configured to trust DSCP or CoS depending on the capabilities of the distribution-layer switch attached. In the following configuration, port 3/1 is attached to a Layer 3-aware distribution device and can trust DSCP arriving from it. Port 3/2 illustrates an example where CoS-only classification is used. Note The system-wide CoS-to-DSCP mapping and DSCP-to-queue admission criteria configurations must have been completed and the priority queue must be enabled for these ports in order for the access-layer uplink ports to perform QoS as expected. Configure DSCP trust SUPIII-Access(config)#int g 3/ SUPIII-Access(config-if)#qos trust dscp Enable the priority queue on this interface SUPI(config-if-tx-queue)#tx-queue SUPI(config-if-tx-queue)#priority high 3-25

26 Selecting an Access-Layer Switch Chapter 3 Step 3 Step 4 Configure CoS trust SUPIII-Access(config-if)#int g 3/ SUPIII-Access(config-if)#qos trust cos Enable the priority queue on this interface SUPI(config-if-tx-queue)#tx-queue SUPI(config-if-tx-queue)#priority high Verifying the Configuration On the Catalyst 4000 access-layer switch, you can verify the configuration and performance during periods of high congestion by examining the output of the following commands: Command Description See show qos map cos Displays the QoS CoS mapping information. Example 3-8 show qos map dscp Displays the QoS DSCP mapping information. Example 3-9 show qos interface interface Displays QoS queuing information. Example 3-10 show policy-map interface Displays statistics and configurations of input Example 3-11 and output policies attached to an interface. show interface counters Displays statistics regarding traffic seen on the physical interface. Example 3-12 Example 3-8 Displaying QoS CoS Mapping Information 4006-SUPIII-Access#show qos map cos CoS-DSCP Mapping Table CoS: DSCP: Example 3-9 Displaying QoS DSCP Mapping Information 4006-SUPIII-Access#show qos map dscp tx-queue DSCP-TxQueue Mapping Table (dscp = d1d2) d1 : d : : : : : : :