Committed Access Rate (CAR) is a rate limiting feature that can be used
to provide Classification and Policing services. CAR can be used to classify
packets based on certain criteria, such as IP address and port values that use
access-lists. The action for packets that conform to the rate limit value and
exceed the value can be defined. Refer to
Configuring
Committed Access Rate for more information on how to configure
CAR.

This document explains why the output of the show
interface x/x rate-limit command shows a non-zero
exceeded bps value when the conformed
bps value is less than the configured committed information
rate (CIR).

Use the
show
interface x rate-limit command in order to monitor the
performance of the Cisco legacy policer, CAR. In this example, the output of
this command provides hints as to why there is a non-zero exceeded bps. The
current burst value is 7392 bytes, while the committed burst (Bc) value,
indicated by the limit value, is set to 7500 bytes.

When you configure CAR or a newer policer from Cisco, class-based
policing, you must configure sufficiently high burst values in order to assure
expected throughput and in order to ensure that the policer drops packets only
to punish short-term congestion.

When you select burst values, it is important to accommodate transient
increases in the queue size. You cannot simply assume that packets arrive and
depart at the same time. You also cannot assume that the queue changes from
empty to one packet and that the queue remains at one packet based on a
consistent one in/one out arrival time. If the typical traffic is fairly
bursty, then the burst values need to be correspondingly large in order to
allow the link utilization to be maintained at an acceptably high level. A
burst size that is too low, or a minimum threshold that is too low, can result
in unacceptably low link utilization.

A burst can be defined simply as a series of back-to-back, MTU-sized
frames, such as 1500-byte frames that originate on an Ethernet network. When a
burst of such frames arrives at an output interface, it can overwhelm the
output buffers and exceed the configured depth of the token bucket at an
instantaneous moment in time. With the use of a token metering system, a
policer makes a binary decision about whether an arriving packet conforms,
exceeds, or violates the configured policing values. With bursty traffic, such
as an FTP stream, the instantaneous arrival rate of these packets can exceed
the configured burst values and lead to CAR drops.

In addition, overall throughput in times of congestion vary with the
type of traffic that is evaluated by the policer. While TCP traffic is
responsive to congestion, other flows are not. Examples of non-responsive flows
include UDP-based and ICMP-based packets.

TCP is based on positive acknowledgement with retransmission. TCP uses
a sliding window as part of its positive acknowledgement mechanism. Sliding
window protocols use network bandwidth better because they allow the sender to
transmit multiple packets before they wait for an acknowledgement. For example,
in a sliding window protocol with a window size of 8, the sender is permitted
to transmit 8 packets before it receives an acknowledgement. If you increase
the window size, the network idle time is largely eliminated. A well-tuned
sliding window protocol keeps the network completely saturated with packets and
maintains high throughput.

Since endpoints do not know the specific congestion status of the
network, TCP as a protocol is designed react to congestion in the network by
the reduction its transmission rates when congestion occurs. Specifically, it
uses two techniques:

Technique

Description

Multiplicative decrease congestion avoidance

Upon loss of a segment (the equivalent of a packet to TCP),
reduce the congestion window by half. The congestion window is a second value
or window which is used to limit the number of packets that a sender can
transmit into the network before it waits for an acknowledgement.

Slow start recovery

When you start traffic on a new connection or increase traffic
after a period of congestion, start the congestion window at the size of a
single segment and increase the congestion window by one segment each time an
acknowledgement arrives. TCP initializes the congestion window to 1, sends an
initial segment, and waits. When the acknowledgement arrives, it increases the
congestion window to 2, sends two segments, and waits. For more details, see
RFC 2001.

Packets can be lost or destroyed when transmission errors interfere
with data, when network hardware fails, or when networks become too heavily
loaded to accommodate the load presented. TCP assumes that lost packets, or
packets that fail to be acknowledged within the timed interval due to extreme
delay, indicate congestion in the network.

The token-bucket metering system of a policer is invoked on each packet
arrival. Specifically, the conformed rate and exceed rate are calculated based
on this simple formula:

(conformed bits since last clear counter)/(time in seconds elapsed since last clear counter)

Since the formula calculates rates over a period from the last time
that the counters were cleared, Cisco recommends to clear the counters in order
to monitor the current rate. If the counters are not cleared, then the previous
formula rate effectively means that the show command
output displays an average calculated over a potentially very long period, and
the values possibly are not meaningful in the determination of the current
rate.

The average throughput should match the configured committed
information rate (CIR) over a period of time. Burst sizes allow a maximum burst
duration at a given time. If there is no traffic or less than the CIR's worth
of traffic and the token bucket does not fill, a very large burst is still
limited to a particular size calculated based on normal burst and extended
burst.

The drop rate results from this mechanism

Note the current time.

Update the token bucket with the number of tokens that have
accumulated continuously since the last time a packet arrived.

The total number of accumulated tokens cannot exceed the maxtokens
value. Drop excess tokens.

Check for packet conformance.

Rate-limiting can also be achieved with Policing. This is a sample
configuration in order to provide rate-limiting on the Ethernet interface that
uses Class based policing.

This table lists resolved issues with the counters displayed in the
show policy-map or show interface
rate-limit commands. Registered customers who are logged in can
view the bug information in the Bug Toolkit, linked from the
Tools and
Utilities
(registered customers only)
page.

When an input hierarchical service policy uses the
police command at the parent and child levels, the
policer can drop less than the expected number of packets since the
parent-level policer must be congested before it drops the packets. This is an
example of such a policy:

Cisco Express Forwarding (CEF) defines an IOS switching
mechanism which forwards packets from input to output interface. Prior to the
changes implemented from this bug ID, both CEF and configured QoS mechanisms
such as CAR or class-based policing incremented the packet counters. The result
is so-called double accounting and inflated conformed packets and excess drop
values.

On the Cisco 12000 series, when output CAR is enabled and the
ingress line card is Engine 2, the egress output counters are doubled. This
double accounting results from how output counters are handled.

If you globally enable the ip cef
distributed command on a Cisco 7500 series router, a
non-Versatile Interface Processor (VIP) card interface appears with the
ip route-cache distributed command enabled by
default. Non-VIPs do not support distributed CEF, and a rare side-effect of
this command that appears on non-VIPs is double accounting.

No drops or a zero drop rate

In general, when you apply class-based QoS features, the first
step in troubleshooting is to ensure that the QoS classification mechanism
works properly. In other words, ensure that the packets specified in the match
statements in your class-map hit the correct classes.

Classification fails when CEF, and not DCEF, is enabled and an
input policy is attached to an ATM PVC. In Cisco IOS Software Release 12.1T,
output classification fails when CEF, and not DCEF, is enabled and an output
policy is attached to an ATM PVC.

The drop rate displayed in the class-map does not match the
drop rates indicated by the police action. In this example output, the drop
rate for the class is 745000 bps, while the drop rate shown by police action is
1072000 bps.