ISR4331 - Packetdrops when Policing

[mihaly.szuhanics]

Dear All,

I have an issue with a nice ISR4331 - My issue is on VOICE class we have a company standards policing to drop all traffic above the requested BW. Our CIR is 32MB - since we started to use ISR routers we have issues with the Qos. The only class that we have an issue for now is the "ef" class that we use for voice.

As you see, we have 888K drop rate already at 11MB traffic

R1#sh policy-map int | s ce_ef_output
        Class-map: ce_ef_output (match-any)
          70585 packets, 43391968 bytes
          30 second offered rate 11242000 bps, drop rate 888000 bps
            Match: class-map match-any ce_ef_customer
              Match: access-group 1
          police:
              cir 32504000 bps, bc 30000 bytes, be 30000 bytes
            conformed 122862 packets, 79965966 bytes; actions:
              transmit
            exceeded 1121 packets, 1290074 bytes; actions:
              drop
            violated 4696 packets, 5475012 bytes; actions:
              drop
            conformed 10354000 bps, exceeded 148000 bps, violated 741000 bps

Config of the Class in the Policy-map

class ce_ef_output
  police cir 32504000 bc 30000 be 30000 conform-action transmit  exceed-action drop  violate-action drop

the Class map itself and the ACL

class-map match-any ce_ef_customer
 match access-group 184

ip access-list extended 1

permit ip any any dscp cs5

My question is, how come that there are drops under the CIR! The customer has a 150MB line, at the time of the test the line had 70MB traffic in overall.

In the Policy-map, the EF is the 2nd Class - first is the management class.

HW details:

ISR4431/K9 - isr4400-universalk9.03.13.04.S.154-3.S4-ext.SPA.bin

Any Ideas are welcome!

[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 wha2tsoever (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

My question is, how come that there are drops under the CIR!

Assuming the policer is working correctly, it's likely due to traffic above CIR during a Tc.

The customer has a 150MB line, at the time of the test the line had 70MB traffic in overall.

The policer doesn't care about line's bandwidth.  It only care about the traffic rate it's measuring.

Not knowing what you're trying to achieve, it's difficult to make suggestions, but increasing Bc might reduce the drop rate or use a shaper rather than a policer.

[mihaly.szuhanics]

Hi,

Thanks for the feedback, however as I wrote this policer is for voice service and company standard to use police and drop as violate action.

What we want to achive is to give the customer 25MB guaranteed BW for voice. If overused drop those packets.

But as you see the offered rate was only 11MB and the drop rate was already 888K

Where as drop rate should kick in above the CIR.

Best Regards 

[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 wha2tsoever (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

Again, assuming the policer is working correctly, it's likely due to traffic above CIR during a Tc.

The offered rated is calculated on a 30 second interval, the Tc is usually subsecond, often in the range of 4 to 25 ms.

[mihaly.szuhanics]

Hi,

the traffic was generated by a special tool used by the customer, generating a specific number of parallel calls.

According to the customer this 32MB should take 380 simultaneous calls. However, at 100 calls the drop rate starts to increase and the calls are failing.

On the old platform, using the same values for EF, the customer had no issues, only since ISR router is in place.

Best Regards

[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 wha2tsoever (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

On the old platform, using the same values for EF, the customer had no issues, only since ISR router is in place.

So you're saying the prior platform was configured the same?  Or, are you saying, the same test tool and same kind of traffic was pushed through a different device, with a different configuration, and the same issue wasn't seen?  If the former, if configs are really alike, and traffic alike, you might be looking at a IOS bug (on one of the two devices).  If the latter, you're comparing apples and oranges.

According to the customer this 32MB should take 380 simultaneous calls. However, at 100 calls the drop rate starts to increase and the calls are failing.

Without knowing exactly how the test tool generates traffic, cannot say whether the customer's assertion is correct or not.

Many don't well understand setting policing parameters.  Your issue might be as simple as the policer's values are not correctly set.  It's also possible, the policer isn't working correctly.  It's also possible, the customer's tool isn't properly configured to simulate 380 concurrent calls.  Insufficient information, to say.

Most likely, though, as I initially noted, the policer is properly enforcing the CIR during a Tc interval, which generally is a small fraction of a second.  If that's happening, you need to determine why CIR is being exceeded during a Tc.  (Often what needs to be done is just increase the Tc, but also don't know what SLA policy you're trying to enforce.)

[mihaly.szuhanics]

Hi,

I have counted the TC values for the current confog and I found that the Tc value was some 7.3ms which seemed to be too high. Compared with another sites using the same ISR series but different EF BW-s the Tc came out to be 4ms only.

I varied the Bc to fit into the calculation form and give me Tc 4ms - So no my tests were showing better results. Seems like the general config generation was not correct. 

Thanks for the good points on the Tc,  I have trusted the system generated values... which were incorrect. 

Cheers