Yes, I've tried fair-queuing on the interface. I'm not entirely sure how its working (I havent had many complaints, but sometimes it goes weeks without any)..

Can someone give a general overview of what fair-queuing does?

Really my ultimate goal would be to prioritize web traffic, and exchange traffic across the link. There isn't much delay sensitive traffic traveling over the link, no voice / video, so I think we should be ok there.

Again, thanks for any replys.

Fair-queue ( or WFQ), is a sort of queueing mechanism, where all streams are divided based on their:

Source and destination addresses, source and destination ports, and precedence number.

Every queue get an EQUAL part of the bandwidth, hence FAIR queueing.

E.g. If you have two flows on a 1 Mbps link, one for one web, and another for another web, each flow will essentially get 0,5 Mbps of bandwidth. If you have one 7 flows for email, and 3 flows for web, every single flow will get 0.1 Mbps of bandwidth

For detailed explanations see:

http://www.cisco.com/en/US/docs/ios/12_0/qos/configuration/guide/qcconman.html#wp7921

Hi Paolo,

I just have a question, can't he just use something like rate-limit to prioritize traffic from the Exchange server by referring to the Exchange server IP or any CBWFQ/LLQ to tag traffic from the Exchange server with a higher DSCP value than the web traffic then apply service-policy output on the T1 link? Thanks.

-John

It's not that easy. One of the base rules of QoS is that you should apply it End-to-End. Marking is recommended as close to the source as possible. Correctly he would have to create a huge project and QoS his whole network.

So he would heve either to classify and mark as close to the source as possible, or he would have to create input policy maps on routers to classify traffic based on ACL or NBAR, and then assigning it DSCP/IPP value.

So for quick-fix that is required in his example, it is actually easier just to prioritize traffic right away, without using marking and then relying on WFQ to do it's job.

With CBFWQ he will have much more control, since he can limit amount of traffic with "shape average" command, or define minimum bandwidth for the class using "bandwidth" command.

So the straight forward choices are two. Either rely on WFQ, or define simple CBWFQ as provided in my example.

You can use IP precedence to favor some flows within WFQ over others. For instance, try a IP precedence setting of 2 (or 4) for Exchange and 1 (or 2) for web traffic.

If supported, the command "show queue 'interface'" will show any queued flows.

Hi Pavlo,

What if there's a single hop from source to destination. For example, a single point-to-point link separates the source and destination? Then marking packets with DSCP or IP Precedence value will be feasible right? Thanks.

-John

For CBWFQ/LLQ/custom congestion management:

Again, it's all about what suits your needs best. Of course you can mark packets with DSCP or any other mark. But if you need to use them on one hop, it makes more sense just to classify traffic.

For example, we have a network of over 900 Cisco boxes, and we have QoS set up on every single one of them, be it in DC, LAN, MAN or WAN. There if I mark a packet with DSCP, or COS, or IPP, or whatever, I know that wherever the packet goes, it will be easily recognized.

The point of DSCP is that it easily displays where the packet belongs, so you no longer have to analyze the packet, and just do something with it.

But when there is only one hop, as you stated, it doesn't matter much if the packet is marked or unmarked. But i guess it's never bad to have traffic marked, preferably when have all your applications mapped out into classes. At this point configuration will just take additional time without gain, but there could be gain in the future if you plan to expand your policy to other routers.

Also, routers trust markings, but switches do not, they erase markings right away, and require you to set up QoS trust boundaries.

For WFQ:

If you mark your packets with correct values WFQ will recognize the value and prioritize the packets accordingly.

But then again, for granular control I would definitely recommend going with CBWFQ.

Understood, when setting up CBWFQ, do you only have to enable "fair-queue", on each of the links?

I've seen that I can do a "show queue / queueing" on my serial interfaces & if traffic is being passed, it will give fairly detailed info on whats happening.

How do you get into the "granular control" with CBWFQ..

Thanks again for all the help -

CBWFQ is enabled using the commands from my previous post: Jul 25, 2007, 9:29am PST. That was the exact configuration for your scenario to enable CBWFQ.

You need to apply this configuration on both sides of the T1 link