05-28-2010 11:45 AM - edited 03-04-2019 08:37 AM
All,
Taking the following into consideration:
policy-map TEST
class TEST
priority 768
The priority command guarantees at least 768, and I believe at most 768. The question that I have is if only 96k is needed for the above class, does it still set aside the 768k? If I have voice traffic that's matched for this class, and one person picks up the phone on a T1 circuit, does the router automatically set aside ALL 768 for that one phone call?
Thanks,
John
Solved! Go to Solution.
05-28-2010 11:56 AM
Hello John,
there is a recent thread where the question has been widely discussed and tested
see
https://supportforums.cisco.com/thread/2016073?tstart=0
there is no policing action unless the link is congested, not used resources are available to other traffic classes:
so traffic of LLQ queue can be more then stated value in priority command if there are resources unused by other classes
CBWFQ with LLQ has this elasticity, older legacy queueing like priority queueing or custom queueing miss this capability.
When testing a CBWFQ scheduler there are output drops when the traffic mix volume is over 100% capacity of the link (taking in account max-bandwidth for platforms supporting it) and only classes over their value have drops providing effective differentiated services.
When the link is totally used, LLQ traffic is limited to stated priority value to avoid starvation on other queues (that happened in old Priority Queueing)
to be noted one could explicitly set a policer within the policy map and in that you could not go beyond stated value
Hope to help
Giuseppe
05-28-2010 11:56 AM
Hello John,
there is a recent thread where the question has been widely discussed and tested
see
https://supportforums.cisco.com/thread/2016073?tstart=0
there is no policing action unless the link is congested, not used resources are available to other traffic classes:
so traffic of LLQ queue can be more then stated value in priority command if there are resources unused by other classes
CBWFQ with LLQ has this elasticity, older legacy queueing like priority queueing or custom queueing miss this capability.
When testing a CBWFQ scheduler there are output drops when the traffic mix volume is over 100% capacity of the link (taking in account max-bandwidth for platforms supporting it) and only classes over their value have drops providing effective differentiated services.
When the link is totally used, LLQ traffic is limited to stated priority value to avoid starvation on other queues (that happened in old Priority Queueing)
to be noted one could explicitly set a policer within the policy map and in that you could not go beyond stated value
Hope to help
Giuseppe
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