Posts Tagged ‘QoS’
A quick look at WRR.
Weighted Round Robin our method of LAN QoS on the older switching platforms (2950’s/3550’s). Replaced by Shaped (or Shared) Round Robin on our newer platforms but WRR is still a big player out there so let’s take a quick look at it. Before we take a look at any configurations lets quickly take a look at how WRR functions from an overview perspective.
So if we start from top to bottom the first thing we notice is the fact we have 4 queues to work with. Remember these are egress/outbound queues so we are working with outgoing traffic. The switch first checks the fourth queue to see if to see if there are packets in the queue and then it transmits its configured amount of packets. Once the configured amount of packets have been transmitted for that queue it moves along to the next queue. It works this way to ensure queues do not get starved and the switch is not constantly transmitting one queue all the time. After it gets done with queue one it will then reset and start back at queue 4.
So from looking at the above flowchart you can probably guess a few things that need to get configured:
- What belongs in each queue
- How much from each should be transmitted
So in order to configure our queues we go into the interface we are looking to configure (Thank you Cisco for interface range command) and from there we configure the queues as followed:
So from the above we are configuring the following:
- Queue 1 will contain packets marked with CoS 0 & 1
- Queue 2 will contain packets marked with CoS 2 & 3
- Queue 3 will contain packets marked with CoS 4 & 5
- Queue 4 will contain packets marked with CoS 6 & 7
You don’t have to break it up so evenly you can put up 8 CoS markings in a single queue. After all QoS will be different for every network.
So now that we have our queue defined we need to define how many packets from each queue the switch will transmit before working on the next queue. This to, is also done from within interface configuration mode.
When we are configuring the individual queues they start from queue 1 to queue 4 (left to right), so in this example we configured the switch to transmit:
- 10 packets from queue 1
- 20 packets from queue 2
- 30 packets from queue 3
- 50 packets from queue 4
Now we can configure queue 4 as the priority, meaning the switch will check the priority queue and transmit all packets in the priority queue after it checks any other queues. So the switch will check queue 3, transmit the packets then check queue 4 since its got priority transmit those packets, then check queue 2 transmit those packets and then go back to queue 4. We can do that with the following command:
You just have to be careful with what traffic is placed in the priority and how many packets are sent from that priority queue to avoid starving other queues or causing unnecessary latency for other traffic.
You can verify your configuration by issuing the following command sh mls qos interface queueuing
This command will show you the QoS configuration on an interface by interface basis, I only included interface fa0/1 for this example. You see’ll that the expedite queue is enabled (queue 4) and the bandwidth per queue. Right after that we will see the CoS mapping to each of the queues.
Passed QoS and got my CCIP!
Well after 7 months of studying and 2 exams later I’ve finally obtained my CCIP! When I initially thought about going after my CCIP I said this shouldn’t be too bad after going through Routing TCP/IP Volume II, BGP Design & implementation, and half way through MPLS fundamentals (See my Library page on the left for links) I was really starting to feel it. I kept moving along and passed the 642-691 I got a little bit of hope and jumped right into QoS. The funny thing about QoS was I didn’t realize how much I really new about it, nor did realize how much more I could do with it. QoS certainly was an interesting topic to learn, and I am sure I’ll be learning even more about it as time goes on.
Now that I’m done with my CCIP, I think I am going to take a small break from studying. I am going to focus back on my blog (So hopefully I will get some more updates out) and I am going to start building my own home lab for whenever I decide to start studying for my CCIE (not sure when but I will pursue that eventually). Not a bad way to start the new year right?
Configuring LLQ – Low Latency Queuing
Well, since I covered the CBWFQ in my last post I think it’s only natural I jump into the configuration of yet another QoS configuration Low Latency Queuing or LLQ. LLQ simply builds off the CBWFQ, let’s look at the configuration from my last post concerning CBWFQ:
Now let’s configure LLQ:
See the difference? Notice the priority keyword, that is what configures LLQ. Not too complicated right? Now what does this priority command really do for us, well it creates a low latency queue for traffic that needs to be transmitted before other type of data. So if there is data in the low latency queue when does the data in the other queue’s get transmitted, easy when the low latency queue is empty or when the low latency queue exceeds its specified amount of bandwidth. The low latency queue is also policed by the bandwidth we have allocated it. If the low latency queue ever exceeds the amount of bandwidth it has been allocated it will drop the packet and move to another queue.
Below is a flow chart from the QoS Exam Guide explaining how the LLQ works:
A quick look at the MQC and CBWFQ
As I jumped into my QoS studies my first though was going to be “I’m in way over my here head this is not going to be fun”, after all QoS is a very daunting subject. However as I trek my way through the QoS Exam Guide I am finding QoS easier to swallow. A very large topic in the QoS exam guide is the MQC – Modular QoS CLI (Yes, an acronym within an acronym) this MQC is the way to configure QoS and boy is it simple to get the hang of. In fact the configuration of a Zone Based Firewall was actually based off the MQC design. That was a big relief to me, I’ve spent plenty of time around firewalls and to find out that the QoS MQC is really the heart of the zone based firewall configuration I was relieved, and even more relieved when I saw the configuration and understood it fairly quickly.
Let’s take a quick run through the configuration of Class Based Weighted Fair Queuing (CBWFQ) using the MQC.
Step 1: The Class-Map
The first step is to create the class map, the class map is used to classify the data. The data can be matched by an ACL, specific protocol information, DSCP, or IP Precedence values
Below is a list of other match statements, as you can see the list is quite extensive. You can match on everything from a specific interface to a frame-relay DLCI. Also notice the not statement, which allows you to exclude variables from the class map a nifty trick that can come in handy from time to time.
Step 2: The Policy-Map
Now, the policy map is where you add the class maps (remember the class map is case sensitive) and have the router do something you want with traffic matched for a particular class map, whether it be re-classify the packet with a different QoS marking, reserve a specific amount of bandwidth for this traffic, or something else entirely (policy maps are quite powerful. I highly recommend you lab with them to see all the cool things you can do with them). Do keep in mind, until the policy map is assigned to a service policy on an interface the router will not actually do anything. We have one more step.
Here we have a list of actions that can applied to the packets matched to the class map we can do everything from compress the header, set QoS values, drop the packets, police or shape the traffic, and much more.
Step 3: The Service-Policy
The service policy is where we apply our policy map to an interface in the input or output direction (Remember like ACLs, the inbound direction means packets coming into an interface and outbound refers to packets leaving the interface)
Now the service policy is actually pretty smart it will not allow you to assign the service policy to an interface in which some of the features are unsupported, it also will not allow you to oversubscribe the interface bandwidth
So, there is a typical QoS configuration using Cisco’s MQC setup, this QoS method is also the configuration for CBWFQ, so hey I technically showed you 2 things with one blog post! Now the biggest different between the configuration of CBWFQ and the Zone Based Firewall is the service policy is applied to an interface and not a zone pair.
Now one final look at all the configurations:
Notice there is a class-default in there, the class-default is the where every packet gets matched that does not match any other class map in the policy map, so you can easily effect all the traffic without matching every protocol or subnet, again something that can come in handy from time to time.
CCIE or Null! 