Help understanding a COS policy

[ThomasD86]

Hi,

in some of the router of our network we have a policy that should guarantee that traffic marked with a certain CoS Value has a CIR of 80% and a PIR of 100%. Looking at the policy however, I cannot see how it can do that, people have assured me it works fine but, I can't wrap my head around it. Can someone please understand?

This is the policy:

policy-map 2COS_STANDARD_PROFILE_UPSTREAM
 class P2P_2COS_CLASS_L
  set cos 1
  set qos-group 1
  police cir percent 80 pir percent 100 conform-action transmit  exceed-action drop  violate-action drop

My doubts are the following:

-shouldn't the exceed-action be "transmit"?

-Isn't the violate-action redundant?

The way I am reading this policy is "If traffic is <= 80% of the link bandwidth, transmit it. The moment it exceeds this value, drop it.
If I am reading this correctly that means the policy will never allow the marked traffic to reach 100% link utilization because the moment it tries to go above 80, its gonna get dropped, this also makes the violate action redundant as it will never come into play due to the exceed-action action being drop.

Besides, isn't the violate action redundant regardless of what the exceed action is? Once the traffic exceeds the link's capacity wouldn't the router drop it regardless?

Can anyone please help me understand?

Thank you

[Joseph W. Doherty]

"Once the traffic exceeds the link's capacity wouldn't the router drop it regardless?"

Maybe, maybe not.  Policing works against defined usage-capacity caps within some time period, while "normal" router dropping is due to buffer/queue overflow.  Assuming a policy is specified to drop at 100% of link capacity, when 100% capacity is exceeded, a policer and interface buffer/queue are both likely to drop packets, but their behavior is not exactly the same.  For example, an interface is more likely to buffer short duration overages, while a policer, especially using defaults, is more likely to physically drop because it doesn't buffer/queue.  (I.e. for similar rate control, a shaper might more likely behave closer to a interface's drop behavior than a policer but it too often has slightly different impact than an actual interface.)

"Besides, isn't the violate action redundant regardless of what the exceed action is?"

No, because this is a two level/color policer.  The important component is that both a CIR and PIR are defined.

"The way I am reading this policy is "If traffic is <= 80% of the link bandwidth, transmit it."

Insufficient information, posted, to say the percentages are actually tied to link bandwidth.  Policer and shaper percentages are tied to what the policer/shaper believes the bandwidth to be, which by default, on a physical interface, is the media bandwidth.  But, add the "bandwidth" statement to such an interface, and the policer/shaper will use that as its basis.

E.g.

interface ethernet1
ip service-policy in|out 2COS_STANDARD_PROFILE_UPSTREAM
bandwidth 5000000

"shouldn't the exceed-action be "transmit"?"

I believe the answer should be no, because of PIR.  I.e. is allowed to implicitly exceed CIR if PIR isn't exceeded.

"Isn't the violate-action redundant?"

Also no, I believe, because it applies to when PIR is exceeded, which may before actual link capacity is exceeded, and even if PIR is link capacity, you might want dropping behavior to conform to it rather than whatever the physical interface might do.

If this is still unclear, please post further questions.

[Drum69]

The way I am reading this policy is "If traffic is <= 80% of the link bandwidth, transmit it. The moment it exceeds this value, drop it. If I am reading this correctly that means the policy will never allow the marked traffic to reach 100% link utilization because the moment it tries to go above 80, its gonna get dropped, this also makes the violate action redundant as it will never come into play due to the exceed-action action being drop. My Merrill

[Giuseppe Larosa]

Hello @ThomasD86 ,

>>

shouldn't the exceed-action be "transmit"?

-Isn't the violate-action redundant?

in class based policy framework you can implement a three colors two rates policer

>>

police cir percent 80 pir percent 100 conform-action transmit  exceed-action drop  violate-action drop

 but if exceed.action = drop and violate action = drop this becomes a single rate policer at 80% of line

Hope to help

Giuseppe

[Joseph W. Doherty]

@Giuseppe Larosa is correct about when exceed action should trigger, i.e.: Cisco QoS Policing and Shaping :

From this documentation, conform-action applies to traffic within CIR, exceed-action applies to traffic within CIR to PIR and violate-action applies to traffic exceeding PIR.

From this documentation, as both you noted, you wouldn't expect the policer would allow traffic beyond 80%, and that may indeed be the case.  However, in my experience Cisco policing/shaping implementations sometimes appear to make overall CIR the PIR, and if your implementation does, the exceed-action might not trigger until the PIR is exceeded (where violate-action should come into play).

Again, if this is the case, it might explain why this policer is, in your OP noted as ". . . people have assured me it works fine . . .", when it appears it should drop all traffic over CIR rate.

The only way I've seen to truly find out what a particular Cisco policer/shaper does, is actually test it.

Way, way back, @Peter Paluch did some testing to confirm my (back then) described unexpected rate management experience on some Cisco devices and he confirmed it (on an ISR, I recall?).

[Giuseppe Larosa]

Hello @Joseph W. Doherty , @ThomasD86 ,

actually Peter Paluch or other Cisco experts have reported the explanation in terms of supporting RFCs to make Class Based Policing comparable to RFCs.

By reading the QoS section of the books Exam certification guides two volumes i explain as Cisco routers had legacy policers and shapers. The legacy policer is named CAR = committed access rate

CAR does not fit exactly in the single rate two color policer.

With CAR you have two token buckets Xn and Xe, with Xn the number of bits allowed to be transmitted between two consecutivte time intervals. if Xe is not greater then Xb you get a single rate policer with no execss traffic in the first time window

if Xe is greater thne Xn  credits are cumulated.

With Class based Policing or Shaping the Cisco implementation is compliant with the RFC explaining the two rates three colors policer.

the initial time window can cumulate credits from the conformant past time = -1 , -2 and so on.

Hope to help

Giuseppe