I have an issue where some developers are doing large downloads of iso images during they day and killing our 2MB internet connection - I ideally would like to police this traffic on the router and limit it to 256k.
I have created this policy
police cir 250000
This matches ftp,secure-ftp
However when I tried to apply it inbound to the serial interface of the router despite the option being there I was told this could only be applied outbound. Which does not achieve my goal.
How can I limit ftp traffic coming into my internet router?
Well, you really can't. Once the traffic has hit the router, it's already there.
So what you do, is shape traffic for the certains IPs (using an ACL) on the outgoing lan interface.
I suggest shaping and not policing because it will let TCP do his job and overall is more beneficial.
The problem your dealing with is, your trying to restrict the traffic after it's already gone through your physical bottleneck. You can indeed regulate the speed the FTP images get to the developers but it's likely not to be as effective as you hope. However, the more the delta between the restriction and the physical bottleneck, the better it will work. So, there might be some benefit with your restricting FTP to 256 Kbps across a 2 Mbps link.
You could apply your policy on your LAN interface outbound, or, I believe, inbound on your WAN interface.
service policy DOWNLOAD-POLICE output
service policy DOWNLOAD-POLICE input
Although I too often prefer shapers over policiers, in this instance, a policer is better because you want packets drops to indicated to the sender to slow down its transmission rate.
I agree with joseph on everything expect that a policer is better than a shaper, even in this case.
A shaper will drop packets at some points just like the policer does, but it won't do that abruptly. Instead, will give tcp senders time to adjust rates nice and smooth, without the the drops and the retransmissions associated with policer. Result, the download will complete faster and without sending the same packets more than once.
Remember, any router that handles a link has a queue of some capacity, why shouldn't you have one for the virtual pipe you're creating ?
Paolo, I agree a shaper will also drop packets, but, indeed, abrupt is what I think is called for in this instance.
Since we're downstream of the physical bottleneck, whose bandwidth we're trying to protect after the fact, dropping sooner to get FTP(TCP) into congestion avoidance or slow start, also sooner, I think, is better. What we want to avoid is the transmitter opening its send window, bursting its flow, filling the WAN link, and then finally seeing dropped packets.
If we were upstream of the WAN link, where we could meter the traffic and were the initial bottleneck, I would then prefer a shaper over a policer. (Actually, I would prefer foreground/background queuing priorities even more.)
With regard to your comment/question about link queues and virtual pipes, again, what's different, is we're not just trying to just regulate bandwidth downstream of our artificial bottleneck, but influence the sender transmission rate to take pressure off upstream link.
I would like to join this conversation if you dont mind:;
(Policer & Shaper)Each has an advantage and disatvantage, The Policer some times affect allow TCP applications operates well, but from a SP point of view, its the best bandwidth limitation strategy.
Shaper would allow it at some extend but it will consume memory buffers & bursts, so its not a prefered method for SPs
As from a client point of view, the prefered method is Shaping.
Maybe applying shaping a long with Congestion avoidance Mechanism such as (Random Detect) would be the optimal for TCP sensitive applications.
Mind? I don't! Hope Roger doesn't either.
I had thought of RED, but I believe its feedback loop is also too slow. Again, I think in this instance, both because it drops at the end of the queue (not FIFO but as packets are added) and because of the running mean queue size delay. RED's purpose is often to drop single packets which might only trigger fast retransmit where we may really want the sender to back off its transmit rate much more.
Consider what we're trying to accomplish in this instance, we want to keep FTP from taking bandwidth away from other traffic across the WAN link yet we're doing this downstream of the WAN link. It's not, I believe, we want to restrict FTP clients to only have 256 Kbps, but by restricting their bandwidth, allow other traffic to have the bandwidth instead.
Something else to consider, I believe we can treat TCP bulk data transfer, e.g. FTP, differently, also in this case "nastier", from an "interactive" TCP app like HTTP. The latter could desire to transfer just as much data, but user performance expectations are often higher. This is another reason why a severe policer might be a better choice over a less severe shaper.
Well, I think in this case only a practical test could tell which solution is better.
My point, as I said, is that a policer will cause frequent retransmissions, ultimately causing more traffic to be carried over the protected link - thta is certainly not wanted. While shaping, using a small buffer if desired, will emulate a slow link - that is what tcp is designed to deal after all.
I'm not sure if and when I can test this, but if someone else does, I will be interested in knowing the results.
What a response!
I have applied the policer outbound on the ethernet and serial and does not seem to affect the ftp, I also have one for smtp for our mail server which works a treat limiting outbound mail to 128k
Taming inbound ftp seems to be a bit of a beast - might have to go for a third party solution which I am not keen on...
Paolo, great question about passive/active FTP. (Roger, in case you miss the point, if your policy only "sees" active FTP, you developer downloads could be bypassing your shaper/policer if they're using passive FTP. If you're using NBAR matching to FTP, it should "see" both. [There's also the issue of "seeing" secure-FTP, from your original post.])
Paolo, your comment about a practical test, is also great, since it's often the only way to truly find out the impact. Very simple to change from a policer to shaper using the same policy. One thing to keep in mind, even if you simulate this in the lab, it still might not indicate what will happen in Roger's production. One reason is what TCP stacks are your lab systems going to use vs. what Roger's clients and the Internet servers use?
With regard to your comment about whether a policer vs. a shaper will cause more total transmissions, another good point. It could go either way. The reason being, much depends whether TCP has reached steady state or whether it's still opening its send window. If the latter, a huge number of burst packets could be dropped as they all fall off the end of the queue. With the former, the more aggressive feedback loop may prevent such large bursts from being sent. Regardless, though, even if more total packets are sent because of retransmissions, as long as we meet the primary consideration of protecting other traffic, I think it's a better trade off than performing FTP most efficiently.
Your point about using a shaper with a small buffer, I agree with, because a shaper with a very small queue depth starts to behave very much like a policer. (Don't recall, can you define the buffer depth for a shaper within CBWFQ?)
Roger, yes, it's not unexpected how difficult FTP is to tame inbound (downstream) unlike the success you mention taming SMTP outbound. As noted above, insure all your FTP, secure-FTP traffic is seen by your policy. Also, because of bursting issues, you might try reducing the allowance for FTP even further.
One technique I haven't mentioned is shaping outbound FTP ACKs. It avoids many drops that are often caused by a policer or shaper because it "clocks" the transmission rate. It will not stop all bursting, and a very low ACK rate is needed in comparison to the inbound data rate. (I'm unsure whether you could go slow enough to be effective on a 2 Mbps link.)
As to 3rd party solutions, they might use the outbound ACK pacing just described, although much more precise based on actual flow rates. They also might "spoof" the receiver's receive buffer size, a great technique, but unavailable, as far as I know, on a Cisco router.
Oh, great discussion, one thing is sure, as long there is cisco and inquiring minds around, customer networks will stay packeteer-free.
what a nice discussion, I learn more knowledge here.
please allow me to give my opinion.
"bandwidth" means minimum bandwidth guarantee , ftp traffic can use more than 256K when 2M line is not congestion.
"police" means maximum bandwidth guarantee ,ftp traffic will execute preconfig action like drop or forward when ftp traffic exceeding 256K.
so, my suggestion are:
if Roger likes developers ,please using "bandwidth",
if Roger does not like those guys, please using "police",
if Roger likes them very much, please using "prioroty"(only use to voice and video)