I know traffic policing isn't something that you normally find in a LAN environment, and I wish I wouldn't be finding it in mine. That being said... I have no choice.

The device is a 3750X. The requirement is to POLICE (not shape) all traffic coming to/from the and networks to a MAXIMUM of ~48Mbps. Below is the configuration I've come up with. Whatd'ya reckon? Also, I know I should probably have this configured on the inbound interface, but that's a whole 'nother story...

ip access-list extended acl-police
 permit ip
 permit ip
class-map police-san
 match access-group name acl-police
policy-map police-san-replication
 class police-san
  police 47000000 10000 20000 conform-action transmit exceed-action drop

interface <outbound>
service-policy output police-san-replication

One other thing... Can anyone explain to me the "burst-normal" & "burst-max"? Is this allowing it to burst above the police limit (bps) that I defined? What are the timer thresholds for that? Should I configure these burst numbers smaller? Larger?

  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Dec 20 '20 at 18:28

I would use vlan-based policing which works better on these switches. This is an example matching a speed value of 48Mb

mls qos
interface GigabitEthernet1/0/2
 switchport access vlan 500
 switchport mode access
 mls qos vlan-based
class-map match-all CUSTOMER_1
 match input-interface  GigabitEthernet1/0/2
policy-map VLAN500_POLICE
 class CUSTOMER_1
  police 48000000 18000000 exceed-action drop
policy-map VLAN500_PARENT
 class class-default
  set dscp default
  service-policy VLAN500_POLICE
interface Vlan500
 service-policy input VLAN500_PARENT

Under the parent policy you have to 'set' something in order for it to work. This could be anything so in this example I'm simply setting the dscp to 0

  • Thanks so much for this, but I'm having a hard time following the logic here. Why have a two policy maps, nested? Is there a reason you can't simply apply the VLAN500_POLICE map straight to the Vlan SVI?
    – BrianK
    Jun 9 '13 at 8:37
  • The 3750 will not allow you to police until you have a software queue. In order to get a software queue you need a policy. Hence the need for the nested policy
    – mellowd
    Jun 9 '13 at 9:03

Your burst values look a bit small. Choosing burst values is not easy and testing might be required to get it right. Also if I remember correctly 3750 does not support policing on egress.

Bc works a bit different in policing than it does in shaping. With shaping you buffer packets and you have a token bucket where ever Tc (time interval) you have Bc (Commited Burst) bytes added to the bucket. The formula is Tc = Bc / CIR. On some platforms Tc is fixed as well so you don't have the option of configuring it.

When you use policing you don't use fixed time intervals. Instead when packet arrives policer calculates how many bytes have accumulated. So say that you are policing at 10 Mbit/s. You have configured a Bc of 10000 bytes. A burst packet arrives at t0 that make up 5000 bytes of traffic. So 5000 bytes are deducted. Then at t1 5 ms later another batch of 5000 bytes of packets arrive. The policer is set 10 Mbit/s, which is 1250000 bytes per second. That means that 1250000 * 0,005 = 6250 bytes have been added to the 5000 that were left from the first run at t0. So the packets are allowed through.

From this example you can see that at t1 it could have been allowed to send 5000 + 6250 = 11250 bytes but because Bc was set to 10000 bytes the policer would drop anything above that. What if 6000 bytes of packets had arrived? Then some packets would have to be dropped. This is where Be comes into play. Be will allow to accumulate some extra credit from idle intervals. So if Be had been configured to be 20000 bytes then the 6000 bytes could have been passed through the policer.

Be adds a bit of fairness to the policer but it also allows bigger bursts of traffic to go through. Remember that in the end the CIR is still enforced so on average it's not possible to send more than CIR.

This article from Juniper recommends setting burst to 5ms worth of traffic which in your case would be 6250000 bytes.

  • Please note that, even if the Bc = Tc \ CIR formula is valid on every recent Cisco platform, Tc tends to be a fixed value on most of the Catalyst boxes. Ie. is 0.25 ms on C6500 while is 0.125ms on C3750, ecc... Jun 7 '13 at 8:09

I don't think egress policing works on this platform, but you'd need to use SRR, and frankly shaping is always preferable when possible.

Enabling 'mls qos' willy-nilly on 3750 can be recipe for disaster, the defaults are horrible, e.g. EF gets policed at 4%. So you should at least read:

  1. How to maximize available buffers
  2. Cisco Catalyst 3750 QoS Configuration Examples
  3. Configuration Guide

For ingress your suggested config should work.

I'd like to offer some additional thoughts on dimensioning your CIR buffer, I know that traditional Cisco CCO lore talks about RTT, but RTT actually has nothing to do with policer, as your router/switch does not care how long packet has been in-flight when it arrives. What is of key importance is rate of ingress interface, as ingress interface physical rate determines how fast your 'bucket' is being filled and policer rate determines how fast it is emptied.

JNPR formula (burst_time * interface_rate) is quite useful rule-of-thumb, so if you have 10G ingress interface and you have 1Mbps egress policer on interface A and 100Mbps egress policer on interface B, both [AB] policers should have same CIR buffer, say 10G * 5ms to handle 5ms burst, just tune the time to fit the burstiness of your traffic profile.

I'm using 'CIR Buffer' liberally, as technically policing adds no buffering outside from your normal interface buffers. It just means how many bytes will be send out, without applying policer. This is needed, as otherwise each single packet would exceed policer rate and observable rate would be 0.

  • Why would both policers be the same CIR when you're policing to different egress rates on A & B? Jun 7 '13 at 9:11
  • 3
    Not same CIR rate, but same CIR buffer. As you use the buffer to catch bursts, as incoming rate is not 100Mbps or 1Mbps, incoming rate is always 10Gbps. Much like if your router has physical interfaces of only 10G it needs little buffers, if your router has physical interface of 10G and 10M, it needs lot more buffers.
    – ytti
    Jun 7 '13 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.