Solved: Fair-Queue

padenc2001 · ‎02-19-2008

Hi i am trying to figure out some of the options we have setup on the serial port of a 2600 router we have. The serial is used by a t1 controller card heres the config:

interface Serial1/0:0

ip address 192.168.0.1 255.255.255.240

no ip directed-broadcast

encapsulation ppp

no ip route-cache

no fair-queue

Can someone tell me what the fair-queue would be used for? Is it used in this case to give all packets the same priority?

Richard Burts · ‎02-19-2008

Paden

fair-queue was a queuing mechanism which would analyze traffic through an interface, identify conversations within that traffic, characterize the conversations as to their bandwidth requirements, and would allow conversations with lower requirements (perhaps like a user telnet session) to access the interface more quickly and would make conversations with higher requirements (perhaps like an FTP file transfer) to wait more for the interface access.

In general fair-queue is more effective on lower speed interfaces and less effective on higher speed interfaces. I have also seen instances (for example auto-install running over a serial interface with Frame Relay encapsulation where the autoinstall would disable fair-queue on the interface).

Since fair queue is disabled on this interface then all packets would be treated in first in first out order.

HTH

Rick

HTH

Rick

View solution in original post

Joseph W. Doherty · ‎02-19-2008

When there are packets waiting to be transmitted, fair queue places each traffic flow into its own queue and chooses between them when another packet is to be transmitted. The effect is each flow obtains the same minimal amount of bandwidth, but if some flows desire more, and if it's available, they obtain it. Fair-queue also often supports weights, so that the minimal amount of bandwidth provided can differ.

Without fair-queue, or other queuing options, the interface implements FIFO, which is one queue for all traffic. Less resource demanding traffic is often delayed by more resource demanding traffic. (FIFO analogy: you want to just buy eggs and bread, but the person ahead of you is buying a week's worth of groceries for a large family.)

Richard Burts · ‎02-19-2008

Paden

fair-queue was a queuing mechanism which would analyze traffic through an interface, identify conversations within that traffic, characterize the conversations as to their bandwidth requirements, and would allow conversations with lower requirements (perhaps like a user telnet session) to access the interface more quickly and would make conversations with higher requirements (perhaps like an FTP file transfer) to wait more for the interface access.

In general fair-queue is more effective on lower speed interfaces and less effective on higher speed interfaces. I have also seen instances (for example auto-install running over a serial interface with Frame Relay encapsulation where the autoinstall would disable fair-queue on the interface).

Since fair queue is disabled on this interface then all packets would be treated in first in first out order.

HTH

Rick

HTH

Rick

padenc2001 · ‎02-19-2008

Thanks Rick that straightens everything out!

Richard Burts · ‎02-19-2008

Paden

I am glad that my answer helped you to understand this better. Thank you for using the rating system to indicate that your question was resolved (and thanks for the rating). It makes the forum more useful when people can read a question and can know that they will read something that successfully resolved the question.

The forum is an excellent place to learn about Cisco networking. I encourage you to continue your participation in the forum.

HTH

Rick

HTH

Rick

Joseph W. Doherty · ‎02-19-2008

I like to comment on Rick's comments about fair-queue effectiveness on different speed interfaces. Rick is correct, fair-queue often doesn't appear as effective on faster interfaces. There are a couple of reasons.

First, faster interfaces, especially LAN interfaces, might not congest as often seen with most WAN interfaces. If there's little actual congestion, i.e. no significant queuing, fancy queuing buys you little or nothing.

Second, on congested interfaces, it isn't the speed of the interface, per se, but the number of concurrent flows that seems to reduce the effectiveness of fair-queue. (Usually more flows on a faster interface.) The variable size of packets also skews its performance.

For example, using fair-queue, I've seen one telnet session perform great on a T1 with several concurrent bulk transfers (host backups), link 100%. But on the same T1, using fair-queue, again with a single telnet session and now with 200 bulk transfers, telnet didn't work well. (The fix for the latter was CBWFQ, with the backups in their own class.)

PS:

Also note, ordinary fair-queue doesn't scale well, i.e. it's very resource intensive (the reason it appears to only be on by default for E1/T1 or less).

CBWFQ fair-queue does seem to scale well, at least from my experience to FastEthernet or OC3 speeds.