Thank you so much. After fighting with a large/extensive QOS policy from Cisco's SDM tool, I used your sample and tweaked it for my needs and everything started working fine.<br><br>Bruce<br><br><div><span class="gmail_quote">
On 8/23/06, <b class="gmail_sendername">Rich Adamson</b> <<a href="mailto:radamson@routers.com">radamson@routers.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bruce Reeves wrote:<br>> I'm needing some pointers from anyone who has been able to get Cisco<br>> routers to recognize the iax protocol and perform QOS on it. Or if there<br>> is a better way to get my iax traffic prioritized by the router.
<br>><br><br>You can either match on udp/4569, or, match on TOS header bits. I like<br>using the TOS header bits personally as lots of other protocols (eg,<br>dns) will eventually match on udp/4569.<br><br>For the TOS bits &
v1.2.10, use tos=lowdelay in iax.conf and on the<br>cisco use an access list to match on the tos bits. Something like:<br>access-list 103 permit ip any any dscp cs3<br>access-list 103 permit ip any any dscp ef<br>access-list 103 permit ip any any tos min-delay <= same as tos=lowdelay
<br>access-list 103 permit ip any any tos 12<br><br>For the TOS bits & svn truck, the tos= settings have changed in<br>asterisk. Look in the supplied documentation (eg, readme's, sample<br>configs) for exactly what is allowed in terms of DiffServ (new term for
<br>TOS basically). You'll find examples that support the above access list<br>item "dscp cs3" and "dscp ef".<br><br>If you're not all that experienced on cisco qos, then the following is<br>an example of a working config that you should be able to translate into
<br>your router config one way or another.<br><br>class-map match-all voice-rtp<br> match access-group 103<br>class-map match-all www-traffic<br> match access-group 105<br>!<br>policy-map voice-policy<br> class voice-rtp
<br> priority percent 40<br> class www-traffic<br> bandwidth percent 30<br> class class-default<br> fair-queue<br>!<br>interface Dialer0<br> bandwidth 555<br> <snip, my specific interface config statements>
<br> service-policy output voice-policy<br>!<br>access-list 103 permit ip any any dscp cs3<br>access-list 103 permit ip any any dscp ef<br>access-list 103 permit ip any any tos min-delay<br>access-list 103 permit ip any any tos 12
<br>access-list 105 permit tcp any eq www any<br><br>The above config provides low-latency "priority" to voice-rtp, then<br>provides an additional qos piece to ensure www-traffic is given<br>bandwidth before all of the "class-default" traffic. In other words,
<br>voice-rtp traffic will always get 40% of the bandwidth (eg, 40% of<br>bandwidth=555 above) "if" voice traffic is present. If voice traffic<br>isn't present, that bandwidth can be used by other qos sections or by
<br>the default class. Same with www-traffic "after" the router deals with<br>voice-rtp traffic. The default class always gets what bandwidth is left<br>over (or all bandwidth if there is no voice-rtp or www-traffic).
<br><br>To troubleshoot the above, do a "show access-list 103" from the CLI (on<br>the router) and watch for matching packets in each access list line.<br>Once you've structured the access list to truly match asterisk traffic,
<br>then do a "show policy-map interface dialer0" to display how the overall<br>qos structure is functioning.<br><br>Note that cisco didn't get real serious about IOS qos until v12.2 of<br>their IOS code. In v12.2
(and later versions of IOS) there has been a<br>significant amount of work to bring all of their products into industry<br>standard implementations / conformance / expectations. If you want to<br>get real serious with cisco's qos stuff, purchase the book "End-to-end
<br>QoS Network Design" and read the 700+ pages devoted to the subject. It<br>is an excellent book with lots of examples, etc. The book (and actual<br>practice) suggests IOS v12.3 has more QoS funtionality then v12.2
, and<br>v12.4 has more then v12.3. (The authors of the book back that statement<br>up 100% as well, and they are cisco employees.)<br><br>In the above config, the "bandwidth=555" statement is very important. It
<br>should represent the "actual" outgoing bandwidth for whatever interface<br>you are using and not the theoretical max that someone said you should get.<br><br>Also note that for relatively slow speed interfaces (eg, most dsl's),
<br>the outgoing bandwidth is rather slow. If you calculate how much time is<br>consumed sending a non-voice 1500-byte packet, the time is likely to be<br>more then the 20 millisecond interval for sip/iax traffic. If that is
<br>your case, then you may need to forcibly reduce the MTU size of packets<br>originating from other non-voice workstations/servers. The later cisco<br>IOS versions have a parameter to do that if you can't do it via the<br>
workstation/server configuration parameters. If memory serves correctly,<br>that parameter appeared around v12.4 of their IOS.<br><br>One last item... all of the above deals only with "outgoing" traffic.<br>You would need to talk to your ISP about QoS for your incoming traffic,
<br>and most of the local ISP's don't have a clue. Increasingly, some of the<br>larger backbone isp's are beginning to understand QoS and some have<br>actually implemented something. However, those isp's are heading towards
<br>providing QoS as a value-add chargeable service (as in MPLS, etc).<br><br>R.<br><br>_______________________________________________<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a>
--<br><br>asterisk-users mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br></blockquote>
</div><br><br clear="all"><br>-- <br>Bruce<br>Nortex Networks