Breaking a Shaper?

[wilson-danny]

Hi Everyone,

This may / may not be a simple question.

In an MPLS enviroment we use shaping on a part bearer to throttle bandwidth to the ISP specified amount, but we still are having issues.

So what we did as a secondary method was to wrap a policer around the shaper a couple of MB higher, to see if we were oversaturating the shaper. Please note that the inbound of the ISP has a policer, so if we try to send more traffic than the designated link is capable of it just get's dropped.

We use a shape-average policy with a router calculated load interval / final burst set to 0.

My question is, if you saturated a link by a large amount could you break the shaper?

Or is the policer getting in the way of the shaper and should be removed?

[wilson-danny]

Anyone?

[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

It might help if you could elaborate on your "issues".

That noted, two common issues when dealing with a provider policing include: whether they (and you) account for L2 overhead or not in the nominal bandwidth and what kind of Tc is being used.  If you and your provider are different, you can encounter "unexpected" drops.

Less common, provider isn't providing what they ought (usually due to a misconfiguration error on their part).

Very uncommon, you or provider has an underlying issue that's difficult to detect and isolate.  (Once I had to badger a tier 1 provider for 3 months that a policed MPLS circuit wasn't quite right.  They finally found problem was caused by buggy firmware on a line card on one of their devices.)

[wilson-danny]

What's with the Disclaimer ? LOL

Sorry, moving on.

The issue is dropped packets, the wan is being saturated.. This being a part bearer a shaper is needed, the ISP runs over Sonnet so we have already accounted for this by setting the CIR of the shaper to 85% of the total amout of the link.

The policer is a couple of MB's above the shaper.. Reason as stated we did this was due to the ISP dropping packets and we wanted to catch it first.

So e.g. 10MB link, we would set the shaper to 85% and the policer @ 12MB. On DS3's we don't have any problems because it's not a part bearer. It's only links that are ethernet that we have to shape.

We are hitting the policer and I was thinking due to the shaper this should never happen, only starts in times of extreme stress E.g. 30MB trying to go down a 15MB link.

Obvious thing is to upgrade the bandwidth, but for this purpose I am asking.. Can you run up the buffers on the shaper that the router can no longer take it?, can packets exceed the shaper and hit the policer?

[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

"What's with the Disclaimer ?"

That's due to the Cisco's user agreement.

Yes, I understand the situation of needing to shape for logical bandwidths when you don't congest on the physical interface.

I'm unaware of a shaper being unable to shape as needed.  As to your, or the provider's, policer seeing traffic above the shaped valued, I wouldn't expect too much conflict unless they're using different parameters besides the nominal rate although its also possible if shaper and policer are not synchronized (as would normally be the case) and they would treat the same traffic differently.

Consider both shapers and policers, when they measure at some nominal rate, are really counting overall usage during some time period (Tc).  So, for example, transmitting continuously on a 100 Mbps for 10 ms, but only 10 ms, is considered 100 Mbps during that 10 ms but only 50 Mbps for 20 ms or 10 Mbps for 100 ms.  If your nominal rate is only 10 Mbps, a policer would discard all packets if it measures on a 10 ms or 20 ms Tc.  Even if the policer measured on a 100 ms Tc, if its timing periods aren't aligned with the shaper's, it could count the tail and beginning of a two shaper Tcs into just one policer Tc, and discard half the packets.

If this is the issue you're bumping into, try setting your shaper's Tc to minimum value, which I believe can be 4 ms.  Also try to find out the Tc your provider is using.  Ideally, the provider's policer should have a considerably larger Tc than you're using.  This allows them to measure/enforce a longer term "average" rate, but without clipping short duration bursts.  (NB: often default policer values clip short term bursts, and TCP flows especially, don't reach nominal bandwidth.  Similar results would be seen on a physical interface with a too small queue.)