QoS Policing Configuration Example

Lessons Discussion
1

This topic is to discuss the following lesson:

2

It is a good post. In your example, pir is cir + Be, right ? what is pir meaning ? why do you choose pir as 256000 ?

3

Hi David,

Did you see this post?

This is where I explained the PIR. Let me know if it’s helpful ok?

Rene

4

Rene,
Great article. I can see you applied policy-map on R2 in the inbound direction.
What if we need to ping from R2 to R1 how can we then apply a policy map?
Do we need another policy-map with the same configs?

Hamood

5

Hi Hamood,

Policing can be applied in- or outbound. I applied it inbound on R2 so that we can police whatever we receive from R1. You could also apply it outbound on R2, this would police any traffic from traffic (behind R2) headed towards R1.

You can use the same policy-map in- and outbound.

Rene

6

Rene, great article, thanks for sharing your knowledge.

In the ISP world, if I have 25mb download and 1mb upload contract rate, will they be policing my traffic inbound on their premise? What about when I run a speed test, the results are coming from my gateway doing any policing or from the isp side?

Thanks,

Jose

7

Hi Jose,

The connection between the customer/ISP often offers a higher bandwidth than what you are paying for so yes, it’s very likely that all traffic is policed to enforce traffic contracts.

Rene

8

Hi Rene

Thanks for the configuration guide.

I was trying to figure out how Bc = 4000byte? If Bc is 4000 Byte, using the formula:

TC=BC/CIR

TC = (4000 * 8) bits / 128 000 bits
TC= 0.25s = 250ms

From previous note, mention default TC value is 125ms. Do I get my calculation wrong?

Thanks in advance

9

Policing doesn’t use a Tc “interval” like shaping does. The policer calculates the gap between packets to figure out how many tokens are in the bucket and figures out if the packet is within the policed rate or not.

CIR = the rate you want to police at in bits per second.
BC = size of the token bucket in bytes.

Let’s say we have a CIR of 128000 and a BC of 4000.

The police rate is 128kb/sec and the token bucket can store 4000 bytes * 8 = 32000 bits (32kb).

When we transfer at 128kb/sec then we empty the bucket for 16000 (128000/8) tokens per second. The bucket only holds 4000 tokens (or bytes) so that’s 1/4 of a second worth of tokens that we have.

Once the first packet arrives we put its amount of bytes in the bucket. When it’s a 1500 byte packet, we put 1500 tokens in the bucket. When the next packet arrives 50ms later then we remove 50ms of tokens from the bucket to see if the next packet will fit or not.

50ms at the CIR rate is 128000 / 20 = 6400 (There are 20x 50ms in 1 second).

The CIR is in bits so let’s convert it to bytes:

6400 / 8 = 800

These are 800 tokens which are removed from the bucket. That’s no problem as we have enough tokens in the bucket at this moment. Once we receive a packet and there are not enough tokens in the bucket, we are exceeding.

Hope this helps.

Rene

2 Likes
10

That’s fast!!

Well explained Rene!

Thanks

11

Hi Rene, thanks for the good content.

I understand why we need a single rate(two color) vs a single rate(three color) but I am just struggling with these questions:
-Why do we need the dual rate (three color)?
-Is there a case where we prefer one from another?

  • is one “better” the the other? (dual rate three color vs single rate three color)

Thanks man!

12

Juan Pablo,
The difference between a single rate three color (1-3C) vs a dual rate three color (2-3C) is more apparent when you compare the traffic rates between them over the long term.

1-3C
As the name implies, the 1-3C has just a single rate, the CIR. Your ability to send traffic at a rate higher than the CIR for a short time is only possible because you had NOT sent at the full CIR before–so you are allowed to “make up” the difference. Even though in some instances you can send traffic that exceeds the CIR, over the long run, the theoretic maximum is the CIR.

2-3C
Unlike 1-3C, it is possible to send a higher average rate than the CIR, even over a long period of time. This is possible because of the second rate, the PIR. The PIR will allow you to exceed consistently the CIR, but it is up to your service provider as to what happens to the traffic that goes above the CIR. The reason a provider would give you a 2-3C connection is because the provider knows they have enough excess capacity that their customers could send more data than their CIR allows, but maybe not all customers doing this at once. From the Provider’s point of view, the PIR is a sort of bonus incentive for you to sign up with them.

However, the provider needs to protect itself should all of their customers decide to max out the PIR rate. Usually providers will say something like, “we will guarantee your traffic up to the CIR will get such and such a priority, but anything above the CIR will be best effort only.” This means providers can throw away the traffic between the CIR and PIR should their network get saturated.

Which is Better?
If you were given a choice between a 1-3C and a 2-3C, go for the 2-3C. As long as you are okay with the possibility of excess traffic not making it through the provider’s network in all cases, you gain two benefits:

  1. The ability to send at a higher rate than the CIR over the long run (free data!)
  2. The ability to deal with very bursty or chatting traffic more predictably. What happens if your application really needs to send extra data, but your Be buckets are empty with 1-3C? Too bad for you! With 2-3C you at least have the possibility of your traffic getting through.

I hope that makes sense!

--Andrew

1 Like
13

Hi Andrew, thanks for the explanation.

I get it now, clearly the 2-3C have more benefits but it all depends of the ISP capabilities. And it makes sense because I have seen several ISPs with 1-3C configs and a few 2-3C, maybe these are some premium clients or something like that.

I will definitely try to get a 2-3C service from now on :smiley: (free dada is always welcome).

Regards,

14

Hi Rene/ Andrew,

Is the policy map can be apply to the switch access port, trunk port, and SVI?

Davis

15

Hello Davis.

Keep in mind that the QoS policing that Rene has implemented in this lesson functions at Layer 3. You can see this by the fact that the configuration applied matches layer 3 protocols (such as ICMP). So this means that this policy map can be applied to a Router interface, or to a Routed interface on a switch, or an SVI on a switch. Access and trunk ports are layer 2 so this implementation cannot be applied.

However, as Cisco documentation states, “To police bridged (Layer 2 [L2]) traffic as well, you need to enable bridged microflow policing.” If you’re interested in reading more, check it out here: http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/12493-102.html#parameters

I hope this has been helpful!

Laz

16

Hi Laz,

Thanks.

Davis

17

Hi Rene,

How can we validate the count of confirm/exceed/violate for a given CIR value. For eg , Single rate 2 color?

Can you pls provide an example?

Regards,
Ananth

18

Hello Rene,

Again a great article .
Is it correct way to read this example :

  1. customer can send 128K traffic without any issue but if it exceeds beyond 128, that is also allowed but with DSCP 0 (best effort). but then my doubt is - where is the limit on traffic , customer can send traffic as much as they want ?
  2. what exactly dscp 0 is doing here with traffic - can you just explain in a nut-shell please ?
  3. If customer has purchased 128K and with a burst up to 200K, what will be the below config ?
  4. Now as a customer, if I myself want to put policing on my outgoing interface , will same config work ?
R2(config)#policy-map SINGLE-RATE-THREE-COLOR
R2(config-pmap)#class ICMP
R2(config-pmap-c)#police 128000 
R2(config-pmap-c-police)#conform-action transmit 
R2(config-pmap-c-police)#exceed-action set-dscp-transmit 0
R2(config-pmap-c-police)#violate-action drop

Thanks
Abhishek

19

Abhishek,

  1. The answer this depends on whether we are talking about two color or three color. If you are talking two color with 128K or less being within policy, and the provider is allowing excess traffic but remarking it as DSCP 0, then yes, you have the ability to transmit up to whatever your physical link bandwidth would be. Of course, who knows what would happen to exceeding traffic later within the provider’s network–it might get dropped later if there is congestion elsewhere. This leads in to your question #2 …

  2. The purpose of remarking exceeding traffic as DSCP 0 is so the provider will know what traffic it can “throw away” first if the ISP network starts to get congested. Presumably, the provider has an SLA with you that says they guarantee traffic will flow through their network with a certain kind of higher level treatment for any traffic below 128 K. Once you exceed 128Kbps, however, that guarantee no longer applies. So how can the ISP distinguish between normal and exceeding traffic? That is the purpose of their policer that marks the traffic as DSCP 0.

  3. For 128K SLA with bursting to 200K, you would see something like this on the provider’s end:

R2(config)#policy-map SINGLE-RATE-THREE-COLOR
R2(config-pmap)#class class-default
R2(config-pmap-c)#police 128000 200000
R2(config-pmap-c-police)#conform-action transmit 
R2(config-pmap-c-police)#exceed-action set-dscp-transmit 0
R2(config-pmap-c-police)#violate-action drop
  1. As a customer, it is generally not a good idea to police your own traffic, since you are simply dropping it. It is better to put a shaper on the other end of a policer. So in this case, the ISP would have the policer, and you would create a shaper based on the ISP’s police values. These should match as closely as possible. With a shaper, you are queuing your own traffic, but from your application’s point of view it is probably better to delay the traffic than to lose it.

There is a lesson on shaping here: https://networklessons.com/topic/traffic-shaping-on-cisco-ios/

1 Like
20

Thanks Andrew for correcting me.

SO lets say now I have this requirement as a customer.

ISP will give me a 50 MB link and they also allow me to burst upto 70 MBPS as a part of traffic contract. so they are going to put a policier on their end with similar config that you suggested .

Now on my end…I have to use shaping which means whenever my traffic reaches 70 MBPS i should be able to shape (buffer) it and not drop , hence i should use shaping config. but i am not able to figure out how to use these options for my case :

R1(config-pmap-c)#shape ?
  adaptive        Enable Traffic Shaping adaptation to BECN
  average         configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]],
                  send out Bc only per interval
  fecn-adapt      Enable Traffic Shaping reflection of FECN as BECN
  fr-voice-adapt  Enable rate adjustment depending on voice presence
  max-buffers     Set Maximum Buffer Limit
  peak            configure token bucket: CIR (bps) [Bc (bits) [Be (bits)]],
                  send out Bc+Be per interval

Can you please give me a sample config , many thanks

Abhishek