04-19-2016 08:18 AM - edited 03-05-2019 03:50 AM
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!
Solved! Go to Solution.
04-20-2016 06:13 AM
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.)
04-19-2016 10:21 AM
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.
04-19-2016 01:28 PM
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
04-19-2016 02:46 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 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.
04-20-2016 12:20 AM
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
04-20-2016 06:13 AM
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.)
04-20-2016 06:26 AM
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
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