QoS Policing Configuration Example

Hello Adam

So if you would like to provide a hard limit of 50Mbps, then use the single rate two colour approach. This would require the following police configuration:

police 50000000
conform action transmit
exceed-action drop

This will allow all traffic under 50Mbps to go through, but if the traffic reaches above 50 Mbps, all exceeding packets will be dropped. No BE, no bursting capability, no tolerance to this level.

You would use the value that you desire the traffic to confirm to. This will also depend on the speed of the link to your ISP as well. There’s no sense in limiting Wi-Fi traffic to 50Mbps if your ISP connection is 30 Mbps. It depends on what you want to achieve, on what your network requirements are and on what the profile of your network traffic is.

Whenever you’re traffic shaping, especially to control traffic going to the ISP, a good rule of thumb is to use values as percentages of the total bandwidth that is available to you. In your previous scenario, you wanted to limit Wi-Fi traffic to 50 Mbps out of the 200Mbps ISP link, that is, one quarter of the ISP link. Look at the traffic generated by each network, see what their requirements are and how mission critical they are, and allocate the appropriate fraction of the total ISP bandwidth to that network.

Now one more thing that we may need to clarify is that policing and shaping are two different things. Policing will drop packets that exceed the set thresholds while shaping will attempt to store exceeding packets into queues or local memory to be sent as soon as bandwidth becomes available. In this lesson, it is policing that is being discussed and implemented. For traffic shaping, take a look at this lesson:

I hope this has been helpful!


Good Day Laz,

Thanks for clearing interface vs provider selection for QoS. The configuration guidance you provided gave the desired result. Thanks Again !!!


1 Like

I need some assistance working out how the police cir was calculated?
Here is a part of the config
the shape average is 94 percent of the offered data rate

policy-map ISP
 class real-time
  police cir 4096000
   conform-action set-dscp-transmit ef
   exceed-action set-dscp-transmit af41
   violate-action set-dscp-transmit af41
 class video
  bandwidth remaining percent 40............ 

policy-map 65.8Mbs
 class class-default
  shape average 65800000   
   service-policy ISP
policy-map MM
 class real-time


Hello David

There doesn’t seem to be a direct correlation between the policy map values of 94% of the offered data rate and the police cir that is configured in the policy-map ISP. Some general statements I can make about this based on the information you have given are the following:

  • The offered data rate is 70 Mbps
  • This offered data rate is shaped to an average of 65.8 Mbps
  • Of that shaped average, 4.096 Mbps are policed and this is a maximum bandwidth guarantee due to the priority keyword
  • In the event that there is traffic that exceeds or violates this CIR, the traffic is actually transmitted - so no packets will be dropped due to the CIR, but DSCP values may be adjusted accordingly
  • The remaining bandwidth that is made available is 65.8 Mbps - 4.096 Mbps = 61.704 Mbps
  • 40% of this bandwidth is made available to the class video which is 24.6816 Mbps, but traffic is allowed to exceed this allocated rate

Now the 4.096 Mbps data rate may have to do with the maximum number of real-time data streams that are to be transmitted depending on what traffic is being matched. If you are matching voice conversations using the G.711 codec which allows for 64 Kbps bandwidths per conversation, then 4096 Kbps / 64 Kbps = 64 conversations.

It comes down to what traffic is being matched in the real-time class map and how much of that traffic do you want to allow using the specified CIR before beginning to change the DSCP values on all exceeding/violating traffic…

I hope this has been helpful!


Hello guys,
I just wanted to point out that I labbed the three examples
1)Single Rate two color
2)Single Rate three color
3)Dual Rate three color

and all of the packets conformed. I did not have any exceed or violate.
I used the exact code provided in the example. Did I do anything wrong? I am attaching my running configuration:


Hello Martha

At first glance, your code looks good. If you’re sure that your pings are indeed traversing the link between the two routers, then the only other thing I can think of is that the rate at which the pings are being sent are not fast enough to reach the thresholds that you are setting. This could be due to the GNS3 setup, the CPU capabilities and other resource issues. I suggest you do one of the following:

  1. Reduce the police CIR and PIR to smaller values and see if you get exceeding and violating counts
  2. Use extended ping command to increase the size of each ping so that more bytes are being sent per ping.

Try one or both of those, and let us know your results!

I hope this has been helpful!


I need to try this again. Will let you know once I lab again.

1 Like

Hi all,

The police rate mentioned in the below class-map applies to the entire bandwidth or the bandwidth allocated to that queue?

In other words, if I have 100 Mbps circuits, the policing mentioned here will be 40% of the 100 Mbps or 2.X % of the 100 Mbps?

Any comments will be appreciated.

class TEST123
  bandwidth percent 5
  set ip dscp cs1
  random-detect ecn
    police cir percent 40
     exceed-action drop

Hello bhaskar

When using the police cir percent X command, the maximum rate of bandwidth available is used as the reference point for the calculation of the percentage. The maximum rate of bandwidth available is defined either as the bandwidth of the interface itself, which in your example is 100Mbps, or by the amount specified in a parent policy map, if the policy map in question is nested within another policy map.

In your particular example, the bandwidth percent 5 command that has been used in the same class does not represent the maximum rate of bandwidth available. So the policy will look to the next higher level, which in this case is the bandwidth of the interface itself to use as the reference for the calculation of the percentage.

You can find out more information about how this command behaves at this Cisco command reference documentation.

I hope this has been helpful!


Hi, what is the maximum number of sub policy maps? meaning, if I configure policy 1, inside policy 1 I put (service policy 2), inside policy 2 I put (service policy 3), etc. what is the limit?

Hello Mohanad

Policy maps within policy maps are called nested policy maps, and are often used when implementing QoS. Such a configuration is called Hierarchical Modular QoS and can typically be configured with two- or three-level queuing policies. You can find information for two and three level QoS in the following documentation:


According to Cisco:

Hierarchical QoS allows you to specify QoS behavior at multiple policy levels, which provides a high degree of granularity in traffic management.

Now configuration wise, there is no restriction as to how many levels of nested policy maps you can have. Needless to say, the more levels, the more complex the configuration becomes. Generally speaking, more than three levels are not really needed, as the level of granularity is more than sufficient for most applications.

However, some platforms may have restrictions as to how they interpret such hierarchies as far as QoS goes. For example, a three-level hierarchy configuration will be rejected on an ASR9000 if the top-level class has queueing actions but the middle or bottom level class do not.

I hope this has been helpful!


1 Like

when i tried to apply your configuration on physicale inteface on my switch i have this error:
Only markdown with a table-map is supported

The configuration is:

class-map match-all TEST
 match access-group 100
policy-map TEST2
 class TEST
  police cir 20000000
   conform-action transmit 
   exceed-action set-dscp-transmit default
   violate-action drop 

Any solution?

Hello Valerio

It seems that you are running into a particular error message that is unique to Cisco Catalyst 3850 switches. I assume that is what you are using? According to this Cisco documentation that specifies particular QoS error messages that appear on the 3850, this configuration requires a table map. Specifically, the restriction is described like so:

A table map is needed when trying to change the DSCP/COS/IPP value dynamically by means of a policer whenever the rate is exceeded.

The Cisco link above also indicates a workaround. Keep in mind that this seems to be related only to the specific series of switches, and is not applicable to other platforms.

I hope this has been helpful!


I have been trying to understand the difference between a single rate three color and a dual rate 3 color. It seems like the difference is the bc and be are seperate in a dual rate 3 color.

I imagine you could create a situation where single rate 3 color acts the same as dual rate 3 color.
Are there any meaningful differences?

Hello Justin

The main difference is the parameters used for each. Single rate three color uses the following parameters:

  • Committed Information Rate (CIR) which is the average traffic rate a customer is allowed to send traffic at.
  • Committed Burst Size (Bc) which is the maximum amount of contiguous packets that a customer can send in a single “batch”.

There is only one rate defined here, which is the CIR of 128000 bps in the lesson’s configuration. From this single rate, the Bc is calculated internally by the device. Thus, there are three colors, which are green for anything under the CIR, yellow for anything between the CIR and CIR+Bc, and red for anything above CIR+Bc. These colors come from the way the mechanism is defined in RFC 2697.

Dual rate three color uses the following parameters

  • Committed Information Rate (CIR) which is the average traffic rate a customer is allowed to send traffic at.
  • Committed Burst Size (Bc) which is the maximum amount of contiguous packets that a customer can send in a single “batch”.
  • Peak Information Rate (PIR) is an additional parameter that defines the maximum average sending rate for the customer. Traffic that exceeds the CIR but is less than the PIR is still sent but is marked for more aggressive discarding.

In this case, there are two rates defined, the CIR and PIR. Anything that is between the CIR and PIR is transmitted, but the markings on such traffic are changed so that downstream, they can be considered to be of a lower priority by any other QoS mechanisms that may act upon the packets.

Theoretically, you can configure the PIR to be identical to the Bc and thus have the same result as a single rate configuration, but the configurable PIR gives you more control over the operation of the QoS feature.

For more info about both of these mechanisms you can take a look at the RFCs:

I hope this has been helpful!


have we answered this post? @ReneMolenaar

Hello Abishek

In order to apply shaping, you’ll need to create an access list a class map and a policy map. The details of how to do this can be found in the following lesson:

Although this is a six-year-old post, thanks to @rkvignesheee for pointing it out…

I hope this has been helpful!


Hello, I have a question regarding the following commands:

Whats the difference between policing with the priority and police command and the priority policy-raste-in-kbps. From my understanding if we use the priority and the police command we use the LLQ regardless if we experience congestion or not. With the other command we’d only police and use the LLQ during times of congestion.

Thanks in advance!

Hello Mirko

For the most part you are correct in your understanding. Here’s an overview of the differences involved:

Policing with the priority and police command:

  • This method sets up an LLQ strict priority queue.
  • The priority command itself enables LLQ for the class of traffic to which it’s applied, ensuring that traffic is given preferential treatment.
  • When you combine the priority command with the police command, you are explicitly setting a rate limit for the priority traffic. This is recommended to prevent the priority queue from consuming all available bandwidth and starving other queues.
  • With this configuration, the policing is always in effect, regardless of whether the network is experiencing congestion or not. This means that the priority traffic will always be limited to the configured rate.

Policing with the priority police-rate-in-kbps:

  • This configuration also sets up LLQ for priority traffic.
  • However, the policing in this case is conditional—meaning it’s only in effect during times of congestion.
  • When congestion occurs, traffic exceeding the configured rate in kbps will be policed down to the configured rate.
  • If there is no congestion, the policing doesn’t take effect, and the priority traffic isn’t rate-limited.

The main difference is that with the priority command combined with the police command, the priority traffic is always subjected to the configured rate limit. In contrast, with the priority police-rate-in-kbps command, the rate limit only applies during periods of congestion. This means that in a congestion-free scenario, priority traffic could potentially use more bandwidth than the rate specified in the priority police-rate-in-kbps command.

I hope this has been helpful!


Hello, everyone!

I have a question about this

Isn’t the BC the maximum capacity of the bucket? If so, shouldn’t it be 16,000 bytes instead? Because 128,000 bits / 8 = 16,000. The OCG says to divide the CIR by 32 but I don’t understand why.

Thank you in advance for your help.