[c-nsp] shaping outbound

[Dan Letkeman]

Excellent info Anton.  This has help immensely.

I have tested the configuration example that you have shown me and it
seems to work very well.  I added a class in the shape-down policy-map
for http and shaped it to 2M just for testing.

policy-map shape-down
 class http
  shape average 2000000 256000 128000
  queue-limit 32768 packets
 class class-default
  shape average 40000000
  service-policy qos-down

It works, but I had to add the queue-limit 32768 packets (i know this
is a large number), as the default is 64 packets.  If I left it at 64
packets I would see many drops in my test environment which makes
sense as I am hammering a 2M http policy.   I just needed to see this
to make sense of it all.

>From my understanding, when the traffic load is too much for the
allotted bandwidth the queue would need to be increased or the
bandwidth needs to be increased?

If I wanted shape a website, for example youtube.com, would it be best
to mark it on the incoming interface with a dscp marking and then
shape that dscp marking on the output interface?  I tried this, but
with no success, I was only able to drop the traffic, and not shape
it.

Now my next stumbling block is how to shape my sub interfaces for my
guest networks on the router.  It seems as if you are not allowed to
add shaping even with a child/parent policy map.....

Dan.

On Sun, Dec 25, 2011 at 2:46 PM, Anton Kapela <tkapela at gmail.com> wrote:
> Dan,
>
> On Sat, Dec 24, 2011 at 2:49 PM, Dan Letkeman <danletkeman at gmail.com> wrote:
>
>> I'm confused as to when and where it is possible to shape traffic.  I
>> have a 50Mbps internet connection from our ISP and I would like to
>> shape some of the download traffic using our 2821.  Here is what I
>> have setup:
>>
>> lan users ----- g0/0 - 2821 - g0/1 ------internet
>>
>> Currently I have no way of limiting someone from using up the entire
>> pipe.  My thought was to add a policy-map in the outbound direction on
>
> [..]
>
>> Any idea on how to go about this?  Or Am I stuck with buying a
>> ridiculously expensive packet shaper or something of the sorts?
>
> You can, in fact, shape, queue, and control bits arriving at your
> doorstep if you're willing to give up a bit of the internet pipes'
> peak downstream bitrate. In general, if you were to, say, queue
> packets towards your users (lan side), at less than the configured ISP
> rate, you'd effectively congest within the router (which you control).
> This could be useful.
>
> A rule of thumb I've kept in mind is to shape at ~80% of the overal
> CIR from your isp. Then, apply queueing to taste. A fairly useful &
> straight-forward approach might look like the following:
>
> policy-map qos-down
>  class class-default
>    fair-queue
>    queue-limit 2048 packets
>
> policy-map shape-down
>  class class-default
>    shape average 40000000 160000
>  service-policy qos-down
>
> Then, apply to lan facing port:
>
> interface GigabitEthernet0/0
> service-policy output shape-down
>
> Same for upstream, though, you can typically get away shaping within
> 95% of the configured CIR bitrate. Say you had 5 mbits/sec upstream.
> You'd then want something like:
>
> policy-map qos-up
>  class class-default
>    fair-queue
>    queue-limit 512 packets
>
> policy-map shape-up
>  class class-default
>    shape average 4750000 19000
>  service-policy qos-down
>
> ..then applied in the output direction of Gi 0/1, per your config setup.
>
> Fair-queue alone will ensure per-flow fairness is provided by the
> router in the Tx direction for any packets buffered in the shaped
> class-default. This could be 'bad' if you're concerned that or faced
> with many-flow apps (torrents, etc) out-competing single- or few-flow
> apps (shoutcast, iptv, netflix, etc). If that's the case, then
> adjustment and specific queueing must be created to single-out the
> jerks and/or reserve bits for known-friendly-er apps. If you're not
> seeing/concerned with flow-rich vs. flow-poor apps getting a fair
> shake, and are considering a more docile/typical app mix (few big
> downloads, app updates, imap/exchange email, vpns, net radio, etc),
> then fair-queue alone will probably be sufficient.
>
> -Tk