Question on how to read this policy map

can you read this line by line so I can se how to read this. I am confused on remaining 40 and then remaining 30 how does that work? Thanks guys.

policy-map pm-avpn
class cm-voice
priority percent 60
set ip dscp ef
class cm-company
set ip dscp af31
bandwidth remaining percent 40
class cm-branch
set ip dscp af21
bandwidth remaining percent 30
class class-default
fair-queue
set ip dscp default

Find more posts tagged with

Comments

networker050184

You give 60% of the reservable bandwidth to the first class leaving 40% of the reserveable bandwidth available to other classes (whether this is 40% of the actual interface bandwidth depends on max-reserved bandwidth). Of that remaining 40% cm-company get's 40% and cm-branch get's 30%. Class default uses fair queuing.

itdaddy

networker050184

remaining 40 % =total 100 % used. how can you get 30 percent more from 100%?

davenull

We first carve out a 60% piece of a pie and give it to voice. Then we look at leftovers and cut 40% of the leftovers (not of the original pie) to the cm-company class, and 30% of the leftovers to the cm-branch. Class default gets what's left of the leftovers, which is 30%.

powmia

you will starve your network, as 60% LLQ is much too high

creamy_stew

powmia wrote: »

you will starve your network, as 60% LLQ is much too high

I really need to read up on QoS (I've said this many times

). Are all 60% really reserved for the priority queue, regardless of whether there is congestion or not? I thought realistically that voip would take at the most 10%, so if voip would take 10%, that would still allow the remaining 50% of the priority queue to be used by other queues as long as there is no congestion. Or is there some sort of built in policer in the priority queue?

edit: Typing "queue" sucks. Also, it looks weird

davenull

I thought I read somewhere 75% is the max that should be assigned to priority queuing. Not that it was recommended, I think the wording was 'don't go over 75%'.

DiffServ QoS is only triggered when there's a congestion. Even with 60% configured for voice, other traffic may use 100% as long as there's no voice calls.

fredrikjj

creamy_stew wrote: »

Or is there some sort of built in policer in the priority queue?

Yes, but it's "implicit". This means that it's only used when the queuing policy is used. So in this example, if there's no congestion the traffic in the class 'cm-voice' can use the entire interface bandwidth. But if congestion occurs, it's limited to 60% of interface bandwidth. This implicit policer is needed because the priority queue is a strict priority queue so the scheduler always picks packets from this queue first. The policer prevents packets from entering the LLQ after a certain point, which gives the scheduler time to serve the other queues as well (which is done in proportion to their configured bandwidths).

I get the starvation argument, I think, and the official Cisco number is that the LLQ shouldn't exceed 30% or something like that, but if you have voice traffic, isn't the point that this should starve the other traffic? You could for example configure 'priority' with no parameter to remove the implicit policer. You would then have "complete" starvation assuming that you have enough voice traffic to fill up the entire interface bandwidth. Your voice traffic would get through and everything else would be dropped, but doesn't that just mean that your interface bandwidth is way too low to begin with?

creamy_stew

fredrikjj wrote: »

You could for example configure 'priority' with no parameter to remove the implicit policer.

Nice!

fredrikjj wrote: »

Your voice traffic would get through and everything else would be dropped, but doesn't that just mean that your interface bandwidth is way too low to begin with?

Yeah, this is one of the things I don't get: If your LLQ traffic is saturating the connection, no amount of voodoo can make bandwidth out of thin air. Assuming, of course, that only the traffic we want to have priority is in the priority queue. But that's really more of a classification issue, I guess?

I just don't have the full picture of QoS and it's frustrating at times.

itdaddy

thank so much nicely explained. super. Yeah I think 60 is too high as well.