3 messages in net.nether.puck.cisco-nsp[c-nsp] Cisco 3550 QoS to limit FTP
FromSent OnAttachments
ni...@precisionmillworks.comJan 3, 2005 6:16 pm 
Ted MittelstaedtJan 4, 2005 12:31 am 
Daniel HagertyJan 4, 2005 7:11 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[c-nsp] Cisco 3550 QoS to limit FTPActions...
From:Daniel Hagerty (ha@linnaean.org)
Date:Jan 4, 2005 7:11:40 am
List:net.nether.puck.cisco-nsp

ni@precisionmillworks.com writes:

I'm trying to implement QoS on a 3550, here's the situation. I've got about 400 hosts on my network. One machine is used to ftp large files(2-4gig) to clients. Currently we only transfer these files at night now, because it causes packet loss on our network. I want to be able to give all of the FTP traffic coming from this machine a low priority,

That's a very ill behaved FTP server, but anyway.

Lots of knobs in QoS. You're looking for what cisco calls congestion management, congestion avoidance, and perhaps classification. Management for when the link is full, avoidance to push back the inevitable, and classification to tune the management and avoidance behavior.

I've found the best thing for situations like yours (bulk transfers interfering with interactive services) is weighted fair queue (WFQ) w/ random early discard (RED) and some classification. Sadly, I don't have a config in front of me. Ask privately, and I can probably dig one up.

First, turn on WFQ on the congested interface if it isn't already. Second, turn on RED within the WFQ engine.

This may be enough by itself, but probably isn't. Classification offers a bunch of differernt ways to change how WFQ manages the full link; ToS, qos groups, and IP precedence values are all an option with slightly different results (I *think* precedence is the only method that preserves flow based WFQ).

The upside of a config like this is that you can use the full link bandwith the way you like, and the behavior is dynamic -- if the FTP is the only thing going, it gets the whole link. And the interactive users will *love* you -- they generally only notice a very slight latency tax during link full, rather than the huge latency you get under FIFO queue. The downside is that your configuration is more complicated and CPU intensive.

See:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt2/qcfwfq.htm

for WFQ and using RED under WFQ,

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt3/qcfwred.htm

for a little more on RED,

and

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcprt1/qcfcbmrk.htm

for packet classification.

Note that it's a good idea to clear the precedence bits at your network ingress/egress points if you have queues heeding it in the middle of your network. You usually don't want randoms controlling queueing behavior.