Catalyst 6500 Series Switch Microflow Policing Configuration Example

Introduction

This document describes microflow policing on Catalyst 6500 Series switches.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

The information in this document is based on a Cisco Catalyst 6500 Series switch that runs on a Supervisor Engine 720.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Background Information

Here is a use case for your consideration. There is a university requirement to limit each student to a bandwith of 10Mbps while they use the Internet. If aggregate policing is configured, then there is an unequal distribution of bandwidth among the students. Microflow policer is better able to help us acheive this task.

Microflow policing helps users police traffic based on flows. A flow is usually defined by Source IP (SRC-IP), Destination IP (DST-IP), SRC-DST IP, SRC-DST Port, or SRC-Interface. Here is an example:

Source 10.0.0.1 sending a tcp stream to 15.0.0.1 with a source tcp port of 50
and destination 2000
Source 10.0.0.1 sending a tcp stream to 15.0.0.2 with a source tcp port of 60
and destination 2000.

If classification is done based on the SRC-IP, then the number of flows equals one. If classification is done based on the DST-IP, then the number of flows equals two. If classification is done based on the DST Port, then the number of flows equals one.

Note: Microflow policers can only be applied in the ingress direction, unlike the aggregate policer.

When we apply a service policy under an interface, either the physical interface or the Switch Virtual Interface (SVI), the service policy is programmed in the hardware. Quality of Service (QoS) Ternary Content Addressable Memory (TCAM) is used in order to store the entry. Additionally, since the switch must remember the flows, it stores individual flow information in the hardware. NetFlow TCAM is used for this purpose. Hence, there are two places where you can check the programming in the hardware: the Access Control List (ACL) TCAM and the NetFlow TCAM.

Since the same NetFlow TCAM is used by other features, like Network Address Translation (NAT), NetFlow Data Export (NDE), and Web Cache Communication Protocol (WCCP), it is possible that there is a conflict in the microflow policer programming in the hardware. Some TCAM conflict scenarios are provided at the end of this document.

Configuration Examples

Example 1

There is a Cisco Catalyst 6500 Series switch engaged in interVLAN routing. The sources of traffic are located in VLAN 20, and have these IP addresses: 20.20.20.2 and 20.20.20.3. Both of the sources try to send traffic towards the IP address 30.30.30.2, which is located in VLAN 30. The goal is to allocate 100Kbps of bandwidth to each source.

1. Create and map an ACL in a class-map in order to match the traffic that comes from these two sources.
   

   ip access-list ext vlan20_30
   permit ip 20.20.20.0 0.0.0.255 30.30.30.0 0.0.0.255

   
   

   class-map POLICE_DIFF_SRC
   match access-group name vlan20_30

   
   
   
2. Apply the class-map in a policy-map. Configure Committed Information Rate (CIR) and burst values as required.
   
   

   policy-map POLICE_DIFF_SRC
   class POLICE_DIFF_SRC 
   police flow mask src-only 100000 3000 conform transmit exceed drop

   
   
   Here are the options that are available after police flow mask:
   

   police flow mask ?
   dest-only 
   full-flow
   src-only

   
   
   
3. Apply the service policy under the ingress SVI or under the ingress physical interface. In case you apply it under the interface VLAN, configure mls qos vlan-based under the physical interface. This instructs the Cisco IOS^® to look for a policy under the interface VLAN as soon as a packet reaches a layer 2 interface in a specific VLAN.
   
   

   interface vlan 20
   service-policy input POLICE_DIFF_SRC

Example 2

There is a Catalyst 6500 Series switch engaged in layer 2 switching of the traffic in the same VLAN. This example deomonstrates how to restrict traffic that comes from 10.10.10.2 and goes towards 10.10.10.3 in VLAN to 100Kbps of bandwidth. In order to have the policer affect layer 2-switched traffic, you must enter the mls qos bridged command under the interface VLAN 10.

ip access-list ext VLAN10
permit ip 10.10.10.0 0.0.0.255 10.10.10.0 0.0.0.255
class-map POLICE_SAME


match access-group name VLAN10
policy-map POLICE_SAME
class POLICE_SAME     
police flow mask src-only 100000 3000 conform transmit exceed drop


int vlan 10 
service-policy in POLICE_SAME 
mls qos bridged

Verify

There is currently no verification procedure available for this configuration.

Troubleshoot

1. Enter the show mls qos ip command, and check for the FL ID beside the policer name. If the FL ID is 1, then the policy is in use for microflow policing.
   
   

   6500#show mls qos ip
      QoS Summary [IPv4]:      (* - shared aggregates, Mod - switch module)
   
    Int Mod Dir  Class-map DSCP  Ag  Trust   FL   AgForward-By   AgPoliced-By
                                                          Id           Id
   ---------------------------------------------------------------------------
   
   Fa3/3  1 In   POLICE_SAM   0   0*   dscp    1   11266001160            0

   
   Here are some noteworthy points based on this output:
   
   
   • The policy is mapped in the hardware.
   • The interface on which it is applied is Fa3/3.
   • If there is a Distributed Forwarding Card (DFC)-enabled Line Card (LC) present in the chassis, then the QoS polices are programmed separately for each DFC and Policy Feature Card (PFC). The module number gives the entry for the PFC/DFC in slot 1.
   • Supervisor Engine 720 creates an Aggregate ID (AgID) for every aggregate policer that is created. 1020 AgIDs are the maximum usable IDs, which is a hardware limitation. This is not relevant for the microflow policer, but is a useful command for the aggregate policer.
   • The trust field holds no relevance in this case.
   • FL ID=1, as discussed previously.
   • The AgForward?By and AgPoliced-By are not used in order to calculate packets that are transmitted or dropped by the microflow policer (there is a separate command for that). However, the same counters are used in order to calculate packets transmitted/dropped by an aggregate policer.
   
   
   
2. Enter the show tcam int < vlan/or physical interface> qos type1 ip command in order to determine if the ACL is programmed in the QoS TCAM.
   
   

   6500#show tcam interface fa3/3 qos type1 ip   
       QOS Results:   A - Aggregate Policing       F - Microflow Policing
       M - Mark          T - Trust
       U - Untrust
       ------------------------------------------------------
       FT     ip 10.10.10.0 0.0.0.255 10.10.10.0 0.0.0.255  ==> entry is 
       programmed correctly
       MU     ip any any

   
   
   
3. Check the output of the show mls NetFlow ip qos nowrap command in order to discover if the flows are installed in the Netlflow TCAM.
   
   

   6500#show mls NetFlow ip qos nowrap 
   Displaying NetFlow entries in Active Supervisor EARL in module 1
   DstIP           SrcIP           Prot         : SrcPort :   DstPort   Src i/f         :AdjPtr    Pkts   
   Bytes         LastSeen      QoS       PoliceCount  Threshold   Leak          Drop     Bucket
   ------------------------------------------------------------------------------------------------------
   0.0.0.0          0.0.0.0            0                     :0                   :0           -- 
   0x0       140394     
   67383880   15:16:29        0x0                   0                    0           0
   NO             0
   
   0.0.0.0         10.10.10.2      0                     :0                   :0           --               
   0x0           227
   108506        15:16:22        0x0                  35996208    0           0                NO         3386

   
   
   In this output, you can see that the flow (source-only) is installed in the NetFlow TCAM, and there are 35,996,208 packets that were policed.

Possible Problems

It is possible that the service policy is not programmed in the hardware in these scenarios. Here are some possible reasons:

1. There is a hardware limitation on the number of aggregate/microflow policers that can be configured. In order to reserve hardware resources, the service policy is not programmed in the hardware.
   
   Enter the show platform hardware capacity qoscan command in order to check the availability of the policers.
   
   

   6500#show platform hardware capacity qos
   QoS Policer Resources
     Aggregate policers: Module                      Total         Used     %Used
                         1                            1024            102     10%
                         6                            1024            102     10%
     Microflow policer configurations: Module        Total         Used     %Used
                                       1                64            32        50%
                                       6                64            32        50%

   
   
   
2. Because of a flow mask conflict with other features configured under the same interface, the microflow policer might not be able to cache flows in NetFlow TCAM.
   
   It is important to understand the concept of flow mask. In order to support hardware acceleration of certain features, there are dedicated pieces of hardware (TCAMs) that are used in order to install certain features. There are multiple features which use the same TCAM, such as NAT WCCP NetFlow. They use a TCAM that is commonly called the NetFlow TCAM, whereas for features like security ACLs, Policy-Based Routing (PBR) uses the ACL TCAM.
   
   For the NetFlow TCAM, a flow mask is needed in order to install entries in the hardware. NetFlow flow masks determine the granularity of the flows to be measured. Very specific flow masks generate a large number of NetFlow table entries, and a large volume of statistics to export. Less specific flow masks aggregate the traffic statistics into fewer NetFlow table entries, and generate a lower volume of statistics.
   
   The NetFlow Table Configuration article describes the flow mask requirement (supported) features.
   
   
   • Enter the show fm summary command, and determine if the interface is in an inactive state. An Inactive state indicates that there is some feature configured under the interface that cannot be programmed in the hardware. Packets received on that interface that require that feature are programmed in the software.
     
     

     6500#show fm summary
     Interface: Vlan13 is up
     TCAM screening for features: INACTIVE inbound
     TCAM screening for features: INACTIVE outbound
     Interface: Vlan72 is up
     TCAM screening for features: ACTIVE inbound
     TCAM screening for features: ACTIVE outbound
     Interface: Vlan84 is up
     TCAM screening for features: ACTIVE inbound
     TCAM screening for features: INACTIVE outbound

     
     
     
   • Enter the show fm fie interface <> command, and determine if the microflow policer is configured in the hardware.
     
     

     6500#show fm fie int vlan 10
     Interface Vl10:
     Feature interaction state created: Yes
      Flowmask conflict status for protocol IP : 
      FIE_FLOWMASK_STATUS_SUCCESS
      Flowmask conflict status for protocol OTHER : 
      FIE_FLOWMASK_STATUS_SUCCESS Interface Vl10 [Ingress]:
      Slot(s) using the protocol IP : 1
      FIE Result for protocol IP : FIE_SUCCESS_NO_CONFLICT  
      Features Configured : [empty] - Protocol : IP  
      FM Label when FIE was invoked : 66  Current FM Label : 66  
      Last Merge is for slot: 0  num# of strategies tried : 1
       num# of merged VMRs in bank 1 = 0
       num# of free TCAM entries in Bank1 = Unknown
       num# of merged VMRs in bank 2 = 1
       num# of free TCAM entries in Bank2 = Unknown
      Slot(s) using the protocol OTHER : 1
      FIE Result for protocol OTHER : FIE_SUCCESS_NO_CONFLICT
      Features Configured : OTH_DEF   - Protocol : OTHER
      FM Label when FIE was invoked : 66
      Current FM Label : 66
      Last Merge is for slot: 0
      Features in Bank1 = OTH_DEF
     +-------------------------------------+
             Action Merge Table
     +-------------------------------------+
        OTH_DEF      RSLT    R_RSLT  COL
     +-------------------------------------+
        SB           HB      P       0
         X            P       P       0
     +-------------------------------------+
      num# of strategies tried : 1
      Description of merging strategy used:
      Serialized Banks: FALSE
      Bank1 Only Features: [empty]
      Bank2 Only Features: [empty]
      Banks Swappable: TRUE
      Merge Algorithm: ODM
      num# of merged VMRs in bank 1 = 1
      num# of free TCAM entries in Bank1 = 32745
      num# of merged VMRs in bank 2 = 0
      num# of free TCAM entries in Bank2 = 32744 Interface Vl10 [Egress]:
     No Features Configured
     No IP Guardian Feature Configured
     No IPv6 Guardian Feature Configured
     IP QoS Conflict resolution configured, QoS policy name: POLICE_SAME

   Compatible flow masks should be used for features configured under the same interface that share the NetFlow TCAM. Compatible flow masks are available for almost all types of combinations.

Other Useful Commands

• Apply the policy
• Check FL-ID=1 - show mls qos ip
• Check QoS TCAM - show tcam int <> qos type 1 ip
• Check NetFlow TCAM - show mls NetFlow ip qos module nowrap
• Check for the availability of policers - show platform hardware capacity fabric
• Check for Flow Mask (FM) conflict- show log, show fm summary
• Check for the features configured under the interface - show fm fie interface

Revision History