Specifications

White Paper

Figure 34. Aggregate Policer

There are two forms of aggregates that can be defined in Cisco IOS, and those are

1. Per interface aggregate policers, and

2. Named aggregate policers or shared aggregate

Per interface aggregates are applied to an individual interface using the police command within a policy map class.

These map classes can be applied to multiple interfaces, but the policer polices each interface separately. Named

Aggregates are applied to a group of ports and police traffic across all interfaces cumulatively. Named aggregates

are applied using the mls qos aggregate policer command.

There are system limitations set in place that one needs to be mindful of when implementing policing. When defining

Micro-flows, the number of flows you can police is limited by the number of flows supporting in the Netflow Table on

the PFC. For the PFC3A and PFC3B you can rate limit up to 128K+ unique flows using up to 63 different rate +

traffic class combinations. The PFC3BXL allows up to 256K flows to be policed. For Aggregate policers, there is a

system limit of 1023 policers and this applies across all PFC versions.

8.7 The Rules of the Token Bucket

The Token Bucket is used to determine if a packet can be sent (i.e. data is in profile) or dropped (i.e. data is out of

profile). The Token Bucket is a virtual bucket with a set of tokens. A token bucket exists for each aggregate policer

you create. There are 1023 aggregate policers that can be defined on a Catalyst 6500. When a Microflow policer is

created, a token bucket is created for each flow that is monitored by the Microflow policer. The Catalyst 6500 can

support 63 Microflow policers at the same time. This does not mean 63 flows, but 63 different Microflow policing

rates. For each Microflow policer, a separate token bucket is kept for each flow that is matched by the policer. If a

user were to start up an email session, web session and an FTP session and those sessions match the classification

criteria set by the Microflow policer, then a separate token bucket would exist for each of the flows created from

those sessions.

The PFC2 introduced the concept of dual rate token bucket policing. This is also supported in all versions of the

PFC3. A dual token bucket approach allows for a standard rate and burst to be defined along with an extended rate

and burst. An example of a dual rate policer is given later in this paper. It is important to note, however, that dual rate

policing is only supported for aggregate policers. Microflow policers operate with a single token bucket.

In order for data to be forwarded by the policer, a set of tokens must exist in the token bucket. Each token amounts

to the policer being able to send one bit of data. If a 512-byte packet arrives within the hardware interval of 0.25ms,

then 4096 tokens will be required to be in the bucket to send the packet. The requirement of 4096 tokens is based