[c-nsp] QoS on the 2960

[Roger Wiklund]

This should work.

This is the way I did bandwith management on a 3750, policing on
ingress and srr-queue bandwith limit on egress.

The problem with Internet users and TCP is policing. As soon as a
packet exceeds the limit it drops it. And TCP has to resend, and then
you have the TCP sliding window etc. So you will see the a sawtooth
effect if you look at grahps.

Our Internet users complained about this, when they ran TCP based
bandwith testers. If you crank up the burst when you police, you will
see smoother graphs and get better throuthput.

If you test with UDP you should get the full 8 meg.

Regards
Roger

On Thu, Sep 23, 2010 at 2:16 AM, Seth Mattinen <sethm at rollernet.us> wrote:
> I'm trying to figure out QoS on a 2960 - something I've read about a lot
> but never had to do before. I'm very simply attempting to limit a
> customer to speed X, 8M for example. So far I have this:
>
> !
> mls qos srr-queue input bandwidth 100 1
> mls qos srr-queue input buffers 100 0
> mls qos srr-queue input priority-queue 2 bandwidth 0
>
> class-map match-all customerX
>  match access-group name customerX
>
> policy-map customerX
>  class customerX
>  police 8000000 100000 exceed-action drop
>
> interface FastEthernet0/1
>  srr-queue bandwidth limit 10
>  service-policy input customerX
> !
>
> Other than the fact that the "download" only gets at granular as 10%,
> will this work?
>
> I previously tried applying 8 meg policers (with mls qos srr-queue
> defaults) on both the customer's port and the uplink port, but the net
> result seemed to be about a 3 to 5 meg max rather than closer to 8. This
> customer is alone on the switch.
>
> ~Seth
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>