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.