Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

QoS understanding

I understand how to create ACLs, class-maps, policy-maps and use service-policy [input|output| to apply the QoS

to a specific interface etc etc. But I'm having a bit if a problem understanding how QoS actually goes into effect.

I'm assuming let's say, we have a T1 line, and I setup QoS so that 25% of that traffic is guaranteed for VoIP.

From what I understand VoIP can use as much bandwidth as it wants up to 75% untill it gets congested and

then it's guaranteed 25%.

6 REPLIES
New Member

Re: QoS understanding

QoS policies go into effect whenever there is congestion on the link.You're likely to have congestion anytime you're going from high bandwidth media (ie, 100Mb LAN) to a lower bandwidth media (ie, T1 lines).

In your example, I believe you're correct with a simple bandwidth guarantee but it is recommended you use a strict priority queue for voice traffic.  You don't want your voice traffic to be at a certain % when it's available, then get dropped or queued during congestion to only 25%... that'll make for crummy voice quality.  Your voice calls have to be guaranteed for the max amount needed at ALL times so the packets can be sent in a timely manner with no drops or excessive delays.  You can use more than that 75% limit if you specify max-reserved-bandwidth xxx on an interface.

If you have 25% of traffic guaranteed for Voice using a priority or priority percent strict-priority queue, the voice will be allocated ~ 386kbps of that T1 and no more.  Any voice traffic exceeding 386kbps will be dropped.  It's very important to calculate your maximum voice requirements based on number of users, type of voice implementation, codec, etc.

The real QoS experts can chime in.  There are many congestion management and congestion avoidance tools used in QoS to keep certain traffic in check and prioritize other flows.

Re: QoS understanding

Thanks, that helped me understand a little better. I would never have QoS for VoIP at 25% of bandwidth

I was just using that as an example. Thanks for your help!

Re: QoS understanding

So VoIP could in theory use as much bandwidth as it wants until there is congestion and then it will get the

guaranteed bandwidth of 25% in my previous example. Which would leave to queueing VoIP and Tail Drop of packets.

This is assuming all defaults btw.

Hall of Fame Super Blue

Re: QoS understanding

JohnTylerPearce wrote:

So VoIP could in theory use as much bandwidth as it wants until there is congestion and then it will get the

guaranteed bandwidth of 25% in my previous example. Which would leave to queueing VoIP and Tail Drop of packets.

This is assuming all defaults btw.

John

If you assigned VOIP to the strict prioriy queue then yes if there is spare bandwidth it can use it but it's important to realise that only the 25% of bandwidth allocated is priority queued. Any additional bandwidth VOIP used would not be prioritised in the same way and could end up getting stuck behind other non-VOIP traffic. That's why it's important to try and get an accurate measurement of VOIP traffic and allocate it the correct amount in the priority queue.

Jon

Re: QoS understanding

So let's say I give 50% bandwidth to VoIP, and give it the strict priority queue per LLQ.

As long as there is not any congestion on the line, it can use however much it wants

per line speed, but if there is congestion only 50% can be used for VoIIP and ones, behind

that queue could end up getting stuck behind other traffic and or tail dropped depending on your

configuration?

Hall of Fame Super Blue

Re: QoS understanding

JohnTylerPearce wrote:

So let's say I give 50% bandwidth to VoIP, and give it the strict priority queue per LLQ.

As long as there is not any congestion on the line, it can use however much it wants

per line speed, but if there is congestion only 50% can be used for VoIIP and ones, behind

that queue could end up getting stuck behind other traffic and or tail dropped depending on your

configuration?

If you give 50% to VOIP and there is congestion then yes the VOIP packets are prioritised above everything else, assuming you assigned VOIP to the priority queue. But the priority queue has a policer as well so that during congestion VOIP cannot go above 50% and starve the other queues.

Jon

429
Views
0
Helpful
6
Replies
CreatePlease to create content