[c-nsp] shaping outbound

[Anton Kapela]

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