Sunday, October 26, 2014

Cisco IOS VoIP QOS on ADSL

Summary

This article describes how to configure a Cisco router with an ADSL interface to provide prioritization of voice (Quality of Service - QOS).  I'll be classifying voice packets and then placing them into a low latency queue (LLQ).  Everything else (generic data) will be placed into flow-based fair queues.  Additionally, I'll configure Random End Detection (WRED) for the generic TCP traffic.


Environment

Figure 1 depicts the system I'll be configuring.  General data and voice traffic are passing through a Cisco router with an ADSL interface.  An ADSL service provider passes that traffic on the Internet or PSTN.  

Note that while it's possible to configure QOS for voice traffic within your router environment, once that traffic leaves your router - there is no QOS.  Unless your service provider honors QOS markings (highly doubtful), your traffic (voice and data) is being handled as best-effort only.  On a positive note, properly configuring queuing alone on your local router does make a significant positive impact on voice quality.

Figure 1

Implementation

Figure 2 provides a logical picture of what I'll be configuring in Cisco IOS.
Figure 2
Configuring QOS in Cisco IOS can be broken down into the following series of steps:  Classify, Mark, Queue, Shape, and finally apply the policy to an interface.  For simplicity's sake, I'm not going to show any Mark configurations here (also as previously mentioned, your ISP likely ignores/overwrites any markings you make to packets).

Classification



1
2
3
4
class-map match-any voip-class
 match protocol rtp
 match protocol rtcp
 match protocol sip

Line 1 creates a class-map named 'voip-class'.  Any matching condition below it causes the entire class to be matched.
Lines 2-3 are the conditions to be matched.  I'm using the Cisco NBAR engine to classify RTP, RTCP, or SIP signalling traffic.  Any traffic of these types needs to be prioritized.

Queuing



1
2
3
4
5
6
policy-map wan-queue-policy
 class voip-class
  priority 180
 class class-default
  fair-queue
  random-detect


Line 1 creates a policy-map named 'wan-queue-policy'.
Lines 2 and 4 define the two traffic classes this policy will apply to.  I defined the 'voip-class' above.  All other traffic that doesn't match that voip class is thrown into the default class.
Line 3 creates a low latency queue for the voip class.  180 kbps is allocated/guaranteed for that queue.
Lines 5 and 6 configure flow-based queuing for all other traffic.  Additionally, WRED is provided for the TCP traffic in this class.

Shaping



1
2
3
4
policy-map wan-shape-policy
 class class-default
  shape average 896000 8960
   service-policy wan-queue-policy


Line 1 creates another policy-map named 'wan-shape-policy'
Line 2 defines the only traffic class within this policy, a default class.
Line 3 defines the traffic shaping parameters.  In this case, I'm shaping to 896 kbps.  You would set this parameter to be equal to whatever upload bandwidth your ISP is providing.  The following IOS command will list the download and upload speeds on your ADSL link.


router#show dsl int <your adsl/atm int>

Finally, Line 4 applies the previously defined queuing policy to this shaping policy.


Apply the Policy to an Interface

This is where everything can wrong.  Applying this policy to the Dialer interface (a logical interface) on your ADSL interface will NOT work.  If you monitor traffic passing through the policy-map you will in fact see class counters incrementing; however, no queuing/shaping is happening.  You must apply the shaping policy-map to the ADSL hardware interface (specifically, the ATM PVC).


1
2
3
4
5
6
7
interface <your int>
 no ip address
 no atm ilmi-keepalive
 pvc 0/32 
  vbr-rt 896 896
  tx-ring-limit 3
  service-policy out wan-shape-policy


All the action happens starting at Line 4, the PVC.
Line 5 defines an ATM service category (variable bit rate real-time).  I allocated 896 kbps for this traffic class.  The documentation on configuring the parameters (SBR, PBR) for 'vbr-rt' command is somewhat sketchy.  I saw discussions of using the max upload bandwidth as the input for these parameters, but I'm open to other suggestions if they provide reasonable justification.
Line 6 decreases the length of hardware transmit buffer for this interface.  From what I can gather from the Cisco documentation, this is a best practice.  That buffer is 60 wide by default.  Shortening it decreases the latency for the hardware to put the ATM cell on the wire, which is a good thing for voice.  However, nothing is free.  Shortening the buffer will increase CPU usage (more interrupts) on a high-speed link.  This isn't a high-speed link.
Finally, Line 7 applies the shaping policy to the interface.  I apply it in the outbound direction as that is where queuing and shaping needs to happen to alleviate congestion.

You can monitor the policy in real-time with the following command:


router#show policy-map int <your adsl/atm int>