limiting download bandwidth on http

Unanswered Question
Apr 24th, 2009

Hi,

how come i m not able to apply a service-policy input when i m using LLQ or WFQ, i get the message :

Flow Fair Queueing feature not supported in input policy

all i want to do is to limit http to 512 kb download and upload

Thanks guys

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
John Blakley Fri, 04/24/2009 - 07:18

If you're trying to shape the traffic from inside out, you can only apply the service policy outbound. You can apply traffic policing policies in or out.

If you want to post your class map, policy map, and interface that you're applying it to, we can take a look.

HTH,

John

I-Routes45 Fri, 04/24/2009 - 07:29

class-map match-all voix

match protocol h323

class-map match-all http

match access-group 102

!

policy-map priority

class http

police 512000 conform-action transmit exceed-action drop

class voix

priority 256

class class-default

fair-queue

!

int f0

ip add (the wan ip)

ip nbar protocol-discovery

service-policy output priority

!

access-list 102 permit tcp any any eq www

access-list 102 permit tcp any any eq 443

!

it's working on the upload but the download is taking all my bandwitdth.

Thx

John Blakley Fri, 04/24/2009 - 07:40

If you're using nat, you'll need to police the traffic back in based on your public address.

Upload is outbound and download is inbound, so try the following and let me know how it works :)

Try taking fair-queue out of the class-default, and apply the same policy inbound on the public interface.

HTH,

John

I-Routes45 Fri, 04/24/2009 - 08:08

when i removed fair-queue of class-default it let s me put my service-policy input but it does not limit my downloads to the specified rate in policing.

and yes i m using nat

interface FastEthernet0

ip address x.x.x.x x.x.x.x

ip nbar protocol-discovery

ip nat outside

ip virtual-reassembly

duplex auto

speed auto

service-policy input priority

John Blakley Fri, 04/24/2009 - 08:29

Try putting it in both directions:

int fa0

service-policy input priority

service-policy output priority

You want to shape you traffic going out though. Shape whenever you can.

Try this:

class-map match-all http

match access-group 102

policy-map INBOUND

class http

police 512000 conform-action transmit exceed-action drop

class voix

priority 256

policy-map OUTBOUND

class http

shape average 512000

class voix

priority 256

int fa0

service-policy input INBOUND

service-policy output OUTBOUND

HTH,

John

I-Routes45 Fri, 04/24/2009 - 08:52

thanks for ur time John but it didn t work, still my downloads starvs all my bandwidth and i cannot use LLQ with input policies.. i tried removing class voix from my policy-map to put service-policy input inbound and it didn t work neither.

John Blakley Fri, 04/24/2009 - 08:56

Another thing you could try is to specifically put your public address in the access-list that's matching the web traffic back in like:

access-list 103 permit tcp any host eq 80

access-list 103 permit tcp any host eq 443

Create a new class-map that matches on this access-list and apply it to the inbound policy map.

It's difficult to control inbound traffic when you're natting.

HTH,

John

Joseph W. Doherty Fri, 04/24/2009 - 09:07

On most router platforms/IOSs, you can not use queuing features within an input CBWFQ policy.

As to it "not working" for downloads, it likely is working, but downstream policing often isn't very effective. For TCP flows, such as HTTP/HTTPS, it requires the sender to detect lost packets and back off it's transmission rate. TCP senders will do this, but the aggregate input traffic often will be much higher than the rate limit. (This because TCP has already openned its send window and only later detects the lost packets.)

You can either try to improve effective downstream rate limiting by decreasing the defined bandwidth (define smaller than the rate you desire) or decrease the Tc.

I-Routes45 Fri, 04/24/2009 - 10:44

i tried everything u said guys but it seems like i can not really control the inboud of the bandwidth even with decreasing the defined bandwidth.

Thank you again

Joseph W. Doherty Fri, 04/24/2009 - 11:25

The only time policing inbound TCP isn't effective is when TCP never needs to get out of slow start. Otherwise, it does work, but again, there's a delay before the sender will back-off and that's often after it already congested your link with a burst.

In practice you often really need to turn down the inbound rate to keep it peaking above your desired rate. What did you actually try? (NB: without adjusting Tc, I've found 1/10 desired rate a starting point. e.g. for 512 try setting 51.)

Again, keep in mind, it's very, very difficult to precisely control inbound traffic on the receiving end on a Cisco router.

Also, another technique is shaping outbound ACKs, but this too tends to be inexact on Cisco routers.

PS:

There are some non-Cisco devices that can better control inbound TCP rates. These too, though, would have trouble with flows that don't need to ramp up out of slow start.

Actions

This Discussion