(queue). The side effect is that flows with small packets (usually interactive flows) get much better service because they do not need a lot of bandwidth. They need low-delay handling, however, which they get because small packets have a low finish time.
Content 4.4 Configuring WFQ 4.4.5 Benefits and Drawbacks of WFQ The WFQ mechanism provides simple configuration (no manual classification is necessary) and guarantees throughput to all flows. It drops packets of the most aggressive flows. Because WFQ is a standard queuing mechanism, most platforms and most Cisco IOS versions support WFQ. As good as WFQ is, it does have its drawbacks: Figure summarizes these points.
Content 4.4 Configuring WFQ 4.4.6 Configuring WFQ Cisco routers automatically enable WFQ on all interfaces that have a default bandwidth of less than 2.048 Mbps. The fair-queue command enables WFQ on interfaces where it is not enabled by default or was previously disabled. Figure shows the command syntax. fair-queue [congestive-discard-threshold [dynamic-queues [reservable-queues]]] fair-queue Parameters
Parameter Description congestive-discard-threshold (Optional) Number of messages allowed in the WFQ system. The default is 64 messages, and a new threshold must be a power of 2 in the range from 16 to 4096. When a conversation reaches this threshold, new message packets are discarded. dynamic-queues (Optional) Number of dynamic queues used for best-effort conversations. Values are 16, 32, 64, 128, 256, 512, 1024, 2048, and 4096. reservable-queues (Optional) Number of reservable queues used for reserved conversations in the range 0 to 1000. The default is 0. Reservable queues are used for interfaces configured for features such as RSVP. WFQ Maximum Limit Configuration
The WFQ system will generally never reach the hold-queue limit because the CDT limit starts dropping the packets of aggressive flows in the software queue. Under special circumstances, it might be possible to fill the WFQ system. For example, a denial-of-service attack that floods the interface with a large number of packets (each different) could fill all queues at the same rate. Figure shows the command syntax for the hold-queue max-limit out command.
Content 4.4 Configuring WFQ 4.4.7 Monitoring WFQ The show interface command, as shown in Figure can be used to determine the queuing strategy. The output also displays summary statistics. The sample output in this figure shows that there are currently no packets in the WFQ system. The system allows up to 1000 packets (hold-queue limit) with a CDT of 64. WFQ is using 256 queues. The maximum number of concurrent flows (conversations, or active queues) is four. The show queue command as shown in Figure is used to display the contents of packets inside a queue for a particular interface, including flow (conversation) statistics:
Content 4.5 Configuring CBWFQ and LLQ 4.5.1 Combining Queuing Methods Neither the basic queuing methods nor the more advanced weighted fair queuing (WFQ) methods completely solve the quality of service (QoS) problems resulting from converged network traffic. The following problems remain: Newer queuing mechanisms combine the best aspects of existing queuing methods. Low latency queuing (LLQ) is a combination of class-based weighted fair queuing (CBWFQ), which assigns weights according to bandwidth, and a priority system based on class that gives voice the priority it requires while ensuring that data is serviced efficiently. This solves the potential starvation problem of the priority queue by including a policing function based on the configured bandwidth of the priority system. Figure illustrates the concept.
Content 4.5 Configuring CBWFQ and LLQ 4.5.2 Class-Based Weighted Fair Queuing Figure summarizes the characteristics CBWFQ. CBWFQ extends the standard WFQ functionality to provide support for user-defined traffic classes. With CBWFQ, the user defines the traffic classes based on match criteria, including protocols, ACLs, and input interfaces. Packets satisfying the match criteria for a class constitute the traffic for that class. A queue is reserved for each class, and traffic belonging to a class is directed to that class queue. After a class has been defined and its match criteria have been formulated, you can assign characteristics to the class. To characterize a class, you assign a bandwidth and a maximum packet limit to it. The bandwidth assigned to a class is the minimum bandwidth delivered to the class during congestion. To characterize a class, you also specify the queue limit for that class, which is the maximum number of packets allowed to accumulate in the class queue. The queuing guarantees the minimum bandwidth, but also gives a class unlimited access to more bandwidth if more is available. After a queue has reached its configured queue limit, enqueuing of additional packets to the class causes tail drop or random packet drop, depending on how the class policy is configured. You can configure up to 64 discrete classes in a service policy.
Content 4.5 Configuring CBWFQ and LLQ 4.5.3 CBWFQ Architecture, Classification and Scheduling CBWFQ supports multiple class maps to classify traffic into its corresponding FIFO queues as shown in Figure . CBWFQ classes use tail drop unless you explicitly configure a policy for a class to use weighted random early detection (WRED) to drop packets as a means of avoiding congestion. Note that if you use the WRED packet drop instead of tail drop for one or more classes in a policy map, you must ensure that WRED is not configured for the interface to which you attach that service policy. Serial interfaces at E1 (2.048 Mbps) and below use WFQ by default—other interfaces use FIFO by default. Enabling CBWFQ on a physical interface overrides the default interface queuing method. Be cautious when configuring CBWFQ on ATM interfaces. Enabling CBWFQ on an ATM permanent virtual circuit (PVC) does not override the default queuing method. Unspecified bit rate (UBR) connections do not support CBWFQ. Classification
You can use any classification option for CBWFQ, depending on availability in the Cisco IOS version, support on the selected interface, and encapsulation. Figure lists relevant considerations. The following examples illustrate some of the limitations regarding classification options: