03-14-2013 04:07 PM - edited 03-04-2019 07:18 PM
Hello. I just need some confirmation on exactly what 'b/w exceed drops' means from a 'show policy-map interface' output.
Consider this scenario:
class-map match-any SIGNALING
match dscp cs3
match dscp af31
class-map match-any DROP
match protocol bittorrent
match protocol edonkey
match protocol gnutella
match protocol kazaa2
match protocol irc
match protocol vdolive
class-map match-any CRITICAL
match dscp cs2
match dscp cs6
match dscp af21
match dscp af22
match dscp af23
class-map match-any VOICE
match dscp ef
match protocol rtp
policy-map QOS
class VOICE
priority percent 50
class SIGNALING
bandwidth percent 5
class CRITICAL
bandwidth percent 5
class DROP
drop
class class-default
fair-queue
random-detect
interface Serial0/0/0:1
service-policy output QOS
Why am I getting b/w exceed drops for the priority queue??
#sh policy-map int s0/0/0:1
Serial0/0/0:1
Service-policy output: QOS
queue stats for all priority classes:
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 228024/66725091
Class-map: VOICE (match-any)
410887 packets, 104055512 bytes
5 minute offered rate 608000 bps, drop rate 0 bps
Match: dscp ef (46)
0 packets, 0 bytes
5 minute rate 0 bps
Match: protocol rtp
410887 packets, 104055512 bytes
5 minute rate 608000 bps
Priority: 50% (768 kbps), burst bytes 19200, b/w exceed drops: 44 <----------------------------------
I assume that any traffic marked dscp ef or rtp is exceeding 768kbps and since the priority queue is policed then it drops the excess?
Aside from increasing the priority percent for the voice class (50 seems high enough as it is) what can I do to prevent voice traffic from ever being dropped?
03-14-2013 06:15 PM
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
Why am I getting b/w exceed drops for the priority queue??I assume that any traffic marked dscp ef or rtp is exceeding 768kbps and since the priority queue is policed then it drops the excess?Aside from increasing the priority percent for the voice class (50 seems high enough as it is) what can I do to prevent voice traffic from ever being dropped?
I believe your assumption is correct. Also you have a 5 minute average of > 79% of your logical cap, i.e. possible short term transient burst causes drops. 44 drops over 410,887 packets should be benign, even for VoIP.
The way to preclude VoIP drops is to insure the traffic always has the bandwidth it desires.
Increasing the LLQ bandwidth may decrease your current drops, but you're already at 50%. Cisco recommends not exceeding 33% to allow sufficient bandwidth for other apps. If that's not important to you, you could allocate 99%, but also suggest average LLQ usage doesn't exceed about 66% link bandwidth. This to insure your LLQ traffic doesn't queue against itself.
03-15-2013 11:53 AM
What suggestions do you have for insuring voice traffic always has the bandwidth it desires?
My thoughts were to:
1. Change codec to g711
2. Layer 2 compression
3. Bigger pipe
03-15-2013 07:59 PM
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
To truly guarantee bandwidth for VoIP, you need call admission control (i.e. some way to bound the number of concurrent active calls) and guaranteed path bandwidth to support the allowed maximum number of calls. If using a codec like g711, bandwidth guarantee is the maximum number of concurrent calls times bandwidth per call. If using a codec like g729, you'll want bandwidth guarantee for maximum possible bandwidth per call times the maximum number of concurrent calls. (Note: maximum bandwidth guarantee for a variable rate codec's worst case might not be much better than the bandwidth for a fixed rate codec however the variable rate should average less bandwidth usage freeing bandwidth for other traffic.)
PS:
BTW, you don't need call admission if you "know" maximum calls that transverse your link paths.
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