Quality of Service (QoS) provides the capability to differentiate among different classes of traffic and to prioritize the traffic in times of network congestion, according to its relative importance. The primary goals of QoS are to provide guaranteed minimum bandwidth for identified traffic, control jitter and latency (required by some real-time and interactive traffic) and to improve loss characteristics. This paper assumes the reader is familiar with basic QoS concepts such as classification, congestion avoidance, and bandwidth allocation. The objective of this paper is to provide an overview and configuration examples of the rich QoS capabilities available on the Cisco Catalyst 4500 Series supervisor engines.
These QoS capabilities include:
• Traffic Classification and Marking
• Ingress and Egress Policing
– Individual
– Aggregate
– Microflow Policing
– Hierarchical Policing
• Active Queue Management for congestion avoidance
– Dynamic Buffer Limiting
• Per port Egress Queue Scheduling based on:
– Bandwidth Sharing
– Traffic Shaping
– Strict Priority
• Auto QoS (introduced in Cisco IOS Software Release 12.1.19EW)
Figure 1. Cisco Catalyst 4500 Series Supervisor Engine QoS Processing
Figure 1 shows the different QoS stages implemented on the supervisor engines. The Cisco Catalyst 4500 Series uses a centralized switching architecture. As soon as a packet is received, it is placed into a shared memory buffer until the forwarding decision is made. The forwarding decision includes any QoS actions taken on the packet. When the forwarding decision has been made, the packet is rewritten including the appropriate Layer 2 or Layer 3 marking. The packet is then placed into the appropriate transmit queue based on Differentiated Services Code Point (DSCP) value and is scheduled according to the scheduling criteria configured on the interface queue: strict priority, sharing, or shaping. The actual QoS packet processing flow is depicted in Figure 1. However, for the purposes of clarity, this paper will discuss the beginning and the ending processes first: Traffic Classification and Egress Queue Scheduling followed by Policing and Dynamic Buffer Limiting.
TRAFFIC CLASSIFICATION AND MARKING
Ingress traffic is classified at Layers 3 and 4 for IP traffic as well as at Layer 2 for non-IP traffic or traffic coming in on trunk ports. Regardless of whether the incoming packet is Layer 2 or Layer 3, the Supervisor Engine QoS assigns an "internal DSCP" tag to the packet. This internal DSCP value is then used to place the packet into one of four queues for egress scheduling. This internal DSCP value can be derived in several ways. When QoS is globally disabled (default), the incoming packet's DSCP value is trusted. However a Layer 2 packet's class-of-service (CoS) value would be considered untrusted and a CoS value of zero would be used. This CoS value of 0 also maps to a DSCP value of zero. Example 3 shows CoS to DSCP mappings. The egress port queue selection is then based on the global DSCP-to-Transmit (Tx) queue mapping as shown in Example 1.
Example 1. Global DSCP to Egress Port Queue Mapping
For example, if the internal DSCP tag is 46 (D1= 4, D2=6), Tx queue 3 would be used on egress. With QoS globally disabled, the four Tx queues are serviced Round-Robin. The DSCP to Tx queue mappings are fully configurable and again are enabled on a global basis.
With QoS globally enabled, the internal DSCP value used to determine the egress port queue can be derived in several ways:
1. CoS/DSCP port trust state: With QoS globally enabled, the default port trust state for CoS and DSCP is untrusted. This can be changed to trust either DSCP or CoS using the interface command. Trusting the incoming DSCP value is shown in Example 2.
Example 2. Changing the Trust State of a Port
r3_4507R_S4(config-if)#qos trust dscp
When the incoming CoS value is trusted, for non-IP traffic or traffic arriving on a trunk port, the internal DSCP value used for egress scheduling depends on the CoS to DSCP table mapping, which is configurable. The default mapping is can be shown in Example 3.
Example 3. CoS-to-DSCP Mapping
r3_4507R_S4#sh qos maps CoS dscp
CoS-DSCP Mapping Table
CoS: 0 1 2 3 4 5 6 7
--------------------------------
DSCP: 0 8 16 24 32 40 48 56
Trust can also be extended to Cisco IP phones attached to the port as shown in Example 4 (this will be done automatically using Auto QoS, which is discussed later):
2. CoS/DSCP value on the ingress port: With QoS globally enabled, the second way to derive the internal DSCP value used to determine the egress port queue is by using the DSCP or CoS value assigned to the ingress port. The default setting for CoS and DSCP is zero. This may be changed as shown in Example 5.
Example 5. Changing the Port DSCP/CoS Setting
r3_4507R_S4(config-if)#qos CoS ?
<0-7> CoS value
r3_4507R_S4(config-if)#qos dscp ?
<0-63> DSCP value
3. Using access control lists (ACLs) and service policy class maps: With QoS globally enabled, the third way to derive the internal DSCP value that is used to determine the egress port queue is by using a service policy. Service policies are configured using Cisco's Modular QoS CLI (MQC) where a class map is used to identify the traffic of interest, a policy is defined and then assigned to an interface (Example 6). Service policy configuration details can be found in the documentation referenced at the end of this paper.
Example 6. Using a Service Policy to Mark a Packet
access-list 100 permit udp any any
mac access-list extended classify permit host 1234.5678.9abc any protocol-family ipx
class-map match-all class_setprec
match ip access group 100
class-map match-all mac
match access-group name classify
policy-map pol_setprec
class class_setprec
set ip dscp 26
class mac
set ip dscp 24
class mac
set ip dscp 24
interface vlan 2
service-policy input pol_setprec
In Example 6, the policy-map pol_setprec was defined as an input policy. All incoming UDP packets will be classified with a DSCP value of 26. Classification can also be applied using Layer 2 ACLs for Layer 2 or non-IP traffic. In this example, Internetwork Packet Exchange (IPX) packets from a host are being classified with a DSCP of 24. If the service policy was applied as an output policy, the resultant marking would be used by the next hop QoS enabled device. Policy maps may be applied to individual interfaces or on a VLAN wide basis.
VLAN BASED QoS
VLAN based QoS is typically used for trunk ports. Prior to Cisco IOS Software Release 12.2(25)EWA, VLAN based QoS was the only QoS feature used when a single trunk port was part of the system. With Release 12.2(25)EWA, per-Port per-VLAN QoS was introduced, allowing for multiple trunk ports to be defined in the system and have further VLAN QoS granularity configurations. This is discussed in the next section.
The default QoS behavior is per port. Applying a service policy to a VLAN requires changing this default behavior as shown in Example 7.
Example 7. Changing the default QoS port behavior to VLAN Based
Switch(config)# interface FastEthernet3/2
Switch(config-if)# qos vlan-based
Also note that a policy map will override a port trust status. Note that port-based and VLAN based QoS provides flexibility in defining QoS policies. With VLAN based QoS, if one service policy is attached to a port and another to an SVI, the SVI service-policy takes precedence. Note, however, if port-based QoS is specified on certain ports within a VLAN and VLAN based QoS is configured on other ports, the port-based service-policy will take precedence over the SVI service-policy. This provides QoS flexibility because the more general service-policy may be defined for the VLAN and exception service-policies would be defined on the port. Examples 8 and 9 contain a traditional VLAN based QoS configuration on an access port and trunk port.
Example 8. Traditional VLAN Based QoS
Switch(config)# interface FastEthernet3/2
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 2
Switch(config-if)# qos vlan-based
Switch(config-if)# service-policy input P1
!
Switch(config-)# int vlan 2
Switch(config-if)# service-policy input P2
In Example 8, FastEthernet 3/2 has been configured as a QoS VLAN based interface. By doing this, service policy input P2 configuration will take precedence over service policy P1. If a service policy is not defined under the interface vlan, the service policy defined at the port level will take effect.
In Example 9, FastEthernet 3/3 has been configured as a trunk interface with interface VLANs 2-4. Each VLAN has a different service policy defined providing good granularity. However, this feature is limited to only one trunk interface per system. For example, if FastEthernet 3/4 is configured as a trunk interface as well, VLANs 2-4 under this interface would also be subjected to the same service policies defined for VLANs 2-4 in interface FastEthernet 3/3. Per Port per VLAN QoS is an extension to the traditional VLAN based QoS feature, which provides the network administrator the capability to have identical VLANs with different QoS configurations.
PER-PORT PER-VLAN QoS
As stated above, with per-Port per-VLAN QoS, different QoS configurations can be specified on different VLANs for a given set of trunk interfaces. For example, vlan 10 which exists in trunk interface 3/2 and 3/3 can have different service policies P1 and P2 assigned respectively. Per Port Per VLAN QoS is most often used by service providers wanting to provide guaranteed service level agreements (SLAs) with great QoS.
Example 10 shows how to configure multiple trunk interfaces (GigabitEthernet 6/1 and GigabitEthernet 6/2) with different service policies per QoS VLAN.
Example 10. Configuring Multiple Trunk Interfaces with Different Service Policies
Switch# configure terminal
Switch(config)# interface gigabitethernet 6/1
Switch(config-if)# vlan-range 20,400
! The above command specifies the range or specific vlans to which the service policy will be
attached
In Example 10, VLANs 20 and 400 are voice and video VLANs for two different customers attached to two different trunk ports. Each customer receives a different set of QoS configurations using the same VLANs.
When the traffic has been classified and placed in the appropriate Tx queue, it is ready to be scheduled. The packet is scheduled out of the four Tx queues based on Tx queue characteristics such as Strict Priority, Traffic Shaping, or Bandwidth Sharing. This is discussed in the next section.
EGRESS TRAFFIC QUEUING AND SCHEDULING
The Catalyst 4500 Series supervisor engines use a shared memory architecture to provide queuing and scheduling features to the connected line cards. There are two types of gigabit linecards used: blocking and non-blocking (see Table 1). "Non-blocking" simply means none of the front end user ports are oversubscribed in the backplane connection to the Supervisor Engine switch fabric. "Blocking" means there is an oversubscription between the front end user connected ports and the backplane connection to the Supervisor Engine switch fabric. Depending on the linecard, the oversubscription ratio can be either 4: 1 or 8:1. These cards are typically used for high-density Gigabit Ethernet configurations, either directly to a user or in a server farm.
Table 1 shows the blocking and non-blocking Gigabit Ethernet line cards.
Table 1. Blocking and Non-Blocking Gigabit Ethernet Line Cards
Non-Blocking Gigabit Ethernet Line Card
Blocking Gigabit Ethernet Line Card
Oversubscription Ratio for Blocking Line Cards
Supervisor Gigabit Ethernet uplink Ports
All ports on the WS-X4424-GB-RJ45
4:1
WS-X4306-GB-all ports
All ports on the WS-X4448-GB-LX
8:1
Two 1000-BASE-X ports on the WS-X4232-GB-RJ
All ports on the WS-X4448-GB-RJ45
8:1
First two ports on WS-X4418-GB
Last 16 ports on the WS-X4418-GB
4:1
Two 1000-BASE-X ports on the WS-X4412-2GB-T (end of sale card)
1000-BASE-T ports on the WS-X4412-2GB-TX
4:1
WS-X4302-GB-all ports
WS-X4548-GB-RJ45V
8:1
WS-X4506-GB-T
For Supervisor Engines IV, II-Plus, and II-Plus-TS, the transmit queue size for Fast Ethernet ports and blocking gigabit ports is fixed at 240 packets per queue, and 1,920 packets per queue for non-blocking gigabit ports. For the Supervisor Engine V, the transmit queue size for Fast Ethernet ports and blocking Gigabit ports has been increased to 292 packets per queue, and 2,336 packets for non-blocking Gigabit ports.
For Supervisor Engines II-Plus-10GE, and V-10GE, the transmit queue size for Fast Ethernet ports and blocking gigabit ports is fixed at 260 packets per queue, and 2,080 packets per queue for non-blocking gigabit ports and ten gigabit ports.
Note that the queue size is based on the number, not the size of packets. Input queuing on the Cisco Catalyst 4500 Series is unnecessary because the switch fabric is non-blocking (see Table 2).
Table 2. Cisco Catalyst 4500 Switch Fabric and Queue Allocations
Supervisor Engine II-Plus
Supervisor Engine II-Plus-10GE
Supervisor Engine II-Plus-TS
Supervisor Engine IV
Supervisor Engine V
Supervisor Engine V-10GE
Switch fabric
32 Gigabit non-blocking
54 Gigabit non-blocking
32 Gigabit non-blocking
32 Gigabit non-blocking
48 Gigabit non-blocking
68 Gigabit non-blocking
Number of packets per transmit queue Fast Ethernet/ gigabit blocking Ports
240
260
240
240
292
260
Number of packets per transmit queue non-blocking gigabit Ports
1,920
2,080
1,920
1,920
2,336
2,080
Note: The Cisco Catalyst 4500 Series supports IEEE 802.3z flow control to throttle back on the edge devices connected to the blocking Gigabit Ethernet ports in times of congestion when using the blocking line cards.
BANDWIDTH SHARING
All Cisco Catalyst 4500 Series supervisor engines support two ways of allocating bandwidth among the four Tx queues on a port: sharing and shaping. Bandwidth sharing provides a guaranteed minimum bandwidth to each of the four queues. Sharing is supported only on the non-blocking gigabit ports for Supervisor Engines IV, II-Plus, and II-Plus-TS. It is supported on all ports for the Supervisor V, II-Plus-10GE, and V-10GE. Traffic can either be below share, ie. less than its guaranteed minimum, or above share. This fact is important when discussing transmit scheduling. Bandwidth sharing would typically be used to guarantee some minimum bandwidth to a specific application, such as VoIP which has stringent latency and loss requirements, or a high priority business application. When QoS is enabled globally, all four queues on all the non -blocking ports are assigned equal bandwidth for all supervisor engines. With Supervisor Engines V, II-Plus-10GE, and V-10GE, the default bandwidth allocated to each transmit queue on a blocking port depends on the oversubscription ratio of the line card. For a line card that has a 4:1 oversubscription ratio, the default bandwidth allocation will be 62.5 Mbps per queue. For line cards with 8:1 oversubscription, the default bandwidth allocation will be 31.25 Mbps per queue. The default settings may be changed on individual interfaces. In Example 11, the default 250 Mbps per queue setting is changed for the first three queues. The default bandwidth for blocking ports with Supervisor Engine V would be changed identically.
Example 11. Changing the Default Tx Queue Bandwidth Allocations
r3_4506-sup3#sh run int gig 5/6
interface GigabitEthernet5/6
tx-queue 1
bandwidth 300 mbps or bandwidth percent 30
tx-queue 2
bandwidth 400 mbps
tx-queue 3
bandwidth 50 mbps
Starting with Cisco IOS Software Release 12.1.19EW1, a bandwidth percentage, as shown in Example 11, can be used to specify the minimum guaranteed Tx queue bandwidth.
TRAFFIC SHAPING
Egress Traffic Shaping limits the transmitted traffic to no more than the configured shape rate. This can be looked at as the maximum bandwidth allowed on the port queue on which it is configured. It is used for smoothing traffic helping to reduce downstream device buffering. Traffic Shaping can be configured on all Gigabit Ethernet and Fast Ethernet ports. It is disabled by default. For Supervisor Engines IV, II-Plus, II-Plus-TS, II-Plus-10GE, and V-10E, traffic shaping is typically used on a blocking port's Strict Priority Queue to prevent this queue from potentially starving other queues. Queue scheduling will be explained in more detail in the following section. Traffic Shaping buffers traffic that exceeds the shape limit. In contrast traffic policing drops traffic that exceeds the rate limit. So although both methods are used to limit traffic flow, they use two different means of enforcement.
The Supervisor Engines II-Plus-10GE, V, and V-10GE have some limitations regarding traffic shaping. For Fast Ethernet port transmit queues, traffic can be accurately shaped up to 7 Mbps. For Gigabit Ethernet port transmit queues, traffic can be accurately shaped up to 50 Mbps. When shaping beyond these rates, it should be noted the shaped rate may not be achieved in certain circumstances. These circumstances would include: for example, when all the transmit queues are active; or when the packet sizes on the shaped queue include many small packets and the competing traffic on the other transmit queues has a large proportion of large packets.
STRICT PRIORITY QUEUING
For all supervisor engines, Strict Priority Queuing can be configured on Transmit Queue # 3 of both Gigabit Ethernet and Fast Ethernet ports. For Supervisor Engines IV, II-Plus, II-Plus-TS, II-Plus-10GE, V, and V-10GE, traffic shaping is typically used together with Strict Priority Queuing on blocking ports to ensure the Strict Priority Queue does not starve the other queues. On non-blocking ports on Supervisor Engines IV, II-Plus, and II-Plus-TS, and for all ports on the Supervisor Engine V, II-Plus-10GE, and V-10GE traffic in the Strict Priority Queue will be scheduled ahead of traffic in other queues as long as the configured queue bandwidth share value is not exceeded. Example 12 shows Transmit Queue # 3 being defined as a Strict Priority Queue and the maximum bandwidth or shape rate is set at 50 Mbps.
Example 12. Traffic Shaping on the Strict Priority Queue
interface GigabitEthernet5/6 (truncated output)
tx-queue 1
bandwidth 300 mbps
tx-queue 2
bandwidth 300 mbps
tx-queue 3
bandwidth 100 mbps
priority high
shape 50 mbps
TRANSMIT QUEUE SCHEDULING
Before presenting the hierarchy of queue scheduling, it is important to provide queue definitions:
• Strict Priority Queue: For non-blocking ports on Supervisor Engines IV, II-Plus, and II-Plus-TS and for all ports on a Supervisor Engines V, II-Plus-10GE, and V-10GE the queue remains a Strict Priority Queue as long as it has not exceeded its configured minimum bandwidth share. Therefore, Strict Priority Queue does not mean the queue will always be serviced as long as there are packets in it. For blocking Gigabit Ethernet ports and Fast Ethernet ports on Supervisor Engines IV, II-Plus, and II-Plus-TS the Strict Priority Queue will always be serviced as long as there are packets in the queue.
• High Priority Queue: This is not configured as a Strict Priority Queue and has not exceeded its configured minimum bandwidth share. High priority does not mean a higher CoS/DSCP or ToS value. This definition applies to non-blocking ports on Supervisor Engines IV, II-Plus, II-Plus-TS and to all ports on Supervisor Engines V, II-Plus-10GE, and V-10GE.
• Low Priority Queue: This includes all ports on Supervisor Engines V, II-Plus-10GE, V-10GE and non blocking ports on Supervisor Engines IV, II-Plus, and II-Plus-TS whose queue has exceeded its guaranteed minimum bandwidth share. This applies to both a Strict Priority Queue and a High Priority Queue. On Supervisor's IV, II-Plus, and II-Plus-TS for blocking Gigabit Ethernet ports and Fast Ethernet ports, all queues except the Strict Priority Queue are Low Priority Queues.
Packets are placed into one of the four transmit queues based on the internal DSCP, as discussed previously. Transmit queues are then serviced as follows:
• Strict Priority Queue when the traffic rate is below the shape rate and the share rate. This applies to all ports on Supervisor Engines V, II-Plus-10GE, and V-10GE and the non-blocking gigabit ports on Supervisor Engines IV, II-Plus, and II-Plus-TS. For blocking gigabit ports and fast Ethernet ports on Supervisor Engines IV, II-Plus, and II-Plus-TS the Strict Priority Queue will always be serviced as long as there are packets in the queue.
• High Priority Queues with a traffic rate that is below the shape rate and the share rate. This applies to all ports on Supervisor Engines V, II-Plus-10GE, and V-10GE and to the non-blocking gigabit ports on Supervisor Engines IV, II-Plus, and II-Plus-TS.
• If there is more than one High Priority Queue, round robin between them.
• If there is more than one Low Priority Queue, round robin between them.
• When any queue's traffic rate exceeds the shape rate (if configured), the packet is buffered and not transmitted until the traffic rate is again below the shape rate.
The following command shown in Example 13 is useful in determining the QoS settings on a particular port on the Cisco Catalyst 4500 Series Switch with a Supervisor Engine V. This will show trust settings and any shaping and sharing configured on the port as well as the transmit queue size. Please note that for Supervisor Engines IV, II-Plus or II-Plus-TS the queue size would be 1,920 packets.
Example 13. Interface QoS Information
r3_4510R_S4#sh qos int gig 5/6
QoS is enabled globally
Port QoS is enabled
Port Trust State: 'untrusted'
Trust device: none
Default DSCP: 0 Default CoS: 0
Appliance trust: none
! Output continue below.
Tx-Queue Bandwidth ShapeRate Priority QueueSize
(bps) (bps) (packets)
1 300000000 disabled N/A 2336
2 300000000 disabled N/A 2336
3 100000000 50000000 high 2336
4 300000000 disabled N/A 2336
QOS POLICING AND MARKING
A policer is typically used to rate limit traffic. Traffic that exceeds the specified rate is considered out of profile and can either be dropped or have its DSCP marked down. The Cisco Catalyst 4500 Series supervisor engines support ingress, egress, and microflow policing (Supervisor Engine V-10E only) in hardware using a single rate policer. The policer also includes a burst parameter to allow for bursting of traffic above the specified rate. The policer supports rates from 32 kbps to 32 Gbps. The burst size is measured in bytes and can range from 1KB to 512MB. The burst size should take into account the type of traffic being policed. If the burst size is set too small, there may be some over policing. If the burst size is set too large, the entire transfer may fit into the burst and hence there may be over policing, particularly for smaller packet sizes. In general smaller burst sizes should be used for voice and video traffic and larger burst sizes should be used for TCP traffic. A good starting point for TCP traffic is:
The exact burst size to be used in practice would depend on the type of traffic being policed.
Policing is configured on the Cisco Catalyst 4500 Series supervisor engines using the previously discussed, Modular QoS CLI. Traffic to be policed is identified using ACLs or match statements in a class map. The supervisor engines support the following match statements in a class map:
• Match access-group (can be Layer 2/3/4)
• Match any
• Match IP DSCP
• Match IP Precedence
• Match flow ip (applicable only when configuring microflow policing to deliver user based rate limiting)
The class maps are then used to identify the type of traffic to police. These policers would then be applied via a service policy to either an individual port(s) or VLAN(s). A single policy map can support up to the Cisco IOS Software system wide limit of 255 class maps. Remember that class maps can be shared among policy maps. For example, in a Metro Ethernet environment, where a service provider may offer four different types of services to 240 different customers, only four class maps are required to accommodate the service policies for these customers.
There are three types of policers supported on the Cisco Catalyst 4500 IOS Supervisors: individual (per interface), aggregate (multiple interfaces), and micro flow policers.
• Individual policer-QoS applies the bandwidth limits specified in the policer separately to each matched traffic class for each port/VLAN to which the policy map is attached. In order to configure an individual policer within a policy map the command police under policy-map class configuration mode needs to be specified. Example 14 shows an individual policer configuration
Example 14. Individual Policer Configuration Applied to VLAN 2
class-map match-all limit_host
match access-group 101
! The above class map,limit_host, is looking for traffic that matches ACL 101 below:
Extended IP access list 101
permit ip any host 10.5.1.2
! The policy map limit_10, below, will be applied to rate limit this type of traffic
policy-map limit_10
class limit_host
police 10m 8k conform-action transmit exceed-action drop
! The policy map is then applied to Vlan 2 as an input policy to rate limit the specified traffic
inbound traffic on Vlan 2 to 10Mbps with a burst size of 8k:
interface Vlan2
ip address 10.20.1.1 255.255.255.0
service-policy input limit_10
• Aggregate policer-With aggregate policers, QoS applies the bandwidth limits specified in an aggregate policer cumulatively to all matched traffic flows. Before any policy map is configured on an interface, the bandwidth limits of the policer must be defined using the qos aggregate-policer global configuration command. In order to configure an aggregate policer, within a policy map, the command police aggregate under policy-map class confiiguration mode needs to be specified. Example 15 shows an aggregate policer configuration.
Example 15. Aggregate Policer Configuration Applied to VLAN 2
! The above defines the aggregate policer which rate limits traffic to 10 Mbps
class-map match-all limit_host
match access-group 101
! the above class map,limit_host, is looking for traffic that matches ACL 101 below:
Extended IP access list 101
permit ip any host 10.5.1.2
! The policy map limit_10, below, will be applied to rate limit this type of traffic
policy-map limit_10
class limit_host
police aggregate pol_10meg
! The policy map is then applied to Vlan 2 as an input policy to rate limit the specified traffic inbound traffic on Vlan 2:
interface Vlan2
ip address 10.20.1.1 255.255.255.0
service-policy input limit_10
• Flow or microflow policer-With flow-based policing, all the identified flows are policed to the specified rate individually. Because the flows are dynamic, distinguishing fields must be configured in class maps. Through the use of microflow policers, two important features can be configured: User Based Rate Limiting (UBRL), and Hierarchical Policing.
– User Based Rate Limiting-This feature adopts the microflow policing capability to dynamically learn traffic flows and rate limit unique flow to an individual rate. UBRL is supported only on the Supervisor Engine V-10GE with the built-in NetFlow support. UBRL is typically used in environments where a per-user granular rate-limiting mechanism is required, such as, per-user outbound traffic rate versus a per-user inbound traffic rate. UBRL can police IP and non-IP traffic. Example 16 shows a typical user based rate limiting configuration.
– Hierarchical Policing-This defines the ability to configure a set of policers (parent and child) to further define the rate limits of a particular flow. A parent policer can be considered as an aggregate policer, while a child policers can be defined as an individual policer within the aggregate policer. A flow-based policy map is defined as a child policy map by default. A parent policy map cannot be a flow-based policy map. Furthermore, both the child policy map and parent policy map must have match-all in their class-map configuration. Hierarchical Policing is supported only with the Supervisor Engine V-10GE in conjunction with UBRL. Example 17 shows a typical hierarchical policer configuration.
Example 16. UBRL Configuration Applied to FastEthernet 6/1 Matching the IP Source Address
