QoS on my cisco 3620 router for my VoiP traffic
10345 pts.
0
Q:
QoS on my cisco 3620 router for my VoiP traffic
I am wanting to enable QoS on my cisco 3620 router for my VoiP
traffic. I believe this can be done using ACL's instead of SDM. Does anyone have any info?.
ASKED: Jan 15 2009  3:48 PM GMT
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
0
11280 pts.
0
A:
 RATE THIS ANSWER
0
Click to Vote:
  •   0
  •  0
  • AddThis Social Bookmark Button
I presume you want to prioritise it over a WAN link ?

Use basic priority queueing for this. It is simple to implement, and it has least impact on the performance of the router, or the other traffic. You use an access-list to define the traffic you want to prioritise, and apply the queue to the interface. You can find several examples on the Cisco website, if you search for Priority Queueing.

You probably also want to do fragmentation and re-assembly, which breaks up the large data packets, so the small VoIP ones don't have to wait for these to be sent over the WAN. Useful if the WAN is slower than about 2MBps. This should also be found in the examples on the website. However do NOT do this if the total of all WAN links that use this technique are over 2MB/s as this will have a huge impact on performance.
Last Answered: May 15 2009  7:01 AM GMT by BlankReg   11280 pts.
0
0
Discuss This Answer:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

IT Knowledge Exchange Community Update for 01/22/08 - ITKE Community Blog   0 pts.  |   Feb 3 2009  3:19PM GMT

[...] >> Enabling QoS on my Cisco 3620 router for my VoIP traffic [...]

 

IT Knowledge Exchange Community Update for 01/20/09 - ITKE Community Blog   0 pts.  |   Feb 3 2009  3:19PM GMT

[...] >> QoS on my Cisco 3620 router for my VoIP traffic [...]

 

Jfernatt   605 pts.  |   May 15 2009  4:04PM GMT

I have to disagree with the answer given. I believe the best queueing (and the one recommended by Cisco) for voice is going to be LLQ. Priority queueing is ok but you run the risk of queue starvation if your high priority queue is always utilized.

LLQ is basically standard MQC with a single priority queue that you will use for voice. You don’t run the risk of queue starvation and you have much more control over how your traffic is queued.

The other technology that the original answerer is refering to is LFI or link fragmentation and interleaving.

To avoid typing out an example config, go here

 <a href="http://www.cisco.com/web/psa/products/index.html" title="http://www.cisco.com/web/psa/products/index.html" target="_blank">http://www.cisco.com/web/psa/products/in…</a>

Click cisco ios software. 12.4 mainline. Go to configuration guides. Click Cisco IOS Quality of Service Solutions Configuration Guide

Good Luck

 

BlankReg   11280 pts.  |   May 18 2009  10:35PM GMT

As this was a simple scenario, and the VoIP traffic is ALWAYS the most important, and always needs to have priority. Priority queueing is the simplest to set up, as you only define the RTP for the priority queue. It should never starve out the other queues, as the VoIP packets are small and not continuous (unless you use it for multiple lines with constant sound, and then you should order more bandwidth for the WAN). Starvation would happen if you prioritise other data, but that is not what intended to mean in my original answer (but I confess I did not make that as clear as I maight have).

LLQ is more complex to set up, and requires you to know roughly how much bandwidth is required for the voice, which may not be a known factor. I agree that it is the more elegant, and is probably the recommended solution, but does need more knowledge of the VoIP implementation to achieve a good QoS. If the guesstimate of the bandwidth for VoIP is too low, then all the VoIP calls can suffer poor quality, with Priority queueing it is much less likely to happen until the entire bandwidth is saturated. I will also confess that I have used LLQ more than Priority for this type of solution, but have also been implementing the VoIP as well, so knew the figures for the bandwidth requirements.

Hey, there is always more than one way to do things, and now ITKE has two methods to achieve his aim ;-)

 
0