Policy map not working.

[Phobos1821]

I'm trying to impliment a policy map on our router to prevent users from excessive FTP &

http://WWW downloading.

This is taking up a great deal of our bandwith. Whenever I impliment the policy map, I go to the internet and try to download an FTP file, and I get it at about 150kb/s. I want to limit the download to 40kb/s. Here is the sample configuration.

class-map match-all ftp_limit
match access-group 113
!
!
policy-map internet_out
class ftp_limit
bandwidth 40
police 40000 1000 1000 conform-action transmit exceed-action drop
!
interface FastEthernet0/0
description connected to EthernetLAN
bandwidth 102400
ip address xxx
ip access-group 110 in
no ip proxy-arp
service-policy output internet_out
ip route-cache flow
no ip mroute-cache
speed 100
full-duplex
no cdp enable
!
access-list 113 permit tcp any any eq ftp

I've searched the internet, and cannot find anything which would prevent this from working. Any ideas?

Thanks,

 

[pmesjar]

The problem is that you are policy-ing only port 21, which is for establishing sessions with FTP servers. Actual data transfers take part on different tcp ports. Since this can be hard to determine if using passive-mode ftp transfers, maybe the better solution is to policy according to input interface using "match input-interface f0/0" - but then this will apply to all traffic incoming to FastEthernet 0/0.

Have you considered rate-limiting using GTS (general treffic shaping) or CAR (comminted access rate)?

It was couple weeks ago I was setting up this at my office, sorry can't remeber exactly how I done this so I'll try your scenario tomorrow in our lab and see what I can get

Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[pmesjar]

By thinking more about your problem, I think you will not be able to do what you need unless you have an access to a router on the other side of your connection.

The problem is that your clients are downloading large files and your are not the source for file transfer but destination. Your clients will establish connection on port 21 and ask for data. This will be done in direction from your clients to the FTP server. Data transfer is established from the server to the client and by the time you want to policy large ftp packets, they have already traversed the entire link. You have to policy large file transfers before they enter your link (closer to the source) and not by the time they already get into your router.

Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[mntlfngrs]

try adding another line to the access list - "access-list 113 permit tcp any any eq ftp-data established"
So your access-list is:
access-list 113 permit tcp any any eq ftp
access-list 113 permit tcp any any eq ftp-data established

you could also limit the high ports (1024+) used for data with something like:

access-list 113 permit tcp any any range 1024 1050 established


think this will get you where you want to be.

"Be all and you'll be to end all.
Life can be a real ball.
State of mind!"

 

[pmesjar]

Just to correct you on syntax of police command:

those 40000 is in bps and 40kB/sec is 8*40000bps

but this will still not help you. I tried your problem here at our lab, but could not get it working unless I was configuring traffic policing on the other side - the side of ftp server. Even when I used the minimum values Cisco commands allowed, I was still able to get about 90KB/sec download speed on lab T1 circuit.

Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[Phobos1821]

I've tried these three access-lists

access-list 113 permit tcp any any eq ftp
access-list 113 permit tcp any any eq ftp-data established
access-list 113 permit tcp any any range 1024 65535 established

Does not limit the bandwidth.

How would you limit downloads via policy maps then? I dont want to limit 40Kb/s to an interface by shaping. Is the answer possibly throwing my "users" on a different VLAN. Creating a subinterface on the router for that VLAN and then using a shape command to hard cap the bandwidth at 40kb/s for everybody on that VLAN?

Thanks for the input thus far.

 

[pmesjar]

If you use separate VLAN that might get download speed to 40kbps but only on that VLAN segment and AFTER the large ftp packets have already traversed your slower Internet link. Didn't you say you want to save bandwidth on your slower serial connection to Internet?

One more thing (just came to my mind as I am writing this) - have you tried applying this policy on both incomming and outgoing interfaces? Like

int s0/0
description Connection to Internet
service-policy input internet_out
int f0/0
service-policy output internet_out

Try it and see what results you can get. I'm just sensing something about TCP sliding windows that may help... If still you have no luck, I think it is time to talk to your provider if it can police the traffic for you.

Peter Mesjar
CCNA, A+ certified
pmesjar@centrum.sk

 

[stevedeb]

PHOBOS1821,

Did you ever get your situation worked out. I am looking for advice as I am about to try somehting similar. I would like to control downloads using policing with packet drop on exceed like you. I disagree a bit with PMESJAR that rate limiting needs to be applied on sending side. If you drop packets from a TCP flow using policing then the sending server will not get ACK and will slow flow until it is properly recieving ACK (the whole TCP window thing I think). Sending server properly receiving ACK should happen at a rate within the conform of the policing where no packets are being dropped.

I would like to know how you made out so that I can try it too.

 

[pmesjar]

The point is he tried to save bandwidth on his link and if you try to police on ingress side, you won't save much... Another point is that packets to start TCP session are pretty small to make them fit into any reasonable policy map - parameters in Cisco commands will not allow you to conform less than 1500-2000 bytes...

Peter Mesjar
CCNP, A+ certified
pmesjar@centrum.sk

"The only true wisdom is in knowing you know nothing.

 

[stevedeb]

I see you point. What about not just the start packets but the actual info packets? They seem to transmit at max ehternet size. As I am trying it I am not as much conerend about saving total bandwidth as I am about slowing down TCP streams when things get tight. So when other apps like video or voice need it, they can have a piece. I was hoping to slow down downloads just anough so that a video conference will not get ckoked out. Any suggestions? I know a pacet shaper will do the trick but they are really expensive. I, on the other hand, am cheap.

 

[pmesjar]

But actual info packets - those ugly huge ftp data - they are sent to you from the other side....

If you are not concerned with bandwidth saving but need to reserve bandwidth for videoconferencing or VoIP in case "things get tight", you should implement QoS congestion management and avoidance techniques. For VoIP I would look into priority queuing or LLQ, for videoconferencing CBWFQ (Class-based Weighted Fair Queuing) can do the trick. If every data flow needs at least some percentage of bandwith at any given time, look into custom queuing.

Problem with QoS is there are many solutions, but only one can be applied to the interface - be sure it is the correct one.

Peter Mesjar
CCNP, A+ certified
pmesjar@centrum.sk

"The only true wisdom is in knowing you know nothing.

 

[stevedeb]

What I was hoping is that through policing and dropping on inbound I could drop packets from streams that do not conform,thereby convincing the sending server to slow down. If all packets aren't received, the receiver will not send an ACK on them to the sender, the sender will then resend the unacked packets. Enough resends and the sender will eventually adjust it's transmission rate.

Is there aflaw in my thinking?

What's LLQ. I'm not using a Cisco and I am not sure that I have that.

 

[pmesjar]

Your thinking is right, you can try configuring that for your setup, however as I said, the point was to save bandwidth, which you cannot if you police on your incoming side of connection.

I also tried working out the exact same problem using "policing" at my lab and could not get any satisfactory results.

LLQ - Low Latency Queuing. It is basically CBWFQ with one priority queue. This priority queue is for highest priority traffic, that has to be delivered no matter what. Other streams will be balanced based on various factors, like IP precedence/DSCP values, source/dest addresses, your configuration, etc., to see which flow will get more bandwidth.

Peter Mesjar
CCNP, A+ certified
pmesjar@centrum.sk

"The only true wisdom is in knowing you know nothing.

 

[stevedeb]

You are right, bandwidth will not be saved because retransmits will be needed. I was thinking more of my situation than the other person who started this link. In my situation I don't care about total bw as long as I can choke what's currently running to make room for more.

Thanks for your help, I appreciate all of your input.