Cisco queueing with priority percentage

[cpnhowdy]

Im not sure if Im configuring my policy-map correctly using the
"bandwidth remaining percent" config.

Assuming Ive got an access line of 1984K and the following policy-map:

policy-map qos-serial-out
class qos_routing
bandwidth remaining percent 5
class qos_voice
priority 680
class qos_priority-data
bandwidth remaining percent 20
class qos_non-priority-data
bandwidth remaining percent 39
random-detect dscp-based
class class-default
bandwidth remaining percent 1

Should percentages add up to 100%? Meaning 1984k- 680k = 1304K remaining and then
divy up that 1304K?

 

[Bean Dip]

I have never seen the "remaining" percent command so don't throw anything at me if my answer sucks.

It has been a while for me but I would drop the "remaining" and set the percent of how much each class gets. Then default takes up the remaining % so no you don't have add to 100.

Also you have a class defined for qos_non-priority-data but that is what the default class is for. Basically default is anything does does not match any defined policy.

With a 2 Mb line do you really need QoS?

 

[UnrealRage]

Looking ok here.

Couple things:

put your voice class on top in your policy map (router processes line by line)

I believe default max-reserved-bandwidth is 75% (unless changed)

so right away you are looking at:

1488K that you can allocate bandwidth to (75% of 1984). All non classified traffic (class-default) will have 496K (1984-1488).

priority 680 for voice (max bandwidth) leaves you with:

1488-680= 808 for other defined classes

I would put my remaining percents in decending order

39 % of 808 = 315K for non priority
20% of 492= 98.6K for priority
5% of 393.4 = 19.67K for router

373.73 remaining bandwidth

1% of 373 = 3.73 K for non matching traffic (class-default)

So basically you end up with 370K that can be used by the other classes, or future classes... All classes except for voice can use remaining bandwidth (priority is max bandwidth using policer) because bandwidth states min guarantee. That being said, I wouldn't normally use a bandwidth statement on the default class since it's getting 25% or 496 K right away... Are you sure you've classifed all your traffic well enough to want to leave a 1% min? I would take off the bandwidth statement on the class-default or raise max-reserved-bandwidth (not a good idea in some cases). I wouldn't use a bandwidth for the class-default. Just make sure you set good mins for classified and you should be fine. If you've got scavenger traffic you want to minimize (kazaa) just police it or drop it. Try using NBAR for this. Also, maybe add fair-queue to the class-default. If not, then no reason to include it since unmatched traffic gets 25% of original. If you get really congested, life is going to suck for the unclassified traffic!!

It's late, but I think this is right. Using bandwidth remaining works just fine, and sometimes makes it easier when you change bandwidth statements down the road....

Oh and there is always a need for QoS. 2Mb isn't that much when you consider the aggregate traffic from the LAN. Even a simple policy to put voice in a LLQ does wonders.

Only in a perfect world where Queueing delays don't occur is QoS not needed.