QoS: Class-based Weighted Fair Queuing

Cisco introduced Class-Based Weighted Fair Queuing (CB-WFQ) and the modular QoS CLI (MQC) almost 8 years before the writing of this blog entry [Cisco IOS 12.1(5T)]. Check the Cisco feature navigator online for the exact version for your router hardware. Cisco switches do not use the CB-WFQ algorithm. Cisco switches use weighted round robin (WRR) and shaped round robin (SRR) for congestion management (queuing). The term congestion management is very closely aligned with different queuing technologies like CB-WFQ. The following QoS technologies are all configured with the modular QoS CLI: • Class-based weighted fair queuing • Class-based marking • Class-based policing • Class-based shaping • Class-based header compression • Class-based link fragmentation and interleaving Class-based is indicative of the class-map component in the modular QoS CLI that is used to classify traffic. Traffic must first be identified for the router to do anything interesting with it. Access control lists (ACL) and network-based application recognition (NBAR) are the two most popular classification methods leveraged in class-map configuration mode. NBAR is not supported on any switch platforms other than the Catalyst 6500 as of the time of this writing. NBAR does not run in the ASIC (application specific integrated circuit) of the switch modules. NBAR should be deployed very cautiously in the 6500 switch so the supervisor module does not become overburdened with this processing. The SUP32-PISA module supports hardware NBAR processing up to 1Gbps. The MQC allows application classes to be created by mapping application traffic to separate class-maps. Each class-map is then allocated an amount of processing time during periods of output interface congestion. The processing time is internally derived by a Cisco algorithm based on the amount of bandwidth the administrator allocated to the application class. Bandwidth can be allocated statically (8kbps increments), as a percentage of interface bandwidth, or as a percentage of remaining available bandwidth (after any static guarantees in RSVP and/or priority queue). Only one allocation mechanism can be used across all application classes of a policy or the policy will not work when the policy-map is applied to an interface. The following is an example of a simple two class-policy that allocates 10 percent of the interface bandwidth (154kbps) to FTP traffic and 20 percent of interface bandwidth 20 percent interface bandwidth (307kbps) to HTTP traffic: Class-map match-any FTP Match protocol ftp Match access-group name ftp Class-map match-any HTTP Match protocol http Match access-group name HTTP Policy-map CBWFQ Class FTP Bandwidth percent 10 Class HTTP Bandwidth percent 20 Interface Serial 0/0/0 Bandwidth 1536 service-policy output CBWFQ The names used in the class-maps are called in the policy-map CBWFQ. It is imperative that the same case be used for these names. The names used in Cisco IOS are almost always case sensitive. I can affirm that names are case sensitive in the naming of class-maps, policy-maps, named access-control lists, MPLS VPN VRFs (VPN routing and forwarding tables), and translation profiles. Since Cisco IOS is based on a Unix bash shell and Unix is case sensitive, it is safer to assume that everything in Cisco IOS is case sensitive. Notice that the bandwidth of the T-1 interface has been tuned from the default of 1.544Mbps (1544kbps) to 1536kbps. The 8kbps of framing information on a T-1 cannot be used for data transport, so we technically only have use of 1536kbps. While this may seem like the splitting of hairs, it’s concepts like this that can cost you points on a Cisco CCIE exam. In the next blog, we’ll continue this conversation to include the priority queue (PQ). CB-WFQ + PQ = LLQ (low latency queueing). More on that next time… REFERENCES Cisco Feature Navigator www.cisco.com/go/fn