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 |
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>
