Aggregate Policer

You can measure the rate of traffic that matches a predefined set of rules. To enforce limits, use ACLs in one or more class maps to match the desired traffic, and use a policer to apply the QoS on the matching traffic.

A policer is configured with a QoS specification. There are two kinds of policers:

• Single (Regular) Policer—A single policer applies the QoS to a single class map, and to a single flow based on the policer's QoS specification. When a class map using single policer is bound to multiple ports, each port has its own instance of single policer. Thus, each applying the QoS on the class map (flow) at ports that are otherwise independent of each other. A single policer is created in the Policy Table page.

• Aggregate Policer—An aggregate policer applies the QoS to one or more class maps, and one or more flows. An aggregation policer can support class maps from different policies. An aggregate policer applies QoS to all its flows in aggregation regardless of policies and ports. An aggregate policer is created in the Aggregate Policer page.

  An aggregate policer is defined if the policer is to be shared with more than one class. Policers on a port can’t be shared with other policers in another device.

Each policer is defined with its own QoS specification with a combination of the following parameters:

• A maximum allowed rate, called a Committed Information Rate (CIR), measured in Kbps.

• An action to be applied to frames that are over the limits (called out-of-profile traffic), where such frames can be passed as is, dropped, or passed, for all subsequent handling within the device.

• Configures traffic policing on the basis of the specified rates and optional actions Enter the CIR and these optional values and actions

Assigning a policer to a class map is done when a class map is added to a policy. If the policer is an aggregate policer, you must create it using the Aggregate Policer page.

To define an aggregate policer, complete the following steps: