QoS Class Map VOIP Violated Packets

[adnane dakna]

                   Our Clients encountered somes problems with VOIP traffic under MPLS network , when I take a look at class Map used to match VOIP trafic , I found the below result:

Class-map: VOIP (match-any)

      443351169 packets, 50088114649 bytes

      5 minute offered rate 1144000 bps, drop rate 0 bps

      Match: ip dscp cs5 (40)

        0 packets, 0 bytes

        5 minute rate 0 bps

      Match: ip dscp ef (46)

        443351169 packets, 50088114649 bytes

        5 minute rate 1144000 bps

      Police:

        4168000 bps, 130250 limit, 0 extended limit

        conformed 438934020 packets, 49227706074 bytes; action:

        transmit

        exceeded 0 packets, 0 bytes; action:

        drop

        violated 4405250 packets, 858568744 bytes; action:

        drop

      Priority: Strict, b/w exceed drops: 0

I need to understand what can cause the violated Packets

Best Regards.

[Rejohn Cuares]

Traffic that has a tagged of EF is violating the traffic. This doesnt mean it's all voice. I suggest running NBAR to identify what traffic passing through the router.

Sent from Cisco Technical Support iPhone App

[adnane dakna]

what you mean by tagged of EF

[Wantser1981_2]

Can you provide a copy of the configuration of your map?

When tagged EF is mentioned, this means DSCP marked. So effectively your trust boundary is pushed out elsewhere and you are allowing all EF marked traffic into this queue. VoIP handsets usually mark their RTP traffic EF and this is then trusted through the network. Issue with this is, if you have some other service or server marking traffic inside this trust boundary, the EF queue will also be used to transmit this traffic.

So this looks to me that you are having your queue overrun by either poor sizing, or the fact that this is not all RTP traffic. The 5 min rate on your interface suggests an average 17ish calls for the five minute period using a G711 codec or around the 65ish using G729. Does this sound right? The suggestion of NBAR or maybe even netflow to verify what is in this queue or rather hitting the router with EF tagged traffic would be a good idea.

The voilation is effectively the third choice token bucket if your config allows you to reach it. There is no configurated bytes allocated in your violation bucket so any traffic reaching this third choice will be dropped. Be good to take a look at what you have set up.

Cheers

[adnane dakna]

Thanks for your answers ,(the link is 3 E1 multilink bundle )  the config of our map is :

!

class-map match-any VOIP

match access-group name VOIP

class-map match-any NETWORK-CONTROL

match access-group name NETWORK-CONTROL

class-map match-any CRITICAL-DATA

match access-group name CRITICAL-DATA

!

!

policy-map MULTIMEDIA-PLUS-6M

class NETWORK-CONTROL

  bandwidth percent 1

  random-detect dscp-based

  random-detect dscp 16 4 11 1

  random-detect dscp 48 11 33 1

class VOIP

  priority percent 70

  police cir percent 70

   conform-action set-dscp-transmit ef

class CRITICAL-DATA

  bandwidth percent 20

  random-detect dscp-based

  random-detect dscp 26 512 1536 1

  random-detect dscp 28 154 512 1

  police cir percent 20 bc 250 ms

   conform-action set-dscp-transmit af31

   exceed-action set-dscp-transmit af32

class class-default

  bandwidth percent 9

  random-detect dscp-based

  random-detect dscp 0 52 171 1

  set ip dscp default

!

!

class-map match-any VOIP

match access-group name VOIP

class-map match-any NETWORK-CONTROL

match access-group name NETWORK-CONTROL

class-map match-any CRITICAL-DATA

match access-group name CRITICAL-DATA

!

!

policy-map MULTIMEDIA-PLUS-6M

class NETWORK-CONTROL

  bandwidth percent 1

  random-detect dscp-based

  random-detect dscp 16 4 11 1

  random-detect dscp 48 11 33 1

class VOIP

  priority percent 70

  police cir percent 70

   conform-action set-dscp-transmit ef

class CRITICAL-DATA

  bandwidth percent 20

  random-detect dscp-based

  random-detect dscp 26 512 1536 1

  random-detect dscp 28 154 512 1

  police cir percent 20 bc 250 ms

   conform-action set-dscp-transmit af31

   exceed-action set-dscp-transmit af32

class class-default

  bandwidth percent 9

  random-detect dscp-based

  random-detect dscp 0 52 171 1

  set ip dscp default

!

[Wantser1981_2]

Okay,

Looking through these figures etc I have noticed the normal burst value that has been calculated by the device. This doesnt seem to conform to the normal calculation and is reflected in you throughput figure

    5 minute rate 1144000 bps

      Police:

        4168000 bps, 130250 limit, 0 extended limit

So you have set 70% for VOIP, which has configured 4168000bps (4Mbps). The burst that the device has configured for you is 130250bytes, which caluculates as 1.114Mbps. Which incidently is very near your five minute rate.

So what I think is happening is; you are experiencing is a larger amount of traffic than your conform policer can handle which is being calculated based on a percentage of your bandwdith. It has allocated 4Mbps. However, the burst size or rather the size of the bucket with space to conform is only allowing enough space to pass about 1Mbps. Everything else is dropped because have no exceed allocation also. As soon as you use the 130250bytes of the conform "queue" packets are considered violated as they cannot use any of the conform or exceed space (conform used up, no extended/exceed availability). As the exceed  has no value, you look to be being passed straight to violate (you cannot use 0 of the exceed bucket to register against exceed).

You also have a priority and policer setup against the EF traffic. Use one or the other I would suggest as to police a priority queue defeats the object. I cant remember which will be used as I dont tend to use is this way and also I dont tend to allow the device to determine my queues, but either way you will violate the rate and be droped as no exceed space is configured. It looks to be placed in the policer as your priority value is 0.

So you need to be sure about the traffic that is getting into this queue first if you wish to keep the configuration as it is. NBAR/Netflow etc. Then investigate your trust boundary maybe. You could then maybe look at a better queuing based on network flow diagnostics. If all valid VoIP traffic, you might want to look at lowering the codec (if not already done), other wise you could be looking at a need to upgrade the bandwidth.

I would look at changing your queuing methodology away from percentages and calculating the queue sizes against your known available bandwith and ensuring you are allowing the room for the required traffic to pass. Still would be best to do the traffic discovery to ensure your policy is valid.

I hope that makes a little sence - summary is, your EF queue doesnt look to be big enough and you are not recieving the CIR you think you have configured (configured 70% bandwidth=4Mbps, actuall 1Mbps due to calculated queue limit 130250btyes = 1.042Mbps). But you want to make sure that only desired traffic is consuming the bandwidth.

Wantser

[adnane dakna]

Many thanks for you answer, I will follow theses steps to understand what happening

[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

I need to understand what can cause the violated Packets

Traffic being received faster than the policer will allow (ditto for "exceed").

Why there's "too fast" traffic, could be too much traffic (i.e. many multiple flows) or some (even one) flows transmitting very quickly or some combination of both.  You would need to do traffic analysis to further identify cause.