Changes between Initial Version and Version 1 of VLANQoS

Show
Ignore:
Timestamp:
03/29/10 16:47:31 (9 years ago)
Author:
yxin (IP: 152.54.8.156)
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • VLANQoS

    v1 v1  
     1Introduction 
     2 
     3QoS 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 
     5Do 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 
     7The 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 
     9Prerequisites 
     10 
     11Requirements 
     12 
     13There are no specific requirements for this document. 
     14 
     15Components Used 
     16 
     17This document is not restricted to specific software and hardware versions. 
     18 
     19Conventions 
     20 
     21Refer to the Cisco Technical Tips Conventions for more information on document conventions. 
     22 
     23QoS Policing Parameters 
     24 
     25To 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. 
     26 
     27Microflow—police traffic for each applied port/VLAN separately on a per-flow basis. 
     28 
     29Aggregate—police traffic across all of the applied ports/VLANs. 
     30 
     31Each policer can be applied to several ports or VLANs. The flow is defined using these parameters: 
     32 
     33source IP address 
     34 
     35destination IP address 
     36 
     37Layer 4 protocol (such as User Datagram Protocol [UDP]) 
     38 
     39source port number 
     40 
     41destination port number 
     42 
     43You 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.) 
     44 
     45As 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. 
     46 
     47If 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. 
     48 
     49By 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. 
     50 
     51Policing is protocol-aware. All traffic is divided into three types: 
     52 
     53IP 
     54 
     55Internetwork Packet Exchange (IPX) 
     56 
     57Other 
     58 
     59Policing 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. 
     60 
     61 
     62 
     63Note: 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. 
     64 
     65Calculate Parameters 
     66 
     67Several parameters control the operation of the token bucket, as shown here: 
     68 
     69Rate—defines how many tokens are removed at each interval. This effectively sets the policing rate. All traffic below the rate is considered in-profile. 
     70 
     71Interval—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. 
     72 
     73Burst—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. 
     74 
     75To determine the burst parameter, use this equation: 
     76 
     77Burst = (Rate [bps]) * 0.00025 [sec/interval]) or (maximum packet size [bits]), whichever is greater. 
     78 
     79For 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: 
     80 
     81Burst = (1,000,000 bps * 0.00025) or (1518 bytes * 8 bits/byte) = 250 or 12144. 
     82 
     83The larger result is 12144, which you round to 13 kbps. 
     84 
     85Note: 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. 
     86 
     87Note: 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. 
     88 
     89For 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. 
     90 
     91When 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. 
     92 
     93For 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. 
     94 
     95Police Actions 
     96 
     97As mentioned in the Introduction, the policer can do one of two things to an out-of-profile packet: 
     98 
     99drop the packet (the drop parameter in the configuration) 
     100 
     101mark the packet to a lower DSCP (the policed-dscp parameter in the configuration) 
     102 
     103To 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.) 
     104 
     105Note: 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. 
     106 
     107On the Supervisor Engine II, which supports excess rate, two triggers are possible: 
     108 
     109When traffic exceeds normal rate 
     110 
     111When traffic exceeds excess rate 
     112 
     113One 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. 
     114 
     115Policing Features Supported by the Catalyst 6500/6000 
     116 
     117As 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. 
     118 
     119The Catalyst 6500/6000 supports up to 63 microflow policers and up to 1023 aggregate policers. 
     120 
     121The Supervisor Engine 1a supports ingress policing, starting with CatOS version 5.3(1) and Cisco IOS Software Release 12.0(7)XE. 
     122 
     123Note: A PFC or PFC2 daughter card is required for policing with the Supervisor Engine 1a. 
     124 
     125The 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. 
     126 
     127Configurations 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. 
     128 
     129Policing Features Update for Supervisor Engine 720 
     130 
     131Note: 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. 
     132 
     133The Supervisor Engine 720 introduced these new QoS policing features: 
     134 
     135Egress 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. 
     136 
     137Per-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. 
     138 
     139Another 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. 
     140 
     141 
     142Configure and Monitor Policing in Cisco IOS Software 
     143 
     144The configuration for policing in Cisco IOS Software involves these steps: 
     145 
     146Define a policer. 
     147 
     148Create an ACL to select traffic to police. 
     149 
     150Define a class map to select traffic with ACL and/or DSCP/IP precedence. 
     151 
     152Define a service policy that uses class, and apply the policer to a specified class. 
     153 
     154Apply the service policy to a port or VLAN. 
     155 
     156Consider 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: 
     157 
     158Catalyst 6500/6000 
     159 
     160mls qos 
     161 
     162!--- This enables QoS. 
     163 
     164mls qos aggregate-policer udp_1mbps 1000000 2000 conform-action  
     165transmit exceed-action drop 
     166 
     167!--- Note: The above command should be on one line. 
     168 
     169!--- This defines a policer. For the calculation of rate and burst, 
     170!--- refer to Calculate Parameters. 
     171!--- Note: The burst is 2000 instead of 1518, due to hardware granularity. 
     172 
     173access-list 111 permit udp any any eq 111 
     174 
     175!--- This defines the ACL to select traffic. 
     176 
     177class-map match-all udp_qos 
     178match access-group 111 
     179 
     180!--- This defines the traffic class to police. 
     181 
     182policy-map udp_policy 
     183class udp_qos  
     184police aggregate udp_1mbps 
     185 
     186!--- This defines the QoS policy that attaches the policer to the traffic class. 
     187 
     188interface GigabitEthernet2/8 
     189switchport 
     190service-policy input udp_policy 
     191 
     192!--- This applies the QoS policy to an interface. 
     193 
     194There 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: 
     195 
     196Catalyst 6500/6000 
     197 
     198mls qos 
     199 
     200!--- This enables QoS. 
     201 
     202access-list 111 permit udp any any eq 111 
     203 
     204!--- This defines the ACL to select traffic. 
     205 
     206class-map match-all udp_qos 
     207match access-group 111 
     208 
     209!--- This defines the traffic class to police. 
     210 
     211policy-map udp_policy 
     212class udp_qos 
     213 
     214!--- This defines the QoS policy that attaches the policer to the traffic class. 
     215 
     216police 1000000 2000 2000 conform-action transmit exceed-action drop 
     217 
     218!--- This creates a per-interface aggregate 
     219!--- policer and applies it to the traffic class. 
     220 
     221interface GigabitEthernet2/8 
     222switchport 
     223service-policy input udp_policy 
     224 
     225!--- This applies the QoS policy to an interface. 
     226 
     227Microflow 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: 
     228 
     229Catalyst 6500/6000 
     230 
     231mls qos 
     232 
     233!--- This enables QoS. 
     234 
     235access-list 1 permit 192.168.2.2 
     236 
     237!--- This defines the access list to select traffic from host 192.168.2.2. 
     238 
     239class-map match-all host_2_2 
     240match access-group 1 
     241 
     242!--- This defines the traffic class to police. 
     243 
     244policy-map host 
     245class host_2_2 
     246 
     247!--- This defines the QoS policy. 
     248 
     249police flow 100000 2000 conform-action transmit exceed-action drop 
     250 
     251!--- This defines a microflow policer. For the calculation of rate and 
     252!--- burst, refer to Calculate Parameters. 
     253 
     254police 500000 2000 2000 conform-action transmit exceed-action drop 
     255 
     256!--- This defines the aggregate policer to limit 
     257!--- traffic from the host to 500 kbps aggregate. 
     258 
     259interface fa4/11 
     260mls qos vlan-based 
     261interface fa4/12 
     262mls qos vlan-based 
     263 
     264!--- This configures interfaces in VLAN 2 for VLAN-based QoS. 
     265 
     266interface vlan 2 
     267service-policy input host 
     268 
     269!--- This applies the QoS policy to VLAN 2. 
     270 
     271The 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: 
     272 
     273Catalyst 6500/6000 
     274 
     275mls qos 
     276 
     277!--- This enables QoS. 
     278 
     279access-list 111 permit ip any any 
     280 
     281!--- This defines the ACL to select traffic. All IP traffic is subject to policing. 
     282 
     283class-map match-all cl_out 
     284 match access-group 111 
     285 
     286!--- This defines the traffic class to police. 
     287 
     288policy-map pol_out 
     289class cl_out 
     290police 100000 3000 3000 conform-action transmit exceed-action drop 
     291 
     292!--- This creates a policer and attaches it to the traffic class. 
     293 
     294interface GigabitEthernet8/6 
     295ip address 3.3.3.3 255.255.255.0 
     296service-policy output pol_out 
     297 
     298!--- This attaches the policy to an interface. 
     299 
     300The 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: 
     301 
     302Catalyst 6500/6000 
     303 
     304mls qos 
     305 
     306!--- This enables QoS. 
     307 
     308access-list 111 permit ip any any 
     309 
     310!--- This defines the ACL to select user traffic. 
     311 
     312class-map match-all cl_out 
     313match access-group 111 
     314 
     315!--- This defines the traffic class for policing. 
     316 
     317policy-map pol_out 
     318class cl_out 
     319police flow mask src-only 1000000 32000 conform-act transmit exceed-act drop 
     320 
     321!--- Only the source IP address is considered for flow creation 
     322!--- on interfaces with this policy attached. 
     323 
     324interface gigabit 1/1 
     325 
     326!--- 1/1 is the uplink toward the users. 
     327 
     328service-policy input pol_out 
     329 
     330!--- Traffic comes in from users, so the policy is attached 
     331!--- in the input direction. 
     332 
     333class-map match-all cl_in 
     334match access-group 111 
     335policy-map pol_in 
     336class cl_in 
     337police flow mask dest-only 5000000 32000 conform-act transmit exceed-act drop 
     338 
     339!--- Only the destination IP address is considered for flow creation 
     340!--- on interfaces with this policy attached. 
     341 
     342interface gigabit 1/2 
     343 
     344!--- 1/2 is the uplink to the Internet. 
     345 
     346service-policy input pol_in 
     347To monitor policing, you can use these commands: 
     348 
     349bratan# show mls qos  
     350QoS is enabled globally 
     351Microflow policing is enabled globally 
     352QoS global counters: 
     353Total packets: 10779 
     354IP shortcut packets: 0 
     355Packets dropped by policing: 2110223 
     356IP packets with TOS changed by policing: 0 
     357IP packets with COS changed by policing: 0 
     358Non-IP packets with COS changed by policing: 0 
     359 
     360bratan# show mls qos ip gigabitethernet 2/8 
     361[In] Policy map is udp_policy [Out] Default. 
     362QoS Summary [IP]: (* - shared aggregates, Mod - switch module) 
     363 
     364Int   Mod Dir Class-map DSCP AgId Trust FlId AgForward-Pk AgPoliced-Pk 
     365------------------------------------------------------------------------------ 
     366Gi2/8 1   In  udp_qos   0    1*   No    0        127451           2129602 
     367 
     368 
     369bratan# show mls qos ip gigabitethernet 2/8 
     370[In] Policy map is udp_policy [Out] Default. 
     371QoS Summary [IP]: (* - shared aggregates, Mod - switch module) 
     372 
     373Int   Mod Dir Class-map DSCP AgId Trust FlId AgForward-Pk AgPoliced-Pk 
     374------------------------------------------------------------------------------ 
     375Gi2/8 1   In  udp_qos   0    1*   No    0        127755           2134670 
     376Note: 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. 
     377 
     378For microflow policing statistics, use the show mls ip detail command: 
     379 
     380Orion# show mls ip detail 
     381IP Destination IP Source        Protocol L4 Ports     Vlan Xtag L3-protocol  
     382--------------+---------------+--------+-------------+----+----+-----------+ 
     383192.168.3.33    192.168.2.2     udp     555 / 555       0   1           ip  
     384192.168.3.3     192.168.2.2     udp     63 / 63         0   1           ip  
     385 
     386[IN/OUT] Ports Encapsulation RW-Vlan RW-MACSource       RW-MACDestination       Bytes  
     387--------------+-------------+-------+--------------+-----------------+------------+ 
     388Fa4/11 - ----   ARPA            3    0030.7137.1000  0000.3333.3333     314548  
     389Fa4/11 - ----   ARPA            3    0030.7137.1000  0000.2222.2222     314824  
     390 
     391Packets      Age   Last Seen    QoS      Police Count Threshold Leak  
     392------------+-----+---------+-----------+------------+---------+-----------+ 
     3936838         36    18:50:09     0x80      346197        62*2^5   3*2^0  
     3946844         36    18:50:09     0x80      346695        62*2^5   3*2^0  
     395 
     396Drop Bucket  Use-Tbl Use-Enable 
     397----+-------+-------+----------+ 
     398YES   1968     NO       NO 
     399YES   1937     NO       NO 
     400Note: The Police Count field shows the number of policed packets per flow.