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 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
priority
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
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âŚ
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:
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:
Reduce the police CIR and PIR to smaller values and see if you get exceeding and violating counts
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!
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.
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?
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:
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.
Hello,
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
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 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?
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:
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âŚ
Whats the difference between policing with the priority and police command and the prioritypolicy-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.
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.
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.
