Disclaimer: I am not a Cisco IOS expert. I have dealt with them mostly in dialup (access server) capacity, but I have some QoS experience with these routers. I have worked mainly with the 2600-series.

First things first: If you do not have control over the hardware at BOTH ends of your link, you will have suboptimal performance. However I have found that with a little work it's not quite so bad. I will be talking about my real-world setup: a point-to-point HDSL DS1 to MCI, and a similar T1, but with a 2500-series router and AT&T.

Both routers try to keep the incoming traffic UNDER the maximum link speed in order to prevent the upstream router from plugging the link with traffic and drowning out VOIP traffic. Since you cannot shape traffic coming to you, you try and police it instead.

NOTE: This only works with TCP traffic. UDP/ICMP traffic cannot be policed, since these protocols do not try and ensure that data transmission was successful.

I have an access group (105) which matches any of my VOIP traffic:
access-list 105 remark VOIP (SIP/IAX/IAX2) traffic gets top priority (5)
access-list 105 permit udp any any eq 4569
access-list 105 permit udp any any eq 5004
access-list 105 permit udp any any eq 5036
access-list 105 permit udp any any eq 5060
access-list 105 permit ip host OTHER.VOIP.HOST.HERE any
access-list 105 permit ip any host OTHER.VOIP.HOST.HERE

As you can see, I'm matching UDP 4569 (IAX2), 5004 (RTP), 5036 (IAX1) and 5060 (SIP). I am also allowing any traffic from OTHER.VOIP.HOST.HERE to be included. This is a SIP device and I'm trying to also match the actual voice traffic. SIP's an awful little protocol since it uses dynamic port allocation. You may want to alter these rules to taste; You can accidentally include non-VOIP traffic here very easily. I'm not overly worried about it in my particular setup.

Now, to prevent the upstream from plugging up the link, I am going to set up two input rate-limit rules to police the incoming traffic. The first will allow 128k of VOIP traffic in no matter what, set its precedence to high priority (5) and transmit it. The other part of the first rule will allow any excess VOIP traffic (above 128k), but its precedence set to best-effort (0) and the remaining police rule will be evaluated as well. The second rate-limit command will allow no more than 1408kbps through; any excess will be dropped.

Again, this only works for TCP traffic, since dropped packets will cause the sender to back off and try again slower. If your link is full of other protocols without this particular feature, this won't do anything to help:

in s0/0
 rate-limit input access-group 105 128000 65536 65536 conform-action set-prec-transmit 5 exceed-action set-prec-continue 0
 rate-limit input 1408000 8000 8000 conform-action transmit exceed-action drop

At any rate, that takes care of the incoming traffic. Ideally you want to be able to control the traffic on both sides of the link, but the world is far from ideal.

Now to handle outgoing traffic. This is where you have all the power.

In the 2600 series of routers you can use service polices and LLQ (Low Latency Queueing) — this queueing discipline was _designed_ for VOIP. I am running IOS 12.1(21) RELEASE.

Setting it up is a snap:

class-map voice
 match access-group 105
!
policy-map policy1
 class voice
   priority 96
 class class-default
  fair-queue
!

The first pair of commands sets up a class called 'voice', which matches any traffic which matches access group 105 (the VOIP ACL I have defined above). The second group actually sets up the police map; it guarantees 96kbps of traffic for the voice class, and everything else is queued using the fair-queue discipline. Now all you have to do is attach this to an interface:

in s0/0
 service-policy output policy1

in e0/0
 service-policy output policy1

Again, you can only do meaningful QoS on OUTGOING traffic. Once the traffic's in the pipe, you're stuck with it.

Other hints:

My particular setup has an incoming T1 to the 2600, then it is split off to various companies through an SDSL DSLAM. I have set up ACLs to match the companies who are using VOIP in a similar fashion to how I did the s0/0 polcing; I try to keep ther individual links from plugging up so that any VOIP traffic can get through, even under excessive TCP load. An example:

in e0/0
 rate-limit output access-group 2128 512000 8000 8000 conform-action set-prec-transmit 1 exceed-action continue
 rate-limit output access-group 2128 128000 8000 8000 conform-action set-prec-transmit 1 exceed-action drop

Here ACL 2128 matches one of the companies /30 network (all companies have a /30 network with us, and additional IPs are routed to their end of the /30 if necessary). They have a 768kbps link. The first rate-limit matches the first 512kbps of their traffic, which I send off immediately. Above 512kbps they fall into the second ACL which gives them a second kick at the cat, so to speak. After they exceed 768k total, their traffic starts to get dropped. This "dual-action" rate-limit on traffic to their router seems to work better than a single 768000 rate-limit. I can only guess that it is working with the output service policy in nicer manner.

I need to set up more output policies to enforce minimum VOIP traffic on a per-customer basis in order to get better VOIP functionality.

---

Another example:

class-map match-any VOIP-SIGNAL
 match ip dscp cs5
 match ip precedence 4
 match ip precedence 3
class-map match-any VOIP-RTP
 match ip dscp ef
match ip precedence 5
!
!
policy-map QOS-Policy
 class VOIP-SIGNAL
  priority percent 5
 class VOIP-RTP
  priority percent 70
 class class-default
  fair-queue
 random-detect
!
interface Serial0/0/0:0
 service-policy output QOS-Policy

---

Yet another example, this time for routers using sub-interfaces:

no access-list 117
access-list 117 remark VOIP (SIP/IAX/IAX2) signaling gets ensured bandwidth (16)
access-list 117 permit udp any any eq 4569
access-list 117 permit udp any any eq 5036
access-list 117 permit udp any any eq 5060

no access-list 118
access-list 118 remark VOIP (RTP) traffic gets top priority (5)
access-list 118 permit udp any any range 16384 32767

class-map match-all voice-traffic
match access-group 118
class-map match-all voice-signaling
match access-group 117

policy-map qos-voice
class voice-traffic
  priority 240
class voice-signaling
  bandwidth 16

policy-map qos-parent
class class-default
  shape average 2000000 
  service-policy qos-voice

interface FastEthernet0/0.1
service-policy output qos-parent

-b

---

Configuring Cisco Switches for QoS with Cisco 79xx IP Phones:

interface FastEthernet0/1
description IP Phone port
switchport trunk encapsulation dot1q
switchport trunk native vlan 106        !subsitute "106" for your data vlan
switchport mode trunk
switchport voice vlan 103                  !subsitute "103" for your voice vlan
switchport priority extend cos 0          !ensures PCs connected to IP Phone don't also classify traffic
spanning-tree portfast

With this configuration all voice traffic will get an L2 COS tag of 5 and a L3 IP Precedence of 5. All data traffic from the connected PC will get an L2 COS of 0.

Additionally ensure the the speed and duplex settings for the port are set to auto. If the port is statically configured to 100baseT full-duplex, the phone will configure it's port to 100baseT half-duplex, resulting in a duplex mismatch.

If your switch supports inline power, add the following:

power inline auto

-b

---

Yet another way, this time for those of us stuck with DSL (ATM w/ PPPoE)

• Here is where you create classes that will be used by the VoicePolicy below. You could do some direct matches here. I prefer to do this via access lists. That way you can create multiple and test different things by switching between which list you map.

class-map match-any signaling
match access-group 102
class-map match-any voice
match access-group 101

• Here is where you create your voice policy. Here you can reserve bandwidth for your traffic. You may need to adjust these values to reflect your specific case and upload speeds. The idea here is to have plenty of room for RTP and SIP traffic with overhead no matter what other traffic is present.

policy-map VoicePolicy
class voice
 priority 384
class signaling
 priority 128
class class-default
 fair-queue

• This is where the QoS policy is applied for outbound. Note your Interface name, DSL settings, and bandwidth is probably different than mine. My upload is 768 so if you had 512 upload you would use vbr-nrt 512 512. If you regularly see LESS than your maximum upload you may wish to adjust the second value to match your true upload speed. i.e vbr-nrt 512 384. The most interesting part of this and most important part though is the tx-ring-limit statement. I originally had this setup without it and it QoS never seemed to work. Turns out, according to a cisco tech, the DSL interface has its own rather large packet buffer. Apparently it will store large a mounts of packets that may bypass QoS. Setting this setting only allows 3 packets in that buffer thus forcing QoS policies to apply on active non buffered traffic. You can then check out if this actually worked by running 'show policy-map interface'. Make sure neither of your voice or signaling maps are dropping packets. Remember, you can only apply the service policy on OUTBOUND traffic in any useful way. We have no way of controlling the flow of traffic flowing inbound.

interface ATM0/0/0
no ip address
no atm ilmi-keepalive
bundle-enable
dsl operating-mode auto 
pvc 0/35 
 vbr-nrt 768 768
 tx-ring-limit 3
 service-policy output VoicePolicy
 pppoe-client dial-pool-number 1

• You'll note here that QoS does NOT get applied to the dialer interface like you would think. It actually goes on the ATM PVC which calls the dialer

interface Dialer0
ip unnumbered FastEthernet0/0
no ip redirects
no ip unreachables
ip mtu 1492
encapsulation ppp
no ip route-cache cef
no ip route-cache
ip tcp adjust-mss 1452
no ip mroute-cache
dialer pool 1
no cdp enable
ppp authentication pap chap callin
ppp pap sent-username <your PPPoE Username> password 0 <Your PPPoE Password>

• Change these access lists to match your situation. Here we match only UDP ef voice traffic and af41 signaling traffic

access-list 101 remark ***QoS for RTP and IAX***
access-list 101 permit udp any any dscp ef
access-list 102 remark ***QOS for SIP***
access-list 102 permit udp any any dscp af41

-raymckay

---

See Also:

• QoS Cisco IOS

---

• Cisco
• QoS: Quality of Service in VOIP Networks