Traffic Policing

Question

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 10.0.0.0 and 10.0.1.0 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 10.0.0.0 0.0.0.255 10.0.1.0 0.0.0.255
 permit ip 10.0.1.0 0.0.0.255 10.0.0.0 0.0.0.255
!
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?

Answer 1

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

Answer 2

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.

Answer 3

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.