Specifications

White Paper
© 2009 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. Page 46 of 89
The differences between the policing capabilities of the different Supervisors (Policy Feature Card’s) are
summarised in the following table.
Table 18. Policing capabilities of different Supervisor Engines
Sup32 Sup720 Sup720-3B Sup720-3BXL Sup720-3C Sup720-3CXL
Default PFC PFC3B PFC3A PFC3B PFC3BXL PFC3C PFC3CXL
Ingress Policing Yes Yes Yes Yes Yes Yes
Egress Policing Yes Yes Yes Yes Yes Yes
Aggregate Policing Yes Yes Yes Yes Yes Yes
Microflow Policing Yes Yes Yes Yes Yes Yes
User Based Rate
Limiting
Yes Yes Yes Yes Yes Yes
What is counted by
the Policer
Length of Layer 2
packet
Length of Layer 2
packet
Length of Layer 2
packet
Length of Layer 2
packet
Length of Layer 2
packet
Length of Layer 2
packet
Leaky Bucket
Implementation
Dual Dual Dual Dual Dual Dual
The PFC3x supports both ingress and egress Policing. An ingress service policy can be applied to a layer 2 switch
port, a layer 3 port or a Switched Virtual Interface (i.e. VLAN interface). It is important to remember that ingress
policies are applied at the PFC/DFC level and not at the port ASIC level for that reason; they cannot be used to
mitigate oversubscription on oversubscribed line-cards.
Egress policing can apply a policy to all of the above interfaces except a physical layer 2 switch-port. An egress
service policy is always implemented on the PFC or the DFC that receives the frames and not the one that forwards
the frame. When the Policy Feature Card performs both Ingress and Egress policing, it will process the ingress
policer before the egress policer. It is also worth noting that an Ingress and Egress policer can exist on a physical
interface (or VLAN interface) at the same time, Egress Policing will be discussed in more detail later in this paper.
The PFC3x counts both the Header and Data portion of the packet,a full size packet would be counted by the policer
as 1518 bytes.
8.2 Configure Policing on the Catalyst 6500
Policing is supported with Cisco IOS, however, the configuration and implementation of the policing function is
achieved using policy maps. Each policy map can use multiple class maps to make up a policy map and these
policy classes can be defined for different types of traffic flows. Policing is configured on the Catalyst 6500 using the
Modular QoS CLI (MQC). Up to 255 class maps can be defined per policy map with a total of 1024 class maps per
Catalyst 6500 chassis. MQC is provided in IOS to allow the separation of class maps from policy maps and from the
application of these on an interface. It provides the mechanisms to configure all Policing and Classification features
available in the switch.
It is important to note that on the Catalyst 6500, QoS parameters available in Router IOS are not necessarily
available. Even with the presence of some of these commands are there in the CLI, does not necessarily mean they
are supported on all interfaces. Some MQC QOS commands are applicable only to routed ports on a FlexWAN or
SIP linecard (for instance) yet are not supported on standard Ethernet linecards. Do note that any queuing,
congestion management or scheduling features are configured on a port basis and not within the policy map.
Policy map classes use classification criteria as the means to identify which packets this policy will be applied to.
The classification aspect of this process use IOS based access control lists and class match statements to identify
traffic to be policed. Once the traffic has been identified, the policy classes can use aggregate and Microflow policers
to apply the policing policies to that matched traffic.