subinterface QOS shape vs police

[paul amaral]

OK so i understand you can't directly apply a QOS service poilicy to a sub interface because it needs to be aware of congestion and to get around this you can use the hierarchical serice policy. Im confused on what the shape/police commands use to know the interfce is congested, is it looking at the physical interface as a whole or what is coming into the subinterface.

My question is how does the shape or police this, lets say i have a wan link of 20Mbs and using a GigE subinterface. How would I configure the QOS policy for the subinterface so that when the interface is congested, using the full 20Mbs that it give 5% priorityto the VOIP packets?

interface GigabitEthernet0/0
desc lan interfaceip ddress 10.213.10.1 255.255.255.0

interface GigabitEthernet0/0.118
 description To VOIP
 encapsulation dot1Q 118
 ip address 10.213.118.2 255.255.255.0

policy-map sub_int_qos

class voice

priority percent 5

policy-map police_voice_policy

class class-default

shape average 3000000

     random-detect dscp-based

service-policy sub_int_qos

what exactly is the shape command doing above, is it saying once we see 3Mbs of traffic to the subinterface that its congested and we then apply the QOS service police saving 5% of the 3Mbs? 

Does this mean we potentially have 17Mbs coming in to the main GigE and 3 to the suninterface ?

If i use police instead of shape, is it basically the same concept,  using something like, police 3000000 375000 375000 conform-action transmit exceed-action drop violate-action drop.

Do I want exceed action to drop?

thanks, Paul

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

interface GigabitEthernet0/0
desc lan interfaceip ddress 10.213.10.1 255.255.255.0

interface GigabitEthernet0/0.118
 description To VOIP
 encapsulation dot1Q 118
 ip address 10.213.118.2 255.255.255.0

service-policy output police_voice_policy

policy-map sub_int_qos

class voice

priority percent 5

policy-map police_voice_policy

class class-default

shape average 3000000

     random-detect dscp-based

service-policy sub_int_qos

what exactly is the shape command doing above, is it saying once we see 3Mbs of traffic to the subinterface that its congested and we then apply the QOS service police saving 5% of the 3Mbs? 

Does this mean we potentially have 17Mbs coming in to the main GigE and 3 to the suninterface ?

When the subinterface has more than 3 Mbps, it will queue the excess rate.  When less than 3 Mbps, it will dequeue any previously queued packets.

When it dequeues traffic, any traffic queued in the priority (voice) class will be dequeued first.

(For most CBWFQ platforms) When the overall traffic rate exceeded 3 Mbps, traffic in the voice class that exceeds 5% of the 3 Mbps will be dropped.

If i use police instead of shape, is it basically the same concept,  using something like, police 3000000 375000 375000 conform-action transmit exceed-action drop violate-action drop.

No, it's not the same, as the policer in the parent policy will drop traffic.  Nothing will be queued.

Do I want exceed action to drop?

Depends on what you're trying to accomplish.

[paul amaral]

Joseph, thanks for the reply.

I notice i had to remove random-detect dscp-based as it would not let me apply the service policy also. I have enabled the config above and it looks to be working fine, however im still confused on a couple of things.

"When the subinterface has more than 3 Mbps, it will queue the excess rate.  When less than 3 Mbps, it will dequeue any previously queued packets."

So shaping will smooth out traffic at 3 megs and if the extra access happens to be voip packets it will queue those also but dequeue them 1st when its time?

"(For most CBWFQ platforms) When the overall traffic rate exceeded 3 Mbps, traffic in the voice class that exceeds 5% of the 3 Mbps will be dropped."

I increased this to 90%, shouldn't shaping queue excess packets and always guarantee 90% for voice.

thanks again paul

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

"So shaping will smooth out traffic at 3 megs and if the extra access happens to be voip packets it will queue those also but dequeue them 1st when its time?"

Correct.  Basically a shaper tries to emulate an interface of the same bandwidth.  So if you had a true 3 Mbps interface, transmission will never exceed 3 Mbps, and queuing depends on how fast the data arrives at the interface.

"I increased this to 90%, shouldn't shaping queue excess packets and always guarantee 90% for voice."

A priority (LLQ) class, will implicitly police "too fast" class traffic, and will also be dequeued first.

Cisco recommends you don't exceed 1/3 for LLQ.  This to insure there's sufficient bandwidth for other traffic, but also if you really need 90% for something like VoIP, you might have insufficient bandwidth.  Once you get somewhere above half, you start to increase the changes you'll queue in the LLQ itself.  LLQ guarantees it's dequeued before other traffic classes, but, again, that doesn't help for the class itself.  (Much like if the whole link was devoted for VoIP.  Much depends on the VoIP codec being used; some require a bandwidth cushion.)

[paul amaral]

thanks for the follow up.