Cisco Advanced Services - build kr · PDF fileCisco Advanced Services LAN Campus QoS Design...

Cisco Advanced Services

LAN Campus QoS Design

Version 1.2 Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100

May 23, 2006 LAN QoS Standard Design A printed copy of this document is considered uncontrolled.

2

Legal Notice

THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS DOCUMENT ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company.

Copyright © 2009 Cisco Systems, Inc. All rights reserved.


3

Contents

Contents ...................................................................................................................................... 2

Document Purpose..................................................................................................................... 5

Sample Network Design............................................................................................................. 6

Network Characteristics........................................................................................................ 6

QoS Overview ........................................................................................................................... 10

QoS Requirements .............................................................................................................. 10 Voice .................................................................................................................................................... 10 Voice (Bearer Traffic) ......................................................................................................................... 10 Call Signaling Traffic .......................................................................................................................... 11 Data Applications................................................................................................................................. 12 Best Effort Data ................................................................................................................................... 12 IP Routing ............................................................................................................................................ 12

Design and Configuration Recommendations ....................................................................... 13

Connection Classes ............................................................................................................ 13 Customer Port Class............................................................................................................................. 13 Network Port Class .............................................................................................................................. 13

Application Classification and Marking ............................................................................. 14 Sample Classification and Marking at Campus .................................................................................. 14 2950 Classification and Marking......................................................................................................... 15 3560 Classification and Marking......................................................................................................... 16 4500 Classification and Marking......................................................................................................... 18 6500 Classification and Marking......................................................................................................... 18

Queuing................................................................................................................................ 23 Queuing at Campus............................................................................................................. 24

Catalyst 2950 Queuing......................................................................................................................... 24 Catalyst 3560 Queuing......................................................................................................................... 25 Catalyst 4500 Queuing......................................................................................................................... 27 Catalyst 6500 Queuing......................................................................................................................... 29 Catalyst 6500 – 1P2Q2T Queuing....................................................................................................... 30 Catalyst 6500 – 2Q2T Queuing ........................................................................................................... 31 Cisco 7200 Queuing............................................................................................................................. 32

Creating a Service Policy.................................................................................................... 34


4

Attaching a Service Policy to an Interface......................................................................... 34

Appendix 1 – Buffer Size & Queues by 6500 Modules........................................................... 36

Catalyst 6500 Linecard Queuing Structure........................................................................ 36

Appendix 2 - Configuration Templates ................................................................................... 38

Catalyst 2950 QoS Configuration Template....................................................................... 38 Catalyst 3560 QoS Configuration Template....................................................................... 39 Catalyst 4500 QoS Configuration Template....................................................................... 40 Catalyst 6500 QoS Configuration Template (CatOS) ........................................................ 41 Catalyst 6500 QoS Configuration Template (IOS) ............................................................. 42 Catalyst 6500 MPLS/PE QoS Configuration Template (IOS)............................................. 42 Cisco 7200 QoS Configuration Template (IOS) ................................................................. 44

Appendix 3 – IP Type of Service (ToS).................................................................................... 46

Appendix 4 – QoS Baseline Marking Scheme ........................................................................ 47

Appendix 5 – QoS Marking Policy (Example) ......................................................................... 48


5

Document Purpose

The purpose of this document is to assist in defining LAN switch configuration standards.

The scope of this document is currently restricted to providing an appropriate QoS conceptual strategy, and providing sample configurations based on the defined marking schema.

This document does not specifically cover intrinsic IP Telephony infrastructure devices, such as Call Managers / Gatekeepers or any other video / mission-critical data-based applications requiring preferential treatment within the LAN.

The recommendations that have been made are in-line with the current Cisco QoS Baseline initiatives. These RFC-based initiatives make QoS transparent by standardizing the way traffic is classified and handled. Adjustments to the recommendations are foreseen -in terms of QoS packet-marking, and transmit-queue scheduling and congestion avoidance.

This document incorporates Cisco’s experience and leading practices into the design process to reduce risks and promote success. The recommendations in this document are based on Cisco’s network design leading practices that have been developed through many years of experience involving the design and deployment of thousands of customer networks. Each section of this document focuses on a specific set of issues.


6

Sample Network Design

This sample network consists of different parts; these all will need to be enabled with QoS, and some of these reside in the datacenter while other devices in the edge or core. As QoS is end to end, all have to take part and play their role. The QoS policies which are described herein will mainly focus on the devices used in a campus network design where IPT has already been implemented

This document highlights design decisions that are based on the following principles and leading practices:

• Mark traffic as near to the source as possible.

• Define the trust boundary as near to the user as possible.

• Limit QoS in the Core (to 3-4 classes max.)

• Protect the network from excessive use by user applications.

• Keep the policy as simple as possible

• Promote only traffic which needs to have special treatment.

• Use default settings unless there is a very valid reason to adjust or tune to meet QoS requirements.

• If providing QoS within a MPLS network and you are acting as a Service Provider, make sure the MPLS part will have its own QoS policy and the customers’ policies are mapped towards the QoS policy of the MPLS network.

QoS is not a substitute for bandwidth; it is the reallocation of resources to provide preferential treatment for business/mission critical applications

The following sections give an overview of the QoS concept proposed. These sections address several crucial areas of the QoS design including traffic classification, queuing, and topologies in the LAN part of the network.

Network Characteristics Figures 1 and 2 show schematic sketches of the network and the buildings in the campus where QoS capabilities need to be implemented.

The core of the campus consists of an MPLS Network with 14 Catalyst 6509 switches (C1). Each of these core switches has MPLS PE (Provider Edge) capabilities by providing connectivity to either the L3 Building networks inside the campus or to the worldwide Corporate Network VPN.

The network in building C102 is based on two redundant Catalyst 4500 switches (D2) in the distribution layer providing default Gateway functionality. The access layer is based on several Catalyst 3560 switches with inline power (A1). Voice (or ‘auxiliary’) VLANs are created in the building infrastructure in addition to data VLANs. The Catalysts 3560 switches are connected to each Catalyst 4500 via Gigabit Ethernet uplinks. The Catalyst 3560 Series 24 and 48 port switches in the access layer and Catalyst 4500 Series switches in the distribution layer will support the separate QoS requirements for voice & voice control traffic and data. Due to the requirements of having a common port setup regardless of connecting IP Phones or other devices the access-switches need to classify and remark the traffic accordingly.

In building C102 we also have one analog voice gateway VG248 which provides 48 FXS ports for analog end devices. This analog voice gateway is directly connected to one of the distribution switches.

Building C301 consists of some Catalyst 2950 switches (A2) which are used to provide LAN connectivity to the Siemens HiPath PBX. The connection to the MPLS Core is via 2 Cisco 7200 Router (R1). Two digital voice gateways (R2) will also be used in the IP Telephony (IPT) network, two C3725 Routers, one at building W008 and one at building C301.

In Building B151 we have two Catalyst 6509 acting as distribution switches (D1) where the Cisco Call Managers are connected.


7

Figure 1 Current Network Topology (IPT)


8

Figure 2 End-to-End QoS Mechanisms and Topology

12 AB

C3 DE

F

45 JK

L6

MN

OG

HI 7

8 TUV

9W

XY

ZP

QR

S *0

OP

ER

#

7960

CIS

CO

IP

PHO

NE

im

ess

ages

dire

cto

ries

setti

ngs

serv

ices


9

The following table describes the different hardware devices per network component:

Table 1 Hardware Matrix

Network Component 2950 3650 4500/

SupIV 6500/ Sup720/ IOS

6500/ Sup2/ IOS

6500/ Sup2/ CatOS

3725 720x-NPE300

A1 x A2 x D1 x x D2 x

C1 x R1 x R2 x


10

QoS Overview

QoS is the measure of transmission quality and service availability of a network (or internetworks). Service availability is a crucial foundation element of QoS. The network infrastructure must be designed to be highly available before you can successfully implement QoS. The target for High Availability is 99.999 % uptime, with only five minutes of downtime permitted per year. The transmission quality of the network is determined by the following factors:

• Loss - A relative measure of the number of packets that were not received compared to the total number of packets transmitted. Loss is typically a function of availability. If the network is Highly Available, then loss during periods of non-congestion would be essentially zero. During periods of congestion, however, QoS mechanisms can determine which packets are more suitable to be selectively dropped to alleviate the congestion.

• Delay - The finite amount of time it takes a packet to reach the receiving endpoint after being transmitted from the sending endpoint. In the case of voice, this is the amount of time it takes for a sound to travel from the speaker’s mouth to a listener’s ear.

• Delay variation (Jitter) - The difference in the end-to-end delay between packets. For example, if one packet requires 100 ms to traverse the network from the source endpoint to the destination endpoint and the following packet requires 125 ms to make the same trip, then the delay variation is 25 ms.

Each end station in a Voice over IP (VoIP) or Video over IP conversation uses a jitter buffer to smooth out changes in the arrival times of voice data packets. Although jitter buffers are dynamic and adaptive, they may not be able to compensate for instantaneous changes in arrival times of packets. This can lead to jitter buffer over-runs and under-runs, both of which result in an audible degradation of call quality.

Even though it might seem that there is sufficient bandwidth on LAN links it is always recommended to implement at least low latency queuing

QoS Requirements

Voice Voice quality is directly affected by two major factors:

• Lost packets

• Delayed packets VoIP deployments require provisioning explicit priority servicing for VoIP (bearer stream) traffic and a guaranteed bandwidth service for Call-Signaling traffic. These related classes will be examined separately.

Voice (Bearer Traffic) A summary of the key QoS requirements and recommendations for Voice (bearer traffic) are:

• Voice traffic should be marked to DSCP EF per the QoS Baseline and RFC 3246.

• Loss should be no more than 1 %.

• One-way Latency (mouth-to-ear) should be no more than 150 ms.

• Average one-way Jitter should be targeted under 30 ms.


11

• 21–320 kbps of guaranteed priority bandwidth is required per call (depending on the sampling rate, VoIP codec and Layer 2 media overhead).

Voice quality is directly affected by all three QoS quality factors: loss, latency and jitter.

Packet loss causes voice clipping and skips. The packetization interval determines the size of samples contained within a single packet. Assuming a packetization interval of 20 ms (default) has been set, the loss of two or more consecutive packets results in a noticeable degradation of voice quality.

Network congestion can lead to both packet drops and variable packet delays. Voice packet drops from network congestion are usually caused by full transmit buffers on the egress interfaces somewhere in the network. As links or connections approach 100% utilization, the queues servicing those connections become full. When a queue is full, new packets attempting to enter the queue are discarded. Because network congestion can be encountered at any time within a network, buffers can fill instantaneously. This instantaneous buffer utilization can lead to a difference in delay times between packets in the same voice stream. This difference, called jitter, is the variation between when a packet is expected to arrive and when it actually is received. To compensate for these delay variations between voice packets in a conversation, VoIP endpoints use jitter buffers to turn the delay variations into a constant value so that voice can be played out smoothly. VoIP networks are typically designed for very close to zero percent VoIP packet loss, with the only actual packet loss being due to L2 bit errors or network failures

Packet delay can cause either voice quality degradation due to the end-to-end voice latency or packet loss if the delay is variable. If the end-to-end voice latency becomes too long (250 ms, for example), the conversation begins to sound like two parties talking on a CB radio. If the delay is variable, there is a risk of jitter buffer overruns at the receiving end. Eliminating drops and delays is even more imperative when including fax and modem traffic over IP networks. If packets are lost during fax or modem transmissions, the modems are forced to "retrain" to synchronize again.

Because of its strict service-level requirements, VoIP is well suited to the Expedited Forwarding Per-Hop Behavior, as defined in RFC 3246 (formerly RFC 2598). It should therefore be marked to DSCP EF (46) and assigned strict priority servicing at each node, regardless of whether such servicing is done in hardware (as in Catalyst switches via hardware priority queuing) or in software (as in Cisco IOS routers via LLQ).

Call Signaling Traffic The following are key QoS requirements and recommendations for Call-Signaling traffic:

• Call-Signaling traffic should be marked as DSCP CS3 per the QoS Baseline (during migration, it may also be marked the legacy value of DSCP AF31).

• 150 bps (plus Layer 2 overhead) per phone of guaranteed bandwidth is required for voice control traffic; more may be required, depending on the call signaling protocol(s) in use.

Call-Signaling traffic was originally marked by Cisco IP Telephony equipment to DSCP AF31. However, the Assured Forwarding classes, as defined in RFC 2597, were intended for flows that could be subject to markdown and – subsequently – the aggressive dropping of marked-down values. Marking down and aggressively dropping Call-Signaling could result in noticeable delay-to-dial-tone (DDT) and lengthy call setup times, both of which generally translate to poor user experiences.

The QoS Baseline changed the marking recommendation for Call-Signaling traffic to DSCP CS3 because Class Selector code points, as defined in RFC 2474, were not subject to markdown/aggressive dropping. Some Cisco IP Telephony products have already begun transitioning to DSCP CS3 for Call-Signaling marking. In this interim period, both code-points (CS3 and AF31) should be reserved for Call-Signaling marking until the transition is complete.

Call signaling protocols include (but are not limited to) H.323, H.225, Session Initiated Protocol (SIP) and Media Gateway Control Protocol (MGCP). Each call signaling protocol has unique TCP/UDP ports and traffic patterns that should be taken into account when provisioning QoS policies for them.


12

Data Applications There are hundreds of thousands of data networking applications. Some are TCP, others are UDP; some are delay sensitive, others are not; some are bursty in nature, others are steady; some are lightweight, others require high bandwidth, and so on. Not only do applications vary one from another, but even the same application can vary significantly in one version to another. Given this, how best to provision QoS for data is a daunting question. The Cisco QoS Baseline identifies four main classes of data traffic, according to their general networking characteristics and requirements. These classes are Best Effort, Bulk Data, Transactional/Interactive Data and Locally-Defined Mission-Critical Data.

We assume a current business driver is VoIP traffic, meaning all data traffic will receive best-effort treatment. Therefore only Best Effort Data will be considered here.

Best Effort Data The Best Effort class is the default class for all data traffic. An application will be removed from the default class only if it has been selected for preferential or deferential treatment.

When addressing the QoS needs of Best Effort data traffic, Cisco recommends the following guidelines:

• Best Effort traffic should be marked to DSCP 0.

• Adequate bandwidth should be assigned to the Best Effort class as a whole, because the majority of applications will default to this class; reserve at least 25 percent for Best Effort traffic.

Because enterprises have several hundred, if not thousands, of data applications running over their networks (of which, the majority will default to the Best Effort class), you need to provision adequate bandwidth for the default class as a whole, to handle the sheer volume of applications that will be included in it. Cisco therefore recommends that you reserve at least 25 percent of link bandwidth for the default Best Effort class.

IP Routing Unless the network is up and running, QoS is irrelevant. Therefore, it is critical to provision QoS for control plane traffic, which includes IP Routing traffic and Network Management. By default, Cisco IOS software (in accordance with RFC 791 and RFC 2474) marks Interior Gateway Protocol (IGP) traffic such as Routing Information Protocol (RIP/RIPv2), Open Shortest Path First (OSPF), and Enhanced Interior Gateway Routing Protocol (EIGRP) to DSCP CS6.

When addressing the QoS needs of IP Routing traffic, Cisco recommends the following guideline:

• IP Routing traffic should be marked to DSCP CS6; this is default behavior on Cisco IOS platforms.


13

Design and Configuration Recommendations

Because we assume the current business driver for Quality of Service in the Campus Network is Voice, Voice over IP (VoIP) traffic, using either Cisco or non-Cisco IP Phones, should be granted priority across the LAN Network Devices. For that reason, the focus of this network is to provision explicit priority servicing for VoIP traffic as well as to guarantee bandwidth service for Call-Signaling and Control traffic. No distinction in regard to the Data Application traffic will be done, so all other traffic will receive best-effort treatment.

This implies separate queuing of voice and voice control traffic and data traffic within the Catalysts. The LAN infrastructure must also be resilient to device failures. In particular a single node failure should not result in loss of connectivity to all devices in the VLANs, or in the loss of connectivity to the PSTN networks.

Connection Classes The access to the network is mainly done using the following classes:

Customer Port Class:

• Normal PC connected.

• Cisco IP phone connected.

• PC with Cisco Communicator connected

• Siemens phone connected.

Network Port Class:

• Call Managers

• Voice Gateways

• Application servers

• Siemens HiPath

Customer Port Class In these situations, the best thing is to create either a connection class per port and translate this to the network devices or create a universal policy to do the marking. The latter is more uniform.

Using a uniform marking schema requires the platform to be able to handle layer 4 port ranges so that traffic can be classified correctly. Some of the platforms used would not be able to perform this function. Depending on the location in the network this is needed or not. This is called the trust boundary and the trust boundary in a network is determined by what device is trusted or not trusted concerning the marking.

Network Port Class Certain network devices could be trusted to do the marking properly as these are network based devices like Call Managers (soft PABX) or other devices like database servers.


14

Application Classification and Marking Following are some guidelines and principles that adhere to Cisco leading practices:

Cisco recommends using DSCP marking whenever possible, because these are end-to-end, more granular and more extensible than Layer 2 markings. Layer 2 markings are lost when media changes (such as LAN-to-WAN/VPN edge). There is also less marking granularity at Layer2. For example, 802.1Q/p CoS supports only 3 bits (values 0-7), as does MPLS EXP. Therefore, only up to eight classes of traffic can be supported at Layer 2, and inter-class relative priority (such as RFC 2597 Assured Forwarding Drop Preference markdown) is not supported. On the other hand, Layer 3 DSCP marking allow up to 64 classes of traffic, which is more than enough for most enterprise requirements for the foreseeable future. It is recommended to follow standards-based DSCP1 PHB markings in the entire network to ensure interoperability and future expansion When classifying and marking traffic, an unofficial Differentiated Services design principle is to classify and mark applications as close to their sources as technically and administratively feasible. This principle promotes end-to-end Differentiated Services and Per-Hop Behaviors (PHBs). Do not trust markings that can be set by users PCs or network devices that are NOT under your administrative control. If you not follow this rule you might receive unauthorized non-real time traffic marked with DSCP EF that could easily hijack the priority queues, thus ruin the service quality of real time applications in your network.

Sample Classification and Marking at Campus We will use the classification scheme which is shown in Figure 3. It consists of 4 traffic classes were we differentiate between Voice, Signaling, Control traffic. All the Data traffic will be mapped to Best Effort class. On the Access-Layer Switches, packets will be classified with extended access lists (ACLs). These ACLs can match packets on Source/Destination IP address, protocol type, and UDP/TCP port numbers. After classification, packets need to be marked with their appropriate DSCP value.

Figure 3 Classification and Marking Scheme

If a more complex schema is needed in the near future, it should be incorporated into this schema to avoid a duplicate design effort later. This document will only focus on the above mentioned scheme.

It was decided to have a common port setup on the Access-Switches regardless on what device (Cisco Phones, Siemens Phones, PC-SoftPhone, PCs) will be connected to. However, trusting end users and their PCs is generally a bad idea because newer operating systems like Windows XP and Linux make it

1 standards-based DSCP PHBs :

RFC 2474 class selector code points

RFC 2597 assured forwarding classes

RFC 3246 expedited forwarding)


15

relatively easy to set CoS and DSCP markings on PC NICs. This leads to the fact that we can’t trust the Endpoints and therefore rely on the untrusted Endpoint model. Previous –set markings of the Endpoints are overridden as required at the Access-Switch trust boundary (Figure 4) by the use of extended ACLs matching on L3 and L4 traffic information. This of course requires that the Switches in the access-layer support marking based L3 and L4 information.

An additional layer of protection can be offered by access edge policers. As stated previously, the tighter the policers the better, provided that adequate bandwidth is permitted for legitimate applications. This can be achieved by the use of per-port policers.

For example, the peak amounts of legitimate voice or call signaling traffic originating from the voice or data VLAN on a per-port basis are:

• 128 kbps for Voice traffic, marked CoS 5/DSCP EF (320 kbps in the case of G.722 codecs)

• 32 kbps for call signaling traffic (marked CoS 3/DSCP AF31 or CS3)

There should not be any other voice or call signaling traffic originating from the voice or data VLAN, so the policer can be configured to remark or drop anything else because such traffic is considered illegitimate and indicative of an attack.

Figure 4 Trust Boundaries

The primary function of access edge policies is to establish and enforce trust boundaries. A trust boundary is the point within the network where markings such as CoS or DSCP begin to be accepted

2950 Classification and Marking The Catalyst 2950 has limited marking capabilities and some platform-specific caveats. Some of them are listed below:

• The range keyword cannot be used in the ACLs being referenced by the class-map. Therefore, a policy to mark UDP flows in the port range of 16384 through 32767 cannot be configured on the Catalyst 2950. So it can not analyze the traffic from the ports and recognize the voice call. The problem does not impact the control traffic but does for the voice bearer traffic, which is the most important part. Workarounds are available if using phones and putting the trust boundary at these IP phones.

• User-defined masks must be consistent for all ACLs being referenced by class maps (if filtering is being done against TCP/UDP ports, then all Access Control Entries (ACEs) should be set to filter by TCP/UDP ports. As opposed to some ACEs filtering by ports and others by subnet or host addresses)

• System-defined masks (such as permit ip any any) cannot be used in conjunction with user-defined masks (such as permit tcp any any eq 3200) within the same policy map; therefore, if some traffic is


16

being matched against TCP/UDP ports, then a final ACE cannot be used to match all other traffic via permit ip any any statement)

• Only standard DSCP values are supported (0, 8, 10, 16, 18, 24, 26, 32, 34, 40, 46, 48, and 56); therefore traffic cannot be marked to non-standard DSCP values

• There is the possibility to prevent certain classes from sending too much traffic using policing. The granularity of this platform is 1 Mbps

Due to these limitations, it is not recommended to use a Catalyst 2950 to support an untrusted PC running SoftPhone. This would disqualifies it be used for classification and marking in the network.

Nevertheless this platform can be used in a part of the network where all traffic can be ‘trusted’ and no remarking of traffic has to take place (Trusted Endpoint Model).

QoS on the 2950 is always ‘enabled’; there is no command to switch it off.

A Configuration template where we Trust the endpoint on the ingress ports for the Catalyst 2950 Switch is shown below:

! ! Cat 2950 Marking Configuration ! !QoS is always enabled and can’t be disabled ! interface FastEthernet0/2 !Access-Ports mls qos trust dscp !Trust ingress traffic ! interface GigabitEthernet0/1 !Uplink-Port to/from Distribution mls qos trust dscp

!Use this configuration on all untrusted ports !Trust state of all ports is un-trusted (default) !On ingress ports remark all inbound data packets with COS=0 & DSCP=0 ! interface FastEthernet0/1 mls qos cos override

3560 Classification and Marking The 3560 access switch in the model will connect the Customer Class Devices to the network. This platform is highly intelligent and can recognize port ranges and has a more granular policing capability in comparison with the 2950. Default for this platform is QoS disabled. The port ASICs used act as FIFO buffers. The platform is capable of ingress and egress QoS. The ingress QoS will play a part if the platform forwarding capabilities are reached. The performance of this platform is in the Multiple Gbps. In this architecture it will not be a problem. This chapter will focus on the egress queuing as it is far more likely that congestion will take place there.

This platform is part of the trust boundary in the network. It will perform remarking of the traffic and will do queuing. QoS is globally disabled by default on the Catalyst 3560. While QoS is disabled, all frames/packets are passed-through the switch unaltered (which is equivalent to a trust CoS and trust DSCP state on all ports). When QoS is globally enabled, however, all DSCP and CoS values are (by default) set to 0 (which is equivalent to an untrusted state on all ports).

Configuration templates for over-riding QoS marking on ingress ports for the Catalyst 3560 Switch are described below:

! ! Cat 3560 Marking Configuration ! !*Enable Global QoS – This will rewrite all QoS markings to zero by default.* ! mls qos ! !*Matches VoIP Payload – RTP Packets* !


17

class-map match-all Voice_Payload match access-group name acl_VoIP_Payload ! !*Matches VoIP Signaling Packets* ! class-map match-all Voice_Control match access-group name acl_VoIP_Control ! !*Applies actions to the matched traffic. In this case, we mark the payload and signaling !packets with specific DSCP values.* ! policy-map Edge_QoS_Marking class Voice_Payload set ip dscp ef !Voice traffic will be remarked to DSCP 46/EF police 128000 8000 exceed-action drop !only one voice call is permitted per switchport class Voice_Control set ip dscp cs3 !Call signaling traffic will be remarked to DSCP 24/CS3 police 32000 8000 exceed-action drop !out-of-profile call signaling will be dropped ! !*Apply QoS policies to interfaces. Apply to all VoIP ports* ! interface FastEthernet0/2 ! Access-Ports description VoIP or Data only Port switchport access vlan 816 switchport voice vlan 817 service-policy input Edge_QoS_Marking !Attaches policy ! interface GigabitEthernet0/1 ! Uplink-Port to/from Distribution switchport trunk encapsulation dot1q switchport trunk allowed vlan 816,817 switchport mode trunk mls qos trust dscp !Trust ingress traffic from the distribution ! !*ACL to capture RTP Voice Packets.* ! ip access-list extended acl_VoIP_Payload remark VoIP-ACL for Cisco - VoIP-Payload (RTP) permit udp any range 16384 32767 any permit udp any any range 16384 32767 remark VoIP-ACL for Siemens Phone - VoIP-Payload (RTP/RTCP) permit udp any range 29100 29159 any permit udp any any range 29100 29159 remark VoIP-ACL for Siemens Access Point - VoIP-Payload (RTP/RTCP) permit udp any range 4352 25599 any permit udp any any range 4352 25599 remark VoIP-ACL for Siemens HiPath - VoIP-Payload (RTP/RTCP) permit udp any range 15000 16000 any permit udp any any range 15000 16000 ! !*ACL to capture Voice Signaling Packets.* ! ip access-list extended acl_VoIP_Control remark VoIP-ACL for Cisco - MGCP Control permit udp any eq 2427 any permit udp any any eq 2427 remark VoIP-ACL for Cisco - MGCP Backhaul permit tcp any eq 2428 any permit tcp any any eq 2428 remark VoIP-ACL for Cisco – Skinny permit tcp any range 2000 2002 any permit tcp any any range 2000 2002 remark VoIP-ACL for Siemens Phone - HiPath (CoreNet IP) permit tcp any eq 1720 any permit tcp any any eq 1720 remark VoIP-ACL for Siemens Access Point - HiPath (CoreNet IP) permit tcp any range 4000 4002 any permit tcp any any range 4000 4002 permit tcp any range 1124 1129 any permit tcp any any range 1124 1129 permit udp any eq 4007 any permit udp any any eq 4007 remark VoIP-ACL for Siemens HiPath - HiPath (CoreNet IP) permit tcp any eq 1719 any permit tcp any any eq 1719


18

4500 Classification and Marking The Catalyst 4500 with Supervisors II+, III, IV, and V can be found at either the access layer or the distribution layer of the campus. Furthermore, due to their high performance, they may also be found at the core layer of some campus networks. The QoS characteristics on the Catalyst 4500 are determined by the supervisor used. The line cards are functionally transparent. As the entire packet processing, queuing, and manipulation occurs centrally in the Supervisor Engine it is important to see if there are ‘oversubscribed’ cards in the chassis.

QoS is globally disabled on the Catalyst 4500 by default. However, the command to enable QoS globally on a Catalyst 4500 is simply qos, not mls qos. While QoS is globally disabled on the Catalyst 4500, all frames/packets are passed-through the switch unaltered (which is equivalent to a trust CoS and trust DSCP state on all ports). When QoS is globally enabled all DSCP and CoS values are (by default) set to 0 (which is equivalent to an untrusted state on all ports).

The Catalyst 4500s are used as distribution layer switches and are in the trust boundary. So we do not need to remark. The most important task we have to do is to queue according to the scheme set-up defined.

If you have EtherChannel ports configured on your switch, you must configure QoS classification and policing on the EtherChannel. The transmit queue configuration must be configured on the individual physical ports that comprise the EtherChannel.

The configuration commands needed to be entered for are: ! ! Cat 4500 Marking Configuration ! !*Enable Global QoS – This will rewrite all QoS markings to zero by default.* ! qos ! !*Apply QoS policies to interfaces ! interface GigabitEthernet2/3 qos trust dscp

6500 Classification and Marking The Catalyst 6500 is the flagship of the Cisco family of LAN switches, as it is the most powerful and flexible switching platform. As such, it can be found in all three layers of a campus network (Access, Distribution, and Core). We assume that the Catalyst 6500 Switches have been implemented at the Core layer either as MPLS PEs or non MPLS Core Switches.

The QoS characteristics on the 6500 are determined by the supervisor used and the cards. This platform has a partly distributed QoS mode. While the Catalyst 65002 PFC performs classification, marking, mapping and policing functions, all queuing and congestion avoidance policies are administered by the linecards. The trusting of traffic is also performed locally on the ingress card.

The Supervisor Modules and Linecards used are as follows:

Catalyst 6500 with CatOS or native IOS: Supervisor 2 / MSFC 2, WS-X6408A-GBIC, WS-X6324-100FX-MM, WS-X6348-RJ-45, WS-X6148-GE-TX

Catalyst 6500 as MPLS/PE with native IOS: WS-SUP720-3BXL, WS-X6516A-GBIC, WS-X6408A-GBIC, WS-X6324-100FX-MM, WS-X6348-RJ-45

Due to the different deployments where the Catalyst 6500 is used in the Campus Network, using CatOS, native IOS, or as MPLS/PE running native IOS, we divided the classification and marking into two sections:

• Catalyst 6500 running CatOS and native IOS

• Catalyst 6500 as MPLS/PE running native IOS

2 http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/qos.html


19

Catalyst 6500 Running CatOS and Native IOS When QoS is globally disabled, then all frames/packets that are passed-through the switch remain unaltered (which is equivalent to a trust CoS and trust DSCP state on all ports). When QoS is globally enabled all DSCP and CoS values are (by default) set to 0 (which is equivalent to an untrusted state on all ports).

The Switches which are running CatOS are deployed in the Data Center (BYZV86, BYZV87). Currently we have two devices connected to these switches which need to have QoS capabilities (CallManager and Unity Server). As these are well known applications which are providing the correct setting of the IP TOS bits we can configure the ports where these devices are connected too, as trusted ports (trust DSCP). All other ports remain at the default setting which is currently untrusted.

The configuration commands needed to be entered for CatOS are: ! ! Cat 65000 Marking Configuration ! !*Enable Global QoS – This will rewrite all QoS markings to zero by default.* ! set qos enable ! !*Apply QoS policies to interfaces ! set port qos 5/3 trust trust-dscp ! trust the Server ports ! set port qos 1/1 trust trust-dscp ! trust the ports for core uplinks ! ! Trust the Channel between two switches set port qos 1/2 trust trust-dscp set port qos 2/1 trust trust-dscp

As of this writing, no Catalyst 6500/SupII which runs native IOS is subject for implementing QoS. But due to the ongoing migration from CatOS to native IOS this chapter is added for completeness.

The configuration commands needed to be entered for native IOS are: ! ! Cat 65000 Marking Configuration ! !*Enable Global QoS – This will rewrite all QoS markings to zero by default.* ! mls qos ! !*Apply QoS policies to interfaces. ! interface GigabitEthernet0/1 ! Uplink-Port to/from Distribution switchport trunk encapsulation dot1q switchport trunk allowed vlan 816,817 switchport mode trunk mls qos trust dscp !Trust ingress traffic from the distribution ! interface FastEthernet5/3 ! Access-Ports to Server switchport access vlan 806 mls qos trust dscp !Trust ingress traffic from the Server Port ! interface GigabitEthernet1/1 !Uplink-Port to/from Core mls qos trust dscp !Trust ingress traffic from the Core ! interface Port-channel2 !If configured on Port-channel mls qos trust dscp !

On non-Gigabit Ethernet linecards that use 2Q2T Transmit Queuing and 1Q4T Receive queuing (such as the WS-X6248-RJ-xx and WS-X6348-RJ-xx linecards), a hardware limitation prevents the proper functioning of port-based trust (which affects trust-ipprec and trust-dscp). The 2Q2T cards will only trust CoS and not DSCP or IPPREC These cards are also listed in Appendix 1. On such linecards, a workaround ACL can be used to achieve trust-functionality for trust-ipprec and trust-dscp. The workaround ACL for trust-DSCP functionality on such linecards is shown below


20

The workaround ACL for trust-DSCP functionality on 2Q2Tlinecards: Example: Trust-DSCP Workaround ACL for Catalyst 6500 2Q2T-TX/1Q4T-Rx Non-Gigabit Linecards (CatOS) set qos acl ip TRUST-DSCP trust-dscp any !TRUST-DSCP editbuffer modified. Use 'commit' command to apply changes. commit qos acl TRUST-DSCP !QoS ACL 'TRUST-DSCP' successfully committed. set qos acl map TRUST-DSCP 4/1 Example: Trust-DSCP Workaround ACL for Catalyst 6500 2Q2T-TX/1Q4T-Rx Non-Gigabit Linecards (native IOS) class-map match-all class_trust_dscp match access-group name acl_trust_dscp ! policy-map 2Q2T-trust-dscp classclass_trust_dscp trust dscp ! interface FastEthernet2/1 ip address 10.161.0.1 255.255.255.0 service-policy in 2Q2T-trust-dscp ! ip access-list extended acl_trust_dscp permit ip any any

Catalyst 6500 as MPLS/PE Running Native IOS MPLS is a technology allowing multi-service networking in an IP environment. In MPLS packets QoS information is carried in the EXP bits of the MPLS header of frame based MPLS packets. The MPLS EXP bits are only three bits long, while the DSCP bits are six. Therefore not all the information is copied directly from the DSCP IP field into the MPLS EXP field. Only the class selectors (the three most significant bits) are copied into the MPLS EXP bits by default as seen in the following figure.

Figure 5 DSCP to EXP Mapping

How the mapping will behave on the different port trust states will be demonstrated in the figures that follow.


21

When the PE receives an IP packet (ip2ip, ip2mpls), it uses the input interface trust state and, if configured, the policy-map trust command. During ip2mpls imposition, for packets received on an untrusted interface (2), the internal dscp will be set to zero. It then maps the internal dscp to the imposed EXP and the output CoS which results in setting EXP also to 0 (3). It always preserves the underlying IP ToS (IP DSCP). By default, the egress PE discards the popped EXP and does not propagate it to the exposed IP ToS of the egress frame (mpls2ip), thus leaving the IP ToS unchanged (4). So frames received on an untrusted port will get Best Effort Class Queuing inside the MPLS Core. (Figure 6)

When looking at the PEs, there are also some CEs connected where QoS hasn’t been enabled. This leads to the fact that we can’t trust the Endpoints and therefore rely on the untrusted Endpoint model. As the IP ToS (DSCP) is preserved during the whole path, we need to insure that traffic coming from the untrusted ingress ports is remarked to IP ToS 0 (DSCP 0) at the egress PE to ensure protection. (Figure 7)

The configuration commands needed to be entered for the PEs are: ! ! Cat 65000 Marking Configuration ! !*Enable Global QoS – This will rewrite all QoS markings to zero by default.* ! mls qos

Figure 6 MPLS PE and Ingress Port State Untrusted (Short Pipe Mode)

MPLS

Customer A Site 1

Customer A Site 2

DSCP = EF

Dest = A3

6500 PE

DSCP = EFDest = A3

6500 PE

DSCP = EF

EXP = 0EXP = 0

Dest = A3

untrusted1

2

3

4MPLS

Customer A Site 1

Customer A Site 2

DSCP = EF

Dest = A3

6500 PE6500 PE

DSCP = EFDest = A3

6500 PE6500 PE

DSCP = EF

EXP = 0EXP = 0

Dest = A3

untrusted1

2

3

4

Figure 7 represents how we can remark the IP ToS at the egress PE before delivering the packet to the egress CE router. This can be achieved by using the "mpls propagate-cos" command at the PE-to-CE interface. Steps 1 -3 are exactly performed as described in the previous chapter. The only difference when ‘mpls propagate-cos’ is configured for the egress interface is that the internal DSCP is mapped to the exposed IP ToS of the egress frame (4). To ensure that we always remark the IP ToS at egress when using the untrusted Endpoint model it is recommended to configure ‘mpls propagate-cos’ on every PE-CE interface within VRF or on dedicated PE-CE interfaces of other VRFs where remarking of IP ToS is desired.

The default EXP-to-DSCP table maps EXP 5 to DSCP 40. As the Classification Scheme uses DSCP 46 the map has to be changed accordingly on each PE for consistency. This is shown in the following configuration example.

The configuration commands needed to be entered for the PEs are: ! ! Cat 65000 Marking Configuration ! !*Enable Global QoS – This will rewrite all QoS markings to zero by default.* ! mls qos ! ! mpls propagate-cos configuration on the egress interfaces (VRF) ! interface fa8/48 ip vrf forwarding


22

mpls propagate-cos ! ! Changing the EXP-to-DSCP table to map EXP 5 to DSCP 46 ! sho mls qos maps exp-dscp ! show default mapping Exp-dscp map: exp: 0 1 2 3 4 5 6 7 ------------------------------------ dscp: 0 8 16 24 32 40 48 56

! mls qos map exp-dscp 0 8 16 24 32 46 48 56 !setting EXP 5 to DSCP 46 mapping ! sho mls qos maps exp-dscp Exp-dscp map: exp: 0 1 2 3 4 5 6 7 ------------------------------------ dscp: 0 8 16 24 32 46 48 56

Figure 7 MPLS PE and Ingress Port State Untrusted (Uniform Mode)

MPLS

Customer A Site 1

Customer A Site 2

DSCP = EFDest = A3

6500 PE

DSCP = 0Dest = A3

6500 PE

DSCP = EF

EXP = 0EXP = 0

Dest = A3

untrusted mpls propagate-cos

1

2

3

4MPLS

Customer A Site 1

Customer A Site 2

DSCP = EFDest = A3

6500 PE6500 PE

DSCP = 0Dest = A3

6500 PE6500 PE

DSCP = EF

EXP = 0EXP = 0

Dest = A3

untrusted mpls propagate-cos

1

2

3

4

As shown in Figure 8 during ip2mpls imposition, for packets received on a trusted interface (2), the internal DSCP will be set according to the IP ToS (DSCP) of the ingress IP packet. It then maps the internal DSCP to the imposed EXP bits and the output CoS, which results in setting EXP to 5 (3) in the example. Again it always preserves the underlying IP ToS (IP DSCP). By default (Short Pipe Mode), the egress PE discards the popped EXP and does not propagate it to the exposed IP ToS of the egress frame (mpls2ip), thus would leave the IP ToS unchanged (4). But as we are using Uniform Mode by having "mpls propagate-cos" configured at the egress PE-CE interface, the internal DSCP is set according to the EXP-to DSCP map. The internal DSCP is then mapped to the exposed IP ToS of the egress frame (4).

Figure 8 MPLS PE and Ingress Port State Trusted (Uniform Mode)

MPLS

Customer A Site 1

Customer A Site 2

DSCP = EFDest = A3

6500 PE

DSCP = EFDest = A3

6500 PE

DSCP = EF

EXP = 5 EXP = 5

Dest = A3

trust dscp mpls propagate-cos

1

2

3

4MPLS

Customer A Site 1

Customer A Site 2

DSCP = EFDest = A3

6500 PE6500 PE

DSCP = EFDest = A3

6500 PE6500 PE

DSCP = EF

EXP = 5 EXP = 5

Dest = A3

trust dscp mpls propagate-cos

1

2

3

4


23

The configuration commands needed to be entered for the PEs are: ! ! Cat 65000 Marking Configuration ! !*Enable Global QoS – This will rewrite all QoS markings to zero by default.* ! mls qos ! ! Ingress Port configured to trust DSCP (2Q2T Modules) ! Using a policy-map as workaraound to trust DSCP on the 2Q2T Modules, as they don’t ! support ingress port trust due to hardware limitation

class-map match-all class_2Q2T_trust_dscp match access-group name acl_2Q2T_trust_dscp ! policy-map 2Q2T-trust-dscp class class_2Q2T_trust_dscp trust dscp ! ip access-list extended acl_2Q2T_trust_dscp permit ip any any ! ! Apply policy-map to ingress-interfaces ! interface fa8/48 service-policy in 2Q2T-trust-dscp ! ! Ingress Port configured to trust DSCP (NON 2Q2T Modules) ! interface gi2/1 mls qos trust dscp ! ! mpls propagate-cos configuration on the egress L3 interfaces (VRF) ! interface fa8/48 ip vrf forwarding mpls propagate-cos ! ! mpls propagate-cos configuration on the egress SVI interfaces (VRF) ! interface vlan 152 ip vrf forwarding mpls propagate-cos ! ! Changing the EXP-to-DSCP table to map EXP 5 to DSCP 46 ! sho mls qos maps exp-dscp ! show default mapping Exp-dscp map: exp: 0 1 2 3 4 5 6 7 ------------------------------------ dscp: 0 8 16 24 32 40 48 56 ! mls qos map exp-dscp 0 8 16 24 32 46 48 56 !setting EXP 5 to DSCP 46 mapping ! sho mls qos maps exp-dscp Exp-dscp map: exp: 0 1 2 3 4 5 6 7 ------------------------------------ dscp: 0 8 16 24 32 46 48 56

Queuing Even though it might seem that there is sufficient bandwidth on LAN links, it is always recommended to implement at least low latency queuing for high priority traffic (i.e. VoIP). Without LLQ the issue of small packets stuck behind large packets causing high jitter values is not addressed!

QoS in the LAN is required at points of substantial speed mismatch and points of aggregation that could cause congestion in links and buffers leading to uncontrolled delays and drops. Furthermore, transmit buffers have the tendency to fill up due to TCP windowing.


24

Figure 9 LAN Congestion Points

Aggregation Speed Mismatch

10 Mbps

1000 Mbps

LAN to WAN

10 Mbps

64 Kbps

Aggregation Speed Mismatch

10 Mbps

1000 Mbps

LAN to WAN

10 Mbps

64 Kbps

Usually a major speed mismatch exists at the LAN-to-WAN handoff between the WAN aggregation router and the distribution switch. Unlike queuing on the distribution switch, which can be done in hardware, the QoS operation on the WAN router is performed in software. The objective is to discard, as intelligently as possible, traffic that will be inevitably dropped anyways (by the WAN router) but - whenever possible -performing the dropping within the LAN switch hardware (as opposed to IOS software). If the WAN aggregator is homing several remote branches, the collective CPU required to administer complex QoS policies might be more than some older devices can support.

The main point to keep in mind is that QoS entails CPU load on WAN routers. WAN topologies and QoS policies should be designed to limit the average CPU utilization of the WAN aggregator to 60 percent (or lower) because this leaves cycles available to handle control-plane operations like routing updates.

When referring to the individual queues and thresholds on a port, a rather terse nomenclature is used. This terminology describes the number of strict priority queues (if present), the number of standard queues, and the number of tail-drop or WRED thresholds within each of the standard queues.

As each switching platform will have a different default queuing schema some platforms will need some adjustments to make the earlier named marking schema fit. The different queue and threshold types used are platform and module (Catalyst 6500) dependent. Example:

• 2q2t - Two standard queues with two drop thresholds per queue

• 1p2q2t - One strict-priority queue, two standard queues with two drop thresholds per queue

• 1p3q3t - One strict-priority queue, three standard queues with three drop thresholds per queue

Queuing at Campus As the current Campus, QoS requirements are not complex and do not require any form of scavenger class behavior, the idea is to support the different classes as near to default Catalyst QoS behavior as possible. The advantages are that this would require minimal changes on the switches.

The most important thing is to make sure that the classes are handled either in different queues or have different drop levels to make the distinction between the classes.

Catalyst 2950 Queuing The Catalyst 29503 can be configured to operate in a 4Q1T mode or in 1P3QT mode (with Queue 4 being configured as a strict-priority queue); the 1P3QT mode is recommended in SI network.

The strict priority queue is enabled by configuring the fourth queue weight parameter, as defined in the wrr-queue bandwidth command, to be 0.

The remaining bandwidth is allocated to the other queues according to their defined weights. To allocate remaining bandwidths of 70% (Best Effort), 25% (Call Signaling) and 5% (Internetwork Control), weights of 70, 25 and 5 should be assigned these queues, respectively.

3 http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/12.1_22_ea2/configuration/guide/swqos.html


25

Figure 10 Catalyst 2950 Default Queuing (WRR-Queue CoS Map) Cat2950#sho wrr-queue cos-map CoS Value : 0 1 2 3 4 5 6 7 Priority Queue : 1 1 2 2 3 3 4 4

The show wrr-queue cos-map verification command displays the queue that each CoS value has been assigned to.

The default assignment is CoS 0, 1 to Q1, CoS 2, 3 to Q2, CoS 4, 5 to Q3 and CoS 6, 7 to Q4

The following remapping of classes will support the policy and leaves as much of the default behavior there. To support the model we will need to change the queue mappings and the queue weights. The following diagram shows this.

Figure 11 Catalyst 2950 Queuing

Call Signaling

Voice

Application

AF31/CS3

EF

Best EffortBest Effort 00

Internetwork ControlInternetwork Control CS6CS6

DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS

CoSCoS 5

1P3Q

Queue 4Queue 4Priority QueuePriority Queue

Queue 3 (5%)Queue 3 (5%)

CoS 2,3Queue 2 (25%)Queue 2 (25%)

CoS 4,6,7

Q2T1Queue 1 (70%)Queue 1 (70%)CoS 0,1

Call Signaling

Voice

Application

AF31/CS3

EF



DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS

CoSCoS 5

1P3Q


Queue 3 (5%)Queue 3 (5%)

CoS 2,3Queue 2 (25%)Queue 2 (25%)

CoS 4,6,7


The following configuration is to be used to make the above mentioned schema work. The complete configuration template for the Catalyst 2950 can be found in the Appendix 2. ! ! Cat 2950 Queuing Configuration ! !provides weights for wrr settings of the queues, in the case of congestion q1 will get !most of the time !Q1 gets 70% BW, Q2 gets 25% BW, Q3 gets 5%, Q4 is PQ ! wrr-queue bandwidth 70 25 5 0 ! !Maps CoS 4,6,7 to Q3; 5 to Q4 (PQ) ! wrr-queue cos-map 3 4 6 7 wrr-queue cos-map 4 5 !

Figure 12 Catalyst 2950 WRR-Queue CoS Map setting verification Cat2950(config)#sho wrr-queue cos-map CoS Value : 0 1 2 3 4 5 6 7 Priority Queue : 1 1 2 2 3 4 3 3

Catalyst 3560 Queuing The Catalyst 35604 supports four egress queues, which can be configured on a per-interface basis to operate in either 4Q3T or 1P3Q3T modes. Unlike the Catalyst 2950, the Catalyst 3560 has Queue 1 (not Queue 4) as optional priority queue. It is recommended to use 1P3Q3T mode and enable priority queue via the priority-queue out interface command.

4 http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_sea/configuration/guide/swqos.html


26

The three remaining egress queues on the Catalyst 3560 are scheduled by a Shaped Round-Robin (SRR) algorithm, which can be configured to operate in shaped mode or in shared mode. In shaped mode, assigned bandwidth is limited to the defined amount; in shared mode, any unused bandwidth is shared among other classes (as needed).

Shaped or Shared bandwidth weights can be assigned to a queue via the srr-queue bandwidth shape and srr-queue bandwidth share interface commands. Shaped mode weights override shared mode weights and use an inverse ratio (1/weight) to determine the shaping bandwidth for the queue. Furthermore, if shaped weights are set to 0, then the queue is operating in shared mode. For example, the following interface command srr-queue bandwidth shape 3 0 0 0 would shape Q1 to 1/3 of the available bandwidth and set all other queues to operate in sharing mode.

Traffic can be assigned to queues and thresholds either by CoS values or DSCP values, using the mls qos srr-queue output cos-map queue and mls qos srr-queue output dscp-map queue global commands, respectively. While DSCP-to-Queue/Threshold maps override CoS-to-Queue/Threshold maps, these mappings should be as consistent as possible to ensure predictable behavior and simplify troubleshooting.

Figure 13 Catalyst 3560 Default Queuing (DSCP-to-Queue Map) #sh mls qos maps dscp-output-q Dscp-outputq-threshold map: d1 :d2 0 1 2 3 4 5 6 7 8 9 ------------------------------------------------------------ 0 : 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 02-01 1 : 02-01 02-01 02-01 02-01 02-01 02-01 03-01 03-01 03-01 03-01 2 : 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 03-01 3 : 03-01 03-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 4 : 01-01 01-01 01-01 01-01 01-01 01-01 01-01 01-01 04-01 04-01 5 : 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 04-01 6 : 04-01 04-01 04-01 04-01

DSCP 46 (EF) - Queue 01 DSCP 48 (CS6) - Queue 04 DSCP 26/24 (AF31/CS3) - Queue 03

DSCP 0 - Queue 02

The default queuing scheme of the Catalyst 3560 (Figure 13) perfectly fits to our defined marking scheme, so adjustments regarding the DSCP-to-Queue mapping is not necessary. We only have to adapt the amount of bandwidth per queue. Queues 2 through 4 should be set to operate in shared mode (which is the default mode of operation on Queues 2 through 4). The ratio of the shared weights determines the relative bandwidth allocations (the absolute values are meaningless).

The PQ of the Catalyst 3560 is Q1, Q2 is representing the Best Effort queue, Q3 is representing the Call Signaling queue and Q4 is representing the Network Control queue. Therefore, shared weights of 70, 25, and 5 can be assigned to Queues 2, 3, and 4, respectively.


Call Signaling

Voice

Application

AF31/CS3

EF



DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS

CoSCoS 5

1P3Q3T


Queue 2 (70%)Queue 2 (70%)

CoS 2,3Queue 3 (25%)Queue 3 (25%)

CoS 0,1

Q2T1Queue 4 (5%)Queue 4 (5%)CoS 4,6,7

Call Signaling

Voice

Application

AF31/CS3

EF



DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS

CoSCoS 5

1P3Q3T


Queue 2 (70%)Queue 2 (70%)

CoS 2,3Queue 3 (25%)Queue 3 (25%)

CoS 0,1

Q2T1Queue 4 (5%)Queue 4 (5%)CoS 4,6,7


27

The following configuration is to be used to make the above mentioned schema work. The complete configuration template for the Catalyst 3560 can be found in Appendix 2.

interface FastEthernet0/2 description VoIP or Data only Port switchport access vlan 816 switchport voice vlan 817 srr-queue bandwidth share 1 70 25 5 !Q2 gets 70% of remaining BW,Q3 gets 25% and Q4 gets 30% priority-queue out !Q1 is enabled as PQ service-policy input Edge_QoS_Marking ! interface GigabitEthernet0/1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 816,817 switchport mode trunk srr-queue bandwidth share 1 70 25 5 !Q2 gets 70% of remaining BW,Q3 gets 25% and Q4 gets 30% priority-queue out !Q1 is enabled as PQ mls qos trust dscp

Catalyst 4500 Queuing The Catalyst 45005 supports four egress queues for scheduling, which may be configured in either 4Q1T or 1P3Q1T modes. The strict-priority queue on the Catalyst 4500 is transmit-queue 3.

By default, all queues are scheduled in a round robin manner. The third transmit queue can be designated as an optional strict-priority queue. This can be enabled with the tx-queue 3 interface command followed by the priority high interface transmit-queue sub-command. This queue can be defined to be shaped to a peak limit, to allow bandwidth to be available to non-voice applications.

Bandwidth allocations can also be assigned to queues (for certain interfaces) using the tx-queue interface command followed by the bandwidth sub-command. Bandwidth sharing provides a guaranteed minimum bandwidth to each of the four queues. Sharing is supported only on the non blocking Gigabit ports for Supervisor IV, II-Plus and II-Plus-TS. It is supported on all ports for the supervisor V. It can only be assigned on the following interface types:

• Uplink ports on supervisor engines

• Ports on the WS-X4306-GB linecard

• The 2 1000Base-X ports on the WS-X4232-GB-RJ linecard

• The first 2 ports on the WS-X4418-GB linecard

• The two 1000BASE-X ports on the WS-X4412-2GB-TX linecard

The Catalyst 4500 does not support CoS-to-Queue mappings, only DSCP-to-Queue mappings. These can be defined with the qos map dscp to tx-queue global command.

Figure 15 Catalyst 4500 Default Queuing (DSCP-to-Queue Map) 4500#sho qos maps DSCP-TxQueue Mapping Table (dscp = d1d2) 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 02 02 02 02 2 : 02 02 02 02 02 02 02 02 02 02 3 : 02 02 03 03 03 03 03 03 03 03 4 : 03 03 03 03 03 03 03 03 04 04 5 : 04 04 04 04 04 04 04 04 04 04

5 http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/25ewa/configuration/guide/qos.html


28

6 : 04 04 04 04 <output truncated> CoS-DSCP Mapping Table CoS: 0 1 2 3 4 5 6 7 -------------------------------- DSCP: 0 8 16 26 32 46 48 56

The default assignment is DSCP 0, 8 to Q1, DSCP 16, 24/26 to Q2, DSCP 46, 32 to Q3 and DSCP, 48, 56 to Q4. This fits within model. As DSCP 32 is not used in the network. If DSCP 32 will be used in the future the default queue mapping needs to be changed. The current default model fits.

The following mapping of classes will support policy and leaves as much of the default behavior there. To support the model we will need to change the queue mappings for Q4 to assign DSCP 26/24 to Q3. The following diagram shows this


Call Signaling

Voice

Application

AF31/CS3

EF



DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS

CoSCoS 4,5

1P3Q1T

Queue 3 (15%)Queue 3 (15%)Priority QueuePriority Queue

Queue 1 (60%)Queue 1 (60%)

CoS 2,3Queue 2 (20%)Queue 2 (20%)

CoS 0,1


Call Signaling

Voice

Application

AF31/CS3

EF



DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS

CoSCoS 4,5

1P3Q1T

Queue 3 (15%)Queue 3 (15%)Priority QueuePriority Queue

Queue 1 (60%)Queue 1 (60%)

CoS 2,3Queue 2 (20%)Queue 2 (20%)

CoS 0,1


While tail-drop or WRED thresholds are not supported on the Catalyst 4500, it does support one of the most advanced congestion avoidance mechanisms in the catalyst family. This congestion avoidance feature is performed by Dynamic Buffer Limiting (DBL). DBL tracks the queue length for each traffic flow in the switch and when the queue length of a flow exceeds its limit, DBL drops packets or sets the (RFC 3168) Explicit Congestion Notification (ECN) bits in the IP headers. DBL can be enabled globally with qos dbl global command, as well as on a per-class basis within a policy-map with the dbl policy command. A default DBL policy can be applied to all transmit queues, as is shown in the configuration template below.

The following configuration is to be used to make the above mentioned schema work. The complete configuration template for the Catalyst 4500 can be found in Appendix 2. ! ! Cat 4500 Queuing Configuration ! ! Enable QoS globally ! qos ! qos dbl ! Globally enables DBL ! interface GigabitEthernet2/3(blocking) tx-queue 3 priority high ! Enables Q3 as PQ shape percent 15 ! Shapes PQ to 15% ! interface GigabitEthernet2/1 (non blocking) tx-queue 1 bandwidth percent 60


29

! Q1 gets 60% tx-queue 2 bandwidth percent 20 ! Q2 gets 20% tx-queue 3 priority high ! Enables Q3 as PQ bandwidth percent 15 ! PQ gets 15% shape percent 15 ! Shapes PQ to 15% tx-queue 4 bandwidth percent 5 ! Q4 gets 5%

Catalyst 6500 Queuing While the Catalyst 65006 PFC performs classification, marking, mapping and policing functions, all queuing and congestion avoidance policies are administered by the linecards. This inevitably leads to per-linecard hardware-specific capabilities and syntax when it comes to configuring queuing and dropping.

There are currently six main transmit queuing/dropping options for Catalyst 6500 linecards:

• 2Q2T – Indicates two standard queues, each with two configurable tail-drop thresholds

• 1P2Q1T – Indicates one strict-priority queue and two standard queues, each with one configurable WRED-drop threshold (however, each standard queue also has one non-configurable tail-drop threshold)

• 1P2Q2T – Indicates one strict-priority queue and two standard queues, each with two configurable WRED-drop threshold

• 1P3Q1T – Indicates one strict-priority queue and three standard queues, each with one configurable WRED-drop threshold (however, each standard queue also has one none-configurable tail-drop threshold)

• 1P3Q8T – Indicates one strict-priority queue and three standard queues, each with eight configurable WRED-drop threshold (however, each standard queue also has one none-configurable tail-drop threshold)

• 1P7Q8T – Indicates one strict-priority queue and seven standard queues, each with eight configurable WRED-drop threshold (on 1p7q8t ports, each standard queue also has one none-configurable tail-drop threshold)

(Note: Appendix 1 shows the Catalyst linecards that are currently available and their respective queuing/dropping structures.)

Almost all Catalyst 6500 linecards support a strict-priority queue and when supported, the switch services traffic in the strict-priority transmit queue before servicing the standard queues. When the switch is serving a standard queue, after transmitting a packet, it checks for traffic in the strict-priority queue. If the switch detects traffic in the strict-priority queue, it suspends its service of the standard queue and completes service of all traffic in the strict-priority queue before returning to the standard queue.

The following chapters describe design recommendations for the following two Catalyst 6500 structures. Those structures are most common and also used in the network. Information about the remaining structures are out of the scope of this document, but could be provided upon request.

• 2Q2T (WS-X63xx non Gigabit Ethernet , WS-X60xx and WS-X61xx non Gigabit Ehernet Modules)

• 1P2Q2T (WS-X65xx and WS-X64xx Modules)

6 http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/qos.html


30

Catalyst 6500 – 1P2Q2T Queuing (Note: The following sections focus on native IOS configurations only. Refer to Appendix 2 for corresponding CatOS configurations on hybrid systems.)

On 1P2Q2T linecards three egress queues are available per port:

• Q3 Strict Priority Queue

• Q2 High Priority Queue

• Q1 Low Priority Queue

The Transmit Queue Size Ratio defines the way the buffers are split among the queues. The transmit queue size can be configured for each of the three Tx queues. The biggest part of the buffers should be left for the low priority queue (Q1) as it is the queue where more buffering is needed because of the fact that the other queues are served with a higher WRR priority. With three queues, only the buffer size for the two standard transmit queues (WRR served) needs to be configured. The strict priority use the same buffer size than the high priority standard transmit queue (Q2).

e.g. (Q1 40% buffer / Q2 30% / Q3 30%) wrr-queue queue-limit 40 30

Weighted Round Robin (WRR) is used to schedule egress traffic from the standard transmit queues (Q1/2). The weighted aspect of WRR allows the scheduling algorithm to inspect a weighting that has been assigned to the queue. The WRR weights for Q1 and Q2 (for dividing the remaining bandwidth, after the priority queue has been fully serviced) can be set for instance to 30:70 ratio representing Q1:Q2

e.g. (Q1 served 30% of time / Q2 served 70% of time) wrr-queue bandwidth 30 70

Figure 17 Default 1P2Q2T Queuing (CoS-to-Queue Map) c6k-2#sho queuing interface gi4/1 Interface GigabitEthernet4/1 queuing strategy: Weighted Round-Robin Port QoS is enabled Port is untrusted Extend trust state: not trusted [COS = 0] Default COS is 0 Queuing Mode In Tx direction: mode-cos Transmit queues [type = 1p2q2t]:

…<output truncated> queue thresh cos-map --------------------------------------- 1 1 0 1 1 2 2 3 2 1 4 6 2 2 7 3 1 5

…<output truncated>

The default queuing scheme of the 1P2Q2T Modules (Figure 17) partially fits to our defined marking scheme, so some adjustments regarding the CoS-to-Queue mapping is necessary. In the Figure 18 below, CoS 3 is reassigned to Q2T1, CoS 6 is reassigned to Q2T2, and CoS values 0,1,4,7 and 5 remain according to the default. The size ratio has been allocated 70% for Q1 and 30% for Q2 and the WRR weights are set to 70:30 to service Q1 and Q2, respectively.

Figure 18 Adapted 1P2Q2T Queuing


31

Call Signaling

Voice

Application

AF31/CS3

EF



DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS 1P2Q2T

Q2T1 (80%)T1: CoS 3,4

Queue 2 (15%)T2: CoS 6,7 Q2T2 (100%)

CoSCoS 5Queue 3 (15%)Queue 3 (15%)

Priority QueuePriority Queue

Queue 1 (70%)Queue 1 (70%)

Q1T2 (100%)

Q1T1 (80%)T1: T1: CoSCoS 0,1

T1: T1: CoSCoS 2

Call Signaling

Voice

Application

AF31/CS3

EF



DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS 1P2Q2T

Q2T1 (80%)T1: CoS 3,4

Queue 2 (15%)T2: CoS 6,7 Q2T2 (100%)

CoSCoS 5Queue 3 (15%)Queue 3 (15%)

Priority QueuePriority Queue

Queue 1 (70%)Queue 1 (70%)

Q1T2 (100%)

Q1T1 (80%)T1: T1: CoSCoS 0,1

T1: T1: CoSCoS 2

The following configuration is to be used to make the above mentioned schema work. The complete configuration template for the Catalyst 6500 1P2Q2T modules can be found in Appendix 2. This configuration does NOT include WRED in order to simplify initial deployment. WRED could be used as future extension if more QoS granularity is required. ! ! Cat 6500 1P2Q2T Queuing Configuration ! ! Enable QoS globally ! mls qos ! interface GigabitEthernet1/0 wrr-queue bandwidth 70 30 ! Sets the WRR weights for 70:30 (Q1:Q2) bandwidth servicing wrr-queue cos-map 2 1 3 ! Maps CoS 3 to Q2 WRED Threshold 1 wrr-queue cos-map 2 2 6 ! Maps CoS 6 to Q2 WRED Threshold 2

Catalyst 6500 – 2Q2T Queuing (Note: The following sections focus on native IOS configurations only. Refer to Appendix 2 for corresponding CatOS configurations on hybrid systems.)

Linecards that only support 2Q2T queuing models have no provision for priority-queuing. Nonetheless, tuning the Weighted Round-Robin (WRR) weights and the queue sizes can help offset this limitation. For example, if Q1 is to service Scavenger/Bulk (CoS 1) and Best Effort (CoS 0) traffic, then assigning 30% of the buffer space to the first queue is adequate; the remaining 70% can be assigned to Q2. The WRR weights can be set to the same ratio of 30:70 for servicing Q1:Q2. This ensures that Q2 will be served more often than Q1 which is desired as Q2 would also include Voice traffic (CoS 5).

Figure 19 Default 2Q2T Queuing (CoS-to-Queue Map) c6k-2#sho queuing interface fa6/1 Interface FastEthernet6/1 queuing strategy: Weighted Round-Robin Port QoS is enabled Port is untrusted Extend trust state: not trusted [COS = 0] Default COS is 0 Queuing Mode In Tx direction: mode-cos Transmit queues [type = 2q2t]: …<output truncated> queue thresh cos-map ----------------------- 1 1 0 1


32

1 2 2 3 2 1 4 5 2 2 6 7 …<output truncated>

The default queuing scheme of the 2Q2T Modules (Figure 19) needs to be modified to fit into our defined marking scheme, so some adjustments regarding the CoS-to-Queue mapping is necessary. In Figure 20 below, CoS 3, 6 and 7 are reassigned to Q2T1, and CoS 5 is reassigned to Q2T2. CoS values, 0, 1 and 4, remain according to the default. The size ratio has been allocated 30% for Q1 and 70% for Q2 and the WRR weights are set to 30:70 to service Q1 and Q2, respectively.

Figure 20 Adapted 2Q2T Queuing

Call Signaling

Voice

Application

AF31/CS3

EF



DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS

T2: T2: CoSCoS 5

2Q2T

Q2T1 (80%)

T1: CoS 0,1

Q2T2 (100%)

T1: T1: CoSCoS 3,4,6,7

Q2T1 (80%)

Queue 2 (70%)Queue 2 (70%)

Queue 1 (30%)Queue 1 (30%)T2: CoS 2 Q1T2 (100%)

Call Signaling

Voice

Application

AF31/CS3

EF



DSCP

CoS 3

CoS 5

00

CoS 6CoS 6

CoS

T2: T2: CoSCoS 5

2Q2T

Q2T1 (80%)

T1: CoS 0,1

Q2T2 (100%)

T1: T1: CoSCoS 3,4,6,7

Q2T1 (80%)

Queue 2 (70%)Queue 2 (70%)

Queue 1 (30%)Queue 1 (30%)T2: CoS 2 Q1T2 (100%)

The following configuration is to be used to make the above mentioned schema work. The complete configuration template for the Catalyst 6500 2Q2T modules can be found in the Appendix 2.

! ! Cat 6500 2Q2T Queuing Configuration ! ! Enable QoS globally ! mls qos ! interface FastEthernet6/1 wrr-queue queue-limit 30 70 ! Sets the buffer allocations to 30% for Q1 and 70% for Q2 wrr-queue bandwidth 30 70 ! Sets the WRR weights for 30:70 (Q1:Q2) bandwidth servicing wrr-queue cos-map 2 1 3 6 7 ! Maps CoS 3,6,7 to Q2 WRED Threshold 1 wrr-queue cos-map 2 2 5 ! Maps CoS 5 to Q2 WRED Threshold 2

Cisco 7200 Queuing We assume there are two 7206 VXR Routers (by9l37, by9l38) in the area where we have to implement QoS. These 7200 Routers provide connectivity between the MPLS Core and the access-switches where the Siemens HiPath is connected to. At this place we trust the DSCP values, so we only need to ensure that VoIP traffic will be prioritized by reserving bandwidth.


33

Modular QoS CLI Overview

This chapter will explain how to configure queuing using Modular QoS (MQC) supporting the queuing scheme. Software based routers i.e. Cisco 800 series - Cisco 7200 series in general support Modular QoS Command line.

The MQC allows users to specify a traffic class independently of QoS policies. It is used to configure QoS by using the following three steps, which are detailed more thoroughly later in this document:

Step1. Defining a traffic class with the class-map command

Step2. Creating a service policy by associating the traffic class with one or more QoS policies (using the policy-map command)

Step3. Attaching the service policy to the interface with the service-policy command

The class-map command is used to define a traffic class. A traffic class contains three major elements: a name, a series of match commands, and an instruction on how to evaluate these match commands. The traffic class is named in the class-map command line; for example, if you enter the class-map don command while configuring the traffic class in the command-line interface, the traffic class would be named don.

Match commands are used to specify various criteria for classifying packets. Packets are checked to see whether they match the criteria specified in the match commands; if a packet matches the specified criteria, that packet is considered a member of the class and is forwarded according to the QoS specifications set in the service policy. Packets that fail to meet any of the matching criteria are classified as members of the default class.

The instruction on how to evaluate these match commands is specified with one of the following two options: class-map match-any or class-map match-all.

The policy-map command is used to associate a traffic class, which was defined by the class-map command, with one or more QoS policies. The result of this association is called a service policy. A service policy contains three elements: a name, a traffic class (specified with the class command), and the QoS. The purpose of the service policy is to associate a traffic class with one or more QoS policies. The name of a service policy is specified in the policy-map command-line interface (for example, issuing the policy-map gary command would create a service policy named gary).

The Modular QoS CLI does not necessarily require that users associate only one traffic class to one service policy. When packets match to more than one match criterion, multiple traffic classes can be associated with a single service policy.

Similarly, the Modular QoS CLI allows multiple traffic classes (nested traffic classes, which are also called nested class maps) to be configured as a single traffic class. This can be achieved with the use of the match class-map command. The only method of combining match-any and match-all characteristics within a single traffic class is with the match class-map command.

The service-policy command is used to attach the service policy, as specified with the policy-map command, to an interface. Because the elements of the service policy can be applied to packets entering and leaving the interface, users are required to specify whether the service policy characteristics should be applied to incoming or outgoing packets. For instance, the service-policy output gary command would attach all the characteristics of the service policy named gary to the specified interface. All packets leaving the specified interface are evaluated according to the criteria specified in the service policy named Gary.

Defining Traffic Classes

In the following example, two traffic classes are created and their match criteria are defined. For the first traffic class, called class1, access control list (ACL) 101 is used as the match criterion. For the second traffic class, called class2, ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the class.


34

Figure 21 Defining Traffic Classes class-map class1

match access-group 101 exit class-map class2 match access-group 102 exit

Creating a Service Policy In the following example, a service policy called policy1 is defined to contain policy specifications for the two classes—class1 and class2. The match criteria for these classes were defined in the traffic classes.

For class1, the policy includes a bandwidth allocation request and a maximum packet count limit for the queue reserved for the class. For class2, the policy specifies only a bandwidth allocation request.

Figure 22 Creating a Service Policy policy-map policy1 class class1 bandwidth percent 30 exit class class2 bandwidth percent 70 exit

Attaching a Service Policy to an Interface The following example shows how to attach an existing service policy (which was created in the preceding "Creating a Service Policy" section) to an interface. After you define a service policy with the policy-map command, you can attach it to one or more interfaces to specify the service policy for those interfaces by using the service-policy command in interface configuration mode. Although you can assign the same service policy to multiple interfaces, each interface can have only one service policy attached at the input and only one service policy attached at the output.

Figure 23 Attaching a Service Policy interface e1/1 service-policy output policy1 exit interface fa1/0/0 service-policy output policy1 exit


35

Figure 24 Cisco 7200 Bandwidth Allocation

Voice 30%

Call-Signaling 10%

Best Effort 60%

The following configuration is to be used to make the above mentioned schema work. The complete configuration template for the Cisco 7200 used in the current topology can be found in the Appendix 2. ! ! Cisco 7200 MQC Configuration ! class-map voice ! We trust Voice and Call Signaling Traffic match ip dscp ef class-map control match ip dscp cs3 match ip dscp af31 match ip dscp cs6 ! policy-map QoS class voice priority percent 30 ! Voice will get 30% BW for LLQ class control bandwidth percent 10 ! Call-Signaling and Control Traffic get min 10% BW class class-default ! Remaining traffic gets 60% BW fair-queue ! interface fa0/0 service-policy output QoS ! Attach the MQC policy to the interface


36

Appendix 1 – Buffer Size & Queues by 6500 Modules

Catalyst 6500 Linecard Queuing Structure

C2 (xCEF720) Modules Description

Receive-Q Structure7

Transmit-Q Structure Buffer Size

WS-X6704-10GE Catalyst 6500 4-port 10 Gigabit Ethernet Module 1Q8T (8Q8T with DFC3a)

1P7Q8T 16MB per port

WS-X6724-SFP Catalyst 6500 24-port 10 Gigabit Ethernet SFP Module

1Q8T (8Q8T with DFC3a)

1P3Q8T 1MB per port

WS-X6748-GE-TX

Catalyst 6500 48-port 10/100/1000 RJ-45 Module 1Q8T (8Q8T with DFC3a)

1P3Q8T 1MB per port

WS-X6748-SFP Catalyst 6500 4-port 10 Gigabit Ethernet Module 1Q8T (8Q8T with DFC3a)

1P3Q8T 1MB per port

Classic/CEF256 Ethernet Modules Description

Receive-Q Structure

Transmit-Q Structure Buffer Size

WS-X6024-10FL-MT

Catalyst 6000 24-port 10BaseFL MT-RJ Module 1Q4T 2Q2T 64KB per port

WS-X6148-RJ21 Catalyst 6500 48-port 10/100 RJ-21 Module 1Q4T 2Q2T 128KB per port

WS-X6148-RJ21V

Catalyst 6500 48-port 10/100 Inline Power RJ-21 Module

1Q4T 2Q2T 128KB per port

WS-X6148-RJ45 Catalyst 6500 48-port 10/100; RJ-45 Module 1Q4T 2Q2T 128KB per port

WS-X6148-RJ45V



WS-X6148-GE-TX

Catalyst 6500 48-port 10/100/1000 RJ-45 Module 1Q2T 1P2Q2T 1MB per 8 port

WS-X6148V-GE-TX

Catalyst 6500 48-port 10/100/1000 Inline Power RJ-45 Module

1Q2T 1P2Q2T 1MB per 8 port

WS-X6316-GE-TX

Catalyst 6000 16-port 1000TX Gigabit Ethernet RJ-45 Module

1PQ2T 1P2Q2T 512KB per port

7 It is extremely unlikely that ingress congestion occurs, thus the default settings (all CoS 5 traffic assigned to strict-priority queue) for the Catalyst 6500 linecard receive queues are more than adequate to protect VoIP traffic.


37

WS-X6324-100FX-MM

Catalyst 6000 24-port 100FX MT-RJ MMF Module (with Enhanced QoS)


WS-X6324-100FX-SM

Catalyst 6000 24-port 100FX MT-RJ SMF Module (with Enhanced QoS)


WS-X6348-RJ21 Catalyst 6000 48-port 10/100 RJ-21 Module 1Q4T 2Q2T 128KB per port

WS-X6348-RJ21V



WS-X6348-RJ-45 Catalyst 6500 48-port 10/100 RJ-45 Module 1Q4T 2Q2T 128KB per port

WS-X6348-RJ45V



WS-X6408-GBIC Catalyst 6000 8-port Gigabit Ethernet Module 1Q4T 2Q2T 512KB per port

WS-X6408A-GBIC

Catalyst 6000 8-port Gigabit Ethernet Module 1P1Q4T 1P2Q2T 512KB per port

WS-X6416-GBIC Catalyst 6000 16-port Gigabit Ethernet Module 1P1Q4T 1P2Q2T 512KB per port

WS-X6416-GE-MT

Catalyst 6000 16-port Gigabit Ethernet MT-RJ Module

1P1Q4T 1P2Q2T 512KB per port

WS-X6501-10GEX4

1-port 10 Gigabit Ethernet Module 1P1Q8T 1P2Q1T 64MB per port

WS-X6502-10GE Catalyst 6500 10 Gigabit Ethernet base Module 1P1Q8T 1P2Q1T 64MB per port

WS-X6516A-GBIC

Catalyst 6500 16-port Gigabit Ethernet Module 1P1Q4T 1P2Q2T 1MB per port


WS-X6516-GE-TX

Catalyst 6500 16-port Gigabit Ethernet Copper Module

1P1Q4T 1P2Q2T 1MB per port

WS-X6524-100FX-MM

Catalyst 6500 24-port 100FX MT-RJ Module 1P1Q0T 1P3Q1T 1MB per port

WS-X6548-RJ21 Catalyst 6500 48-port 10/100 RJ-21 Module 1P1Q0T 1P3Q1T 1MB per port

WS-X6548-RJ-45 Catalyst 6500 48-port 10/100 RJ-45 Module 1P1Q0T 1P3Q1T 1MB per port

WS-X6548V-GE-TX

Catalyst 6500 48-port 10/100/1000 Inline Power RJ-45 Module

1Q2T 1P2Q2T 1MB per 8 ports

WS-X6548-GE TX

Catalyst 6500 48-port 10/100/1000 RJ-45 Module 1Q2T 1P2Q2T 1MB per 8 ports



38

Appendix 2 - Configuration Templates

Please be aware that it is recommended to verify the configurations below in a lab environment.

Catalyst 2950 QoS Configuration Template Refer to http://www.cisco.com/en/US/docs/switches/lan/catalyst2950/software/release/ 12.1_22_ea2/configuration/guide/swqos.html for detailed information about Catalyst 2950 QoS configuration.

Example: byzp0a

wrr-queue bandwidth 70 25 5 0 ! wrr-queue cos-map 3 4 6 7 wrr-queue cos-map 4 5 ! interface FastEthernet0/1 description BY229O Hicom STMI1 mls qos trust dscp ! interface FastEthernet0/24 description BY9L37.FE3/0 mls qos trust dscp ! interface range FastEthernet0/2 -23 mls qos cos override ! interface GigabitEthernet0/1 description to byzp0b EG mls qos trust dscp ! interface GigabitEthernet0/2 description to byzoe3 EG mls qos trust dscp

Catalyst 2950 QoS configuration when used as trust boundary (Classification & Marking only for Voice Vlan)

wrr-queue bandwidth 70 25 5 0 ! wrr-queue cos-map 3 4 6 7 wrr-queue cos-map 4 5 ! class-map match-all 2950_Voice_Payload match access-group name 2950_acl_VoIP_Payload ! class-map match-all 2950_Voice_Control match access-group name 2950_acl_VoIP_Control ! ! Trust VoIP Payload in the Voice Vlan. Traffic would be policed against 1 Mbps ! Set VoIP Control traffic (cs3,af31) to cs3 in the Voice Vlan. Traffic would be policed against 1 Mbps ! Traffic not matching the ACLs should be marked to dscp 0 ! policy-map 2950_Edge_QoS_Marking class 2950_Voice_Payload trust dscp police 1000000 8192 exceed-action drop class 2950_Voice_Control set ip dscp cs3 police 1000000 8192 exceed-action drop ! ip access-list extended 2950_acl_VoIP_Payload


39

permit ip 10.161.30.0 0.0.1.255 any dscp ef !ip address range for voice Vlan ip access-list extended 2950_acl_VoIP_Control permit ip 10.161.30.0 0.0.1.255 any dscp af31 !ip address range for voice Vlan permit ip 10.161.30.0 0.0.1.255 any dscp cs3 !ip address range for voice Vlan ! interface range FastEthernet0/1 -24 description Access-Ports switchport access vlan 816 switchport voice vlan 817 mls qos cos override service-policy input 2950_Edge_QoS_Marking ! interface range GigabitEthernet0/1 -2 description Uplinks mls qos trust dscp

Catalyst 3560 QoS Configuration Template Refer to http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/ 12.2_25_se/configuration/guide/swqos.html for detailed information about Catalyst 3560 QoS configuration.

Example: byzpom

mls qos ! class-map match-all Voice_Payload match access-group name acl_VoIP_Payload ! class-map match-all Voice_Control match access-group name acl_VoIP_Control ! policy-map Edge_QoS_Marking class Voice_Payload set ip dscp ef police 128000 8000 exceed-action drop class Voice_Control set ip dscp cs3 police 32000 8000 exceed-action drop ! interface range FastEthernet0/1 -48 description VoIP or Data only Port switchport access vlan 816 switchport voice vlan 817 srr-queue bandwidth share 1 70 25 5 priority-queue out service-policy input Edge_QoS_Marking ! interface GigabitEthernet0/1 description to byzpo8 G2N1 switchport trunk encapsulation dot1q switchport trunk allowed vlan 816,817 switchport mode trunk srr-queue bandwidth share 1 70 25 5 priority-queue out mls qos trust dscp ! interface GigabitEthernet0/2 description to byzpo7 G2N2 switchport trunk encapsulation dot1q switchport trunk allowed vlan 816,817 switchport mode trunk srr-queue bandwidth share 1 70 25 5 priority-queue out mls qos trust dscp

! ip access-list extended acl_VoIP_Payload remark VoIP-ACL for Cisco - VoIP-Payload (RTP) permit udp any range 16384 32767 any permit udp any any range 16384 32767


40

remark VoIP-ACL for Siemens Phone - VoIP-Payload (RTP/RTCP) permit udp any range 29100 29159 any permit udp any any range 29100 29159 remark VoIP-ACL for Siemens Access Point - VoIP-Payload (RTP/RTCP) permit udp any range 4352 25599 any permit udp any any range 4352 25599 remark VoIP-ACL for Siemens HiPath - VoIP-Payload (RTP/RTCP) permit udp any range 15000 16000 any permit udp any any range 15000 16000 ! ip access-list extended acl_VoIP_Control remark VoIP-ACL for Cisco - MGCP Control permit udp any eq 2427 any permit udp any any eq 2427 remark VoIP-ACL for Cisco - MGCP Backhaul permit tcp any eq 2428 any permit tcp any any eq 2428 remark VoIP-ACL for Cisco – Skinny permit tcp any range 2000 2002 any permit tcp any any range 2000 2002 remark VoIP-ACL for Siemens Phone - HiPath (CoreNet IP) permit tcp any eq 1720 any permit tcp any any eq 1720 remark VoIP-ACL for Siemens Access Point - HiPath (CoreNet IP) permit tcp any range 4000 4002 any permit tcp any any range 4000 4002 permit tcp any range 1124 1129 any permit tcp any any range 1124 1129 permit udp any eq 4007 any permit udp any any eq 4007 remark VoIP-ACL for Siemens HiPath - HiPath (CoreNet IP) permit tcp any eq 1719 any permit tcp any any eq 1719

Catalyst 4500 QoS Configuration Template Refer to http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/ 12.2/25ewa/configuration/guide/qos.html for detailed information about IOS-based QoS configuration.

Example: byzpo8

! qos ! qos dbl ! interface GigabitEthernet1/1 description to bybl12 C102 switchport access vlan 157 switchport mode access qos trust dscp tx-queue 1 bandwidth percent 60 tx-queue 2 bandwidth percent 20 tx-queue 3 priority high bandwidth percent 15 shape percent 15 tx-queue 4 bandwidth percent 5 ! interface GigabitEthernet1/2 description to byzpo7 G2N2 switchport trunk encapsulation dot1q switchport trunk allowed vlan 814-817 switchport mode trunk channel-group 1 mode on tx-queue 1 bandwidth percent 60 tx-queue 2 bandwidth percent 20


41

tx-queue 3 priority high bandwidth percent 15 shape percent 15 tx-queue 4 bandwidth percent 5 ! interface GigabitEthernet2/1 description to byzpo7 G2N2 switchport trunk encapsulation dot1q switchport trunk allowed vlan 814-817 switchport mode trunk channel-group 1 mode on tx-queue 1 bandwidth percent 60 tx-queue 2 bandwidth percent 20 tx-queue 3 priority high bandwidth percent 15 shape percent 15 tx-queue 4 bandwidth percent 5 ! interface Port-channel1 switchport switchport trunk encapsulation dot1q switchport trunk allowed vlan 814-817 switchport mode trunk qos trust dscp ! interface GigabitEthernet4/1 description BYZNFL VG248 switchport access vlan 815 switchport mode access qos trust dscp tx-queue 3 priority high shape percent 15 ! interface GigabitEthernet3/4 description to byzpos G4N1 switchport trunk allowed vlan 816,817 switchport mode trunk qos trust dscp tx-queue 3 priority high shape percent 15

Catalyst 6500 QoS Configuration Template (CatOS) Refer to http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ catos/7.x/configuration/guide/qos.html for detailed information about CatOS-based QoS configuration.

Example: byzv87 (1P2Q2T Modules)

set qos enable ! !remap CoS 3 to Q2 threshold 1 ! set qos map 1p2q2t tx 2 1 cos 3 ! !remap CoS 6 to Q2 threshold 2 ! set qos map 1p2q2t tx 2 2 cos 6 ! !sets the wrr weights to 30:70 (Q1:Q2) bandwidth servicing ! set qos wrr 1p2q2t 30 70 ! set port qos 5/3 trust trust-dscp set port qos 1/1 trust trust-dscp


42

set port qos 1/2 trust trust-dscp set port qos 2/1 trust trust-dscp !

Catalyst 6500 QoS Configuration Template (IOS) Refer to http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.1E/native/configuration/guide/qos.html for detailed information about IOS-based QoS configuration.

Example: byzv87 (1P2Q2T Modules if used with native IOS)

mls qos ! interface GigabitEthernet5/3 description BYCCM1 Server Voice wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 mls qos trust dscp ! interface GigabitEthernet1/1 description to bybl12 C102-0103 wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 mls qos trust dscp ! interface Port-channel2 mls qos trust dscp ! interface GigabitEthernet1/2 description to byzv86 C102-0103 wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 channel-group 2 mode desirable ! interface GigabitEthernet2/1 description to byzv86 C102-0103 wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 channel-group 2 mode desirable

Catalyst 6500 MPLS/PE QoS Configuration Template (IOS)

Refer to http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/ 12.2SXF/native/configuration/guide/mplsqos.html for detailed information about IOS-based QoS configuration.

Example: bybl12 (1P2Q2T Modules)

mls qos ! mls qos map exp-dscp 0 8 16 24 32 46 48 56 ! interface GigabitEthernet3/3 description to byzpo8 C102 switchport switchport access vlan 157 switchport mode access


43

wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 mls qos trust dscp ! interface GigabitEthernet3/4 description to byzv87 C102 switchport switchport access vlan 152 switchport mode access wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 mls qos trust dscp ! interface GigabitEthernet5/1 description to bybl02 C102 switchport switchport access vlan 13 switchport mode access wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 mls qos trust dscp ! interface GigabitEthernet5/2 description to bybl11 B151 switchport switchport access vlan 12 switchport mode access wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 mls qos trust dscp ! interface Vlan157 description Transfer VLAN - Lev. C102 - Lev. C102 ip vrf forwarding ip address 10.161.253.41 255.255.255.252 mpls propagate-cos ! interface Vlan152 description Transfer VLAN - Lev. C102 - Lev. C102 ip vrf forwarding ip address 10.161.253.17 255.255.255.248 mpls propagate-cos !

Example: bybl32 (1P2Q2T & 2Q2T Modules)

mls qos ! mls qos map exp-dscp 0 8 16 24 32 46 48 56 ! class-map match-all class_2Q2T_trust_dscp match access-group name acl_2Q2T_trust_dscp ! policy-map 2Q2T-trust-dscp class class_2Q2T_trust_dscp trust dscp ! ip access-list extended acl_2Q2T_trust_dscp permit ip any any ! interface GigabitEthernet5/1 description to bybl02 C102 switchport switchport access vlan 33 switchport mode access wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 mls qos trust dscp ! interface GigabitEthernet5/2


44

description to bybl31 B210 switchport switchport access vlan 32 switchport mode access wrr-queue bandwidth 70 30 wrr-queue cos-map 2 1 3 wrr-queue cos-map 2 2 6 mls qos trust dscp ! interface FastEthernet7/2 description BY9L38.FE1/0 C301 switchport switchport access vlan 302 switchport mode access wrr-queue queue-limit 30 70 wrr-queue bandwidth 30 70 wrr-queue cos-map 2 1 3 6 7 wrr-queue cos-map 2 2 5 service-policy in 2Q2T-trust-dscp ! interface FastEthernet8/3 description BYLZXQ.FE0/0 C301 switchport switchport access vlan 305 switchport mode access wrr-queue queue-limit 30 70 wrr-queue bandwidth 30 70 wrr-queue cos-map 2 1 3 6 7 wrr-queue cos-map 2 2 5 service-policy in 2Q2T-trust-dscp ! interface Vlan302 description Transfer VLAN - Lev. C301 - Lev. C301 ip vrf forwarding ip address 10.163.254.13 255.255.255.252 mpls propagate-cos ! interface Vlan305 description Transfer VLAN - Lev. C301 - Lev. C301 ip vrf forwarding ip address 10.163.254.29 255.255.255.252 mpls propagate-cos !

Cisco 7200 QoS Configuration Template (IOS)

Example: byb9l38

! class-map voice match ip dscp ef class-map control match ip dscp cs3 match ip dscp af31 match ip dscp cs6 ! policy-map QoS class voice priority percent 30 class control bandwidth percent 10 class class-default fair-queue ! interface fa1/0 service-policy output QoS ! interface fa2/0 service-policy output QoS !


45

interface fa3/0 service-policy output QoS


46

Appendix 3 – IP Type of Service (ToS)

IP Type of Service (ToS) byte—Layer 2 media often changes as packets traverse from source to destination, so a more ubiquitous classification occurs at Layer 3. The second byte in an IPv4 packet is the ToS byte. The first three bits of the ToS byte are the IPP bits. These first three bits combined with the next three bits are known collectively as the DSCP bits. The IP Precedence bits, like 802.1p CoS bits, allow for only the following 8 values of marking (0–7):

• IPP values 6 and 7 are generally reserved for network control traffic such as routing.

• IPP value 5 is recommended for voice.

• IPP value 4 is shared by videoconferencing and streaming video.

• IPP value 3 is for voice control.

• IPP values 1 and 2 can be used for data applications.

• IPP value 0 is the default marking value.

Figure 25 IPv4 Packet (ToS Byte)

Many enterprises find IPP marking to be overly restrictive and limiting, favoring instead the 6-Bit/64-value DSCP marking model. DSCPs and Per-Hop Behaviors (PHBs)—DSCP values can be expressed in numeric form or by special standards-based names called Per-Hop Behaviors. There are four broad classes of DSCP PHB markings: Best Effort (BE or DSCP 0), RFC 2474 Class Selectors (CS1–CS7, which are identical/backwards-compatible to IPP values 1–7), RFC 2597 Assured Forwarding PHBs (AFxy), and RFC 3268 Expedited Forwarding (EF). There are four Assured Forwarding classes, each of which begins with the letters “AF” followed by two numbers. The first number corresponds to the DiffServ Class of the AF group and can range rom 1 through 4. The second number refers to the level of Drop Preference within each AF class ad can range from 1 (lowest Drop Preference) through 3 (highest Drop Preference). SCP values can be expressed in decimal form or with their PHB keywords. For example, DSCP EF is synonymous with DSCP 46, and DSCP AF31 is synonymous with DSCP 26. IP Explicit Congestion Notification (IP ECN)—IP ECN, as defined in RFC 3168, makes use of the last two bits of the IP ToS byte, which are not used by the 6-bit DSCP markings, as shown in Figure 25.


47

Appendix 4 – QoS Baseline Marking Scheme


48

Appendix 5 – QoS Marking Policy (Example)

Cisco Advanced Services - build kr · PDF fileCisco Advanced Services LAN Campus QoS Design...

Documents

Transcript of Cisco Advanced Services - build kr · PDF fileCisco Advanced Services LAN Campus QoS Design...