[asterisk-users] Cisco Router QOS and IAX2

[Rich Adamson]

Bruce Reeves wrote:
> I'm needing some pointers from anyone who has been able to get Cisco 
> routers to recognize the iax protocol and perform QOS on it. Or if there 
> is a better way to get my iax traffic prioritized by the router.
> 

You can either match on udp/4569, or, match on TOS header bits. I like 
using the TOS header bits personally as lots of other protocols (eg, 
dns) will eventually match on udp/4569.

For the TOS bits & v1.2.10, use tos=lowdelay in iax.conf and on the 
cisco use an access list to match on the tos bits. Something like:
access-list 103 permit ip any any dscp cs3
access-list 103 permit ip any any dscp ef
access-list 103 permit ip any any tos min-delay  <= same as tos=lowdelay
access-list 103 permit ip any any tos 12

For the TOS bits & svn truck, the tos= settings have changed in 
asterisk. Look in the supplied documentation (eg, readme's, sample 
configs) for exactly what is allowed in terms of DiffServ (new term for 
TOS basically). You'll find examples that support the above access list 
item "dscp cs3" and "dscp ef".

If you're not all that experienced on cisco qos, then the following is 
an example of a working config that you should be able to translate into 
your router config one way or another.

class-map match-all voice-rtp
   match access-group 103
class-map match-all www-traffic
   match access-group 105
!
policy-map voice-policy
   class voice-rtp
     priority percent 40
   class www-traffic
    bandwidth percent 30
   class class-default
    fair-queue
!
interface Dialer0
  bandwidth 555
  <snip, my specific interface config statements>
  service-policy output voice-policy
!
access-list 103 permit ip any any dscp cs3
access-list 103 permit ip any any dscp ef
access-list 103 permit ip any any tos min-delay
access-list 103 permit ip any any tos 12
access-list 105 permit tcp any eq www any

The above config provides low-latency "priority" to voice-rtp, then 
provides an additional qos piece to ensure www-traffic is given 
bandwidth before all of the "class-default" traffic. In other words, 
voice-rtp traffic will always get 40% of the bandwidth (eg, 40% of 
bandwidth=555 above) "if" voice traffic is present. If voice traffic 
isn't present, that bandwidth can be used by other qos sections or by 
the default class. Same with www-traffic "after" the router deals with 
voice-rtp traffic. The default class always gets what bandwidth is left 
over (or all bandwidth if there is no voice-rtp or www-traffic).

To troubleshoot the above, do a "show access-list 103" from the CLI (on 
the router) and watch for matching packets in each access list line. 
Once you've structured the access list to truly match asterisk traffic, 
then do a "show policy-map interface dialer0" to display how the overall 
qos structure is functioning.

Note that cisco didn't get real serious about IOS qos until v12.2 of 
their IOS code. In v12.2 (and later versions of IOS) there has been a 
significant amount of work to bring all of their products into industry 
standard implementations / conformance / expectations. If you want to 
get real serious with cisco's qos stuff, purchase the book "End-to-end 
QoS Network Design" and read the 700+ pages devoted to the subject. It 
is an excellent book with lots of examples, etc. The book (and actual 
practice) suggests IOS v12.3 has more QoS funtionality then v12.2, and 
v12.4 has more then v12.3. (The authors of the book back that statement 
up 100% as well, and they are cisco employees.)

In the above config, the "bandwidth=555" statement is very important. It 
should represent the "actual" outgoing bandwidth for whatever interface 
you are using and not the theoretical max that someone said you should get.

Also note that for relatively slow speed interfaces (eg, most dsl's), 
the outgoing bandwidth is rather slow. If you calculate how much time is 
consumed sending a non-voice 1500-byte packet, the time is likely to be 
more then the 20 millisecond interval for sip/iax traffic. If that is 
your case, then you may need to forcibly reduce the MTU size of packets 
originating from other non-voice workstations/servers. The later cisco 
IOS versions have a parameter to do that if you can't do it via the 
workstation/server configuration parameters. If memory serves correctly, 
that parameter appeared around v12.4 of their IOS.

One last item... all of the above deals only with "outgoing" traffic. 
You would need to talk to your ISP about QoS for your incoming traffic, 
and most of the local ISP's don't have a clue. Increasingly, some of the 
larger backbone isp's are beginning to understand QoS and some have 
actually implemented something. However, those isp's are heading towards 
providing QoS as a value-add chargeable service (as in MPLS, etc).

R.