limiting download bandwidth on http

Unanswered Question
Apr 24th, 2009
User Badges:

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
John Blakley Fri, 04/24/2009 - 07:18
User Badges:
  • Purple, 4500 points or more

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
User Badges:

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
User Badges:
  • Purple, 4500 points or more

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
User Badges:

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
User Badges:
  • Purple, 4500 points or more

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
User Badges:

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
User Badges:
  • Purple, 4500 points or more

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
User Badges:
  • Super Bronze, 10000 points or more

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
User Badges:

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
User Badges:
  • Super Bronze, 10000 points or more

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