Table of Contents

Traffic Policing

Traffic Policing

This feature module describes the Traffic Policing feature. It includes information on the benefits of the feature, supported platforms, related documents, and so forth.

This document includes the following sections:

• Feature Overview
  
  
• Supported Platforms
  
  
• Supported Standards, MIBs, and RFCs
  
  
• Prerequisites
  
  
• Configuration Tasks
  
  
• Monitoring and Maintaining Traffic Policing
  
  
• Configuration Examples
  
  
• Command Reference
  
  
• Glossary
  
  

Feature Overview

The Traffic Policing feature performs the following functions:

• Limits the input or output transmission rate of a class of traffic based on user-defined criteria
  
  
• Marks packets by setting the IP precedence value, the Quality of Service (QoS) group, or the differentiated services control point (DSCP) value
  
  

Traffic policing is used to control the rate of traffic flowing across an interface. These matching criteria are defined in a traffic class (which is configured with the class-map command). The Traffic Policing feature is applied when you configure a service policy in the Modular Quality of Service Command-Line Interface (Modular QoS CLI). For information on configuring the Modular QoS CLI, see the Modular Quality of Service Command-Line Interface Overview on CCO and the Documentation CD-ROM.

Benefits

Bandwidth Management Through Rate Limiting

Traffic policing allows you to control the maximum rate of traffic transmitted or received on an interface. Traffic policing is often configured on interfaces at the edge of a network to limit traffic into or out of the network. Traffic that falls within the rate parameters is transmitted, whereas traffic that exceeds the parameters is dropped or transmitted with a different priority.

Packet Marking Through IP Precedence, QoS Group, and DSCP Value Setting

Packet marking allows you to partition your network into multiple priority levels or classes of service (CoS).

• Use traffic policing to set the IP precedence or DSCP values for packets entering the network. Networking devices within your network can then use the adjusted IP precedence values to determine how the traffic should be treated. For example, the Distributed Weighted Random Early Detection (DWRED) featyre uses the IP precedence values to determine the probability that a packet will be dropped.
  
  
• Use traffic policing to assign packets to a QoS group. The router uses the QoS group to determine how to prioritize packets.
  
  

Restrictions

• Traffic policing can monitor Cisco Express Forwarding (CEF) switching paths only. In order to use the Traffic Policing feature, Cisco Express Forwarding must be configured on both the interface receiving the packet and the interface sending the packet.
  
  
• Traffic policing cannot be applied to packets that originated from or are destined to a router.
  
  
• Traffic policing can be configured on an interface or a subinterface.
  
  
• Traffic policing is not supported on the following interfaces:
  
  
  • Fast EtherChannel
    
    
  • Tunnel
    
    
  • PRI
    
    
  • Any interface that does not support Cisco Express Forwarding
    
    

Related Features and Technologies

• Modular Quality of Service Command-Line Interface
  
  
• Class-based weighted fair queueing (CBWFQ)
  
  

Related Documents

• Modular Quality of Service Command-Line Interface
  
  
• Committed Access Rate feature module
  
  
• Class-Based Weighted Fair Queuing feature module
  
  

Supported Platforms

• Cisco 7000 series with RSP7000
  
  
• Cisco 7100 series
  
  
• Cisco 7200 series
  
  
• Cisco 7500 series
  
  

Supported Standards, MIBs, and RFCs

Standards

No new or modified standards are supported by this feature.

MIBs

No new or modified MIB's are supported by this feature.

For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.

RFC's

No new or modified RFCs are supported by this feature.

Prerequisites

Cisco Express Forwarding (CEF) must be configured on the interface before traffic policing can be used.

For additional information on Cisco Express Forwarding, see the Cisco Express Forwarding and Distributed Cisco Express Forwarding feature modules.

Configuration Tasks

See the following sections for configuration tasks for the Traffic Policing feature. Each task in the list indicates if the task is optional or required.

• Configuring Traffic Policing (Required)
  
  

Configuring Traffic Policing

To successfully configure the Traffic Policing feature, a traffic class and a service policy have to be created, and the service policy must be attached to a specified interface. These tasks are performed using the Modular QoS CLI. For information on the Modular QoS CLI, see the Modular Quality of Service Command-Line Interface document on CCO or the Documentation CD-ROM.

The Traffic Policing feature is configured in the service policy. To configure the Traffic Policing feature, use the following command in policy map configuration mode:

The Traffic Policing feature works with a token bucket. For a description of a token bucket and an explanation of how it works, see the "What is a Token Bucket?"  section of the Policing and Shaping Overview document. An example of how the token bucket algorithm works is also given in the Command Reference section of this document.

Verifying Traffic Policing

Use the show policy-map interface EXEC command to verify that the Traffic Policing feature is configured on your router. If the feature is configured on your interface, the show policy-map interface command output displays policing statistics:

Router# show policy-map interface
 Ethernet1/7 
  service-policy output: x
    class-map: a (match-all)
      0 packets, 0 bytes
      5 minute rate 0 bps
      match: ip precedence 0
      police:
        1000000 bps, 10000 limit, 10000 extended limit
        conformed 0 packets, 0 bytes; action: transmit
        exceeded 0 packets, 0 bytes; action: drop
        last packet: 1096090208ms ago, current burst: 0 bytes
        conformed 0 bps, exceed 0 bps

Troubleshooting Tips

• Check the interface type. Verify that your interface is not mentioned in the nonsupported interface description in the "Restrictions" section of this document.
  
  
• For input traffic policing, verify that CEF is configured on the interface where traffic policing is configured.
  
  
• For output traffic policing, insure that the incoming traffic is CEF-switched. Traffic Policing cannot be used on the switching path unless CEF switching is enabled.
  
  

Monitoring and Maintaining Traffic Policing

Configuration Examples

This section provides the following configuration example:

• Configuring a Service Policy that Includes Traffic Policing
  
  

Configuring a Service Policy that Includes Traffic Policing

The following configuration shows how to define a traffic class (with the class-map command) and associate that traffic class with a service policy (with the policy-map command). Traffic policing is applied in the service policy. The service-policy command is then used to attach the service policy to the interface.

For additional information on configuring traffic classes and service policies, see the Modular Quality of Service Command-Line Interface document on CCO and the Documentation CD-ROM.

In this particular example, traffic policing is configured with the average rate at 8000 bits per second, the normal burst size at 2000 bytes, and the excess burst size at 4000 bytes. Packets coming into Fast Ethernet interface 0/0 are evaluated by the token bucket algorithm to analyze whether packets conform or exceed. Packets that conform are transmitted, whereas packets that exceed are assigned a QoS transmit value of 4.

For a description of a token bucket and an explanation of how a token bucket works, see the "What is a Token Bucket?" section of the Policing and Shaping Overview  document. An example of how the token bucket works is also given in the "Command Reference" section of this document.

7200-uut(config)# class-map larry
7200-uut(config-cmap)# match access-group 2
7200-uut(config-cmap)# exit
7200-uut(config)# policy-map bird
7200-uut(config-pmap)# class larry
7200-uut(config-pmap-c)# police 8000 2000 4000 conform-action transmit exceed-action set-qos-transmit 4
7200-uut(config-pmap-c)# exit
7200-uut(config-pmap)# exit
7200-uut(config)# interface fastethernet 0/0
7200-uut(config-if)# service-policy input bird

Command Reference

This section documents new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.0 command reference publications.

police

To configure the Traffic Policing feature, use the police policy map configuration command. The no form of this command removes the Traffic Policing feature from the configuration.

Syntax Description Description

Defaults

Disabled

Command Modes

Policy-map configuration mode

Command History

Usage Guidelines

The Traffic Policing feature operates with a token bucket. For a description of a token bucket and an explanation of how a token bucket works, see the "What is a Token Bucket?"  section of the Policing and Shaping Overview  document.

Examples

The following configuration shows users how to define a traffic class (using the class-map command) and associate the match criteria from the traffic class with the Traffic Policing configuration, which is configured in the service policy (using the policy-map command). The service-policy command is then used to attach this service policy to the interface.

In this particular example, traffic policing is configured with the average rate at 1 bit per second, the normal burst size at 2 bytes per second, and the excess burst size at 4 bytes per second for all packets leaving Fast Ethernet interface 0/0.

7200-uut(config)# class-map larry
7200-uut(config-cmap)# match access-group 2
7200-uut(config-cmap)# exit
7200-uut(config)# policy-map bird
7200-uut(config-pmap)# class larry
7200-uut(config-pmap-c)# police 1 2 4 conform-action transmit exceed-action set-qos-transmit 4
7200-uut(config-pmap-c)# exit
7200-uut(config-pmap)# exit
7200-uut(config)# interface fastethernet 0/0
7200-uut(config-if)# service-policy input bird

Below is a step-by-step summation of how a series of packets entering Fast Ethernet interface 0/0 are treated. This example assumes that all entering packets conform to the specified matching criteria and that 1 data unit enters the token bucket for each time unit.

• As specified by the normal burst size (2 bytes), the token bucket has two tokens. In this example, one token equals 1 byte.
  
  
• As specified by the average rate, each packet needs one token to meet the conform action.
  
  
• The first packet needs one token, leaving one token remaining in the token bucket. Because the necessary number of tokens was available in the token bucket, packet 1 conforms to the token bucket restrictions and is transmitted.
  
  
• The second packet needs another token, leaving no tokens remaining in the token bucket. Because the necessary number of tokens was available in the token bucket, packet 2 conforms to the token bucket restrictions and is transmitted.
  
  
• The third packet needs another token. However, the token bucket is now empty. Therefore, the extended burst capability is enabled.
  
  

The extended burst capability analyzes two numbers: the excess burst size and compound debt. The excess burst size is specified by the user in the command-line interface (in this example, the excess burst size is 4). The compound debt is equal to the sum of all actual debt since the last time a packet was dropped.

The actual debt equals the number of tokens that the current flow is borrowing. Actual debt can be calculated by multiplying the number of tokens currently being taken from the bucket (in this case, 1 token is being borrowed) by the number of times tokens have been taken from the bucket (in this case, this is the first time a packet is borrowing a token). Therefore, the actual debt after the third packet is 1 (that is, 1*1).

Because no compound interest existed, the compound debt is also equal to 1 (that is, 0+1). Note that compound debt can also be calculated by adding the compound debt after the previous packet evaluation to the actual debt of the current packet.

Because the compound debt of 1 is less than the excess burst rate of 4, packet 3 conforms and is transmitted.

• The fourth packet needs another token.
  
  

The extended burst capability remains enabled.

One token needs to be borrowed. This is the second time that tokens are being borrowed since the last time a packet was dropped. Therefore, the actual debt of this packet is 2 (that is, 2*1).

The compound debt is equal to the sum of the previous compound debt and the current actual debt. Therefore, the compound debt is now equal to 3 (that is, 1+2).

Because the compound debt of 3 is less than the excess burst size of 4, packet 4 conforms and is transmitted.

• The fifth packet needs another token.
  
  

The extended burst capability remains enabled.

The actual debt is 3 (that is, 1*3).

The compound debt is equal to 6 (that is, 3+3).

Because the compound debt of 6 is greater than the excess burst size of 4, packet 5 exceeds and is assigned a QoS transmit value of 4.

After the exceed action occurs, the compound debt is reset to 0. The actual debt from packet 4 (the last packet to conform), however, is unaffected by the packet drop. Therefore, the actual debt remains at 2 after the packet drop.

• The sixth packet needs another token.
  
  

The extended burst capability remains enabled.

The actual debt is 3 (that is, 3*1). Note that the two times tokens were borrowed from the bucket (for packets 3 and 4) are still a factor when calculating the number of times tokens have been borrowed from the bucket.

The compound debt is equal to 3 (that is, 0+3).

Because the compound debt of 3 is less than the excess burst size of 4, packet 6 conforms to the token bucket restrictions and is transmitted.

• The seventh packet needs one token.
  
  

The extended burst capability remains enabled.

The actual debt is 4.

The compound debt is equal to 7 (3+4).

Because the compound debt of 7 is greater than the excess burst size of 4, packet 7 exceeds the token bucket restrictions and is assigned a QoS transmit value of 4.

After the exceed action occurs, the compound debt is reset to 0. The actual debt from packet 6, however, is unaffected by the packet drop. Therefore, the actual debt remains at 3.

The following table summarizes the example:

Related Commands

Glossary

average rate—Maximum long-term average rate of conforming traffic.

conform action—Action to take on packets with a burst size below the rate allowed by the rate limit.

DSCP—differentiated services code point 

exceed action—Action to take on packets that exceed the rate limit.

excess burst size—Bytes allowed in a burst before all packets will exceed the rate limit.

normal burst size—Bytes allowed in a burst before some packets will exceed the rate limit. Larger bursts are more likely to exceed the rate limit.

QoS group—Internal QoS group ID for a packet used to determine weighted fair queuing characteristics for that packet.

policing policy—Rate limit, conform actions, and exceed actions that apply to traffic matching a certain criteria.

Versatile Interface Processor (VIP)—Interface card used by Cisco 7500 series and Cisco 7000 series with RSP7000 routers.