Cisco QoS – LLQ / CBWFQ and MQC Processing

In the past couple of blogs, we investigated the MQC, CB-WFQ, and LLQ. Since you’re familiar with the MQC policy-maps now, let’s discuss some details of the system. Similar to an access control list (ACL), a policy-map is processed by the router in a top down fashion. Each class is evaluated in the order they were put into the policy-map and the last class in the policy-map is always the class-default. The class-default is in every policy-map by default and it cannot be removed. The class-default has a classification policy that matches all traffic that has not been identified by any other class in the policy. In the following 11 class policy-map, all known important enterprise traffic is identified in the classes above the class-default. The class-default represents the best effort (BE) traffic that has not been identified in the policy. The class-default has been given a bandwidth guarantee of 20 percent to ensure unidentified traffic is allocated bandwidth during periods of congestion. The MQC will only allow 75% of the interface bandwidth to be allocated by default. Cisco programmed this mechanism to ensure customers allocate some bandwidth to unidentified traffic in their policy. If 25% of the interface bandwidth is not allocated, any class can spike into that bandwidth during periods of congestion (except the PQ which is implicitly policed). To ensure a more strict policy, bandwidth can be explicitly allocated to the class-default, but this involves changing the maximum reservable bandwidth at the interface level as shown in the following policy. Policy-map 11-class Class voice Priority percent 10 Class interactive-video Priority percent 20 Class streaming video Bandwidth percent 10 Class bulk-data Bandwidth percent 10 Class mission-critical Bandwidth percent 10 Class transactional Bandwidth percent 15 Class signaling Bandwidth percent 1 Class network-management Bandwidth percent 1 Class routing Bandwidth percent 2 Class scavenger Bandwidth percent 1 Class class-default Bandwidth percent 20 ! Interface serial 0/0/0 Max-reserved-bandwidth 100 Service-policy output 11-class Each individual class in the policy-map represents an independent FIFO (first in, first out) queue. In previous blogs, I mentioned the disadvantages of having one large FIFO queue and that’s what we have at the interface level before configuring an LLQ policy. The LLQ policy example above represents 11 independent FIFO queues. LLQ is the scheduling mechanism that services each queue to ensure each class (queue) receives the treatment intended for our policy. Let’s relate back to a previous analogy of going to the bank or airport where there is one large FIFO line. Regardless of the customer importance level, this model has no service differentiation. Now imagine that you show up to the bank and there are 11 independent lines and the lines are differentiated by customer level. While I have never seen this paradigm at a bank, I encounter it frequently at the airport. Airport lines are normally broken down into a 3-class model: • First class (PQ) • Business class (high bandwidth guarantee) • Coach (class-default) The first class line never has a lot of people on it and the ticket agent seems to be much nicer on this line. The business class line is definitely shorter than the coach line and as soon as a ticket agent is available, they service the next guest in the business class line instead of the coach line. If there are not any customers waiting on either the first class or business class line, the ticketing agents servicing those customers de-queue a person from the coach line (fairness). The airport line servicing paradigm of large airlines like American Airlines is very similar to QoS. The class-default is a little different than every other class in the respect that the administrator can turn on fair queuing in the class-default as shown in the configuration example below: Class class-default Fair-queue While this is the same command as the WFQ mechanism that can be configured at the interface level, the operation is different. The fair queuing mechanism implemented in the MQC does not weight the traffic in any way. Weighting is a terminology Cisco uses to indicate the fact that the router is looking at the prioritization of the packet (IP Precedence or DSCP). Recall from our WFQ conversation, that this mechanism is only IP Precedence aware. The algorithm used to calculate the weighting could be very processor intensive, thus limiting the scalability of the mechanism. Cisco changed the operation when they implemented this mechanism in the MQC to ensure the scalability of the mechanism. In the next blog, we’ll start talking about mechanisms to limit the maximum bandwidth a class can use (policing and shaping). REFERENCES Cisco QoS www.cisco.com/go/qos