

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
3 messages in net.nether.puck.cisco-nsp[c-nsp] Cisco 3550 QoS to limit FTP| From | Sent On | Attachments |
|---|---|---|
| ni...@precisionmillworks.com | Jan 3, 2005 6:16 pm | |
| Ted Mittelstaedt | Jan 4, 2005 12:31 am | |
| Daniel Hagerty | Jan 4, 2005 7:11 am |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread 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 FTP | Actions... |
|---|---|---|
| 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.







