Changes between Version 13 and Version 14 of VLANQoS

Show
Ignore:
Timestamp:
05/07/10 12:14:19 (9 years ago)
Author:
yxin (IP: 152.54.8.156)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • VLANQoS

    v13 v14  
    1 = Introduction = 
    2  
    3 QoS policing on a network determines whether network traffic is within a specified profile (contract). This may cause out-of-profile traffic to drop or to be marked down to another differentiated services code point (DSCP) value to enforce a contracted service level. (DSCP is a measure of the QoS level of the frame.) 
    4  
    5 Do not confuse traffic policing with traffic shaping. Both ensure that traffic stays within the profile (contract). You do not buffer out-of-profile packets when you police traffic. Therefore, you do not affect transmission delay. You either drop the traffic or mark it with a lower QoS level (DSCP markdown). In contrast, with traffic shaping, you buffer out-of-profile traffic and smooth the traffic bursts. This affects the delay and delay variation. You can only apply traffic shaping on an outbound interface. You can apply policing on both inbound and outbound interfaces. 
    6  
    7 The Catalyst 6500/6000 Policy Feature Card (PFC) and PFC2 only support ingress policing. The PFC3 supports both ingress and egress policing. Traffic shaping is only supported on certain WAN modules for the Catalyst 6500/7600 series, such as the Optical Services Modules (OSMs) and FlexWAN modules. Refer to the Cisco 7600 Series Router Module Configuration Notes for more information 
    8  
    9 == QoS Policing Parameters == 
    10  
    11 To set up policing, you define the policers and apply them to ports (port-based QoS) or to VLANs (VLAN-based QoS). Each policer defines a name, type, rate, burst, and actions for in-profile and out-of-profile traffic. Policers on Supervisor Engine II also support excess rate parameters. There are two types of policers: microflow and aggregate. 
    12  
    13  * Microflow—police traffic for each applied port/VLAN separately on a per-flow basis. 
    14  
    15  * Aggregate—police traffic across all of the applied ports/VLANs. 
    16  
    17 Each policer can be applied to several ports or VLANs. The flow is defined using these parameters: 
    18  
    19  * source IP address 
    20  
    21  * destination IP address 
    22  
    23  * Layer 4 protocol (such as User Datagram Protocol [UDP]) 
    24  
    25  * source port number 
    26  
    27  * destination port number 
    28  
    29 You can say that packets that match a particular set of defined parameters belong to the same flow. (This is essentially the same flow concept as that which NetFlow switching uses.) 
    30  
    31 As an example, if you configure a microflow policer to limit the TFTP traffic to 1 Mbps on VLAN 1 and VLAN 3, then 1 Mbps is allowed for each flow in VLAN 1 and 1 Mbps for each flow in VLAN 3. In other words, if there are three flows in VLAN 1 and four flows in VLAN 3, the microflow policer allows each of these flows 1 Mbps. If you configure an aggregate policer, it limits the TFTP traffic for all flows combined on VLAN 1 and VLAN 3 to 1 Mbps. 
    32  
    33 If you apply both aggregate and microflow policers, QoS always takes the most severe action specified by the policers. For example, if one policer specifies to drop the packet, but another specifies to mark down the packet, the packet is dropped. 
    34  
    35 By default, microflow policers work only with routed (Layer 3 [L3]) traffic. To police bridged (Layer 2 [L2]) traffic as well, you need to enable bridged microflow policing. On the Supervisor Engine II, you need to enable bridged microflow policing even for L3 microflow policing. 
    36  
    37 Policing is protocol-aware. All traffic is divided into three types: 
    38  
    39  * IP 
    40  
    41  * Internetwork Packet Exchange (IPX) 
    42  
    43  * Other 
    44  
    45 Policing is implemented on the Catalyst 6500/6000 according to a "leaky bucket" concept. Tokens corresponding to inbound traffic packets are placed into a bucket. (Each token represents a bit, so a large packet is represented by more tokens than a small packet.) At regular intervals, a defined number of tokens are removed from the bucket and sent on their way. If there is no place in the bucket to accommodate inbound packets, the packets are considered out-of-profile. They are either dropped or marked down according to the configured policing action. 
    46  
    47  
    48 Note: The traffic is not buffered in the bucket, as it may appear in the image above. The actual traffic does not go through the bucket at all; the bucket is only used to decide whether the packet is in-profile or out-of-profile. 
    49  
    50 == Calculate Parameters == 
    51  
    52 Several parameters control the operation of the token bucket, as shown here: 
    53  
    54 Rate—defines how many tokens are removed at each interval. This effectively sets the policing rate. All traffic below the rate is considered in-profile. 
    55  
    56 Interval—defines how often tokens are removed from the bucket. The interval is fixed at 0.00025 seconds, so tokens are removed from the bucket 4,000 times per second. The interval cannot be changed. 
    57  
    58 Burst—defines the maximum number of tokens that the bucket can hold at any one time. To sustain the specified traffic rate, burst should be no less than the rate times the interval. Another consideration is that the maximum-size packet must fit into the bucket. 
    59  
    60 To determine the burst parameter, use this equation: 
    61  
    62 Burst = (Rate [bps]) * 0.00025 [sec/interval]) or (maximum packet size [bits]), whichever is greater. 
    63  
    64 For example, if you want to calculate the minimum burst value needed to sustain a rate of 1 Mbps on an Ethernet network, the rate is defined as 1 Mbps and the maximum Ethernet packet size is 1518 bytes. The equation is: 
    65  
    66 Burst = (1,000,000 bps * 0.00025) or (1518 bytes * 8 bits/byte) = 250 or 12144. 
    67  
    68 The larger result is 12144, which you round to 13 kbps. 
    69  
    70 Note: In Cisco IOS® Software, the policing rate is defined in bits per second (bps), as opposed to kbps in Catalyst OS (CatOS). Also in Cisco IOS Software, the burst rate is defined in bytes, as opposed to kilobits in CatOS. 
    71  
    72 Note: Due to hardware policing granularity, the exact rate and burst is rounded to the nearest supported value. Be sure that the burst value is not less than the maximum-size packet. Otherwise, all packets larger than the burst size are dropped. 
    73  
    74 For example, if you try to set the burst to 1518 in Cisco IOS Software, it is rounded to 1000. This causes all frames larger than 1000 bytes to be dropped. The solution is to configure burst to 2000. 
    75  
    76 When you configure the burst rate, take into account that some protocols (like TCP) implement a flow-control mechanism that reacts to packet loss. For example, TCP reduces windowing by half for each lost packet. Consequently, when policed to a certain rate, the effective link utilization is lower than the configured rate. You can increase the burst to achieve better utilization. A good start for such traffic is to double the burst size. (In this example, the burst size is increased from 13 kbps to 26 kbps). Then, monitor performance and make further adjustments if needed. 
    77  
    78 For the same reason, it is not recommended to benchmark the policer operation using connection-oriented traffic. This generally shows lower performance than the policer permits. 
    79  
    80 == Policy Actions == 
    81  
    82 As mentioned in the Introduction, the policer can do one of two things to an out-of-profile packet: 
    83  
    84 drop the packet (the drop parameter in the configuration) 
    85  
    86 mark the packet to a lower DSCP (the policed-dscp parameter in the configuration) 
    87  
    88 To mark down the packet, you must modify the policed DSCP map. The policed DSCP is set by default to remark the packet to the same DSCP. (No mark down occurs.) 
    89  
    90 Note: If "out-of-profile" packets are marked down to a DSCP that is mapped into a different output queue than the original DSCP, some packets may be sent out of order. For this reason, if the order of packets is important, it is recommended to mark down out-of-profile packets to a DSCP that is mapped to the same output queue as in-profile packets. 
    91  
    92 On the Supervisor Engine II, which supports excess rate, two triggers are possible: 
    93  
    94 When traffic exceeds normal rate 
    95  
    96 When traffic exceeds excess rate 
    97  
    98 One example of the application of excess rate is to mark down packets that exceed the normal rate and drop packets that exceed the excess rate. 
    99  
    100 Policing Features Supported by the Catalyst 6500/6000 
    101  
    102 As stated in the Introduction, the PFC1 on the Supervisor Engine 1a and the PFC2 on the Supervisor Engine 2 only support ingress (inbound interface) policing. The PFC3 on the Supervisor Engine 720 supports both ingress and egress (outbound interface) policing. 
    103  
    104 The Catalyst 6500/6000 supports up to 63 microflow policers and up to 1023 aggregate policers. 
    105  
    106 The Supervisor Engine 1a supports ingress policing, starting with CatOS version 5.3(1) and Cisco IOS Software Release 12.0(7)XE. 
    107  
    108 Note: A PFC or PFC2 daughter card is required for policing with the Supervisor Engine 1a. 
    109  
    110 The Supervisor Engine 2 supports ingress policing, starting with CatOS version 6.1(1) and Cisco IOS Software Release 12.1(5c)EX. The Supervisor Engine II supports the excess rate policing parameter. 
    111  
    112 Configurations with Distributed Forwarding Cards (DFCs) only support port-based policing. Also, the aggregate policer only counts traffic on a per-forwarding-engine basis, not per-system. The DFC and PFC are both forwarding engines; if a module (line card) does not have a DFC, it uses a PFC as a forwarding engine. 
    113  
    114 Policing Features Update for Supervisor Engine 720 
    115  
    116 Note: If you are unfamiliar with Catalyst 6500/6000 QoS policing, be sure to read the QoS Policing Parameters and Policing Features Supported by the Catalyst 6500/6000 sections of this document. 
    117  
    118 The Supervisor Engine 720 introduced these new QoS policing features: 
    119  
    120 Egress policing. The Supervisor 720 supports ingress policing on a port or VLAN interface. It supports egress policing on a port or L3 routed interface (in the case of Cisco IOS System Software). All ports in the VLAN are policed on egress regardless of the port QoS mode (whether port-based QoS or VLAN-based QoS). Microflow policing is not supported on egress. Sample configurations are provided in the Configure and Monitor Policing in CatOS Software section and Configure and Monitor Policing in Cisco IOS Software section of this document. 
    121  
    122 Per-user microflow policing. The Supervisor 720 supports an enhancement to microflow policing known as per-user microflow policing. This feature is only supported with Cisco IOS System Software. It allows you to provide a certain bandwidth for each user (per IP address) behind given interfaces. This is achieved by specifying a flow mask inside the service policy. The flow mask defines which information is used to differentiate between the flows. For example, if you specify a source-only flow mask, all traffic from one IP address is considered one flow. Using this technique, you can police traffic per user on some interfaces (where you have configured the corresponding service policy); on other interfaces, you continue to use the default flow mask. It is possible to have up to two different QoS flow masks active in the system at a given time. You can associate only one class with one flow mask. A policy can have up to two different flow masks. 
    123  
    124 Another important change in policing on the Supervisor Engine 720 is that it can count traffic by the L2 length of the frame. This differs from the Supervisor Engine 2 and Supervisor Engine 1, which count IP and IPX frames by their L3 length. With some applications, L2 and L3 length may not be consistent. One example is a small L3 packet inside a large L2 frame. In this case, the Supervisor Engine 720 may display a slightly different policed traffic rate as compared with the Supervisor Engine 1 and Supervisor Engine 2. 
    125  
    126  
    127 == Configuring and Monitoring Policing in Cisco IOS Software == 
    128  
    129 The configuration for policing in Cisco IOS Software involves these steps: 
    130  
    131 Define a policer. 
    132  
    133 Create an ACL to select traffic to police. 
    134  
    135 Define a class map to select traffic with ACL and/or DSCP/IP precedence. 
    136  
    137 Define a service policy that uses class, and apply the policer to a specified class. 
    138  
    139 Apply the service policy to a port or VLAN. 
    140  
    141 Consider the same example as that provided in the section Configure and Monitor Policing in CatOS Software, but now with Cisco IOS Software. For this example, you have a traffic generator attached to port 2/8. It sends 17 Mbps of UDP traffic with destination port 111: 
    142  
    143 {{{ 
    144 Catalyst 6500/6000 
    145  
    146 mls qos 
    147  
    148 !--- This enables QoS. 
    149  
    150 mls qos aggregate-policer udp_1mbps 1000000 2000 conform-action  
    151 transmit exceed-action drop 
    152  
    153 !--- Note: The above command should be on one line. 
    154  
    155 !--- This defines a policer. For the calculation of rate and burst, 
    156 !--- refer to Calculate Parameters. 
    157 !--- Note: The burst is 2000 instead of 1518, due to hardware granularity. 
    158  
    159 access-list 111 permit udp any any eq 111 
    160  
    161 !--- This defines the ACL to select traffic. 
    162  
    163 class-map match-all udp_qos 
    164 match access-group 111 
    165  
    166 !--- This defines the traffic class to police. 
    167  
    168 policy-map udp_policy 
    169 class udp_qos  
    170 police aggregate udp_1mbps 
    171  
    172 !--- This defines the QoS policy that attaches the policer to the traffic class. 
    173  
    174 interface GigabitEthernet2/8 
    175 switchport 
    176 service-policy input udp_policy 
    177  
    178 !--- This applies the QoS policy to an interface. 
    179 }}} 
    180 There are two types of aggregate policers in Cisco IOS Software: named and per-interface. The named aggregate policer polices the traffic combined from all interfaces to which it is applied. This is the type used in the above example. The per-interface policer polices traffic separately on each inbound interface to which it is applied. A per-interface policer is defined within the policy map configuration. Consider this example, which has a per-interface aggregate policer: 
    181  
    182 {{{ 
    183 Catalyst 6500/6000 
    184  
    185 mls qos 
    186  
    187 !--- This enables QoS. 
    188  
    189 access-list 111 permit udp any any eq 111 
    190  
    191 !--- This defines the ACL to select traffic. 
    192  
    193 class-map match-all udp_qos 
    194 match access-group 111 
    195  
    196 !--- This defines the traffic class to police. 
    197  
    198 policy-map udp_policy 
    199 class udp_qos 
    200  
    201 !--- This defines the QoS policy that attaches the policer to the traffic class. 
    202  
    203 police 1000000 2000 2000 conform-action transmit exceed-action drop 
    204  
    205 !--- This creates a per-interface aggregate 
    206 !--- policer and applies it to the traffic class. 
    207  
    208 interface GigabitEthernet2/8 
    209 switchport 
    210 service-policy input udp_policy 
    211  
    212 !--- This applies the QoS policy to an interface. 
    213 }}} 
    214 Microflow policers are defined within the policy map configuration, as are per-interface aggregate policers. In the example below, every flow from host 192.168.2.2 that comes into VLAN 2 is policed to 100 kbps. All traffic from 192.168.2.2 is policed to 500 kbps aggregate. VLAN 2 includes interfaces fa4/11 and fa4/12: 
    215  
    216 {{{ 
    217 Catalyst 6500/6000 
    218  
    219 mls qos 
    220  
    221 !--- This enables QoS. 
    222  
    223 access-list 1 permit 192.168.2.2 
    224  
    225 !--- This defines the access list to select traffic from host 192.168.2.2. 
    226  
    227 class-map match-all host_2_2 
    228 match access-group 1 
    229  
    230 !--- This defines the traffic class to police. 
    231  
    232 policy-map host 
    233 class host_2_2 
    234  
    235 !--- This defines the QoS policy. 
    236  
    237 police flow 100000 2000 conform-action transmit exceed-action drop 
    238  
    239 !--- This defines a microflow policer. For the calculation of rate and 
    240 !--- burst, refer to Calculate Parameters. 
    241  
    242 police 500000 2000 2000 conform-action transmit exceed-action drop 
    243  
    244 !--- This defines the aggregate policer to limit 
    245 !--- traffic from the host to 500 kbps aggregate. 
    246  
    247 interface fa4/11 
    248 mls qos vlan-based 
    249 interface fa4/12 
    250 mls qos vlan-based 
    251  
    252 !--- This configures interfaces in VLAN 2 for VLAN-based QoS. 
    253  
    254 interface vlan 2 
    255 service-policy input host 
    256  
    257 !--- This applies the QoS policy to VLAN 2. 
    258 }}} 
    259  
    260 The example below shows a configuration for egress policing for the Supervisor Engine 720. It establishes the policing of all outbound traffic on interface Gigabit Ethernet 8/6 to 100 kbps: 
    261  
    262 {{{ 
    263 Catalyst 6500/6000 
    264  
    265 mls qos 
    266  
    267 !--- This enables QoS. 
    268  
    269 access-list 111 permit ip any any 
    270  
    271 !--- This defines the ACL to select traffic. All IP traffic is subject to policing. 
    272  
    273 class-map match-all cl_out 
    274  match access-group 111 
    275  
    276 !--- This defines the traffic class to police. 
    277  
    278 policy-map pol_out 
    279 class cl_out 
    280 police 100000 3000 3000 conform-action transmit exceed-action drop 
    281  
    282 !--- This creates a policer and attaches it to the traffic class. 
    283  
    284 interface GigabitEthernet8/6 
    285 ip address 3.3.3.3 255.255.255.0 
    286 service-policy output pol_out 
    287  
    288 !--- This attaches the policy to an interface. 
    289 }}} 
    290  
    291 The example below shows a configuration for per-user policing for the Supervisor Engine 720. Traffic that comes in from users behind port 1/1 toward the Internet is policed to 1 Mbps per user. Traffic that comes from the Internet toward the users is policed to 5 Mbps per user: 
    292  
    293 {{{ 
    294 Catalyst 6500/6000 
    295  
    296 mls qos 
    297  
    298 !--- This enables QoS. 
    299  
    300 access-list 111 permit ip any any 
    301  
    302 !--- This defines the ACL to select user traffic. 
    303  
    304 class-map match-all cl_out 
    305 match access-group 111 
    306  
    307 !--- This defines the traffic class for policing. 
    308  
    309 policy-map pol_out 
    310 class cl_out 
    311 police flow mask src-only 1000000 32000 conform-act transmit exceed-act drop 
    312  
    313 !--- Only the source IP address is considered for flow creation 
    314 !--- on interfaces with this policy attached. 
    315  
    316 interface gigabit 1/1 
    317  
    318 !--- 1/1 is the uplink toward the users. 
    319  
    320 service-policy input pol_out 
    321  
    322 !--- Traffic comes in from users, so the policy is attached 
    323 !--- in the input direction. 
    324  
    325 class-map match-all cl_in 
    326 match access-group 111 
    327 policy-map pol_in 
    328 class cl_in 
    329 police flow mask dest-only 5000000 32000 conform-act transmit exceed-act drop 
    330  
    331 !--- Only the destination IP address is considered for flow creation 
    332 !--- on interfaces with this policy attached. 
    333  
    334 interface gigabit 1/2 
    335  
    336 !--- 1/2 is the uplink to the Internet. 
    337 service-policy input pol_in 
    338 }}} 
    339 To monitor policing, you can use these commands: 
    340 {{{ 
    341 bratan# show mls qos  
    342 QoS is enabled globally 
    343 Microflow policing is enabled globally 
    344 QoS global counters: 
    345 Total packets: 10779 
    346 IP shortcut packets: 0 
    347 Packets dropped by policing: 2110223 
    348 IP packets with TOS changed by policing: 0 
    349 IP packets with COS changed by policing: 0 
    350 Non-IP packets with COS changed by policing: 0 
    351  
    352 bratan# show mls qos ip gigabitethernet 2/8 
    353 [In] Policy map is udp_policy [Out] Default. 
    354 QoS Summary [IP]: (* - shared aggregates, Mod - switch module) 
    355  
    356 Int   Mod Dir Class-map DSCP AgId Trust FlId AgForward-Pk AgPoliced-Pk 
    357 ------------------------------------------------------------------------------ 
    358 Gi2/8 1   In  udp_qos   0    1*   No    0        127451           2129602 
    359  
    360  
    361 bratan# show mls qos ip gigabitethernet 2/8 
    362 [In] Policy map is udp_policy [Out] Default. 
    363 QoS Summary [IP]: (* - shared aggregates, Mod - switch module) 
    364  
    365 Int   Mod Dir Class-map DSCP AgId Trust FlId AgForward-Pk AgPoliced-Pk 
    366 ------------------------------------------------------------------------------ 
    367 Gi2/8 1   In  udp_qos   0    1*   No    0        127755           2134670 
    368  
    369 }}} 
    370  
    371 Note: Allowed packets have increased by 304 and excess packets have increased by 5068. This means that the policer has dropped 5068 packets and allowed 304 to pass through. Given the input rate of 17 Mbps, the policer should pass 1/17 of the traffic. If you compare the dropped and forwarded packets, you see that this has been the case: 304 / (304 + 5068) = 0.057, or roughly 1/17. Some minor variation is possible due to hardware policing granularity. 
    372  
    373 For microflow policing statistics, use the show mls ip detail command: 
    374  
    375 {{{ 
    376 Orion# show mls ip detail 
    377 IP Destination IP Source        Protocol L4 Ports     Vlan Xtag L3-protocol  
    378 --------------+---------------+--------+-------------+----+----+-----------+ 
    379 192.168.3.33    192.168.2.2     udp     555 / 555       0   1           ip  
    380 192.168.3.3     192.168.2.2     udp     63 / 63         0   1           ip  
    381  
    382 [IN/OUT] Ports Encapsulation RW-Vlan RW-MACSource       RW-MACDestination       Bytes  
    383 --------------+-------------+-------+--------------+-----------------+------------+ 
    384 Fa4/11 - ----   ARPA            3    0030.7137.1000  0000.3333.3333     314548  
    385 Fa4/11 - ----   ARPA            3    0030.7137.1000  0000.2222.2222     314824  
    386  
    387 Packets      Age   Last Seen    QoS      Police Count Threshold Leak  
    388 ------------+-----+---------+-----------+------------+---------+-----------+ 
    389 6838         36    18:50:09     0x80      346197        62*2^5   3*2^0  
    390 6844         36    18:50:09     0x80      346695        62*2^5   3*2^0  
    391  
    392 Drop Bucket  Use-Tbl Use-Enable 
    393 ----+-------+-------+----------+ 
    394 YES   1968     NO       NO 
    395 YES   1937     NO       NO 
    396  
    397 }}} 
    398 Note: The Police Count field shows the number of policed packets per flow. 
    399  
    4001= BEN Example (vlan based) = 
    4012{{{ 
     
    417186509-Duke(config-if)#end 
    418196509-Duke#sh mls qos ip vlan 100 
    419  
    420 }}} 
     20}}} 
     21 
     22= Introduction = 
     23 
     24QoS policing on a network determines whether network traffic is within a specified profile (contract). This may cause out-of-profile traffic to drop or to be marked down to another differentiated services code point (DSCP) value to enforce a contracted service level. (DSCP is a measure of the QoS level of the frame.) 
     25 
     26Do not confuse traffic policing with traffic shaping. Both ensure that traffic stays within the profile (contract). You do not buffer out-of-profile packets when you police traffic. Therefore, you do not affect transmission delay. You either drop the traffic or mark it with a lower QoS level (DSCP markdown). In contrast, with traffic shaping, you buffer out-of-profile traffic and smooth the traffic bursts. This affects the delay and delay variation. You can only apply traffic shaping on an outbound interface. You can apply policing on both inbound and outbound interfaces. 
     27 
     28The Catalyst 6500/6000 Policy Feature Card (PFC) and PFC2 only support ingress policing. The PFC3 supports both ingress and egress policing. Traffic shaping is only supported on certain WAN modules for the Catalyst 6500/7600 series, such as the Optical Services Modules (OSMs) and FlexWAN modules. Refer to the Cisco 7600 Series Router Module Configuration Notes for more information 
     29 
     30== QoS Policing Parameters == 
     31 
     32To set up policing, you define the policers and apply them to ports (port-based QoS) or to VLANs (VLAN-based QoS). Each policer defines a name, type, rate, burst, and actions for in-profile and out-of-profile traffic. Policers on Supervisor Engine II also support excess rate parameters. There are two types of policers: microflow and aggregate. 
     33 
     34 * Microflow—police traffic for each applied port/VLAN separately on a per-flow basis. 
     35 
     36 * Aggregate—police traffic across all of the applied ports/VLANs. 
     37 
     38Each policer can be applied to several ports or VLANs. The flow is defined using these parameters: 
     39 
     40 * source IP address 
     41 
     42 * destination IP address 
     43 
     44 * Layer 4 protocol (such as User Datagram Protocol [UDP]) 
     45 
     46 * source port number 
     47 
     48 * destination port number 
     49 
     50You can say that packets that match a particular set of defined parameters belong to the same flow. (This is essentially the same flow concept as that which NetFlow switching uses.) 
     51 
     52As an example, if you configure a microflow policer to limit the TFTP traffic to 1 Mbps on VLAN 1 and VLAN 3, then 1 Mbps is allowed for each flow in VLAN 1 and 1 Mbps for each flow in VLAN 3. In other words, if there are three flows in VLAN 1 and four flows in VLAN 3, the microflow policer allows each of these flows 1 Mbps. If you configure an aggregate policer, it limits the TFTP traffic for all flows combined on VLAN 1 and VLAN 3 to 1 Mbps. 
     53 
     54If you apply both aggregate and microflow policers, QoS always takes the most severe action specified by the policers. For example, if one policer specifies to drop the packet, but another specifies to mark down the packet, the packet is dropped. 
     55 
     56By default, microflow policers work only with routed (Layer 3 [L3]) traffic. To police bridged (Layer 2 [L2]) traffic as well, you need to enable bridged microflow policing. On the Supervisor Engine II, you need to enable bridged microflow policing even for L3 microflow policing. 
     57 
     58Policing is protocol-aware. All traffic is divided into three types: 
     59 
     60 * IP 
     61 
     62 * Internetwork Packet Exchange (IPX) 
     63 
     64 * Other 
     65 
     66Policing is implemented on the Catalyst 6500/6000 according to a "leaky bucket" concept. Tokens corresponding to inbound traffic packets are placed into a bucket. (Each token represents a bit, so a large packet is represented by more tokens than a small packet.) At regular intervals, a defined number of tokens are removed from the bucket and sent on their way. If there is no place in the bucket to accommodate inbound packets, the packets are considered out-of-profile. They are either dropped or marked down according to the configured policing action. 
     67 
     68 
     69Note: The traffic is not buffered in the bucket, as it may appear in the image above. The actual traffic does not go through the bucket at all; the bucket is only used to decide whether the packet is in-profile or out-of-profile. 
     70 
     71== Calculate Parameters == 
     72 
     73Several parameters control the operation of the token bucket, as shown here: 
     74 
     75Rate—defines how many tokens are removed at each interval. This effectively sets the policing rate. All traffic below the rate is considered in-profile. 
     76 
     77Interval—defines how often tokens are removed from the bucket. The interval is fixed at 0.00025 seconds, so tokens are removed from the bucket 4,000 times per second. The interval cannot be changed. 
     78 
     79Burst—defines the maximum number of tokens that the bucket can hold at any one time. To sustain the specified traffic rate, burst should be no less than the rate times the interval. Another consideration is that the maximum-size packet must fit into the bucket. 
     80 
     81To determine the burst parameter, use this equation: 
     82 
     83Burst = (Rate [bps]) * 0.00025 [sec/interval]) or (maximum packet size [bits]), whichever is greater. 
     84 
     85For example, if you want to calculate the minimum burst value needed to sustain a rate of 1 Mbps on an Ethernet network, the rate is defined as 1 Mbps and the maximum Ethernet packet size is 1518 bytes. The equation is: 
     86 
     87Burst = (1,000,000 bps * 0.00025) or (1518 bytes * 8 bits/byte) = 250 or 12144. 
     88 
     89The larger result is 12144, which you round to 13 kbps. 
     90 
     91Note: In Cisco IOS® Software, the policing rate is defined in bits per second (bps), as opposed to kbps in Catalyst OS (CatOS). Also in Cisco IOS Software, the burst rate is defined in bytes, as opposed to kilobits in CatOS. 
     92 
     93Note: Due to hardware policing granularity, the exact rate and burst is rounded to the nearest supported value. Be sure that the burst value is not less than the maximum-size packet. Otherwise, all packets larger than the burst size are dropped. 
     94 
     95For example, if you try to set the burst to 1518 in Cisco IOS Software, it is rounded to 1000. This causes all frames larger than 1000 bytes to be dropped. The solution is to configure burst to 2000. 
     96 
     97When you configure the burst rate, take into account that some protocols (like TCP) implement a flow-control mechanism that reacts to packet loss. For example, TCP reduces windowing by half for each lost packet. Consequently, when policed to a certain rate, the effective link utilization is lower than the configured rate. You can increase the burst to achieve better utilization. A good start for such traffic is to double the burst size. (In this example, the burst size is increased from 13 kbps to 26 kbps). Then, monitor performance and make further adjustments if needed. 
     98 
     99For the same reason, it is not recommended to benchmark the policer operation using connection-oriented traffic. This generally shows lower performance than the policer permits. 
     100 
     101== Policy Actions == 
     102 
     103As mentioned in the Introduction, the policer can do one of two things to an out-of-profile packet: 
     104 
     105drop the packet (the drop parameter in the configuration) 
     106 
     107mark the packet to a lower DSCP (the policed-dscp parameter in the configuration) 
     108 
     109To mark down the packet, you must modify the policed DSCP map. The policed DSCP is set by default to remark the packet to the same DSCP. (No mark down occurs.) 
     110 
     111Note: If "out-of-profile" packets are marked down to a DSCP that is mapped into a different output queue than the original DSCP, some packets may be sent out of order. For this reason, if the order of packets is important, it is recommended to mark down out-of-profile packets to a DSCP that is mapped to the same output queue as in-profile packets. 
     112 
     113On the Supervisor Engine II, which supports excess rate, two triggers are possible: 
     114 
     115When traffic exceeds normal rate 
     116 
     117When traffic exceeds excess rate 
     118 
     119One example of the application of excess rate is to mark down packets that exceed the normal rate and drop packets that exceed the excess rate. 
     120 
     121Policing Features Supported by the Catalyst 6500/6000 
     122 
     123As stated in the Introduction, the PFC1 on the Supervisor Engine 1a and the PFC2 on the Supervisor Engine 2 only support ingress (inbound interface) policing. The PFC3 on the Supervisor Engine 720 supports both ingress and egress (outbound interface) policing. 
     124 
     125The Catalyst 6500/6000 supports up to 63 microflow policers and up to 1023 aggregate policers. 
     126 
     127The Supervisor Engine 1a supports ingress policing, starting with CatOS version 5.3(1) and Cisco IOS Software Release 12.0(7)XE. 
     128 
     129Note: A PFC or PFC2 daughter card is required for policing with the Supervisor Engine 1a. 
     130 
     131The Supervisor Engine 2 supports ingress policing, starting with CatOS version 6.1(1) and Cisco IOS Software Release 12.1(5c)EX. The Supervisor Engine II supports the excess rate policing parameter. 
     132 
     133Configurations with Distributed Forwarding Cards (DFCs) only support port-based policing. Also, the aggregate policer only counts traffic on a per-forwarding-engine basis, not per-system. The DFC and PFC are both forwarding engines; if a module (line card) does not have a DFC, it uses a PFC as a forwarding engine. 
     134 
     135Policing Features Update for Supervisor Engine 720 
     136 
     137Note: If you are unfamiliar with Catalyst 6500/6000 QoS policing, be sure to read the QoS Policing Parameters and Policing Features Supported by the Catalyst 6500/6000 sections of this document. 
     138 
     139The Supervisor Engine 720 introduced these new QoS policing features: 
     140 
     141Egress policing. The Supervisor 720 supports ingress policing on a port or VLAN interface. It supports egress policing on a port or L3 routed interface (in the case of Cisco IOS System Software). All ports in the VLAN are policed on egress regardless of the port QoS mode (whether port-based QoS or VLAN-based QoS). Microflow policing is not supported on egress. Sample configurations are provided in the Configure and Monitor Policing in CatOS Software section and Configure and Monitor Policing in Cisco IOS Software section of this document. 
     142 
     143Per-user microflow policing. The Supervisor 720 supports an enhancement to microflow policing known as per-user microflow policing. This feature is only supported with Cisco IOS System Software. It allows you to provide a certain bandwidth for each user (per IP address) behind given interfaces. This is achieved by specifying a flow mask inside the service policy. The flow mask defines which information is used to differentiate between the flows. For example, if you specify a source-only flow mask, all traffic from one IP address is considered one flow. Using this technique, you can police traffic per user on some interfaces (where you have configured the corresponding service policy); on other interfaces, you continue to use the default flow mask. It is possible to have up to two different QoS flow masks active in the system at a given time. You can associate only one class with one flow mask. A policy can have up to two different flow masks. 
     144 
     145Another important change in policing on the Supervisor Engine 720 is that it can count traffic by the L2 length of the frame. This differs from the Supervisor Engine 2 and Supervisor Engine 1, which count IP and IPX frames by their L3 length. With some applications, L2 and L3 length may not be consistent. One example is a small L3 packet inside a large L2 frame. In this case, the Supervisor Engine 720 may display a slightly different policed traffic rate as compared with the Supervisor Engine 1 and Supervisor Engine 2. 
     146 
     147 
     148== Configuring and Monitoring Policing in Cisco IOS Software == 
     149 
     150The configuration for policing in Cisco IOS Software involves these steps: 
     151 
     152Define a policer. 
     153 
     154Create an ACL to select traffic to police. 
     155 
     156Define a class map to select traffic with ACL and/or DSCP/IP precedence. 
     157 
     158Define a service policy that uses class, and apply the policer to a specified class. 
     159 
     160Apply the service policy to a port or VLAN. 
     161 
     162Consider the same example as that provided in the section Configure and Monitor Policing in CatOS Software, but now with Cisco IOS Software. For this example, you have a traffic generator attached to port 2/8. It sends 17 Mbps of UDP traffic with destination port 111: 
     163 
     164{{{ 
     165Catalyst 6500/6000 
     166 
     167mls qos 
     168 
     169!--- This enables QoS. 
     170 
     171mls qos aggregate-policer udp_1mbps 1000000 2000 conform-action  
     172transmit exceed-action drop 
     173 
     174!--- Note: The above command should be on one line. 
     175 
     176!--- This defines a policer. For the calculation of rate and burst, 
     177!--- refer to Calculate Parameters. 
     178!--- Note: The burst is 2000 instead of 1518, due to hardware granularity. 
     179 
     180access-list 111 permit udp any any eq 111 
     181 
     182!--- This defines the ACL to select traffic. 
     183 
     184class-map match-all udp_qos 
     185match access-group 111 
     186 
     187!--- This defines the traffic class to police. 
     188 
     189policy-map udp_policy 
     190class udp_qos  
     191police aggregate udp_1mbps 
     192 
     193!--- This defines the QoS policy that attaches the policer to the traffic class. 
     194 
     195interface GigabitEthernet2/8 
     196switchport 
     197service-policy input udp_policy 
     198 
     199!--- This applies the QoS policy to an interface. 
     200}}} 
     201There are two types of aggregate policers in Cisco IOS Software: named and per-interface. The named aggregate policer polices the traffic combined from all interfaces to which it is applied. This is the type used in the above example. The per-interface policer polices traffic separately on each inbound interface to which it is applied. A per-interface policer is defined within the policy map configuration. Consider this example, which has a per-interface aggregate policer: 
     202 
     203{{{ 
     204Catalyst 6500/6000 
     205 
     206mls qos 
     207 
     208!--- This enables QoS. 
     209 
     210access-list 111 permit udp any any eq 111 
     211 
     212!--- This defines the ACL to select traffic. 
     213 
     214class-map match-all udp_qos 
     215match access-group 111 
     216 
     217!--- This defines the traffic class to police. 
     218 
     219policy-map udp_policy 
     220class udp_qos 
     221 
     222!--- This defines the QoS policy that attaches the policer to the traffic class. 
     223 
     224police 1000000 2000 2000 conform-action transmit exceed-action drop 
     225 
     226!--- This creates a per-interface aggregate 
     227!--- policer and applies it to the traffic class. 
     228 
     229interface GigabitEthernet2/8 
     230switchport 
     231service-policy input udp_policy 
     232 
     233!--- This applies the QoS policy to an interface. 
     234}}} 
     235Microflow policers are defined within the policy map configuration, as are per-interface aggregate policers. In the example below, every flow from host 192.168.2.2 that comes into VLAN 2 is policed to 100 kbps. All traffic from 192.168.2.2 is policed to 500 kbps aggregate. VLAN 2 includes interfaces fa4/11 and fa4/12: 
     236 
     237{{{ 
     238Catalyst 6500/6000 
     239 
     240mls qos 
     241 
     242!--- This enables QoS. 
     243 
     244access-list 1 permit 192.168.2.2 
     245 
     246!--- This defines the access list to select traffic from host 192.168.2.2. 
     247 
     248class-map match-all host_2_2 
     249match access-group 1 
     250 
     251!--- This defines the traffic class to police. 
     252 
     253policy-map host 
     254class host_2_2 
     255 
     256!--- This defines the QoS policy. 
     257 
     258police flow 100000 2000 conform-action transmit exceed-action drop 
     259 
     260!--- This defines a microflow policer. For the calculation of rate and 
     261!--- burst, refer to Calculate Parameters. 
     262 
     263police 500000 2000 2000 conform-action transmit exceed-action drop 
     264 
     265!--- This defines the aggregate policer to limit 
     266!--- traffic from the host to 500 kbps aggregate. 
     267 
     268interface fa4/11 
     269mls qos vlan-based 
     270interface fa4/12 
     271mls qos vlan-based 
     272 
     273!--- This configures interfaces in VLAN 2 for VLAN-based QoS. 
     274 
     275interface vlan 2 
     276service-policy input host 
     277 
     278!--- This applies the QoS policy to VLAN 2. 
     279}}} 
     280 
     281The example below shows a configuration for egress policing for the Supervisor Engine 720. It establishes the policing of all outbound traffic on interface Gigabit Ethernet 8/6 to 100 kbps: 
     282 
     283{{{ 
     284Catalyst 6500/6000 
     285 
     286mls qos 
     287 
     288!--- This enables QoS. 
     289 
     290access-list 111 permit ip any any 
     291 
     292!--- This defines the ACL to select traffic. All IP traffic is subject to policing. 
     293 
     294class-map match-all cl_out 
     295 match access-group 111 
     296 
     297!--- This defines the traffic class to police. 
     298 
     299policy-map pol_out 
     300class cl_out 
     301police 100000 3000 3000 conform-action transmit exceed-action drop 
     302 
     303!--- This creates a policer and attaches it to the traffic class. 
     304 
     305interface GigabitEthernet8/6 
     306ip address 3.3.3.3 255.255.255.0 
     307service-policy output pol_out 
     308 
     309!--- This attaches the policy to an interface. 
     310}}} 
     311 
     312The example below shows a configuration for per-user policing for the Supervisor Engine 720. Traffic that comes in from users behind port 1/1 toward the Internet is policed to 1 Mbps per user. Traffic that comes from the Internet toward the users is policed to 5 Mbps per user: 
     313 
     314{{{ 
     315Catalyst 6500/6000 
     316 
     317mls qos 
     318 
     319!--- This enables QoS. 
     320 
     321access-list 111 permit ip any any 
     322 
     323!--- This defines the ACL to select user traffic. 
     324 
     325class-map match-all cl_out 
     326match access-group 111 
     327 
     328!--- This defines the traffic class for policing. 
     329 
     330policy-map pol_out 
     331class cl_out 
     332police flow mask src-only 1000000 32000 conform-act transmit exceed-act drop 
     333 
     334!--- Only the source IP address is considered for flow creation 
     335!--- on interfaces with this policy attached. 
     336 
     337interface gigabit 1/1 
     338 
     339!--- 1/1 is the uplink toward the users. 
     340 
     341service-policy input pol_out 
     342 
     343!--- Traffic comes in from users, so the policy is attached 
     344!--- in the input direction. 
     345 
     346class-map match-all cl_in 
     347match access-group 111 
     348policy-map pol_in 
     349class cl_in 
     350police flow mask dest-only 5000000 32000 conform-act transmit exceed-act drop 
     351 
     352!--- Only the destination IP address is considered for flow creation 
     353!--- on interfaces with this policy attached. 
     354 
     355interface gigabit 1/2 
     356 
     357!--- 1/2 is the uplink to the Internet. 
     358service-policy input pol_in 
     359}}} 
     360To monitor policing, you can use these commands: 
     361{{{ 
     362bratan# show mls qos  
     363QoS is enabled globally 
     364Microflow policing is enabled globally 
     365QoS global counters: 
     366Total packets: 10779 
     367IP shortcut packets: 0 
     368Packets dropped by policing: 2110223 
     369IP packets with TOS changed by policing: 0 
     370IP packets with COS changed by policing: 0 
     371Non-IP packets with COS changed by policing: 0 
     372 
     373bratan# show mls qos ip gigabitethernet 2/8 
     374[In] Policy map is udp_policy [Out] Default. 
     375QoS Summary [IP]: (* - shared aggregates, Mod - switch module) 
     376 
     377Int   Mod Dir Class-map DSCP AgId Trust FlId AgForward-Pk AgPoliced-Pk 
     378------------------------------------------------------------------------------ 
     379Gi2/8 1   In  udp_qos   0    1*   No    0        127451           2129602 
     380 
     381 
     382bratan# show mls qos ip gigabitethernet 2/8 
     383[In] Policy map is udp_policy [Out] Default. 
     384QoS Summary [IP]: (* - shared aggregates, Mod - switch module) 
     385 
     386Int   Mod Dir Class-map DSCP AgId Trust FlId AgForward-Pk AgPoliced-Pk 
     387------------------------------------------------------------------------------ 
     388Gi2/8 1   In  udp_qos   0    1*   No    0        127755           2134670 
     389 
     390}}} 
     391 
     392Note: Allowed packets have increased by 304 and excess packets have increased by 5068. This means that the policer has dropped 5068 packets and allowed 304 to pass through. Given the input rate of 17 Mbps, the policer should pass 1/17 of the traffic. If you compare the dropped and forwarded packets, you see that this has been the case: 304 / (304 + 5068) = 0.057, or roughly 1/17. Some minor variation is possible due to hardware policing granularity. 
     393 
     394For microflow policing statistics, use the show mls ip detail command: 
     395 
     396{{{ 
     397Orion# show mls ip detail 
     398IP Destination IP Source        Protocol L4 Ports     Vlan Xtag L3-protocol  
     399--------------+---------------+--------+-------------+----+----+-----------+ 
     400192.168.3.33    192.168.2.2     udp     555 / 555       0   1           ip  
     401192.168.3.3     192.168.2.2     udp     63 / 63         0   1           ip  
     402 
     403[IN/OUT] Ports Encapsulation RW-Vlan RW-MACSource       RW-MACDestination       Bytes  
     404--------------+-------------+-------+--------------+-----------------+------------+ 
     405Fa4/11 - ----   ARPA            3    0030.7137.1000  0000.3333.3333     314548  
     406Fa4/11 - ----   ARPA            3    0030.7137.1000  0000.2222.2222     314824  
     407 
     408Packets      Age   Last Seen    QoS      Police Count Threshold Leak  
     409------------+-----+---------+-----------+------------+---------+-----------+ 
     4106838         36    18:50:09     0x80      346197        62*2^5   3*2^0  
     4116844         36    18:50:09     0x80      346695        62*2^5   3*2^0  
     412 
     413Drop Bucket  Use-Tbl Use-Enable 
     414----+-------+-------+----------+ 
     415YES   1968     NO       NO 
     416YES   1937     NO       NO 
     417 
     418}}} 
     419Note: The Police Count field shows the number of policed packets per flow. 
     420 
    421421 
    422422=  Path provisioning API =