Hello everyone, I have a few questions that I could use some help on :)..
I currently have a T1 link that has no QoS settings at all (L3). Through this link, we pass exchange traffic to offsite clients, all domain services, www traffic, and many other things.
I would like to know exactly how to configure this link so we can prioritize the exchange update traffic, and the web traffic (2nd, behind exchange).
Again, I know this isn't always recommended, but when users are transfering files back and forth between sites, the network at our offsite location runs terrible (I'm assuming that its because theres a large file being transferred, and packets aren't prioritized correctly)..
Any help is greatly appreciated.
to begin with, try "fair-queue" on the congested interface. This will prevent aggressive flows from jeopardizing the others.
Then if you could expand on how you would like things to work we can give some config suggestion.
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:
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.
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.
For custom QoS, where you would be in control of your bandwidth, you can either use NBAR to discover traffic, or define access-lists with IP address ranges of WEB/mail servers/proxies. And then use CBWFQ for congestion management.
Simple configuration would be:
interface XX (all active interfaces where router receives traffic)
ip nbar protocol-discovery
class-map match-any MAIL
match protocol exchange
match protocol pop3
match protocol smtp
class-map match-any WEB
match protocol http
bandwidth percent 35
bandwidth percent 35
interface serial XX (T1 interface)
service-policy output T1_OUT
Or you can define access lists, and match on ACL in class-maps.
Here are some examples from Cisco:
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.
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.
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