Police inbound ftp traffic on 3640

Unanswered Question
Feb 14th, 2008
User Badges:

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

policy-map DOWNLOAD-POLICE

class DOWNLOAD-FTP

bandwidth 250

police cir 250000

conform-action transmit

exceed-action drop


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?


roger

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
paolo bevilacqua Thu, 02/14/2008 - 03:49
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.

Joseph W. Doherty Thu, 02/14/2008 - 12:39
User Badges:
  • Super Bronze, 10000 points or more

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.


e.g.


fastethernet 0

service policy DOWNLOAD-POLICE output


or


serial 0

service policy DOWNLOAD-POLICE input


PS:

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.

paolo bevilacqua Thu, 02/14/2008 - 15:14
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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 ?

Joseph W. Doherty Thu, 02/14/2008 - 16:04
User Badges:
  • Super Bronze, 10000 points or more

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.


Your thoughts?


Mohamed Sobair Thu, 02/14/2008 - 16:36
User Badges:
  • Gold, 750 points or more

Hi Guys,


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.


HTH

Mohamed

Joseph W. Doherty Thu, 02/14/2008 - 17:44
User Badges:
  • Super Bronze, 10000 points or more

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.

paolo bevilacqua Fri, 02/15/2008 - 00:57
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

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.


simplecisco Fri, 02/15/2008 - 01:41
User Badges:

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...


roger

paolo bevilacqua Fri, 02/15/2008 - 02:09
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Hi, relevant config please ?

Also, are you using passive or regular ftp ?

Joseph W. Doherty Fri, 02/15/2008 - 04:58
User Badges:
  • Super Bronze, 10000 points or more

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.

paolo bevilacqua Fri, 02/15/2008 - 05:31
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Oh, great discussion, one thing is sure, as long there is cisco and inquiring minds around, customer networks will stay packeteer-free.

dongdongliu Fri, 02/15/2008 - 19:15
User Badges:

Hi,everyone

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)


good weekend

Actions

This Discussion