"Have you tried srr-queue bandwidth shape?"

I have not.  I'm kind of winging it and I'm not exactly sure how to define the individual queues.

"How did you chose your policer's burst size?  I compute it as a Tc of 58.6 ms, which seems a little long."

I was under the impression that calculating TC is only necessary when using a policer, cir, bc, and be rates?  If this is not the case, I would definitely appreciate some expanded information.

srr queue bandwidth limit 50, for example, is on two interfaces on the same 3750.  One, a customer, it doesn't work on.  The other, for testing, it works great.  At the moment I assume that maybe since iPerf is an extended burst of traffic and the customer is not, srr queue is queuing the test interface correctly and not the customer.

I'm using "police rate 54600000 bps burst 400000 bytes" under the impression that the rate lets me define the amount of bandwidth to use (in bits) while burst (in bytes) is the allowance over that bandwidth.

Thank you very much for your reply.

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 have not.  I'm kind of winging it and I'm not exactly sure how to define the individual queues."

Yes, that can be complex although in your case, if all the packets are marked the same, all packets should go to same queue, and only it would need to be configured to shape.

"I was under the impression that calculating TC is only necessary when  using a policer, cir, bc, and be rates?  If this is not the case, I  would definitely appreciate some expanded information."

Whether you need to calculate Tc depends on your policer requirements.  Usually defaults are either 4 or 25 ms.  Did you explicitly enter 400000, or did you leave it blank and the system provided it?

"I'm using "police rate 54600000 bps burst 400000 bytes" under the  impression that the rate lets me define the amount of bandwidth to use  (in bits) while burst (in bytes) is the allowance over that bandwidth."

No, burst sets the measurement period, indirectly.  It counts bytes (bits) for the against the specified rate.  Remember, physically, actually transmission is at media bandwidth.  What a policer does is measure how many bits are actually transmitted during some Tc and drop excess within that period.

How did you calculate TC for the police rate above?

I've tried multiple things today.  Essentially, we have our core network with upstreams to L3, Cogent, etc.  From our core we provide service to other ISPs, customers, etc.  I need to figure out a good method of limiting bandwidth egress/out to customers from our Core. 

What I have run into today again is that srr-queue bandwidth limit 50 is limiting both in and outbound traffic on my test circuit, but when ever I place that same limitation on a customer circuit, nothing happens.  I assume maybe srr queue limit is ingress only, but with iPerf doing bi directional traffic, limit works fine on test interface in/out.  So now I'm assuming that maybe because our customers burst often, srr queue may not be affecting traffic.  However, one particular customer regularly goes over the bandwidth they pay for and are limited too.

So, as far as srr queue limit goes, it simply doesn't work on a customer interface.  I've played around with multiple srr-queue shape/share numbers and those have no effect at all.  The only difference is that I kill all traffic on an interface before changing srr-queue settings where as I merely added srr-queue to customer's interface while they were still pushing traffic.

Testing with the shape command.

srr-queue bandwidth shape 5 5 5 5

This seems to be working where as 5 0 0 0 did not.  show mls qos interfaces queue shows that the int is in "queue set 1", which I assumed was the first digit.

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

Testing with the shape command.
srr-queue bandwidth shape 5 5 5 5 

This seems to be working where as 5 0 0 0 did not.  show mls qos interfaces queue shows that the int is in "queue set 1", which I assumed was the first digit.

The 5 5 5 5 would enable shaping on all 4 egress queues, equally each 20% (1/5).  5 0 0 0 would only shape on queue 1, others would be in share mode.

Queue set 1 is the default.  There's also a queue set 2.  Allows two different sets of some of the parameter to be selected for a port.  Can be useful if you want to treat edge ports differently from uplink ports.

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

How did you calculate TC for the police rate above?

400000 * 8 / 54600000 = 58.6 ms