Fair-Queue 64 256 3

[rsabapathee]

What is the purpose of this command on a router interface?

Fair-Queue 64 256 3

[sachinraja]

Hello roghen

This command basically enabled weighted fair queuring on ur router interface. this is one of the types of Quality of service parameters available.. You can have a look at this URL for some details on this command:

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1835/products_command_reference_chapter09186a0080087f36.html#wp1098249

Hope this helps.. all the best. rate replies if found useful..

Raj

[bbaillie]

The link given is only accesible to those that have a Cisco "partner" account. For the rest of the CCO folks here is a link to a basic description of WFQ.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_configuration_guide_chapter09186a00800ca597.html

In short terms the 64 means the interface will queue up 64 packets deep per conversation before dropping any packets. The 256 is the number of queues or conversations that will be given "fair" access to the interface bandwidth. The 3 is the number of reservable queues supported for protocols such as RSVP.

Cheers,

Brian

[rsabapathee]

thanks for the reply.

This command has been applied to an interface whereby data and VoIP traffic leaves and enters the interface.

Currently there is no VoIP traffic going through the interface but eventually it will be enabled again.

At the time that command was enabled on the interface, the link had a limited bandwidth of 11Mbps half-duplex. Now the link has been upgraded to 54Mbps full-duplex.

Is there any need for the fair-queue command? What would be its benefit in the present case?

thx

[bbaillie]

The use of fair queuing ensures that no individual device can hog all the bandwidth and monopolize the link. In this case you are better to have fair queuing because the alternative is FIFO, I assume there are numerous devices that converse across this link. Before adding VOIP traffic maybe you should investigate a proper QOS strategy because VOIP packet drops impact voice quality and that is a bad thing. A starting point would be LLQ for the voice traffic and WFQ for the rest but only do this after investigating the current type of traffic and its profile. Some traffic will tolerate drops and delay better than others so remember QOS is giving better service to some traffic at the expense of the rest.

Cheers,

Brian