06-18-2007 01:38 AM - edited 03-03-2019 05:29 PM
I would like to use drop precedence of the EF classe in order to prioritize some phone call in case of congestion.
So, voip flux with higher drop precedence would be discarded before voip flux with lower drop precedence.
I wanted to use LLQ algorithm to give maximum priority to EF class and use RED algorithm to delete packet according to their drop precedence value. But according to what I could read on cisco documentation, RED can't be use with LLQ algorithm (logic as voip don't use TCP windows).
Which technik of packet discarding could I use with LLQ algorithm to be able to discard packet in accordance with their drop precedence?
Thanks for your help.
06-18-2007 02:20 AM
Hi,
LLQ can't use RED at all (due to the nature of the UDP packets that are going to be LLQed), and unfortunately the only drop mechanism that LLQ can utilize is tail drop.
HTH,
Mohammed Mahmoud.
06-18-2007 02:24 AM
Short answer - none.
The theory is that ALL the packets marked EF should have same priority and the link should have enough bandwidth to transmit them as FIFO without further discrimination.
Now, if your link doesn't have enough bandwidth to transmit them all, what do you want is CAC, that is the voip calls that cannot get enough bandwidth will fail at setup time with a diagnostic of "network congestion". This requires additional configuration on the router.
Is that Ok with you? Or what is that you are trying to do ?
06-18-2007 02:38 AM
Ok, I see what you mean!
But the system you explain me don't allow to prioritize some phone call. What I'm tring to do is to ensure that packet flux from very important call phone won't be discarded whereas another voip flux would be police.
I just read this document
http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087b13.html
and i saw it could be possible : Here is this example
"In this example, voice1 and voice2 classes of traffic go into the high priority queue and get strict
priority queueing over data traffic. However, voice1 traffic will be rate-limited to 24 kbps and
voice2 traffic will be rate-limited to 48 kbps. The classes will be individually rate-limited"
PS: Mohammed, I also read that tail drop couldn't be use with LLQ
06-18-2007 02:44 AM
Well it seems to me this in a confusing example.
You will have two priority queues, one limited to 24, one to 48. What will be total? 48, or 24+48 ? The document fails to say that. And, I'm not 100% sure now, but more recent IOS could allow to configure only 1 priority queue.
Anyway, if you want to try that, all what you have to do is make the classification based on IP addresses so that the calls fail in different classes.
06-18-2007 02:48 AM
Thanks for your help, I gonna try to test this configuration.
06-20-2007 03:34 AM
I think you need to do hierarchal queuing/embedded policy maps.
Here is an example I just tried out.
First setup your class maps to whatever method you are using to match.
Then create a policy map for your normal calls like the one I created below named default-call.
policy-map default-call
class default-call
priority 128
Next create a new policy as the parent policy and configure the class for critical calls like normal. Then embedded your default-call policy like I did under the "class crit-call". example below.
policy-map crit-call
class crit-call
priority 256
service-policy default-call
class class-default
fair-queue
From there you can create whatever other classes you need like it was any other policy.
The only draw back is I believe that the embedded policy has to draw upon the bandwidth reserved in the parent. In this case I configured the parent with 256k and then configure the default for 128k. If my reasoning is right then if the parent doesn't use up all 256k then the default would be allowed up to 128. This should get your critical calls scheduled before your normal calls
I'm use to doing hierarchal queuing in other vendor routers but if the logic is the same it should work.
You would have to do this in every router along the traffic path - at least the bottle necks.
While this could be a way to do it with policy maps I think I'm with PB in saying that using call admission control to prioritize who gets to establish a call first would be the best way.
06-20-2007 03:47 AM
Excellent solution! I gonna try to put in pratice what you advise me.
Thank you very much!!!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide