Fair queueing is enabled by default for physical interfaces whose bandwidth is less than or equal to 2.048 Mbps and that do not use the following:
- X.25 and Synchronous Data Link Control (SDLC) encapsulations
- Link Access Procedure, Balanced (LAPB)
- Virtual interfaces
Fair queueing is not an option for the protocols listed above. However, if you enable custom queueing or priority queueing for a qualifying link, it overrides fair queueing, effectively disabling it. Additionally, fair queueing is automatically disabled if you enable the autonomous or silicon switching engine mechanisms.
A variety of queueing mechanisms can be configured using multilink; for example, Multichassis Multilink PPP (MMP). However, if only PPP is used on a tunneled interface--for example, virtual private dialup network (VPND), PPP over Ethernet (PPPoE), or PPP over Frame Relay (PPPoFR)--no queueing can be configured on the virtual interface.
The number of dynamic queues is derived from the interface or ATM permanent virtual circuit (PVC) bandwidth. See the table in the fair-queue(class-default) command for the default number of dynamic queues that WFQ and class-based WFQ (CBWFQ) use when they are enabled on an interface. See the table in the fair-queue(class-default) command for the default number of dynamic queues used when WFQ and CBWFQ are enabled on an ATM PVC.
This command enables WFQ. With WFQ, packets are classified by flow. For example, packets with the same source IP address, destination IP address, source TCP or User Datagram Protocol (UDP) port, destination TCP or UDP port, and protocol belong to the same flow; see the table below for a full list of protocols and traffic stream discrimination fields.
When you enable WFQ on an interface, WFQ provides traffic priority management that automatically sorts among individual traffic streams without requiring that you first define access lists. Enabling WFQ requires use of this command only.
When you enable WFQ on an interface, new messages for high-bandwidth traffic streams are discarded after the configured or default congestive discard threshold has been met. However, low-bandwidth conversations, which include control message conversations, continue to enqueue data. As a result, the fair queue may occasionally contain more messages than its configured threshold number specifies.
WFQ uses a traffic data stream discrimination registry service to determine which traffic stream a message belongs to. For each forwarding protocol, the table below shows the message attributes that are used to classify traffic into data streams.
|Table 5 ||Weighted Fair Queueing Traffic Stream Discrimination Fields |
- Source net, node, socket
- Destination net, node, socket
Connectionless Network Service (CLNS)
- Source network service access point (NSAP)
- Destination NSAP
- Source address
- Destination address
Frame Relay switching
- Data-link connection identified (DLCI) value
- Type of service (ToS)
- IP protocol
- Source IP address (if message is not fragmented)
- Destination IP address (if message is not fragmented)
- Source TCP/UDP port
- Destination TCP/UDP port
- Unicast: source MAC, destination MAC
- Ethertype Service Advertising Protocol (SAP)/Subnetwork Access Protocol (SNAP) multicast: destination MAC address
- Unicast: source MAC, destination MAC
- SAP/SNAP multicast: destination MAC address
- Source/destination network/host/socket
- Level 2 protocol
All others (default)
- Control protocols (one queue per protocol)
IP Precedence, congestion in Frame Relay switching, and discard eligible (DE) flags affect the weights used for queueing.
IP Precedence, which is set by the host or by policy maps, is a number in the range from 0 to 7. Data streams of precedence number are weighted so that they are given an effective bit rate of number+1 times as fast as a data stream of precedence 0, which is normal.
FECN and BECN
In Frame Relay switching, message flags for forward explicit congestion notification (FECN), backward explicit congestion notification (BECN), and DE message flags cause the algorithm to select weights that effectively impose reduced queue priority. The reduced queue priority provides the application with "slow down" feedback and sorts traffic, giving the best service to applications within their committed information rate (CIR).
Fair Queueing, Custom Queueing, and Priority Queueing
Fair queueing is supported for all LAN and line (WAN) protocols except X.25, including LAPB and SDLC; see the notes in the section "Command Default." Because tunnels are software interfaces that are themselves routed over physical interfaces, fair queueing is not supported for tunnels. Fair queueing is on by default for interfaces with bandwidth less than or equal to 2 Mbps.
For Release 10.3 and earlier releases for the Cisco 7000 and 7500 routers with a Route Switch Processor (RSP) card, if you used the tx-queue-limit command to set the transmit limit available to an interface on a Multiport Communications Interface (MCI) or serial port communications interface (SCI) card and you configured custom queueing or priority queueing for that interface, the configured transmit limit was automatically overridden and set to 1. With Cisco IOS Release 12.0 and later releases, for WFQ, custom queueing, and priority queueing, the configured transmit limit is derived from the bandwidth value set for the interface using the bandwidth(interface)command. Bandwidth value divided by 512 rounded up yields the effective transmit limit. However, the derived value only applies in the absence of a tx-queue-limit command; that is, a configured transmit limit overrides this derivation.
When you configure Resource Reservation Protocol (RSVP) on an interface that supports fair queueing or on an interface that is configured for fair queueing with the reservable queues set to 0 (the default), the reservable queue size is automatically configured using the following method: interface bandwidth divided by 32 kbps. You can override this default by specifying a reservable queue other than 0. For more information on RSVP, refer to the chapter "Configuring RSVP" in the Cisco IOS Quality of Service Solutions Configuration Guide .
Cisco 10000 Series Routers
In Cisco IOS Release 12.2(33)SB, the router removes the no fair-queue command from serial interfaces.
Beginning with Cisco IOS Release 12.4(20)T, if your image has HQF support, thefair-queue command is not enabled automatically under class default. You should enable the fair-queue command and any other supported queueing features before using an HQF-capable image.
The following example enables WFQ on serial interface 0, with a congestive threshold of 300. This threshold means that messages are discarded from the queueing system only when 300 or more messages have been queued and the message is in a data stream that has more than one message in the queue. The transmit queue limit is set to 2, based on the 384-kilobit (Kb) line set by the bandwidth command:
interface serial 0 bandwidth 384 fair-queue 300
Unspecified parameters take the default values.
The following example requests a fair queue with a congestive discard threshold of 64 messages, 512 dynamic queues, and 18 RSVP queues:
interface serial 3/0 ip unnumbered ethernet 0/0 fair-queue 64 512 18
You can apply the fair-queue command to a user-defined class as shown in the following example:
policy-map p1 class c1 bandwidth 1000 fair-queue