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 <[email protected]> wrote: > Dan, > > On Sat, Dec 24, 2011 at 2:49 PM, Dan Letkeman <[email protected]> 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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
