On Fri, 2010-08-06 at 23:03 -0400, Mark Brown wrote: > So I gather I need to set up egress service-policy on my > Virtual-Access2 logical interface, via the Virtual-Template2 config > directive.
Take a look at this Cisco document: http://www.cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a00800b2d29.shtml In short, you apply the shaping to the physical interface. For the sake of clarity, in my previous example I did not use a nested policy map but that is actually the correct way. Here is an actual example from one of our devices in the field. Note that even though the theoretical maximum upload is .5mb/s, we've shaped it down significantly (.36mb/s) to reflect results we obtained when actually testing it on-site. ----- policy-map My_VoIP_Policy class My_VoIP_Class_Map priority percent 60 class class-default fair-queue queue-limit 30 policy-map My_Shape_Policy class class-default shape average 364800 3640 service-policy My_VoIP_Policy interface FastEthernet4 description $ETH-WAN$ no ip address ip tcp adjust-mss 542 duplex auto speed auto pppoe enable group global pppoe-client dial-pool-number 1 service-policy output My_Shape_Policy ! ip access-list extended My_VoIP_ACL permit ip host XXX.142.235.138 any permit ip any host XXX.142.235.138 ----- The "shape average" on the parent tells the device how much "speed" is available and the child policy divides it up between the different classes of traffic. The advantage of this technique is that you can specify the QOS as a percent using "priority percent" in the child policy and then just tweak the "shape average" until you get optimal results. As for testing, there are two techniques we use. The quick & dirty way is to just run "speedtest.net" over and over again while on a call. Just keep tweaking the "shape average" value until there is no audio drop out. It works but it's a pain in the ass having to re-run speed-test every time. The better way is to use something like "iperf", that way you can setup a much longer upload which makes tweaking easier. You can also "stress" it a bit more by forcing iperf to "flood" the upstream and a few other things you can't do with a simple web-based speed test. iperf isn't hard to setup but it is harder than just going to a web page. -- Now I'm going to say something controversial; everything I just showed you for outbound (WAN-egress) QOS voice, also works for inbound (LAN-egress) voice as well! Yes, it's true. Despite what most people will tell you, QOS does work well (with some exceptions) in both directions. Here's why. Almost all internet traffic relies on the far end to send acknowledgements so the server side can gauge how fast to send data. The sending side then throttles its rate to match what the receiving side can handle. Therefore, if you shape your receiving rate, you will have effective QOS on inbound voice. In terms of everyday internet useage, the only type of traffic that inbound shaping won't work on are "real time" protocols such as live streaming audio and video (and even some of those do their own internal buffering and rate shaping). And note that I said "live streaming video", QOS on non-live streaming (like uTube) works just fine. So the bottom line here is, once you have your QOS policy working well on the WAN-egress, flip it around and apply a similar policy, adjusted for download speed, to LAN-egress and you will have QOS in both directions. Regards, -- John Lange http://www.johnlange.ca --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
