Posts Tagged ‘CBWFQ’
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! 