Cisco Catalyst 3560 and 3750 QoS Simplified... Seriously!

[Music] [Music] hello everyone and welcome to this special presentation of Cisco Catalyst thirty five sixty and thirty seven fifty quality of service my name is kevin wallace and i've done several cisco training videos over the past year and a half or so and as i've been doing those videos i never really took the time to give you any of my background before we got started i thought that that's not gonna help you let's just get to the business of showing you something cool and teaching you something rather than talking about my background but this video is a bit unique because it's lengthier know the typical videos I do so I thought if you're gonna spend this amount of time with me you probably do want to know a little bit about my background how did I get here where did I come from well again my name is Kevin Wallace and currently I'm a full-time instructor of Cisco courses I'm a Cisco Certified systems instructor CCSI number two zero zero six one specifically and I also write several books for Cisco press you see a selection of those titles at the bottom of the screen some of my more recent titles include the CC and Pt shoot official certification guide I've done the videos the video mentor portions of the CC and Pt shoot to cert kit and the route cert kit from people just getting into the world of voice over IP I wrote the voice over IP first step book and I've written the second third and fourth editions of the C voice book from Cisco press and more recently for Pearson IT certification I authored the Network+ book for the new network plus exam but how did I get to this point well back in college I got my degree in electrical engineering and when you're taking electrical engineering you get to specialize in different areas be it micro circuit design or power systems well my specialty my focus was on digital communication systems I took the microwave in the fiber-optic in the digital signaling top of courses and labs and right out of college I went to work for GT laboratories that was a general telephones version of Bell Labs back in the late 80s and it was a great exposure into just a lot of different telephony equipment I did FCC and ul testing on various types of equipment and worked with key systems PBX ease transmission equipment pots plain old telephone service devices just a great introduction into the world of telephony and they don't want to work for a local university they're thinking I was gonna be their PBX administrator but to my surprise they wanted me to build from scratch a data network centered around an old Cisco a gs+ router this is about 1989 it was running cisco iOS 7.1 and and I fell in love with it I started doing more and more with Cisco routers and then later on in the nineties catalyst switches went after various certifications first it was Novell then Microsoft and Cisco and somewhere in there we did the CompTIA Network+ certification but I really have been focusing on Cisco for more than a decade and you see some of my Cisco credentials on screen I earned my CCI en route switch back in 2001 and at the time of this recording I'm studying for my second CCIE I'm working on my CCIE voice I already got my lab date scheduled and I've already had one attempt so I'm going after my second attempt right now and one of the topics on that CCIE voice lab is quality of service on a Cisco Catalyst 3750 switch and it's interesting that if you go after the current route switch CCIE instead of the 3750 that lab tests you on the 35 60 the great news is architectural II when it comes to quality of service they work the same the same commands the same architecture I'll tell a little bit about the difference between them coming up but we'll see that there are a lot of similarities so this video is going to apply to people going after their route switch or their voice CCIE but getting back to my biography and wrapping that up after I had worked at the University for a while I went to work for Walt Disney World and in Florida if you know anything about my family and I were huge Disney fans and I got to be one of five network design specialists and at Walt Disney World in Florida my biggest project that I worked on I got to help design and install the network that tied together the different theme parks the Magic Kingdom and Epcot in an animal kingdom and the studios and some of the resorts based around Cisco gear and Walt Disney World in Florida it was and I think it still is the largest single-site employer at least in the United States so I got to work on a very very large scale cisco network and that was a great experience but now I've been teaching classes online live Cisco courses for over a decade I've been riding at Cisco pressbooks for about eight years now just loving what I'm doing and like I said I'm currently going after my voice ie and primarily it's the voice courses that I teach and I said that my experience went back to college well to be honest it goes back a bit further than that I actually have a picture no kidding guys this is a picture of me at about three months of age I'm in a telephone central office an old step by step or a Strowger switch office the one that clicks and clacks the relays move as people dial digits you see my dad he's holding me there he was a central office supervisor at the local telephone company for many many years so I grew up in and around the telephone office I really think this is in my blood it's my destiny to be teaching telephony and I certainly love what I do you see my milk bottle being warmed on a soldering iron in the background and I'm really passionate about sharing what I know about telephony and learning more myself and I thought as I'm getting ready for my voice ie this is an area that I really need to master and I thought if I did this video not only would it help me master the topic it could help a lot of other people as well not just those going after the voice lab but people going after the route switch lab as well because like I said the 3560 for the route switch lab in the 3750 on the voice lab architecture lee when it comes to quality of service they work the same really the big difference between these two switches is that the 3750 supports a Cisco's stack wise technology with stack wise you can have a stack of these switches interconnected with these special connectors to form a virtual 32 gigabit per second backplane and you get to administer this stack of switches as if it were just one device think of the 35 60 is more of a standalone version of the 37 50 so when we talk about the quality of service features in this training video I want you to understand that what we're saying applies both to the 35 60 and at the 37 50 let's go ahead and get started talking about the quality of service features of these different switches and we're gonna simplify this and break quality of service down into these four different functional areas we're going to talk about classification and marking together classification is recognizing at different types of traffic where the switch says oh you're this type of traffic well I want to put you in this queue or you're this type of traffic so I'm going to mark you this way and by marking traffic early on in a packets travel the next router or the next switch can very quickly very efficiently look at that marking and make a decision like a forwarding decision or dropping decision based on that marking we'll talk about how that's done then policing that can set a speed limit on traffic if we don't want certain types of traffic to consume too much bandwidth literally we can set a speed limit on it we can say you are not allowed to exceed this limit and here's what happens if you do and if you're taking notes and I hope you are I'd like you to jot down that congestion management is killing congestion management equals queuing this is where we're determining how much bandwidth goes to different types of traffic which type of traffic goes first maybe voice traffic is high priority traffic we want to put that in a priority queue congestion avoidance on a router uses something called weighted random early detection on our switches congestion avoidance refers to waited at tail drop wtd we'll talk about that as well those are the four main areas and something you need to understand there's gonna be a lot of syntax in this presentation but the good news is if you just understand it conceptually if you know what you need to do you don't need to necessarily memorize the syntax after all in the real world you've got access to Cisco documentation in fact in the IE labs the voice and the Arats which lab you've got access there as well with the doc CD if you're practicing let me show you how to get to it from Cisco's website if you just go under support and if we go down to support and documentation and going to configure this is approximately what you get on the lab and if you want a quality of service configuration guide you could go under products let's go to switches will go into our land switches access and again the 3750 the thirty five sixty when it comes to quality of service it's gonna be the same let's just go into the thirty five sixty and let's click on configuration guides and I'm just gonna select what appears to be the most recent configuration guide and there's a section in this configuration guide on configuring quality service so here it is you can use this as your guide in the real lab and in the real world as well so one of the set your mind at ease up front you don't have to memorize all the commands that we're gonna be giving you I want you to understand what the commands do why you need them some of the subtleties about the commands some areas to watch out for but you don't have to memorize everything we're gonna talking about just want to set your mind at ease about that well let's get started now with a discussion of classification and marking the classifying traffic early on in its travel is really a Cisco best practice recommendations Cisco tells us that we should classify and mark our traffic as close to the source as possible and the reason is what I told you earlier if we somehow mark traffic maybe using a layer two marking like a class of service of cos marking or layer 3 marking like a differentiated services code point a DHCP marking or an IP precedence marking if we mark traffic early on then the next router or the next switch and the one after that and the one after that those devices don't have to go through all the work of reclassifying traffic maybe with an access list they can very quickly very a fish we look at the existing marking on a frame or a packet and make a 40 decision or dropping decision based on that the analogy I give is a gate agent at an airport let's say like we see the lady on screen let's say that I'm about to board a plane and I haven't actually reached the status yet but I'm working on it let's pretend that I'm a frequent flyer now I fly Delta Airlines a lot and I'm a member of the SkyMiles Club but I've not quite reached the medallion level yet where I get to board early but imagine the day finally comes I've earned enough miles I've flown enough places and I'm finally a frequent flyer can you imagine the scene as I go up to the gate agent and the gate agent says mr. Wallace before you board the plane early can you just prove to me that you are a frequent flyer can you show me your boarding pass from the time you went to Austin and Chicago and San Jose and Orlando and on and on and on and I've got to produce all these boarding passes from the flights I've taken over the past few years that's not very efficient is it so how do I prove that I'm a frequent flyer what the airline does is they put a marking on my boarding pass the way Delta seems to do it is they give you a zone number and I think I've got it figured out I think if you're in zone 2 usually that means you're a frequent flyer so I can just show the gate agent my boarding pass that it says zone 2 and because I have already been classified one time and marked I have a marking on my boarding pass a zone 2 I get to get on the plane ahead of the other passengers or some of the other passengers first class still beats me on but you get the idea by classifying one time it becomes more efficient the next time in the next time and the next time based on these markings that's what we want to do let's talk about how we can do classification and marking on our Cisco Catalyst switch the big thing you need to know up front is we take a look at our first piece of syntax is that quality of service by default is disabled on our catalyst switches and when I say catalyst switches remember I'm talking specifically about the 3560 and the 3750 if you have a different model things might work a little bit different going to Cisco's documentation and check out the configuration guide for the model you have but I'm trying to focus on the models that are going to be appearing on the route switching the voice ie labs and I should also hasten to say that because this is a CCI level discussion I'm making some assumptions I'm making the assumption that you already know your way around Cisco IOS you're already familiar with the basics of quality of service for example I'm assuming that you already know about the 3-step mqc process where you create class maps to classify traffic and then you create a policy map to say what you want to do with those different classes of traffic and then you apply that policy map somewhere like an interface I'm assuming you already know those basics and if not you might want to check out some of my other quality of service videos you can go to my website one exam a month comm that's one exam a month comm and if you go into the C voice area there's a bunch of free Q West videos you can check out there but assuming that you're kind of studying at the CCA level let's get back to the story to turn on quality service globally in our switch we're gonna say MLS QoS and MLS that stands for multi-layer switching don't try to read too much into that because even on something like a twenty nine fifty or a twenty nine sixty switch we still might use that command even though it's not a multi-layer switch that's just the command MOS QoS to globally turn on quality of service and when we're doing classification when were recognizing different types of traffic we could recognize that traffic and assign a policy to what we're going to do to that traffic at the port level as it comes in a particular interface or we could do it at the VLAN level hopefully you're familiar with the concept of an S VI a switched virtual interface this is where you've got this virtual interface on a switch and it's on that virtual interface that you configure an IP address and you've got other switch ports on that switch that belonged to the VLAN maybe you have interface VLAN 100 and you've got a bunch of ports that belong to VLAN 100 well you can do configuration in the interface vlan1 configuration mode and that configuration applies to all the ports in VLAN 100 that's one way of doing classification in marking that's VLAN based classification and if you want to do VLAN based classification you go into the interfaces into the ports that belonged to that VLAN and you would issue the command we see on the screen MLS QoS VLAN - based in fact let me give an example of this let's first of all go into our switch to virtual interface we go into interface VLAN 100 and assuming we already have this policy that we're about to apply we can apply the policy that I've just called test here we can apply that policy to the SVI to the VLAN interface we're saying service policy input test notice we're applying it to the VLAN interface not the physical ports then we could go into the ports that belong to VLAN 100 let's say gigabit 1 / 2 0 / 7 like we see on screen and in the port configuration mode we could say MLS QoS VLAN - based saying that it's going to take its quality of service policy settings from its switched virtual interface that controls its VLAN we are going to be giving you an example of a VLAN based classification later on in this presentation but primarily we're going to be focused on the port based classification in fact what are some different ways that we can classify at the port level we can classify based on layer 2 characteristics or layer 3 characteristics down at layer 2 we could look at a layer 2 quality of service marking a c-usa class of service marking you see at layer 2 if we have for example an I Triple E 8 or 2.1 queue trunk there are 4 bytes that get added on to a frame except for one VLAN in dot1q trunk there's an untagged VLAN that's called the native VLAN but all the other VLANs they get 4 bytes slapped on the end and in one of the bytes so there are 3 bits better used to identify the priority of that frame and how many possibilities does that give us let's see 2 raised to the 3rd power is 8 we've got 8 different possible see us class of service values 0 through 7 Cisco don't use six or seven those are reserved and perhaps a frame coming into a switch already has a COS marking if it does we can classify based on that we can put it in a certain queue based on that we can remark it to a different marking based on that we could have an access control list down at layer two that matches source and destination MAC addresses that's another way of classifying traffic we could classify it layer three the network layer as well with an existing marking and an IP version 4 header there's a byte called the toss byte the type of service byte and abide of course has eight bits if we use the three leftmost bits to indicate the priority of that packet that's called IP precedence again with three bits at our disposal that's eight possible values two raised to the third power is 8 and again Cisco says don't use six or seven those are reserved so we're dealing with the values in the range of 0 through 5 by the way if we're trying to mark voice over IP traffic with an IP precedence value the actual voice media the best practice is to use an IP precedence of 5 and if we're marking layer 2 with a COS viu we should use a COS of 5 in fact our Cisco IP phone does that for us by default a challenge with IP precedence though is that it's not very granular I mean we only have 6 values that we're supposed to work with we might have more classes of traffic than that so fortunately there's the dscp marking as well that's what we typically use today the dhcp marking is going to use the 6 leftmost bits in that tossed byte that gives us many more possibilities 2 raised to the 6th power is 64 we can have 64 different dscp values and that's almost too many because if I just say well my network I think a value of 25 is awesome that's what I'm going to use to mark my best traffic with and I send it over to your network in your network says yeah 25 that's not a very high priority in my network I like 55 that's what's high priority my network you see there's no common frame of reference so the IETF did us a huge favor the IETF standards body pre-selected certain dscp values in the range of 0 through 63 and they gave them names these names are called Appy HP's per hop behaviors and an example is the value 46 has the name of EF or expedited 14 that's what we should be marking our voice media with in fact the Cisco IP phone does that by default and we could classify based on an existing marking like a DSC p value or we still could use an access list we could use a numbered or named access control list at layer 3 so we've got these different ways of classifying traffic but here's a potential challenge what if we want to classify let's say based on a dscp marking which is in an IP packet but the traffic coming into the switch is not an IP packet how do we handle that type of classification well even though that frame is not an IP frame it still has a layer 2 header and maybe it's coming over a dot 1q trunk or even on ISL trunk maybe it has a cos a class of service value or even a nato 2.1 p value even if it's not coming over a trunk you can still have a COS value by using 8 or 2.1 p where 4 extra bytes get added to a frame a lot of pcs do this you can add 4 extra bytes to a frame and you still have those 3 bits that are used to indicate a COS value except with dot 1p you don't set the VLAN field the VLAN field remains all zeros it looks almost identical to an 802 dot 1q frame but technically it's not a lot of pcs can mark a COS value using 8 or 2.1 p but back to our story we've got this non IP frame going into the switch that non IP frame might have a COS value if it does then the switch is going to by default allow that frame to keep its COS value and I say by default that's we've done ml sqs on the switch we've enabled quality service at that point by default the non IP frame is going to keep its eus value even if we're classifying based on something else however if it does not have a CU s value already it's going to inherit the COS value of the port we're gonna see the syntax coming up for setting a ports class of service value so in this case we have a port cos of 0 a layer 2 quality-of-service marking of 0 this frame with Odysseas Marking comes in he gets real art to the ports marking which defaults to a zero here's how we set that ports see us marking maybe to a non-zero value we can in interface configuration mode say MLS Q s cos and give a value in the range of 0 through 7 again cisco cautions us not to use 6 or 7 you might actually use 6 to mark routing traffic but that's about it otherwise you wouldn't want to use 6 or 7 and remember I said that by default if a frame already has a COS value it's gonna keep that value so here's the way to alter that default we could use the command MLS qsr COS override override says i don't care if you already do have a CU s value i'm going to remark it with the ports class of service value that's a way of overriding that and we can also trust different types of markings coming into our switch if i trust to see us marking for example i might place the frame in a certain queue i might also use that as the basis for remarking it to another marking you see here's a big challenge with cos markings a COS marking is a layer two marking think about what happens to layer 2 information as it tries to cross a router think of a mac address as it tries to cross a router that layer 2 information is rewritten isn't it the router is gonna rewrite the source and destination MAC address same kind of thing happens with the COS value the router is going to rewrite that cos viu to a zero so even if we've done all this great design work upfront to give our traffic the optimal see us value that it should have everything's just perfect as soon as it crosses a router it's blown away it's back to zero so we want to preserve some sort of relative quality of service marking and what we can do is use a mapping that's a big topic we'll talk about in a few moments we could say if then if the COS value is a three then set the dscp value to maybe 24 because IP precedence dscp markings these layer 3 markings they can successfully cross the router boundary without being remarked but right now we're asking the quest what marking coming into the switch is going to be trusted a Cisco IP phone for example is going to mark voice packets with a COS value of a five and a dscp value of a forty six which again has the parot behavior name of EF for expedited forwarding and we could say what we trust if we're coming in from the campus backbone maybe we're trusting those layer three markings but if we're coming in to the switch port from a phone we might want to trust the COS marking and we can trust as you see on screen with the command mos QoS trust a COS value at layer two a dhcp value or an IP precedence value at layer 3 in fact we can even put a qualifier on this we could say I want to trust this marking if and only if it came from a Cisco IP Phone maybe we don't want to trust a COS marking coming from an end users pc who happens to be running a network interface card that this supports 802 dot 1p now we won't want to trust the marking if it comes from a phone here's what we can do to enforce that we could say mos QoS trusts and say what we're trusting here I'm using a COS but we don't stop there we give an additional qualifying a command we say MLS QoS trust device Cisco - phone now a lot of people get confused on this they think that they could just give the bottom command they could just say MLS QoS trust device Cisco - phone and that's sufficient to trust a COS value if and only if it comes from a phone no that's not going to do it because we might be trusting a dscp value if it came from a phone so you have to give two commands to make this happen the first command to say what are we trusting and the last command to say we're only going to trust that marking if it came from a Cisco IP phone by the way how do you think the switch knows that this marking came from a phone how does it know that a phone is directly attached think about it for a second what would allow a Cisco switch to know that a Cisco phone is attached how about the Cisco discovery protocol CDP that would do it specifically CDP version two is what we want to run and the Cisco discovery protocol is going to let the switch realize that a trusted device is a attached to that port and we were talking a few moments ago about how we could take one marking maybe a COS marking and remark it to some other value maybe to a dscp value and this could be based on a mapping table let's think about how that works if we want to see the existing mapping tables in a switch we can give a command like this we could say show MLS a Q s maps and there are lots of options here if you just give that command by itself it's going to show you all the different mapping tables in the switch here though we're just focusing on the COS two dscp mapping we're saying show mo sqs maps see us - dscp and notice how we can interpret the output we have all eight cos values listed 0 through 7 and just below the COS values we see the DSC p value that the switch is going to use to mark that packet frame comes in with the COS value of a 0 well that packets going to be marked through the DSC p value of a 0 a COS of 1 is going to be marked to the DSC p value of an 8 a 2 is going to be marked with a 16 or in our example notice how this works we've got to see us value of a 3 coming in but based on the mapping table we're going to mark that packet whose layer 2 header has a see u.s. value of a 3 in it we're gonna mark it with a DSC p value of 24 something that can survive a router hop I mentioned that there were several different mapping tables that we had available we can get a sense by doing some context-sensitive help we could say show mo SQS maps and we see that we can map from COS values to dscp values we could do something called dscp mutation where we say if we come in with one DSC p value we're gonna mutate that into another DSC p value there's something later we'll be talking about is policed dscp values we can say if traffic is going too fast if it's exceeding our speed limit that we could mark it down based on this particular mapping so lots of different options we don't want to make this an exhaustive discussion of every possible option but this does give us a sense of what different mapping tables are available let's take a look at how we might configure one of these mappings ourselves if we want to all to the default behavior we could say mos QoS map and we see the different things that we could set up a mapping table for and let's say that we want to do a cos to dscp mapping on some switches it might not be optimal on some Cisco Catalyst switches a COS value of a 5 used for our voice over IP traffic is going to be marked to a DHCP value of a 40 we would prefer a 46 so sometimes this is something we would want to do in fact I'm giving you the command on screen that is a best practice for mapping cos to dscp values especially for the voice world we say MLS QoS map see us - DHCP and notice I'm giving 8 values those 8 values are 8 dscp values but they correspond to the 8 cos values here through 7 so a COS value of a 0 is gonna be marked with a DHCP value of a 0 that first value as cos valuable one is going to be marked with the DHCP value of an 8 a 2 with a 16 a 3 with a 24 a 4 with a 32 and here's the big one I want you to notice a suicide of a 5 is going to be marked with the DHCP value of 46 that is what we want for our voice over IP media traffic we can then verify that the mapping was successful we could do a show MLS QoS maps see us - DHCP and we saw how to interpret this previously you can see the COS value and the corresponding dscp value by the way I said that the values I gave on-screen represented the best practice here's an easy way to remember this especially working with voice traffic here's how you should set up your cos 2 dscp markings really simple you might want to capture it in your notes you start out with a 0 and then you give multiples of 8 with one exception and that one exception is when you get to a 40 instead of using 4 to use 46 other than that it's multiples of 8 so you start with 0 and then use multiples of 8 so 0 8 16 24 32 here's the exception instead of a 4 to give a 46 and then continue on with your multiples of 8 48 and 56 start with 0 multiples of 8 the exception use a 40 instead of a 40 and to give you another oqs value mapping example let's talk about dscp mutation this is where we tell the switch if you come in with one value one dscp value we're going to give you a difference dscp value to set this up in global configuration mode we define a dscp mutation here's the command up at the top of the screen MLS QoS map dscp - mutation give it a name I like to use all upper case letter in my names by the way that way when I'm looking through a config I can very quickly spot a name that I came up with so if I see uppercase demo I know that's not some sort of Cisco IOS keyword that's something that I came up with I'm calling this mutation demo and then I'm giving a series of dscp values 24 26 28 30 if a packet comes into the switch with any of those dscp values I'm going to mark it to a dscp value of 24 we then go into interface configuration mode I say that I'm trusting at dscp markings and I apply that mutation which is called demo and then I'm looking at my DHCP to dscp mutation map notice that right within interface configuration mode I don't have to exit back out I could just say do and then give a command I could say do and then something like a show come in I'm saying do show MLS Q s maps dscp - mutation and here's the way you interpret the output you have the incoming dscp value and then you have the outgoing dscp value your incoming dscp value is going to be broken into two different digits in my example let's say that we want to take a 26 and see how it's being mapped we're gonna find the two in 26 along that left-hand column if we go down three rows you see there's a row for the number two and then we look at the column with the header of six and we see where that two row and the sixth column meet the two row in the six column they meet at a value of 24 that's a way for us to interpret that output that a dscp value of a 26 is going to be mutated to a dscp value of 24 and that's going to wrap up the first part of our discussion dealing with classification and marking again just to sum up we want to keep this simple we said that we could classify we could recognize different traffic at layer two using a MAC address access control list or using a COS marking we could classify traffic at layer three with an access control list or an existing dscp or an IP precedence marking and once we recognize that traffic we could do something with that traffic maybe we could take one marking and convert it into another marking and as we're going to see later those values are going to be used for policing congestion management or queuing and congestion avoidance or weighted tail drop and we saw have to influence how those mappings happen oh and we also saw how to turn on QoS globally in our switch with the MLS QoS command this with this point in our discussion we've enabled the quality of service on our switch we're saying what marking if any we're trusting on incoming traffic coming into a port and we saw how to take that marking and maybe remark it to another marking but at this point has the behavior of anything really changed yet no no now we need a mechanism to look at that marking and make some sort of a decision based on that marking the first mechanism we're going to consider that does that is policing the policing is going to set a rate limit for a certain type of traffic metaphorically we could think of this as a speed limit and if traffic obeys that speed limit we've got traffic not trying to exceed that speed limit it's referred to as conforming a traffic if we have traffic that exceeds that speed limit that's called exceeding at traffic exceeding traffic we could say it's going to be dropped if you're violating the speed limit you're discarded you're out of here we're gonna discard you in the bit bucket or we could say well we'll still try to send you but we're gonna punish you you exceeded the speed limit you got to pay a fine we're gonna mark you down to a lower priority dscp viu as an example in fact that's what we're seeing here on screen based on where the traffic is obeying the speed limit or not we can transmit it we could drop it or we could transmit it and remark it with a different value and remember earlier we talked about the fact that classification be turned on at the port level or at the switched virtual interface level policing can be turned on there as well we can turn on policing at a port or under interface VLAN something under the SVI and we'll take a look at the syntax for doing both first let's consider policing a port when we're policing traffic at a port we can do it based on a single class of traffic we could say that we're going to classify FTP traffic and if that File Transfer Protocol is taking up too much bandwidth we can start discarding excess packets or we could say we're gonna set a speed limit but it's not for a single class of traffic it's for lots of classes of traffic combined if the combined bandwidth of multiple classes of traffic if that exceeds a certain speed limit then we're gonna start maybe dropping traffic if we're doing that if we're policing based on the total bandwidth consumed by multiple classes of traffic that's called an aggregate policer let's take a look at our first example and we'll keep this one simple let's police based on a single class of traffic and again I said earlier that I was making the assumption that you were already familiar with mqc the modular quality of service command-line interface if not this is a great example of mqc it's a three-step process step one we classify with the class map step two we say what we're gonna do with the class of traffic with a policy map and step three we apply that policy map typically to an interface the first we are going to recognize a certain type of traffic in my example I'm recognizing Voice media traffic which in the Cisco world uses UDP ports in the range of 16 thousand 384 through 32 767 notice up top it's a good old fashioned access list access list 100 I'm at permitting in other words I'm matching that range of UDP ports and then I do step one of mqc we go into a class map which are called VoIP and I'm saying I want to match access group 100 that's gonna match that access list so now my voice packets they get classified into this VoIP class map that's step one of mqc step2 of him QC says what do you want to do with this class of traffic to do step two of him QC we create a policy map I'm saying policy - map police - VoIP not much happens by the way in policy map configuration mode the magic happens in policy map class configuration mode notice that our config mode goes from P map to P map see when I say class of VoIP now we're in policy map class configuration mode I'm saying what do I want to do with this particular class of traffic and I'm saying police and I'm giving a number of 256,000 followed by a number of 8,000 and then I say exceed - action drop let's camp out here for a moment and understand what's going on we said that policing could set a rate limit on a certain type of traffic well that rate limit in this case is 256 thousand bits per second some quality of service configurations use a unit of measure of kilobits per second when it comes to policing though it's bits per second careful with that and the 8,000 that's even more confusing the 8,000 is not a rate this is not bits per second our bytes per second it's nothing per anything it's not a rate it's just a number of bytes let me explain what we're saying here it's called the burst size let's take a step back and think though how do we send at a rate that is less than the interface speed if I've got a gig port and I'm policing at my voice traffic in this case - 256 K how is that even possible how can I send traffic at a rate that is less than the port speed that seems physically impossible well the secret is this we don't send all the time we send a certain number of bytes at line rate and we stop and then we send a certain number of bytes at line rate and we stop we start and we stop we start and we stop and then over time over the period of a second on average we've sent in our case 256 kilobits per second here's a metaphor to help you understand this let's assume that after I shoot video today I'm gonna hop in my car and I'm gonna go visit a friend and let's say that that friend that lives 60 miles away and I hop in the car I'm anxious to get there and I drive at a rate of a hundred and twenty miles per hour at that rate how quickly would I be getting to my friend's house thirty minutes at a rate of 120 miles an hour I would cover a 60 mile distance in 30 minutes and at that point my car would be stopped but let's say that along the way to my friend's house I get pulled over by a law enforcement official and they say mr. Wallace do you realize you were driving at a rate of 120 miles an hour I could accurately say that well actually officer no I wasn't I was driving at a rate of 60 miles per hour you see over the period of an hour I would only have traveled at 60 miles now travel at a rate of 120 miles an hour for 30 minutes and then I traveled at a rate of zero miles per hour for the next 30 minutes so over the period of an hour on average I traveled 60 miles per hour okay don't try that in the real world but that is the way it works with policing with policing that we're going to send at line rate for a period of time and we're gonna stop we're gonna start and stop and start and stop the value of 8,000 on screen that's how many bytes were gonna send when we are sitting at line rate we're gonna send 8,000 bytes at line rate and then we're gonna stop and then we'll send another 8,000 bytes at line rate and then we're gonna stop but if you take a look at this over time that you will see that on average we will be sending at an average rate not an instantaneous rate if we had one of those police radar guns that we could pull up and check the speed of a packet coming out of a port it wouldn't be 256 K it would be a gig or whatever the line speed was but on average over time it would average out to 256 K because we're not sending all the time the 8,000 that's our burst size that says how many bytes we send at one time before we take a break and don't send anything for a while normally this is not a value that we need to be terribly concerned with it's not changing the speed limit it changes how bursty gonna be sending traffic if I made this a much much larger value then I would be potentially sending that line rate for a fairly long amount of time and everybody else might have to wait on me to send at this rate so traffic that's not being policed it might be delayed while I'm transmitting my traffic however I give other traffic types more opportunities I let them transmit more frequently I give them a smoother bandwidth utilization by picking a smaller number typically use 8,000 so again when we say police 256,000 we're saying that is the rate limit and the way we get to that rate limit it's an average over a period of time the way we get that average rate is we send a line rate and we stop we sin and we stop and when we're sending when we're sending we're sending 8,000 bytes at line rate and then we're stopping and then we send another 8,000 bytes and over a period of time on average we're sitting at an average rate of 256 K then we say what do we want to do with this exceeding traffic traffic that's trying to be transmitted in excess of 256 K and here we're saying we're gonna drop it another option might be to try to transmit it but mark it with a lower dscp value but here we're something we're going to drop it that step to of mqc step 3 of mqc is when we take this policy map and we apply it typically to an interface here we're saying an interface gigabit 1 / 2 0 / 8 we're applying this service policy coming into the switch as traffic is coming into this port we're saying if your voice traffic welcome if your average rate is not greater than 256 K if it is greater than this excess force traffic it's gonna be dropped let's take this a step further let's say that we want to police not just a single class of traffic we want to police a collection of traffic types notice that in our first command on-screen I'm saying MLS a QoS aggregate - police I'm giving an aggregate police her name it's just a name I came up with VoIP media signaling and I'm setting an aggregate rule and that aggregate rule is giving a rate limit of 320 kilobits per second 320,000 bits per second that's the aggregate police rule and then we're saying that the rate limit for all the traffic types that fall under this aggregate police or the rate limit for everybody combined is three hundred and twenty thousand two bits per second again I'm giving eight thousand as my burst I'm gonna be sending eight thousand bytes at line rate maybe it's a gig maybe it's ten gig but I'm gonna send eight thousand bytes at line rate and then I'm gonna stop I'm gonna send nothing and then I'm gonna send another house and I'll send nothing I'll start and I'll stop I'll start and I'll stop and over a period of time on average we will send no more than three hundred and twenty thousand bits per second in exceeding traffic it's going to be dropped but instead of applying this to a single type of traffic notice I'm defining two types of traffic and sticking with my voice example I'm identifying RTP the real-time transport protocol traffic which is a range of UDP port Cisco uses sixteen thousand three to four through thirty-two 767 I'm matching that with an access list and then I'm also matching call set up traffic specifically the skinny client control protocol sccp and I'm creating an access list I'm using a named access list here called sccp where I'm recognizing that call signaling traffic and I create a couple of class Maps one for RTP one for sccp then I create a policy map notice how this works though when I go into policy map class configuration mode for RTP and I say police I'm not saying police and then giving a rate limit I'm saying police aggregate and then I'm giving this aggregate rule of view IP - media - signaling I'm doing the same thing for the sccp class that means that you're gonna be part of this aggregate total amount of bandwidth that all these different classes are going to use in this case I've got two classes assigned to this aggregate policing rule what this means is the grand total amount of being with RTP and the skinny clan control protocol traffic combined bear combined at limit is not allowed to exceed three hundred and twenty thousand bits per second and if it does we're gonna drop that exceeding traffic and again step three of mqc we're applying it to an interface down at the bottom of the config and let me show you one other policing example and this is going to tie in to what we discussed earlier about those quality of service mappings one mapping that we could have is a policed dscp mapping a police - dscp mapping says if traffic is exceeding the rate limit that we specified if that traffic has any of these dscp values let's remark any of those dscp values to this other value so notice the first coming on screen I'm saying if we have dscp values of 24 or 26 or 46 by the way 24 and 26 commonly used for call setup packets and 46 used for actual voice media packets if we are exceeding our rate limit we could say if you have any of these values we're going to remark you to a value of zero and again a little bit repetitive from our previous example I'm creating a class map for RTP a class map for sccp but notice when we get into policy map class configuration mode for RTP and for s CCP notice I'm saying for RTP for the real-time transport protocol police to a rate limit of 256 thousand and the way we're gonna get there we're gonna send 8,000 bytes will stop and will start and will stop not a big deal that does not affect our overall rate limit that just impacts how bursty our transmissions are gonna be the exceed action is not drop in this case the exceed action is policed - DHCP - transmitted which means we're gonna go look at this globally defined mapping which says if your value is 24 or 26 or 46 and it's probably gonna be 46 if we're talking about RTP traffic we're gonna mark you with a DHCP value of a0 same thing for the sccp traffic and step three of mqc we apply that to an interface so here we're setting up this global rule that says if you violate the speed limit instead of just giving an exceed action of drop we can say now we're gonna remark you to this other value there is another policing example I want to give you and it deals with policing and SVI this is where we're going into interface of VLAN something and we're up a policy map there it gets a little tricky here guys we're gonna have to have a nested policy map remember when I was reviewing nqc a few moments ago I said that step one is we create a class map to recognize traffic step two we create a policy map to say what we want to do with those different classes of traffic and step three we apply the policy map and I said that we typically do that to an interface well another place you can apply a policy map is not to an interface you can apply it to another policy map you can apply a policy within a policy that's a nested policy map and that's what we're gonna have to do here we're gonna apply a policy map to the interface VLAN something the SVI that particular policy map is not going to contain the police command instead it's going to reference another policy map and that other policy map the nested policy map the child a policy map some people would call it that's going to contain the police command let's take a look at an example first remember what we discussed early on in this presentation we were saying that if we wanted to do VLAN based quality of service then we would need to go into the interfaces participating in a specific VLAN let's say it's VLAN 100 and we would need to say MLS QoS VLAN - based that's what we're doing at the top of the screen we're going into a range of ports gigabit 1/2 0 size 15 through 20 and for that range of ports we're saying they're gonna be using a VLAN based quality of service then we start to go through the 3 steps of mqc we have an access list that's matching RTP traffic again and that traffic gets classified by the RTP class map and I've got another class mapped at this time instead of matching a particular type of traffic it's matching the input interface we're giving that range of ports as the ingress interface for traffic and then that we're creating what we're going to refer to as the child a policy map I named it port and we go into policy map class configuration mode for the ports class map remember that's the class map matching this series of ports and we're saying for traffic coming into this port we're going to police it we're gonna set a rate limit to two hundred and fifty six thousand two bits per second with the burst of eight thousand bytes the exceed action is drop which is pretty much what we saw before here's where it gets different though we're not going to be able to take that policy map of port and apply it directly to the SVI that would not work instead we have to nest it inside of another policy map so now we're gonna create a parent policy map that we've named VLAN and we go into the RTP class not the ports but the RTP class for the VLAN policy map where we're matching that range of ports and notice it's within policy map class configuration mode of that parent policy map where we say service - policy port that's referencing the child a policy map that's the policy map that sets the policing rate limit now also notice that I'm saying set dscp 46 I'm marking this RTP traffic coming in these ports with a dscp value of 46 you might think well the IP phone is already doing that no need to do it here actually you've got to do something in this policy map because when you try to apply it to your SVI if all you've done is say service policy port it's gonna say you're not doing anything you didn't configure anything in that policy map so you've got to do something and if something I'm doing is I'm setting the dscp value on these voice packets to 46 understanding they're probably already 46 but it's not gonna do any harm to set it to 46 and I have to do something or else I'm not going to be able to apply it then we can finally do the third step of nqc where I go into an interface in this case it's an SV I it's a VLAN interface and I say service - policy input and I give the name of the parent - policy map Beale in this is going to police RTP traffic entering that range of ports to a rate limit of 256 thousand bits per second and it's going to mark that traffic with a DHCP value of 40 six and that's gonna wrap up the discussion of the second quality of service feature on our Cisco Catalyst switches that we mentioned we've now talked about classification marking we've talked about policing and inner notes ask you to write down that congestion management equals cueing let's talk about that next I gave you a fairly intimidating bullet list of things that we might have to configure this is where a lot of people really get confused with quality of service on these models of Cisco Catalyst switches there are so many things to configure we can set up a priority queue we can define something called a cue set we can say how many buffers are gonna be available for sub queues how much memory can they possibly allocate what thresholds are gonna have for dropping traffic what cos or dscp values go into different queues how do we give different amounts of bandwidth to these different queues how can we limit the amount of bandwidth that a queue has available there's a lot to do here however we're gonna try to simplify this and really break it down into two major functions the first function is all about getting our queues configured defining a priority queue saying what type of traffic goes into the various cues you see if you think about the input or the output interface on a switch that interface that port has a buffer a queue allocated to it and it can take that queue space and we can carve it up into sub akyüz we can have a couple of sub q x' going into a switch we have to input queues and a port can have four output queues and we can put different types of traffic in those different queues and we can set some limits some thresholds to say well if the queue isn't and all congested we're going to put all these different see us values in the queue maybe we'll put in C us values of zero one two and three but if the queue starts to get congested if we exceed 25% of the queue capacity for example maybe we start rejecting certain types of traffic maybe we start rejecting C us zero and one traffic that's something we can do with our threshold settings and weighted tail drop so one big task that we have is just laying the groundwork defining our cues defining what goes in the cues defining these thresholds that's job one let's set everything up for the input and output cues then once we do that the second task we have is to say how much bandwidth are we going to give to those different cues that's going to use a technology called shaped round robin or SRR and you'll notice the graphic I have on screen this is a graphic of the Splash Mountain entrance at Walt Disney World one of my daughters and I we were about to go on this ride and I took this picture and I was thinking that this represents what we're about to talk about because on Splash Mountain I remember we had to stand in line for it was about 40 minutes I think before we could get on the ride and we stood in literally it was called a queue you stood in this big line that we've Dan wound around these trees and eventually we got on the ride but some people got on the ride a lot quicker than we did because they had something called a fast pass you could go in and you could request a fast pass before this ride early art of the day and it says okay come back between these times you get to get in a priority queue and if you have this special pass you're able to show it to the cast member and you're able to get in the shorter queue you're able to get on the ride sooner that's what we can do with our traffic inside our Cisco camel switches we can give some traffic a fast pass we can give it access to this priority queue where that traffic gets to go first out ahead of some of the other types of traffic we could loosely compare that to a priority queue and our Cisco Catalyst switches and that's gonna be one of the big concepts we're going to need to understand let's get started though by taking a look at the architecture of our queues coming in and going out of our Cisco Catalyst which we mentioned that we had an ingress queue coming into a port we can have two queues notice when we come in we can classify traffic we could apply our policing rule if we're gonna do any marking based on that policing rule we could do that here coming into the switch and then we're gonna put that traffic in one two cues and one of those cues can be a priority queue and by default after we've enabled a quality of service on our switch by default its queue number two queue number two is the priority queue meaning it's gonna get preferential treatment and I gave you the comparison to the Fast Pass at Walt Disney World another comparison often use is the carpool lane if you're in a large city and there are two or more passengers in your car you're a special type of traffic you might be able to get over into this leftmost Lane called the carpool lane and in times of congestion during rush hour you might be able to go ahead of a lot of the other traffic it's really congested in those primary lanes but you're in this special carpool lane you're in this priority Lane you're a special type of traffic and you get to go ahead of other types of traffic but here in America anyway is that carpool lane like the Autobahn is it unlimited speed can you go as fast as you want no there's still a limit you can still only go so fast and the same thing holds true with the priority queue we're gonna be able to empty that priority queue out first ahead of the other queues up to a certain limit you see by default on the ingress coming into the switch that priority queue has access to 10% of that ports bandwidth the first 10% of that ports bandwidth if we have traffic in that priority queue you bet it's gonna get to go first and it's gonna be able to consume as much as but no more than 10% of the interfaces bandwidth so we're not going to be starving out other traffic types once we place traffic in one of these incoming queues we're gonna be able to configure srr and I know I define that as shaped around robin well it could also be known as shared round robin and in the input queue it it has to be shared round robin will distinguish between those later but we can run this shared round-robin algorithm to dictate how we're going to empty traffic from these queues and send it to what I think of is the backplane of a switch they're referring to it here as the stack ring this is going to interconnect the incoming port with the outgoing port and if there's a lot of congestion on a switch and there can be congestion on a switch do to speed mismatches we might be coming in for example at a rate of 10 gig and leaving at a rate of fastethernet that's a pretty big speed difference even on a high-speed Cisco Catalyst which we can still have congestion and if we're not able to get to the backplane if we're not able to sin from the source port to the destination port right away well the good news is we can store that traffic temporarily in one of these two input queues coming into the switch let's contrast this with our egress or the output queues coming off of the backplane or coming off of the stack ring going toward that outbound port instead of just having two queues we had two input cooze we can have four output queues we have this grand total queue space that gets carved up into for outbound queues and again the way we're going to empty those queues is based on how we have srr configured and in the outbound direction the SRR could be either shaped round-robin or shared round-robin and again we'll talk about the distinction between those in a bit also we could have one of these queues defined as a priority queue a queue that gets serviced first not unlimited but up to a point it could have priority treatment but not to the point of starving out of the traffic hopefully and it's important to understand that on the Cisco Catalyst 35 60 and 37 50 switches this is not true for all switches but for those models of switches its queue number one that could potentially become the priority queue it's not enabled by default but it can be enabled and we're going to show you how to do that in fact let's think for just a moment about how we can configure priority queuing for our input port the ingress port we said by default queue number two was our priority queue and it was limited to 10% of the interfaces bandwidth we could send traffic in that queue first up to a limit of 10 percent of the interfaces bandwidth before we started allowing other types of traffic to flow if we wanted to alter that behavior here's how we would do it in global configuration so this is going to impact the ingress queue for all of our ports we can say MLS Q s s RR - Q input priority half a Q and you get to say which Q is going to be the priority Q it's - by default you could still leave it it - or you could send it to a one then we can set a ban with them out an example on screen I'm saying queue number one is going to be my priority queue and I want the bane with to be 20 percent of the interface bandwidth so my final command is MOS q s s RR - Q input priority - q1 Bane with 20 globally configured I'm making hue on my priority queue instead of the default of q2 and 20 percent of the interfaces bandwidth gets to go first it's gonna get priority treatment kind of like a carpool lane but that's the speed limit of the carpool lane we're not gonna be able to exceed that amount of bandwidth we're not going to just keep sending traffic from the priority queue at the expense of other traffic types how do we enable outbound priority queuing for our egress port here it's not defined globally it's defined in the port in the interface itself if we give the command a priority - Q out that is going to transform a queue number one remember we had for outbound queues well queue number one of those outbound queues and a port is gonna be transformed into a priority queue notice that this command is not being used to specify a bandwidth limit we'll get to that a little bit later but these commands that we've just seen they show us how to configure or manipulate the priority queuing configuration of our ingress our incoming and the egress the outgoing cues before we get into srr and all of that configuration we need to jump ahead and talk about the fourth of our four quality of service topics and that was congestion avoidance and I said that that was gonna be using something called a weighted at tail drop we need to understand that because we're really gonna be configuring srr and weighted taylor up together so we need to understand the theory of both of them before we get into the config the idea is this within one of our queues let's say our outbound queue is divided into those four sub queues like we talked about let's say that this is queue number one of those sub queues and in our case we'll pretend it's not acting as a priority queue what we could do is say different COS values are going to be placed in this queue but as that queue starts to fill to capacity we're going to start denying admission to certain COS values here's the way to interpret the graphic on screen as long as we're not congested everybody is welcome in this queue and to make it simple I'm just putting all of our CU s values in this one queue everybody is welcome until we hit 25% of the Q's capacity at that point cos values of zero and one and two are going to be rejected newly arriving frames that have a COS value of zero one or two they're going to be turned away everybody else still gets to come in until we hit 50% of the queue depth at that point we're gonna start rejecting cos values of three and four in addition to zero one and two but see us values of five and six and seven they're still permitted until we get completely full when a queue completely fills to capacity obviously there's no room in the queue newly arriving frames are gonna be dropped off the top that's called tail drop by the way that's a good term for your notes tail drop is when a newly arriving a packet or frame is dropped because there's simply no room in the queue at that point all of our traffic is going to be dropped and notice that we've defined three thresholds on-screen threshold 1 and 2 we could administrative leakin figure where those thresholds lie I just randomly picked 25% and 50% and we could set those to different values but the third threshold threshold number 3 that is the capacity of the queue that doesn't change and our Cisco Catalyst 3560 and 3750 switches they're gonna have these 3 thresholds we've got two input queues for output queues and we can have three thresholds it's important to understand that as we're thinking about the architecture of these Cisco Catalyst switches and at this point you're probably starting to see that there are a lot of moving parts when it comes to congestion management and avoidance we've got thresholds and it's going to get even more complicated we're gonna see in a few moments that we'll need to set up how much buffer space is going to be available for a queue and it can go above that but we can set a limit on how much it can possibly exceed it's guaranteed capacity we could give different amounts of queue space to different queues on an interface and that's a lot of configuration isn't it to go into each of our ports and say well here's your thresholds here's your guaranteed buffer availability here's your maximum memory here's your buffer allocation Wow that's a lot of work to do on every single interface so here's a shortcut you're gonna like this we're gonna be able to configure it's kind of like a macro we're gonna define something called a queue set and we can define these types of parameters for not just a single interface but for a queue set and then we can assign ports to that queue set and by default all of our ports on a switch belong to a single queue set queue set 1 but there is a second queue set that we can configure if we want some of our ports configured differently than other ports we could define a second queue set and the way you assign an interface or a port to a queue set you see it on-screen we say queue - set space and we give the queue set ID which is going to be either a 1 or 2 again everybody belongs to queue set 1 by default and in that queue set we can define thresholds and buffer availability and on and on like you see on screen but if we need a separate set of rules we can define a queue set number - if we need to let's talk about one of the things that can be defined a for a queue set when we think about a physical port on our Cisco Catalyst switch there is a chunk of the switches memory that's going to be dedicated to the output queue for that port and remember we're gonna take the grand total queue space for that port and we're going to carve that queue space up into 4 separate queues we're going to be able to place different types of traffic into different queues and we can give each of those 4 queues a certain amount of memory maybe we want queue number 1 to have a greater capacity than queue number 2 we're going to be able to specify the allocated amount of memory for each of these sub cues and just because we allocate a certain amount of memory for one of these sub cues that doesn't necessarily mean that it's guaranteed to have that amount of memory available during times of congestion we can specify what percentage of that allocated memory is guaranteed to be there in a pinch if we're congested do we guarantee that 100% of that Q's allocated memory is gonna be there we could do that or we could say well I all accounted you this much memory but if times get tight I'm only gonna guarantee that you can have 75% of that so we can set a different percentage of the memory allocation that we give to one of these cues we can specify what percentage is guaranteed it doesn't have to be 100% and then that we could say well if you need even more storage space than we've guaranteed you it's possible that you can go above that because notice how the memory is laid out each of our ports have these four cues I've Illustrated a couple of ports on-screen ports 1 & 2 h-have 4 cues but in addition to the cue space dedicated for these ports there's this common memory pool from which we can borrow so we could literally say that ACK you can have more memory than its capacity simply by borrowing from the common memory pool or from some other cue that isn't using its memory at the moment we can do something like this we could say well I guarantee that you're going to get a hundred percent of what we've allocated for you but if you need more and more is available maybe you can have as much as 200 percent of your allocation let me show you this graphically notice on-screen that port 1 cue number 2 here I've said that this cue can have a maximum of 200 percent of its memory allocation if it needs it and what's it doing its borrowing from the common memory pool I have the area shaded in not only is it using the memory dedicated to port 1 q2 it's also using an equal amount of memory from the common memory here's the syntax for how we can set this up in global configuration mode we're gonna say MLS QoS Q - set output and we identify the Q set ID everybody belongs to Q set one by default but if we've divided it up we could say the Q set ID might be a two we can also specify those thresholds here for weighted tail drop we could say threshold and we say for a certain q q one for example it can be one two three or four drop threshold one is 25% and drop threshold to maybe is 50% and then I can say what is the reserved threshold is this gonna be 100% of the memory allocated to this Q is gonna be something less than that and then I can say what is the maximum threshold maybe it's two hundred percent it's double the memory that was allocated for that Q and we've been talking about allocating an amount of memory for a Q here's the command that lets us do that not all Q's are necessarily created equal we could give different storage capacities to our different queues we've got these four output queues we could use this global configuration command to size those queues differently MLS qsq - set output again we give the Q set ID and we're gonna specify the number of buffers that we have available for each of our queues and in the example on screen it looks like I'm giving Q number 1/33 buffers Q number 217 buffers Q number 3 and Q number 425 buffers the valid range for the number of buffers is 0 if we don't want to use the Q 0 through 99 for Q's 1 3 and 4 there's kind of an exception though for Q number 2 key number 2 has to have at least one buffer available that's used by the CPU so it has a minimum of 1 and therefore a maximum of 100 we've seen a lot of syntax now let's tie this together and make some sense of it about walking through an example here we're saying in that first command mo qsq set output to we're defining something for cue set to nobody belongs to that by default so we'll need to put a port in that cue set but we're saying for cue set number two were divvying out the memory like this 50 25 10 15 that's the relative amount of memory that's going to be given to these different cues and if we add that up 50 plus 25 plus 10 plus 15 that's really convenient that adds up to 100 that means that 50 out of 100 50 percent of the ports buffer space is going to be given a cue 1 25 out of 100 25 percent of the ports buffer space is going to be given to cue to 10 percent 2 Q 3 15 percent 2 Q 4 that's the buffer allocation but that's not guaranteeing that that cue is going to have access to that much in times of congestion remember we could set the guaranteed reservation amount and then we could set the maximum amount that we could potentially allocate by borrowing from the common memory pool or borrowing from a another cue that doesn't need its memory at the moment that's what we're doing in the next command we're saying MLS qsq - set output to threshold - 3366 100 200 what this means is when we say cue set output - that's cue set - then we say threshold - that's talking about cue number - two of our four cues for cue number two our first drop threshold is going to be 33 percent of the capacity of the cue the second drop threshold is going to be 66 percent remember there is a third threshold we don't configure that here because the third threshold by definition is the entire queue space when the cue is completely full the we've reached the third threshold what's up with the next two numbers though 100 and 200 well the 100 means that 100% of the buffer space that we've allocated to Q - again is going to be guaranteed to be there even in times of congestion guaranteed it's going to be available by the way what is that guaranteed queue space 25 buffers we see that in the top command what's the 200 that second command well that says we're going to be able to use some unused buffer space from another port or from the common memory pool if we suddenly need more than 25 buffers in queue number two during a time of congestion we just gave the one command here for queue number two we might give similar commands for queues one and three and four and this configuration was for queue set two by default nobody belongs to you set two so notice what we're doing toward the bottom of the config oh we're going in to interface gigabit one slice of zero slash 11 and we're saying hey you belong to queue set two and now that interface that port it suddenly inherits all those configurations something we've not done yet though is to say what traffic is going to be placed in the different queues we said here's the buffer allocations for the queues here's how much is going to be guaranteed during a time of congestion here's the maximum amount of buffers that ik you could possibly allocate if it needed more than its original allocation but we've not yet said what kind of traffic goes into these queues and what traffic is gonna fall in these different thresholds that we've set up that's what this command on-screen is gonna do for us let me just walk you through the example by the way there are more options to the command you're seeing on screen but I wanted to show you just the command that we need to accomplish what we're talking about right now I just showed you those parameters well actually showed you one more I showed you how we could map a COS value or a dscp value into a certain queue but I think we can make the most sense of this by taking a look at the example we're saying MLS QoS srr - Q output cos - map we're taking a look at a frames class of service value and based on that frames class of service value we're gonna put it in one of these for outbound Q's 1 2 3 or 4 and at the top command we're saying q1 threshold 1 0 1 what are we saying here we're saying for key number 1 cos values of 0 & 1 they're gonna be permitted into that queue until we reach threshold 1 and on the previous slide we saw how to set the thread shoulde for a cue we could set two thresholds we set up the threshold for cue number two I think it was 33 percent and 66 percent here we're dealing with cue number one though and we're saying whatever that threshold is set to see West values of 0 and 1 are welcome to come in until we hit that first threshold the next command still dealing with cue number 1 says that see us values of 2 and 3 they're gonna be walk up until we hit the second threshold the third command on screen says for key number 2 we're going to allow see us value of a 4 to enter the queue until we hit the first threshold next over key number three we're saying a COS value of a 5 is going to be permitted until we hit threshold number 2 so no effect from threshold one it's only until we hit threshold number two that we're gonna start discarding a CSV of a 5 and finally cue number 4 it's going to be accepting C West values of 6 and 7 until we hit threshold number 2 here's that same command but I've graphically shown you what we're doing I drew out the 4 Q's for you on screen with the thresholds that top command on screen where we're saying q1 threshold 1 0 1 for Q number 1 we're saying 0 and 1 rcus values that are welcome to come into the queue until we hit threshold 1 at that point we'll start rejecting those cos values the next command and the second command on screen that says for threshold 2 we're going to accept cos values of 2 and 3 they're gonna be walking until we hit that second threshold at that point we're gonna start dropping those cos values the third command on screen is dealing with queue number 2 it's only going to be accepting a COS value of a4 and then we're gonna start dropping that cos value before after we hit threshold number one the fourth command on screen is for Q number three we're gonna be accepting a COS value of a five in queue number three until we hit a threshold of two and the final command on screen for queue number four says we're gonna be accepting cos values of 6 and 7 into that queue until we hit threshold number two we've now completed the first of two major chunks of configuration that we were talking about earlier we said that when it comes to congestion management and to congestion avoidance we've got to lay the we've got to go in and define the buffers that are available for our different cues how much is reserved how much is guaranteed during a time of congestion for the different cues how many extra buffers can a queue have in a time of congestion if buffers are available maybe from the common memory pool or from another queue we've defined the thresholds we said where are we placing different cos values we've now laid the groundwork but we haven't yet said how are we going to start emptying these queues what amounts of bandwidth are we going to give to the different queues that's where srr comes in srr has two different modes of operation shaped mode and shared mode shaped mode is only going to be working on the outbound on the egress queues shared mode will work either inbound or outbound or both but shaping doesn't just give a guaranteed amount of bandwidth to a queue it sets a limit on that bandwidth it says yes you can have 20 percent of the interface speed but no more we're not allowed to go above that shaped limit shared however says yeah we're gonna guarantee that you can have 20 percent of the interface beam width but if you need more and more is available we're not gonna limit you to that we're going to allow you to share with other queues so to sum up shaped not only gives us a guaranteed amount of bein with fur queue it says that we can have no more than that amount of bandwidth wall shared says you can have a guaranteed amount of bandwidth and maybe more if you need more let's begin our discussion of the configuration of srr by taking a look at our input queues and remember only shared round-robin not shaped round robin is going to be used on the input queues or the ingress queues first this command is fairly similar to what we saw with our output queues we're setting the drop thresholds for our input queues in this example we're saying for queue number one the first threshold is 25% of the queue capacity and the second threshold is at 50 percent of the queue capacity again the third threshold by definition is 100% of the queue capacity also similar to what we did with our output queues we can say what buffer allocation what storage capacity not bandwidth but what storage capacity is going to be given to our two different queues we say globally and notice we're not using queue sets here queue sets that's a concept that we use outbound only here in global configuration mode without referring to accuse that we're saying MLS Q s s RR - Q input buffers 2575 we're saying that that 25% of a ports buffers are going to be given to queue number one that's the size of the queue that's its capacity that's not necessarily the amount of vein with that's gonna have that just influences how much traffic it can hold 75 percent of a ports buffers is going to be given to queue number two and finally we get to srr here's how we say how much bein with not storage space the buffer options specified the storage space the bandwidth option here on-screen specifies the percentage of actual bandwidth that we have available and we're giving a guarantee of at least 30 percent of a ports vein with two queue number one and a guarantee of at least 70 percent of a ports vein with two queue number two that was our input queues let's take a look at the output queues however remember with output we can use shared mode or we can use shaped mode first we're gonna take a look at shared mode and very similar to what we just saw with our input queue we can specify for weights the relative amount of bandwidth that's going to be given to these four queues and in our example we have a relative weight of 30 for queue number one a relative weight of 24 key number 225 for queues number three and four notice that if we add those numbers up 30 and 20 and 25 and 25 it equals 100 it doesn't have to I like to do it that way I think it makes it a lot easier to visualize the bandwidth percentage that's going to be given to a queue because remember it's a relative weight in other words take a look at the number 30 it's 30 relative to the grand total of the weights for all the Q's so if we add all the Q's up we just said that's 100 well Q number 1 therefore is gonna get 31 hundreds in other words 30% of that ports being with you don't have to make them add up to 100 they can add up to something else if they added up to 200 then it would be 30 divided by 200 that would be the percentage what would that be 15 percent of the port's bein with it will be given to q1 but just as a good practice you might want to make your weights add up to 100 just for your own convenience and also notice that unlike our input Q configuration the output Q configuration for SR it's configured not globally it's configured in interface configuration mode let me give you an example here we're going into interface gigabit 1/2 0 / 4 it's got a speed of 1 gigabit per second the speed is 1,000 Meg that's what we're saying there in that second command and we're saying that the bandwidth for shared round-robin is 1025 3550 does that add up to 100 no it doesn't let's see we've got 50 plus 35 is 85 plus 25 is a hundred and ten plus ten is a hundred and twenty but we said it didn't have to be 100 we can still use that total as our denominator in this ratio in this fraction we can say that the bandwidth for queue number one it's a relative weight it's going to be the value of 10 divided by everything else total up 10 divided by what do we say the total was I think it was 120 and if we take that number and multiply it times the interface speed that's going to give us the bandwidth available to queue number one which is gonna turn out to be 83.3 megabits per second for queue number two it's 25 divided by 10 plus 25 plus 35 plus 50 in other words 25 divided by 120 times 1000 at megabits per second that's going to give to number to a band width of 200 and 8.3 megabits per second and you see I've done the same at calculations for Q's number 3 and 4 and if you add up all those bane widths that we have calculated on screen they should add up to the interface beam width of 1000 2 megabits per second and they do that's a good check to make sure that we did our calculation correctly that was shared mode but now let's take a look at shaped mode this is a bit more confusing now we're not dealing with the relative weight we're dealing with an inverse weight and I didn't say inverse relative weight it's just an inverse weight in other words the value given to queue number 1 has nothing to do with the value given to queue number 2 and that has nothing to do with the value given to key number 3 and so on let me show you what I mean we say that the inverse weight is 1 divided by whatever value we give I've given a value of 50 for key number 1 what would its inverse weight be well what is 1 divided by 50 its point 0 2 if I multiplied point 0 2 by an interface speed of 1000 megabits per second a gig in other words that would be 20 megabits per second so again you take that value and you calculate the inverse in other words 1 divided by that number 1 divided by 50 point 0 2 times 1,000 mag gives us 20 Meg we're saying that queue number one can have guaranteed 20 megabits per second but no more remember shaped mode sets a speed limit we're saying you cannot go over this amount we're doing the same thing for queue number 2 1 divided by 50 in other words 2 percent of the interface speed is going to be available to key number 2 but no more and we're simply not applying any shaping at all to queues number 3 or 4 and notice the tip I'm giving you on screen I'm pointing out that if we configure an interface for both shaping and sharing and we've got numbers set up for queue number 1 for both shaping and sharing which one wins out well it's the shaping configuration that's applied and the sharing number whatever it is it's gonna be ignored this is one of the more challenging concepts in our Cisco Catalyst quality-of-service I want to walk you through some examples you've already seen one example of share round-robin now let's take a look at shape to round robin here for an interface speed of 1,000 megabits per second we're saying srr - cubane with shape 30000 in other words we're not doing shaping for cues 2 3 or 4 but how much bandwidth are we given to queue number one it's the inverse it's 1 divided by that number it's 1/30 times 1,000 that's gonna give us 30 3.3 megabits per second of bandwidth and guaranteed to be available if it needs it guaranteed to queue number 1 but no more because we're saying shaping we're putting a speed limit on that bandwidth and we said we had the option of combining the two this is an interesting example here again for a gigabit interface speed we're giving both a sharing and a shaping at configuration let's make some sense out of this we're saying that the sharing config is 100 100 40 20 and the shaping config is 50 50 0 0 remember what we said would happen if we had conflicting instructions we have a relative weight of 100 assigned to queue number 1 for sharing and we have an inverse weight of 50 assigned to queue number 1 for shaping what do we believe what do we do we go with the shaping number we completely ignore that 100 that number could be 50 it could be 200 it doesn't matter it's ignored completely we're gonna pay attention only to the shaping value of 50 and it's an inverse weight notice the calculation on-screen when we're calculating the bandwidth guaranteed and it's also the bandwidth limit for Q number 1 its 1 divided by 50 times the interface speed 1/50 times 1,000 that's gonna be 20 megabits per second guaranteed if it needs that much it's guaranteed to have 20 megabits per second but no more for queue number 1 it's the exact same calculation for key number 2 you'll notice and then for queue number 3 and 4 there are no shaping values so we get to use the shared values but here's where it can be a bit tricky we've got the use of 40 and 20 remember it's a relative weight it's 40 divided by we said everything else total up well is it 40 divided by 100 plus 100 plus 40 plus 20 no we completely ignore those 100's they were overridden by our shaping configuration since they are completely ignored they're not even used in this calculation when we're determining the relative weight for queue number 3 and 4 the denominator is only gonna be 40 plus 20 we don't pay any attention to the two one-hundredths because like I said those were overridden so the calculation for queue number 3 is going to be 40 divided by 60 40 plus 20 and we don't take that amount and multiply it times the interface speed because there have already been some reservations deducted from the interface speed remember queue number one guaranteed 20 megabits per second queue number 2 guaranteed at 20 megabits per second we cannot include that in this calculation so we have to take 40 divided by 40 plus 20 and we multiply that knot times 1000 we multiply it by what's left of that 1000 after we deduct the 20 Meg for q1 and the 20 Meg for q2 so it's really gonna be 40 divided by 40 plus 20 times 960 if you do that math on the calculator but that's gonna give you 640 megabits per second similarly for Q number 4 it's gonna be 20 divided by it's a relative weight 20 divided by all these sharing weights which in our case are only 40 and 20 so 20 divided by 40 plus 20 times the interface speed less the bane with reservations made by the shape option so it's not 1,000 we're multiplying by its 1,000 minus 20 minus 20 960 if you do that math that's going to give you a bandwidth for queue number 4 of 320 megabits per second again we can do our sanity check to make sure we calculated this correctly let's add up the vein with guarantees and limits for Q's number one and two twenty plus twenty let's add on to that Devane with guarantee for key number three and let's add on to that the bandwidth guarantee for queue number four 320 that great news that totals up to 1000 megabits per second one gigabit per second and in these examples we've been assuming that the interface speed of 1000 megabits per second that's the value we've been using we've been assuming that were allowed to use all 1000 megabits per second all one gigabit per second for our output bandwidth it doesn't have to be that way by default there's not a limit but we could set a beam width limit not for a queue but for a port for an interface we can go into interface configuration mode and we can say srr - cubane with limit and specify a weight here are specifying a weight of 85 that's going to limit us to 85% of the interface speed so if we had issued this command when we were doing our shaping and our sharing calculations we would not have been multiplying times 1,000 or whatever the number was we would be multiplying times 850 instead of 1,000 let's take a look at how we can do some verification and troubleshooting on our Cisco Catalyst switches and a big word of caution this is something I ran into on the catalyst at 3750 and I assume it's the same for the 35 60 the command that I was used to giving on my routers to get packet and byte counts that were matching a class map and we're having a policy applied I used to give the command and I still do on routers show policy - map interface followed by the interface identifier and it would show me how traffic was being classified what the policy was and the number of packets and bytes that were being matched by a client's map and having the policy applied you don't get packet in by accounts that they show up as zeros if you give this command on your catalyst switch something to be aware of and not to be freaked out by just be aware that that's the way it works there are some commands that we can give though we could say show MLS QoS this is going to tell us that QoS is indeed enabled we could take a look at the ports trust configuration by saying show ml sqs interface and giving the interface ID this is going to tell us what are we trusting are we trusting anything what is the ports so service value are we using dscp mutation and so on and so on like you see on screen another command we could give show MLS Q s interface followed by the interface ID followed by the keyword of police ORS and this can tell us if we're doing any police in what the rate limit is on a port we also talked about the benefit of having a queue set for our output queues we could have a different set of values for our buffers for our thresholds for our reserved amount for our maximum amount we could see those values for those two queue sets with this command show MLS Q s Q - set let's now take what we've learned and tackle a couple of sample lab tasks let's challenge ourselves in our first task we're being told that on switch SW one interface gigabit one size 0 / 10 we need to limit the incoming RTP traffic that's already telling me policing let's limit that to 128 kilobits per second traffic that exceeds that should be remarked to a per hop behavior of CS 1 class selector 1 and we're going to assume that our TP traffic originated from a Cisco IP phone that piece of information right there tells us something that tells us that RTP traffic is going to be marked it's going to be marked with a class of service of a 5 it's going to be marked with a dscp value of a 46 so how do you think that we might want to tackle this let's go out to our live interface right now and I'm going to suggest that we use that policed dscp mapping that we had we can set up a rule like this let me show you let's go into global configuration mode and let's say MLS QoS map policed - dscp let's say if we originally had a value of a 46 we want a police that we want to remark that - an 8 only in the event that we're exceeding at this rate limit that we specify now let's create an access list that's gonna recognize the RTP traffic access list 100 permit UDP any-any and this is going to be in a port range of 16 384 through 32 767 let's go through the three steps of mqc let's say class - map RTP and we're going to match that XS list by saying match access - we don't say access list we say access group to match it and it had a number of 100 step2 of mqc we create a policy map and let's call it task one and we go into policy map class configuration mode and let's set up our policing rule now let's say police and we want to set a rate limit according to our task of 128 thousand bits per second we can specify a burst value the minimum value we can specify as 8,000 that's fine that's not going to impact the rate that just impacts how bursty our traffic is going to be how long are we going to have a sustained burst at line rate and to make things a bit smoother I like to use the minimum value after we specify that we can say what is the exceed action what do we do in the event that our TP traffic is exceeding at this limit we can say we're going to drop it or we could say let's apply this globally defined policed DCP map let's say police dscp transmit let's mark the traffic down and let's send it on its way step 3 of mqc is we need to apply this to an interface let's go an interface I think it was gigabit 1/2 0/10 and let's say service - policy and we're gonna do this as we're coming into the switch service policy input and we give the policy map name of task 1 and we're done with task number 1 let's check out task number 2 here we're being told that on switch SW 1 on gigabit 1/2 0 / 11 which is operating at a rate of 1 gigabit per second we need to perform the following tasks we want to enable the outbound priority queue remember what queue that is it's only queue number one SKU number two inbound it's SKU number one outbound we need to put cos for traffic into queue number three at threshold one in other words we're gonna put it into cue number three but after we exceed that first threshold in queue number three we're gonna start discarding cos for traffic and we also want to limit the bane with the traffic leaving at queue number two let's limit that to 40 megabits per second so we've got a few different things to do here let's think about what we have to do number one we need to enable the priority queue for that interface we saw the command to do that earlier we also want to set up a cos mapping we want to put a COS value of a 4 into Q number 3 at threshold number 1 and finally we want to use shaped round robin to limit Q number 2 to 40 megabits per second so we might have to do a bit of math to make that work out but let's get started let's begin by going into interface gigabit 1/2 0 / 11 and let's say priority - Q out that's the first thing we had to do we had to make a priority Q out of Q number 1 we've done that now now let's set up that cos mapping that we talked about the command for that was MLS QoS s RR - Q output and we're going to be placing traffic not based on the DSC p value but based on a COS value so we say cos - map and we're gonna say this is a configuration for Q number 3 and for a threshold number 1 we're going to be placing in a COS value of 4 cos 4 goes into key number 3 but only until the point where we hit threshold 1 and the final thing we had to configure we wanted to limit the bandwidth on key number 2 to 40 megabits per second given the fact that our interface speed was a gigabit per second remember when we're setting up shaped round robin we're going to specify a percentage of the port speed remember it goes like this we're going to go into interface gigabit 1 / 2 0 / 11 and we say s RR - Q bandwidth shape and I'm not limiting anything for Q's number 1 through your force all put in a 0 for those values but for Q number 2 I need to put in a percentage so the question is what percentage of 1,000 Meg is 40 Meg we've got to do a bit of math let's take a look at the algebraic equation we're gonna have to solve we're gonna have to say that 1 divided by X remember it's a relative weight it's 1 divided by some number that we're gonna give here one divided by some number multiplied by the interface speed of 1000 megabits per second is gonna equal 40 megabits per second how do we solve that well we can start by multiplying both sides by an X that's gonna give us 1000 equals 40 X and then to find X we're gonna say that x equals 1,000 divided by 40 let's bring up our calculator and say 1000 divided by 40 that's a value of 25 x equals 25 that's the weight that we need to specify let's say that the inverse wait for Q number two is 25 and we're not doing shaping for Q's 3 or 4 we'll just put in zeros for those values and that's going to complete task number two did you understand how we did this command we're saying we're going to shape Q number two to 40 megabits per second how do we know it's 40 megabits per second it's 1 divided by 25 times the interface speed in fact let me bring the calculator up again and prove this is correct if we say 1 divided by 25 we get point 0 4 and we multiply that times the interface speed of 1,000 Meg 1,000 that's going to give us 40 megabits per second that was our task well guys hopefully you enjoyed that so much challenging lab tasks and as we wrap up this discussion of quality of service on our Cisco Catalyst 35 60 and 3750 switches I want to make sure that this is not the last time we come in contact if you want to keep in touch with me that would be fantastic I've got tons of free certification resources available at my website one exam a month com explore that you're gonna find dozens and dozens of free training videos also if you're into Facebook you can like my fanpage you can like Kevin Wallace networking on Facebook you can follow K Wallace CCA on Twitter or you can subscribe to K Wallace CCIE that's my youtube channel and I just want to say thank you so much for entrusting me with about two hours of your time I hope that I've been a good steward of that time and I certainly wish you the best in your real-world deployments as well as your certification pursuits take good care everyone hope to see you soon [Music]

Channel: Kevin Wallace Training, LLC

Views: 138,145

Rating: 4.9311829 out of 5

Keywords: Catalyst 3750, Catalyst 3560, Cat 3750, Cat 3560, Catalyst 3750 QoS, Catalyst 3560 QoS, Cat 3750 QoS, Cat 3560QoS, Catalyst QoS, Cat QoS, CCIE, CCIE Voice, Voice CCIE, CCIE Lab, Cisco, CCIE Voice Lab, Voice CCIE Lab, Kevin Wallace, CCNP Voice, VoIP, Cisco Systems (Organization), CAPPS, CVOICE, CIPT, QOS, TVOICE, ICOMM, CCNA Voice, #kwtrain

Id: 6UJZBeK_JCs

Length: 105min 33sec (6333 seconds)

Published: Fri Sep 07 2012