b/w exceed drops for voice traffic

Gentry · ‎03-14-2013

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?

Joseph W. Doherty · ‎03-14-2013

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.

Gentry · ‎03-15-2013

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

Joseph W. Doherty · ‎03-15-2013

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.