QoS LLQ dropping packets

[mitchell helton]

Good morning!

I have a bit of a dilemma.  One of our remote sites which has a 10mb metroE circuit is dropping call signaling packets intermittently during periods of congestion.  I've spoken to multiple TAC engineers and their conclusion is we're bursting over the threshold.  Originally we had it set to 570kb and now it's bumped up to 1.1mb - and we're still dropping occasionally.  I just find this hard to believe.

This particular site is a small remote facility and only has 10-15 phones.  We also have another remote facility with a similar number of phones, a T1 link, and does NOT drop these call signaling packets.  I"ll attach our configs and a few screenshots.  I have used Cisco NAM for some reporting as well as Solarwinds NTA.  Most of our call signaling traffic is under 50kbps.  I just find it hard to believe that under any circumstance we're bursting above 570kbps let alone 1mbps.  Thanks folks!                

policy-map QosToDC

class voice

  priority percent 20

class voice-signaling

  priority percent 10

class critical-data

  bandwidth percent 41

  random-detect

class class-default

  bandwidth percent 25

  random-detect

policy-map ManageBWToDC

class class-default

  shape average 9500000

  service-policy QosToDC

class-map match-any voice-signaling

match ip dscp cs3

match protocol sip

interface GigabitEthernet0/1

bandwidth 10000

ip address 10.255.100.15 255.255.255.0

ip flow ingress

ip flow egress

load-interval 30

duplex full

speed 100

no cdp enable

service-policy output ManageBWToDC

[Joseph W. Doherty]

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

You're sure it's just your policy that's dropping, no drops by the provider?

Remember the kinds of bursts that can cause drops can be down at the millisecond level.  Often very difficult to "see" with normal monitoring.

You could try packet capture analysis to determine what's actually happening or you might try a couple of things to avoid the issue.  You might move the signaling traffic out of LLQ, as often LLQ isn't really required for signaling.  Or, you might combine your two LLQ classes into a single class (which other than policing is what's happening anyway) of combined bandwidths.

[mitchell helton]

Thanks for the reply, Joe.

No, I'm not sure it's just my policy that's dropping unfortunately.

The thing that bothered me about bursting... is if my traffic is typically under 50kbps, I can't fathom it ever bursting above 1mbps... even if for a split second.  That's what's bothering me.

I have already changed from priority to bandwidth on the call signaling, but I really wanted to understand why any of this was being dropped.  The weird thing is, the voice traffic (although it's being given around 2mbps) isn't dropping a single packet.

[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

Much depends on your VoIP equipment, but I have seen VoIP gateways "signally" involve mini-data replications between gateways.  Much more traffic in a brief burst then would be expected for pure call signally.  (This can be sort of like the differences between a DNS query and a DNS zone transfer, i.e. the former is what we routinely think of as "DNS" but the latter is "DNS" too.)

Did changing to ordinary bandwidth for signally resolve the issue?

[mitchell helton]

I really appreciate your help and your insight to call signaling.  Knowing that makes understanding this scenario much, much easier.

You're a great help - thanks again Joe.

Yes, that did resolve the issue btw.  But your explanation about call signaling was an even bigger help.