QOS- POLICE and Police RATE DIFFERENCE....

[farooq_0923@hotmail.com]

HI Guys

I have been brushing up on my QOS and just come across something that i cant get my head round it....bascially i setup MQC for PING class (marked as AF33 and part of access-group 1 ) ....i have policed the traffic to 8000bps (1000bytes) but when i generate ping of size 1000 from acces-group 1 class it drop every second packet, when i generate ping size of 300 it on average drops a packet after every 5 packets and few times after 6 packets....if i set ping packet size to 500 then after every three packets it drops one packets....i need lil clearification since i set CIR to be 8000 bps and policed it i was expacting 1000 Byte or 8000 bit to pass per second why i see more than 1000bytes per second , current traffic rate passing through is 1500bytes which is same as in Bc value....can someone explain what BC referes to in my configs when i use police and if i use police rate it shows burst not bc....

I need clarification on when to use police command and when to use Police rate ...with police it show bc value and with police rate burst...

My understanding is to use polic for data plane traffic and police rate is for control plane traffic needed lil clarification

i need to know what bc is (its not frame relay just normal link ) and why is it passing more traffic than its configured for ....

Thanks alot everyone and happy new year....

FastEthernet0/0

  Service-policy output: SHAPE

    Class-map: PING (match-any)

      698 packets, 59372 bytes

      5 minute offered rate 5000 bps, drop rate 0 bps

      Match: ip dscp af33 (30)

        698 packets, 59372 bytes

        5 minute rate 5000 bps

      police:

          cir 8000 bps, bc 1500 bytes

        conformed 689 packets, 57446 bytes; actions:

          transmit

        exceeded 9 packets, 1926 bytes; actions:

          drop

        conformed 5000 bps, exceed 0 bps

Class Map match-any PING (id 4)

   Match ip  dscp af33 (30)

Class Map match-any ICMP (id 1)

   Match access-group  1

R1# sh access-lists 1

Standard IP access list 1

    10 permit 1.1.1.0, wildcard bits 0.0.0.255 (1956 matches)

R1#

R1#sh clas

R1#sh class-map PING

Class Map match-any PING (id 4)

   Match ip  dscp af33 (30)

R3#ping 6.6.6.6 source 1.1.1.1 re 10 size 250

Type escape sequence to abort.

Sending 10, 250-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!!!!!.!!

Success rate is 90 percent (9/10), round-trip min/avg/max = 44/67/84 ms

R3#ping 6.6.6.6 source 1.1.1.1 re 10 size 1000

Type escape sequence to abort.

Sending 10, 1000-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!.!.!.!.!.

Success rate is 50 percent (5/10), round-trip min/avg/max = 52/85/112 ms

R3#ping 6.6.6.6 source 1.1.1.1 re 10 size 500

Type escape sequence to abort.

Sending 10, 500-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:

Packet sent with a source address of 1.1.1.1

!!!.!!!.!!

Success rate is 80 percent (8/10), round-trip min/avg/max = 60/93/120 ms

R3#

[farooq_0923@hotmail.com]

Actualy i figured it out but would still like to validate .....

bc value is same as CIR But only difference is its in bytes not bits and time is one fourth of second ....so in belwo example bc is 9375*8and then the value is multiple to 4 which gives us CIR 300000 , in my previous post bc is higher than CIR becuase i chose 8000bps minimum possible vlaue and for that cisco router chooses 1500bytes which means minimum CIR for a class is  48000bps anything lower then that will still have 1500byte assigned as bc....

Also police CIR is normal syntax and police rate is used for control plane traffic ....we can only use police too without CIR keyword.....

R1#sh policy-map interface fastEthernet 0/0 output class WEB

FastEthernet0/0

  Service-policy output: SHAPE

    Class-map: WEB (match-any)

      100 packets, 101400 bytes

      5 minute offered rate 0 bps, drop rate 0 bps

      Match: ip precedence 7

        100 packets, 101400 bytes

        5 minute rate 0 bps

      Queueing

        Output Queue: Conversation 265

        Bandwidth remaining 10 (%)Max Threshold 64 (packets)

        (pkts matched/bytes matched) 0/0

        (depth/total drops/no-buffer drops) 0/0/0

      police:

          cir 300000 bps, bc 9375 bytes

        conformed 100 packets, 101400 bytes; actions:

          transmit

        exceeded 0 packets, 0 bytes; actions:

          drop

        conformed 0 bps, exceed 0 bps

[paul driver]

Hello

The BC ( commited burst rate) is sent in defind timed intervals (TC) -  meaning every TC ( 0.25 of a second) the amount bps specifed in the BC is sent.

And the default formula for policing is CIR/32 or CIR*0.25/8

res

Paul

Please don't forget to rate any posts that have been helpful.

Thanks.

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

One fourth of a second, 250ms, or 25ms?  The latter is, I recall, is a common default on Cisco policers.

What you may be bumping into, especially with a policer, policers and shapers "count" transmitted bytes during some time period.  When the maximum allowed count is reached, any packets that exceed the count for the current interval are subject to policing (or shaping).  Since policer's don't queue, even if a packet's size, during the time interval, only exceeds the count by 1 byte, it will be dropped.  Larger packets are more likely to "overflow" a count, especially during small time intervals.  Also when using pings, I believe consective ping packets are not generated as quickly as the interface bandwidth would allow.  If this is true, larger ping packets are more likely to exceed the "count" during a measured time interval.

Because policers don't queue, it's quite common that traffic at some policed rate doesn't actually obtain that rate, due to drops during packet bursts.  The way to mitigate this is to insure your Bc equals the buffer space of an interface.  For example, often T1/E1 will default to an egress queue of 40 packets.  Assuming each would be about 1500 bytes, means we need to insure a 1.5 Mbps policer needs a Bc of about (40*1500) 60,000 bytes for similar behavior.