Percentage-based (class-based) policing

[Nasos Ergot]

(There is a small into which you might want to ignore)

<intro>This is the first of a series of topics i will post over the next week or so as im during

a QOS over MPLS VPNs project which will actually focus on the customer edge mostly

and the way traffic is treated.I have a few things that need answering because i am simply

not covered by the Cisco docs which sometimes seem to be very laconic,thanks for your time </intro>

I have configured a traffic policer as a part of the customer's output policy to (de)mark or drop traffic

destined for the provider edge and i am stuck over two things:

1.

I am using a percentage-based policer which,according to Cisco documentation,has got a

default bc burst value of 4 ms (Cisco QOS command reference). Not according to this though:

      police:
          cir 40 %
          cir 102000 bps, bc 3187 bytes
        conformed 0 packets, 0 bytes; actions:
          set-dscp-transmit af21
        exceeded 0 packets, 0 bytes; actions:
          set-dscp-transmit af23
        conformed 0 bps, exceed 0 bps

If you do the maths,the bc value is 250 ms, not 4.Am i missing something here? (i must be)

2.

The policer runs inside classes being a part of a policy map attached on a FR interface as output.

The interface runs Frame Relay Traffic Shaping and with fragmentation at 320 bytes inside the map-class,

where the policy map is applied.

When applied though,the policer automatically sets the default bc in bytes to 1500,which is the Ethernet MTU value.

      police:
          cir 10 %
          cir 25500 bps, bc 1500 bytes
        conformed 0 packets, 0 bytes; actions:
          set-dscp-transmit af41
        exceeded 0 packets, 0 bytes; actions:
          drop
        conformed 0 bps, exceed 0 bps

According to the 250 ms bc i explained above which i think it takes as default, the bc in bytes should be

796 (using the formula: bc in bytes * 8 / class BW = bc in ms).

But i get a message saying: "burst bc increased to 1500 bytes".I can only assume it does this because the ingress

interface is an Ethernet interface and the policer runs before FRTS? (again,according to Cisco diagrams).

This stops me from setting the bc value to lower than 1500 by lowering the value in ms, by the way you cannot specify

bc in bytes, only in ms.

Now, what's a logical solution?I have tried lowering the interface MTU ( a serial interface) but nothing.

It wouldn't make any sense to lower the MTU on the ingress Ethernet interface,would it?

FRTS config:

!
map-class frame-relay 2PE
frame-relay cir 256000
frame-relay bc 2560
frame-relay be 0
frame-relay mincir 256000
frame-relay fragment 320
service-policy output ce2pe

policy-map:

!
policy-map ce2pe
class voice
  priority percent 33
  police cir percent 33 bc 20 ms
    conform-action transmit
    exceed-action drop
class data
  bandwidth percent 40
  random-detect dscp-based
  police cir percent 40
    conform-action set-dscp-transmit af21
    exceed-action set-dscp-transmit af23
class video
  bandwidth percent 10
  police cir percent 10
    conform-action set-dscp-transmit af41
    exceed-action drop
class control
  bandwidth percent 5
class vocontrol
  bandwidth percent 5
  set ip dscp cs3
class class-default
  bandwidth percent 5
  set ip dscp default

interface:

!
interface Serial0/0
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
max-reserved-bandwidth 100
!
interface Serial0/0.1 point-to-point
ip address 10.0.1.2 255.255.255.0
no cdp enable
frame-relay class 2PE
frame-relay interface-dlci 100

Thanks

[Mahesh Gohil]

Hello Athan,

> I think it is tc and not bc. so the formula is tc=cir/bc in bits

In your case it is tc= 102000/3187*8 = 4ms

> If router automatically adjust bc value to some higher value it means , that is the only lowest suported value for that hardware/software combination

   It has no relation with MTU (My opinion) And even the higher value is also fixed. if you set some higher value it will set the supported

   minimum highest value and print the message.

Hope this helps

Regards

mahesh

[Nasos Ergot]

Hi Mahesh,

it is still considered as bc by Cisco,in the config you set it as 'police bps bc value ms',

since you can never set the tc,it calculates itself (well,in case of Frame Relay).

The formula you suggested is used the other way around (Cisco reference),for example,inside the map-class

for FRTS: bc / CIR = tc => 2560 bits / 256000 bps= 0.01 s = 10 ms,which is the recommended value

for an edge running voice.

It has no relation to the MTU indeed as i tried taking it down and that didn't work.

My thoughts

Thanks for yout time.

[Ryan Newell]

Athan,

I know this is an old post but I was researching the  topic myself and wanted to share what I found. I think a Bc lower than  1500 would yield unwanted results. Let's say for example 798 was the Bc.  Any packet above 798 would be dropped because the policer would always  consider it in violation. In your case with FR fragementaiton set to 320  you would never encounter a large packet. Makes me wonder if there is a  way around this...