Table Of Contents
Configuring Modular QoS Congestion Management on Cisco ASR 9000 Series Routers
Contents
Prerequisites for Configuring QoS Congestion Management on Cisco ASR 9000 Series Routers
Information About Configuring QoS Congestion Management on Cisco ASR 9000 Series Routers
Congestion Management Overview
Modified Deficit Round Robin
Low-Latency Queueing with Strict Priority Queueing
Traffic Shaping
Regulation of Traffic with the Shaping Mechanism
Traffic Policing
Regulation of Traffic with the Policing Mechanism
Single-Rate Policer
Two-Rate Policer
Committed Bursts and Excess Bursts
Deciding if Packets Conform or Exceed the Committed Rate
Two-Rate Three-Color (2R3C) Policer
Hierarchical Policing
Packet Marking Through the IP Precedence Value, IP DSCP Value, and the MPLS Experimental Value Setting
Congestion Management Using DEI
How to Configure QoS Congestion Management on Cisco ASR 9000 Series Routers
Configuring Guaranteed and Remaining Bandwidths
Restrictions
Configuring Guaranteed Bandwidth
Configuring Bandwidth Remaining
Configuring Low-Latency Queueing with Strict Priority Queueing
Restrictions
Configuring Traffic Shaping
Restrictions
Configuring Traffic Policing (Two-Rate Color-Blind)
Configuring Traffic Policing (2R3C)
Configuring Hierarchical Policing
Configuration Examples for Configuring QoS Congestion Management on Cisco ASR 9000 Series Routers
Traffic Shaping for an Input Interface: Example
Traffic Policing for a Bundled Interface: Example
2R3C Traffic Policing: Example
Hierarchical Policing: Example
Multi-action Set/Policer: Example
Additional References
Related Documents
Standards
MIBs
RFCs
Technical Assistance
Configuring Modular QoS Congestion Management on Cisco ASR 9000 Series Routers
Congestion management controls congestion after it has occurred on a network. Congestion is managed on Cisco IOS XR software by using packet queueing methods and by shaping the packet flow through use of traffic regulation mechanisms.
The types of traffic regulation mechanisms supported on the Cisco ASR 9000 Series Aggregation Services Routers are:
•
Traffic shaping:
–
Modified Deficit Round Robin (MDRR)
–
Low-latency queueing (LLQ) with strict priority queueing (PQ)
•
Traffic policing:
–
Color blind
–
Color-aware (ingress direction)
Line Card, SIP, and SPA Support
The following table lists the features that are supported on the ASR 9000 Ethernet Line Cards and SIP 700 for the ASR 9000.
Feature
|
ASR 9000 Ethernet Line Cards
|
SIP 700 for the ASR 9000
|
Congestion Management Using DEI
|
no
|
yes
|
Guaranteed and Remaining Bandwidth
|
yes
|
yes
|
Low-Latency Queueing with Strict Priority Queueing
|
yes
|
yes
|
Traffic Policing
|
yes
|
yes
|
Traffic Shaping
|
yes
|
yes
|
Feature History for Configuring Modular QoS Congestion Management on Cisco ASR 9000 Series Routers
Release
|
Modification
|
Release 3.7.2
|
The Congestion Avoidance feature was introduced on ASR 9000 Ethernet Line Cards..
The Guaranteed and Remaining Bandwidth, Low-Latency Queueing with Strict Priority Queueing, Traffic Policing, and Traffic Shaping features were introduced on ASR 9000 Ethernet Line Cards.
|
Release 3.9.0
|
The Guaranteed and Remaining Bandwidth, Low-Latency Queueing with Strict Priority Queueing, Traffic Policing, and Traffic Shaping features were supported on the SIP 700 for the ASR 9000.
|
Release 4.0
|
The Congestion Management Using DEI feature was introduced on ASR 9000 Ethernet Line Cards.
|
Release 4.0.1
|
The police rate command was updated to include packet-based specifications of policing rates and burst sizes.
|
Release 4.1.0
|
The 2-rate 3-color policer feature was added, including the conform-color and exceed-color commands. This feature is applicable to the SIP 700 line cards, ingress side.
|
Contents
•
Prerequisites for Configuring QoS Congestion Management on Cisco ASR 9000 Series Routers
•
Information About Configuring QoS Congestion Management on Cisco ASR 9000 Series Routers
•
How to Configure QoS Congestion Management on Cisco ASR 9000 Series Routers
•
Configuration Examples for Configuring QoS Congestion Management on Cisco ASR 9000 Series Routers
•
Additional References
Prerequisites for Configuring QoS Congestion Management on Cisco ASR 9000 Series Routers
The following prerequisites are required for configuring QoS congestion management on your network:
•
You must be in a user group associated with a task group that includes the proper task IDs. The command reference guides include the task IDs required for each command. If you suspect user group assignment is preventing you from using a command, contact your AAA administrator for assistance.
•
You must be familiar with Cisco IOS XR QoS configuration tasks and concepts.
Information About Configuring QoS Congestion Management on Cisco ASR 9000 Series Routers
To implement QoS congestion management features in this document, you must understand the following concepts:
•
Congestion Management Overview
•
Modified Deficit Round Robin
•
Low-Latency Queueing with Strict Priority Queueing
•
Traffic Shaping
•
Regulation of Traffic with the Shaping Mechanism
•
Traffic Policing
•
Regulation of Traffic with the Policing Mechanism
Congestion Management Overview
Congestion management features allow you to control congestion by determining the order in which a traffic flow (or packets) is sent out an interface based on priorities assigned to packets. Congestion management entails the creation of queues, assignment of packets to those queues based on the classification of the packet, and scheduling of the packets in a queue for transmission. The congestion management features in Cisco IOS XR software allow you to specify creation of a different number of queues, affording greater or lesser degree of differentiation of traffic, and to specify the order in which that traffic is sent.
During periods with light traffic flow, that is, when no congestion exists, packets are sent out the interface as soon as they arrive. During periods of transmit congestion at the outgoing interface, packets arrive faster than the interface can send them. If you use congestion management features, packets accumulating at an interface are queued until the interface is free to send them; they are then scheduled for transmission according to their assigned priority and the queueing method configured for the interface. The router determines the order of packet transmission by controlling which packets are placed in which queue and how queues are serviced with respect to each other.
In addition to queueing methods, QoS congestion management mechanisms, such as policers and shapers, are needed to ensure that a packet adheres to a contract and service. Both policing and shaping mechanisms use the traffic descriptor for a packet. See the "Configuring Modular Quality of Service Congestion Management on Cisco ASR 9000 Series Routers" module in this guide for information about the traffic descriptor.
Policers and shapers usually identify traffic descriptor violations in an identical manner through the token bucket mechanism, but they differ in the way they respond to violations. A policer typically drops traffic flow; whereas, a shaper delays excess traffic flow using a buffer, or queueing mechanism, to hold the traffic for transmission at a later time.
Traffic shaping and policing can work in tandem. For example, a good traffic shaping scheme should make it easy for nodes inside the network to detect abnormal flows.
Modified Deficit Round Robin
MDRR is a class-based composite scheduling mechanism that allows for queueing of up to eight traffic classes. It operates in the same manner as class-based weighted fair queueing (CBWFQ) and allows definition of traffic classes based on customer match criteria (such as access lists); however, MDRR does not use the weighted fair queueing algorithm.
When MDRR is configured in the queueing strategy, nonempty queues are served one after the other. Each time a queue is served, a fixed amount of data is dequeued. The algorithm then services the next queue. When a queue is served, MDDR keeps track of the number of bytes of data that were dequeued in excess of the configured value. In the next pass, when the queue is served again, less data is dequeued to compensate for the excess data that was served previously. As a result, the average amount of data dequeued per queue is close to the configured value. In addition, MDRR allows for a strict priority queue for delay-sensitive traffic.
Each queue within MDRR is defined by two variables:
•
Quantum value—Average number of bytes served in each round.
•
Deficit counter—Number of bytes a queue has sent in each round. The counter is initialized to the quantum value.
Packets in a queue are served as long as the deficit counter is greater than zero. Each packet served decreases the deficit counter by a value equal to its length in bytes. A queue can no longer be served after the deficit counter becomes zero or negative. In each new round, the deficit counter for each nonempty queue is incremented by its quantum value.
Low-Latency Queueing with Strict Priority Queueing
The LLQ feature brings strict priority queueing (PQ) to the MDRR scheduling mechanism. PQ in strict priority mode ensures that one type of traffic is sent, possibly at the expense of all others. For PQ, a low-priority queue can be detrimentally affected, and, in the worst case, never allowed to send its packets if a limited amount of bandwidth is available or the transmission rate of critical traffic is high.
Strict PQ allows delay-sensitive data, such as voice, to be dequeued and sent before packets in other queues are dequeued.
LLQ enables the use of a single, strict priority queue within MDRR at the class level, allowing you to direct traffic belonging to a class. To rank class traffic to the strict priority queue, you specify the named class within a policy map and then configure the priority command for the class. (Classes to which the priority command is applied are considered priority classes.) Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is enqueued to the same, single, strict priority queue.
Through use of the priority command, you can assign a strict PQ to any of the valid match criteria used to specify traffic. These methods of specifying traffic for a class include matching on access lists, protocols, IP precedence, and IP differentiated service code point (DSCP) values. Moreover, within an access list you can specify that traffic matches are allowed based on the DSCP value that is set using the first six bits of the IP type of service (ToS) byte in the IP header.
Traffic Shaping
Traffic shaping allows you to control the traffic flow exiting an interface to match its transmission to the speed of the remote target interface and ensure that the traffic conforms to policies contracted for it. Traffic adhering to a particular profile can be shaped to meet downstream requirements, thereby eliminating bottlenecks in topologies with data-rate mismatches.
To match the rate of transmission of data from the source to the target interface, you can limit the transfer of data to one of the following:
•
A specific configured rate
•
A derived rate based on the level of congestion
The rate of transfer depends on these three components that constitute the token bucket: burst size, mean rate, and time (measurement) interval. The mean rate is equal to the burst size divided by the interval.
When traffic shaping is enabled, the bit rate of the interface does not exceed the mean rate over any integral multiple of the interval. In other words, during every interval, a maximum of burst size can be sent. Within the interval, however, the bit rate may be faster than the mean rate at any given time.
When the peak burst size equals 0, the interface sends no more than the burst size every interval, achieving an average rate no higher than the mean rate. However, when the peak burst size is greater than 0, the interface can send as many as the burst size plus peak burst bits in a burst, if in a previous time period the maximum amount was not sent. Whenever less than the burst size is sent during an interval, the remaining number of bits, up to the peak burst size, can be used to send more than the burst size in a later interval.
Regulation of Traffic with the Shaping Mechanism
When incoming packets arrive at an interface, the packets are classified using a classification technique, such as an access control list (ACL) or the setting of the IP Precedence bits through the Modular QoS CLI (MQC). If the packet matches the specified classification, the traffic-shaping mechanism continues. Otherwise, no further action is taken.
Figure 1 illustrates how a traffic shaping mechanism regulates traffic flow.
Figure 1 How a Traffic Shaping Mechanism Regulates Traffic
Packets matching the specified criteria are placed in the token bucket. The maximum size of the token bucket is the confirm burst (Bc) size plus the Be size. The token bucket is filled at a constant rate of Bc worth of tokens at every Tc. This is the configured traffic shaping rate.
If the traffic shaping mechanism is active (that is, packets exceeding the configured traffic shaping rate already exist in a transmission queue) at every Tc, the traffic shaper checks to see if the transmission queue contains enough packets to send (that is, up to either Bc [or Bc plus Be] worth of traffic).
If the traffic shaper is not active (that is, there are no packets exceeding the configured traffic shaping rate in the transmission queue), the traffic shaper checks the number of tokens in the token bucket. One of the following occurs:
•
If there are enough tokens in the token bucket, the packet is sent (transmitted).
•
If there are not enough tokens in the token bucket, the packet is placed in a shaping queue for transmission at a later time.
Traffic Policing
In general, traffic policing allows you to control the maximum rate of traffic sent or received on an interface and to partition a network into multiple priority levels or class of service (CoS).
Traffic policing manages the maximum rate of traffic through a token bucket algorithm. The token bucket algorithm uses user-configured values to determine the maximum rate of traffic allowed on an interface at a given moment in time. The token bucket algorithm is affected by all traffic entering or leaving the interface (depending on where the traffic policy with traffic policing is configured) and is useful in managing network bandwidth in cases where several large packets are sent in the same traffic stream.
Traffic policing is often configured on interfaces at the edge of a network to limit the rate of traffic entering or leaving the network. In the most common traffic policing configurations, traffic that conforms to the CIR is sent and traffic that exceeds is sent with a decreased priority or is dropped. Users can change these configuration options to suit their network needs. Traffic policing also provides a certain amount of bandwidth management by allowing you to set the burst size (Bc) for the committed information rate (CIR). When the peak information rate (PIR) is supported, a second token bucket is enforced and then the traffic policer is called a two-rate policer.
Regulation of Traffic with the Policing Mechanism
This section describes the single-rate and two-rate policing mechanisms.
Single-Rate Policer
A single-rate, two-action policer provides one token bucket with two actions for each packet: a conform action and an exceed action.
Figure 2 illustrates how a single-rate token bucket policer marks packets as either conforming or exceeding a CIR, and assigns an action.
Figure 2 Marking Packets and Assigning Actions—Single-Rate Policer
The time interval between token updates (Tc) to the token bucket is updated at the CIR value each time a packet arrives at the traffic policer. The Tc token bucket can contain up to the Bc value, which can be a certain number of bytes or a period of time. If a packet of size B is greater than the Tc token bucket, then the packet exceeds the CIR value and a configured action is performed. If a packet of size B is less than the Tc token bucket, then the packet conforms and a different configured action is performed.
Two-Rate Policer
The two-rate policer manages the maximum rate of traffic by using two token buckets: the committed token bucket and the peak token bucket. The dual-token bucket algorithm uses user-configured values to determine the maximum rate of traffic allowed on a queue at a given moment. In this way, the two-rate policer can meter traffic at two independent rates: the committed information rate (CIR) and the peak information rate (PIR).
The committed token bucket can hold bytes up to the size of the committed burst (bc) before overflowing. This token bucket holds the tokens that determine whether a packet conforms to or exceeds the CIR as the following describes:
•
A traffic stream is conforming when the average number of bytes over time does not cause the committed token bucket to overflow. When this occurs, the token bucket algorithm marks the traffic stream green.
•
A traffic stream is exceeding when it causes the committed token bucket to overflow into the peak token bucket. When this occurs, the token bucket algorithm marks the traffic stream yellow. The peak token bucket is filled as long as the traffic exceeds the police rate.
The peak token bucket can hold bytes up to the size of the peak burst (be) before overflowing. This token bucket holds the tokens that determine whether a packet violates the PIR. A traffic stream is violating when it causes the peak token bucket to overflow. When this occurs, the token bucket algorithm marks the traffic stream red.
The dual-token bucket algorithm provides users with three actions for each packet—a conform action, an exceed action, and an optional violate action. Traffic entering a queue with the two-rate policer configured is placed into one of these categories. Within these three categories, users can decide packet treatments. For instance, packets that conform can be configured to be sent; packets that exceed can be configured to be sent with a decreased priority; and packets that violate can be configured to be dropped.
Figure 3 shows how the two-rate policer marks a packet and assigns a corresponding action to the packet.
Figure 3 Marking Packets and Assigning Actions—2-Rate Policer
For example, if a data stream with a rate of 250 kbps arrives at the two-rate policer, and the CIR is 100 kbps and the PIR is 200 kbps, the policer marks the packet in the following way:
•
100 kbps conforms to the rate
•
100 kbps exceeds the rate
•
50 kbps violates the rate
The router updates the tokens for both the committed and peak token buckets in the following way:
•
The router updates the committed token bucket at the CIR value each time a packet arrives at the interface. The committed token bucket can contain up to the committed burst (bc) value.
•
The router updates the peak token bucket at the PIR value each time a packet arrives at the interface. The peak token bucket can contain up to the peak burst (be) value.
•
When an arriving packet conforms to the CIR, the router takes the conform action on the packet and decrements both the committed and peak token buckets by the number of bytes of the packet.
•
When an arriving packet exceeds the CIR, the router takes the exceed action on the packet, decrements the committed token bucket by the number of bytes of the packet, and decrements the peak token bucket by the number of overflow bytes of the packet.
•
When an arriving packet exceeds the PIR, the router takes the violate action on the packet, but does not decrement the peak token bucket.
Committed Bursts and Excess Bursts
Unlike a traffic shaper, a traffic policer does not buffer excess packets and transmit them later. Instead, the policer executes a "send or do not send" policy without buffering. During periods of congestion, proper configuration of the excess burst parameter enables the policer to drop packets less aggressively. Therefore, it is important to understand how policing uses the committed (normal) and excess burst values to ensure the router reaches the configured committed information rate (CIR).
Burst parameters are based on a generic buffering rule for routers, which recommends that you configure buffering to be equal to the round-trip time bit-rate to accommodate the outstanding TCP windows of all connections in times of congestion.
The following sections describe committed bursts and excess bursts, and the recommended formula for calculating each of them:
•
Committed Bursts
•
Excess Bursts
•
Deciding if Packets Conform or Exceed the Committed Rate
Committed Bursts
The committed burst (bc) parameter of the police command implements the first, conforming (green) token bucket that the router uses to meter traffic. The bc parameter sets the size of this token bucket. Initially, the token bucket is full and the token count is equal to the committed burst size (CBS). Thereafter, the meter updates the token counts the number of times per second indicated by the committed information rate (CIR).
The following describes how the meter uses the conforming token bucket to send packets:
•
If sufficient tokens are in the conforming token bucket when a packet arrives, the meter marks the packet green and decrements the conforming token count by the number of bytes of the packet.
•
If there are insufficient tokens available in the conforming token bucket, the meter allows the traffic flow to borrow the tokens needed to send the packet. The meter checks the exceeding token bucket for the number of bytes of the packet. If the exceeding token bucket has a sufficient number of tokens available, the meter marks the packet:
a.
Green and decrements the conforming token count down to the minimum value of 0.
b.
Yellow, borrows the remaining tokens needed from the exceeding token bucket, and decrements the exceeding token count by the number of tokens borrowed down to the minimum value of 0.
•
If an insufficient number of tokens is available, the meter marks the packet red and does not decrement either of the conforming or exceeding token counts.
Note
When the meter marks a packet with a specific color, there must be a sufficient number of tokens of that color to accommodate the entire packet. Therefore, the volume of green packets is never smaller than the committed information rate (CIR) and committed burst size (CBS). Tokens of a given color are always used on packets of that color.
The default committed burst size is the greater of 2 milliseconds of bytes at the police rate or the network maximum transmission unit (MTU).
Committed Burst Calculation
To calculate committed burst, use the following formula:
bc = CIR bps * (1 byte) / (8 bits) * 1.5 seconds
Note
1.5 seconds is the typical round-trip time.
For example, if the committed information rate is 512000 bps, then using the committed burst formula, the committed burst is 96000 bytes.
bc = 512000 * 1/8 * 1.5
bc = 64000 * 1.5 = 96000
Note
When the be value equals 0, we recommend that you set the egress bc value to be greater than or equal to the ingress bc value plus 1. Otherwise, packet loss can occur. For example:
be = 0
egress bc >= ingress bc + 1
Excess Bursts
The excess burst (be) parameter of the police command implements the second, exceeding (yellow) token bucket that the router uses to meter traffic. The exceeding token bucket is initially full and the token count is equal to the excess burst size (EBS). Thereafter, the meter updates the token counts the number of times per second indicated by the committed information rate (CIR).
The following describes how the meter uses the exceeding token bucket to send packets:
•
When the first token bucket (the conforming bucket) meets the committed burst size (CBS), the meter allows the traffic flow to borrow the tokens needed from the exceeding token bucket. The meter marks the packet yellow and then decrements the exceeding token bucket by the number of bytes of the packet.
•
If the exceeding token bucket does not have the required tokens to borrow, the meter marks the packet red and does not decrement the conforming or the exceeding token bucket. Instead, the meter performs the exceed-action configured in the police command (for example, the policer drops the packets).
Excess Burst Calculation
To calculate excess burst, use the following formula:
be = 2 * committed burst
For example, if you configure a committed burst of 4000 bytes, then using the excess burst formula, the excess burst is 8000 bytes.
be = 2 * 4000 = 8000
The default excess burst size is 0.
Deciding if Packets Conform or Exceed the Committed Rate
Policing uses normal or committed burst (bc) and excess burst (be) values to ensure that the configured committed information rate (CIR) is reached. Policing decides if a packet conforms or exceeds the CIR based on the burst values you configure. Several factors can influence the policer's decision, such as the following:
•
Low burst values—If you configure burst values too low, the achieved rate might be much lower than the configured rate.
•
Temporary bursts—These bursts can have a strong adverse impact on throughput of Transmission Control Protocol (TCP) traffic.
It is important that you set the burst values high enough to ensure good throughput. If your router drops packets and reports an exceeded rate even though the conformed rate is less than the configured CIR, use the show interface command to monitor the current burst, determine whether the displayed value is consistently close to the committed burst (bc) and excess burst (be) values, and if the actual rates (the committed rate and exceeded rate) are close to the configured committed rate. If not, the burst values might be too low. Try reconfiguring the burst rates using the suggested calculations in the "Committed Burst Calculation" section and the "Excess Burst Calculation" section.
Two-Rate Three-Color (2R3C) Policer
For the SIP 700 card, a two-rate, three-color (2R3C) policer is supported on policy maps for ingress Layer 2 interfaces. The policer reads a preexisting marking—the frame-relay discard-eligibility (FRDE) bit in the packet header—that was set by a policer on a previous network node. By default the FRDE bit is set to 0. At the receiving node, the system uses this bit to determine the appropriate color-aware policing action for the packet:
•
To classify the FRDE bit value 0 as conform color, create a conform-color class-map for frde=0 packets. This causes packets to be classified as color green, and the system applies the conform action.
•
To classify the FRDE bit value 1 as exceed color, create an exceed-color class-map for frde=1 packets. This causes packets to be classified as color yellow, and the system applies the exceed action.
Note
Color-aware policing is not supported for heirarchical QoS.
The 2R3C policing process is shown in Figure 4.
Figure 4 2R3C Policing Process Flowchart
Hierarchical Policing
The Hierarchical Policing feature is an MQC-based solution that supports hierarchical policing on both the ingress and egress interfaces on Cisco ASR 9000 Series Routers.
This feature allows enforcement of service level agreements (SLA) while applying the classification submodel for different QoS classes on the inbound interface.
Hiearchical policing provides support at two levels:
•
Parent level
•
Child level
Hierarchical policing is covered in the "Configuring Hierarchical Modular QoS on Cisco ASR 9000 Series Routers" chapter.
Packet Marking Through the IP Precedence Value, IP DSCP Value, and the MPLS Experimental Value Setting
In addition to rate-limiting, traffic policing allows you to independently mark (or classify) the packet according to whether the packet conforms or violates a specified rate. Packet marking also allows you to partition your network into multiple priority levels or CoS. Packet marking as a policer action is conditional marking.
Use the traffic policer to set the IP precedence value, IP DSCP value, or Multiprotocol Label Switching (MPLS) experimental value for packets that enter the network. Then networking devices within your network can use this setting to determine how the traffic should be treated. For example, the Weighted Random Early Detection (WRED) feature uses the IP precedence value to determine the probability that a packet is dropped.
If you want to mark traffic but do not want to use traffic policing, see the "Class-based, Unconditional Packet Marking Examples" section in this guide to learn how to perform packet classification.
Note
Marking IP fields on an MPLS-enabled interface results in non-operation on that particular interface.
Congestion Management Using DEI
You can manage congestion based on the Drop Eligible Indicator (DEI) bit that is present in 802.1ad frames and 802.1ah frames. Random early detection based on the DEI value is supported on 802.1ad packets for:
•
Layer 2 subinterfaces
•
Layer 2 main interfaces
•
Layer 3 main interfaces
•
Ingress and egress
Note
If there are any marking actions in the policy, the marked values are used for doing WRED.
How to Configure QoS Congestion Management on Cisco ASR 9000 Series Routers
This section contains instructions for the following tasks:
•
Configuring Guaranteed and Remaining Bandwidths
•
Configuring Low-Latency Queueing with Strict Priority Queueing
•
Configuring Traffic Shaping
•
Configuring Traffic Policing (Two-Rate Color-Blind)
•
Configuring Traffic Policing (2R3C)
•
Configuring Hierarchical Policing
Configuring Guaranteed and Remaining Bandwidths
Guaranteed Service rate of a queue is defined as the bandwidth the queue receives when all the queues are congested. It is defined as:
Guaranteed Service Rate = minimum bandwidth + excess share of the queue
The bandwidth command allows you to specify the minimum guaranteed bandwidth to be allocated for a specific class of traffic. MDRR is implemented as the scheduling algorithm.
The bandwidth remaining command specifies a weight for the class to the MDRR. The MDRR algorithm derives the weight for each class from the bandwidth remaining value allocated to the class. The bandwidth remaining is divided among the classes in a policy using either bandwidth remaining ratio or bandwidth remaining percent commands. If you do not configure the bandwidth remaining command for any class, the leftover bandwidth is allocated equally to all classes for which bandwidth remaining is not explicitly specified.
Restrictions
The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead.
The bandwidth command is supported only on policies configured on outgoing interfaces.
Configuring Guaranteed Bandwidth
SUMMARY STEPS
1.
configure
2.
policy-map policy-name
3.
class class-name
4.
bandwidth {rate [units] | percent percentage-value}
5.
exit
6.
class class-name
7.
bandwidth {rate [units] | percent percentage-value}
8.
exit
9.
class class-name
10.
bandwidth {rate [units] | percent percentage-value}
11.
exit
12.
exit
13.
interface type interface-path-id
14.
service-policy {input | output} policy-map
15.
end
or
commit
16.
show policy-map interface type interface-path-id [input | output]
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RSP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
policy-map policy-name
Example:
RP/0/RSP0/CPU0:router(config)# policy-map
policy1
|
Enters policy map configuration mode.
• Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
|
Step 3
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class1
|
Specifies the name of the class whose policy you want to create or change.
|
Step 4
|
bandwidth {rate [units]| percent
percentage-value}
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth
percent 40
|
Enters policy map class configuration mode.
• Specifies the bandwidth allocated for a class belonging to a policy map.
• In this example, class class1 is guaranteed 40 percent of the interface bandwidth.
|
Step 5
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 6
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class2
|
Specifies the name of the class whose policy you want to create or change.
|
Step 7
|
bandwidth {rate [units]| percent
percentage-value}
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth
percent 40
|
Enters policy map class configuration mode.
• Specifies the bandwidth allocated for a class belonging to a policy map.
• In this example, class class2 is guaranteed 40 percent of the interface bandwidth.
|
Step 8
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 9
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class-default
|
Specifies the name of the class whose policy you want to create or change.
|
Step 10
|
bandwidth {rate [units]| percent
percentage-value}
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth
percent 20
|
Enters policy map class configuration mode.
• Specifies the bandwidth allocated for a class belonging to a policy map.
• In this example, class class-default is guaranteed 20 percent of the interface bandwidth.
|
Step 11
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 12
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap)# exit
|
Returns the router to global configuration mode.
|
Step 13
|
interface type interface-path-id
Example:
RP/0/RSP0/CPU0:router(config)# interface
gigabitethernet 0/2/0/0
|
Enters interface configuration mode and configures an interface.
|
Step 14
|
service-policy {input | output} policy-map
Example:
RP/0/RSP0/CPU0:router(config-if)#
service-policy output policy1
|
Attaches a policy map to an input or output interface to be used as the service policy for that interface.
• In this example, the traffic policy evaluates all traffic leaving that interface.
|
Step 15
|
end
or
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
|
Saves configuration changes.
• When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
– Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
– Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
– Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
• Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 16
|
show policy-map interface type
interface-path-id [input | output]
Example:
RP/0/RSP0/CPU0:router# show policy-map
interface gigabitethernet 0/2/0/0
|
(Optional) Displays policy configuration information for all classes configured for all service policies on the specified interface.
|
Configuring Bandwidth Remaining
SUMMARY STEPS
1.
configure
2.
policy-map policy-name
3.
class class-name
4.
bandwidth remaining {percent percentage-value | ratio ratio-value}
5.
exit
6.
class class-name
7.
bandwidth remaining {percent percentage-value | ratio ratio-value}
8.
exit
9.
class class-name
10.
bandwidth remaining {percent percentage-value | ratio ratio-value}
11.
exit
12.
exit
13.
interface type interface-path-id
14.
service-policy {input | output} policy-map
15.
end
or
commit
16.
show policy-map interface type instance [input | output]
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RSP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
policy-map policy-name
Example:
RP/0/RSP0/CPU0:router(config)# policy-map
policy1
|
Enters policy map configuration mode.
• Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
|
Step 3
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class1
|
Specifies the name of the class whose policy you want to create or change.
|
Step 4
|
bandwidth remaining percent percentage-value
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth
remaining percent 40
|
Specifies how to allocate leftover bandwidth for class class1.
|
Step 5
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 6
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class2
|
Specifies the name of the class whose policy you want to create or change.
|
Step 7
|
bandwidth remaining percent percentage-value
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth
remaining percent 40
|
Specifies how to allocate leftover bandwidth for class class2.
|
Step 8
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 9
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class-default
|
Specifies the name of the class whose policy you want to create or change.
|
Step 10
|
bandwidth remaining percent percentage-value
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# bandwidth
remaining percent 20
|
Specifies how to allocate leftover bandwidth for class class-default.
|
Step 11
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 12
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap)# exit
|
Returns the router to global configuration mode.
|
Step 13
|
interface type interface-path-id
Example:
RP/0/RSP0/CPU0:router(config)# interface
gigabitethernet 0/2/0/0
|
Enters interface configuration mode and configures an interface.
|
Step 14
|
service-policy {input | output} policy-map
Example:
RP/0/RSP0/CPU0:router(config-if)#
service-policy output policy1
|
Attaches a policy map to an input or output interface to be used as the service policy for that interface.
• In this example, the traffic policy evaluates all traffic leaving that interface.
|
Step 15
|
end
or
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
|
Saves configuration changes.
• When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
– Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
– Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
– Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
• Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 16
|
show policy-map interface type
interface-path-id [input | output]
Example:
RP/0/RSP0/CPU0:router# show policy-map
interface gigabitethernet 0/2/0/0
|
(Optional) Displays policy configuration information for all classes configured for all service policies on the specified interface.
|
Configuring Low-Latency Queueing with Strict Priority Queueing
The priority command configures low-latency queueing (LLQ), providing strict priority queueing (PQ). Strict PQ allows delay-sensitive data, such as voice, to be dequeued and sent before packets in other queues are dequeued. When a class is marked as high priority using the priority command, it is required that you configure a policer to limit the priority traffic. This configuration ensures that the priority traffic does not starve all of the other traffic on the line card, which protects low priority traffic from starvation. Use the police command to explicitly configure the policer.
Note
Two levels of priority are supported: priority level 1 and priority level 2. If no priority level is configured, the default is priority level 1.
Restrictions
•
Within a policy map, you can give one or more classes priority status. When multiple classes within a single policy map are configured as priority classes, all traffic from these classes is queued to the same single priority queue.
SUMMARY STEPS
1.
configure
2.
policy-map policy-name
3.
class class-name
4.
police rate {value [units] | percent percentage} [burst burst-size [burst-units]] [peak-burst peak-burst [burst-units]] [peak-rate value [units]]
5.
exceed-action action
6.
exit
7.
priority [level priority-level]
8.
exit
9.
exit
10.
interface type interface-path-id
11.
service-policy {input | output} policy-map
12.
end
or
commit
13.
show policy-map interface type interface-path-id [input | output]
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RSP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
policy-map policy-name
Example:
RP/0/RSP0/CPU0:router(config)# policy-map voice
|
Enters policy map configuration mode.
• Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
|
Step 3
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class voice
|
Enters policy map class configuration mode.
• Specifies the name of the class whose policy you want to create or change.
|
Step 4
|
police rate {value [units] | percent
percentage} [burst burst-size [burst-units]]
[peak-burst peak-burst [burst-units]]
[peak-rate value [units]]
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# police
rate 250
|
Configures traffic policing and enters policy map police configuration mode.
• In this example, the low-latency queue is restricted to 250 kbps to protect low-priority traffic from starvation and to release bandwidth.
|
Step 5
|
exceed-action action
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
exceed-action drop
|
Configures the action to take on packets that exceed the rate limit.
|
Step 6
|
|
|
Step 7
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
exit
|
Returns the router to policy map class configuration mode.
|
Step 8
|
priority [level priority-level]
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# priority
|
Specifies priority to a class of traffic belonging to a policy map.
Note If no priority level is configured, the default is priority 1.
|
Step 9
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 10
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap)# exit
|
Returns the router to global configuration mode.
|
Step 11
|
interface type interface-path-id
Example:
RP/0/RSP0/CPU0:router(config)# interface
gigabitethernet 0/2/0/0
|
Enters interface configuration mode, and configures an interface.
|
Step 12
|
service-policy {input | output} policy-map
Example:
RP/0/RSP0/CPU0:router(config-if)#
service-policy output policy1
|
Attaches a policy map to an input or output interface to be used as the service policy for that interface.
• In this example, the traffic policy evaluates all traffic leaving that interface.
|
Step 13
|
end
or
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
|
Saves configuration changes.
• When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
– Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
– Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
– Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
• Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 14
|
show policy-map interface type
interface-path-id [input | output]
Example:
RP/0/RSP0/CPU0:router# show policy-map
interface gigabitethernet 0/2/0/0
|
(Optional) Displays policy configuration information for all classes configured for all service policies on the specified interface.
|
Configuring Traffic Shaping
Traffic shaping allows you to control the traffic exiting an interface to match its transmission to the speed of the remote target interface and ensure that the traffic conforms to policies contracted for it.
Shaping performed on incoming and outgoing interfaces is done at the Layer 2 level and includes the Layer 2 header in the rate calculation.
Restrictions
The bandwidth, priority, and shape average commands should not be configured together in the same class.
SUMMARY STEPS
1.
configure
2.
policy-map policy-name
3.
class class-name
4.
shape average {percent value | rate [units]}
5.
exit
6.
exit
7.
interface type interface-path-id
8.
service-policy {input | output} policy-map
9.
end
or
commit
10.
show policy-map interface type interface-path-id [input | output]
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RSP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
policy-map policy-name
Example:
RP/0/RSP0/CPU0:router(config)# policy-map
policy1
|
Enters policy map configuration mode.
• Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
|
Step 3
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class1
|
Enters policy map class configuration mode.
• Specifies the name of the class whose policy you want to create or change.
|
Step 4
|
shape average {percent value | rate [units]}
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# shape
average percent 50
|
Shapes traffic to the indicated bit rate according to average rate shaping in the specified units or as a percentage of the bandwidth.
|
Step 5
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 6
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap)# exit
|
Returns the router to global configuration mode.
|
Step 7
|
interface type interface-path-id
Example:
RP/0/RSP0/CPU0:router(config)# interface
gigabitethernet 0/2/0/0
|
Enters interface configuration mode and configures an interface.
|
Step 8
|
service-policy {input | output} policy-map
Example:
RP/0/RSP0/CPU0:router(config-if)#
service-policy output policy1
|
Attaches a policy map to an input or output interface to be used as the service policy for that interface.
• In this example, the traffic policy evaluates all traffic leaving that interface.
|
Step 9
|
end
or
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
|
Saves configuration changes.
• When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
– Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
– Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
– Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
• Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 10
|
show policy-map interface type
interface-path-id [input | output]
Example:
RP/0/RSP0/CPU0:router# show policy-map
interface gigabitethernet 0/2/0/0
|
(Optional) Displays policy configuration information for all classes configured for all service policies on the specified interface.
|
Configuring Traffic Policing (Two-Rate Color-Blind)
Traffic policing allows you to control the maximum rate of traffic sent or received on an interface. This section provides the procedure for configuring two-rate color-blind traffic policing.
SUMMARY STEPS
1.
configure
2.
policy-map policy-name
3.
class class-name
4.
police rate {value [units] | percent percentage} [burst burst-size [burst-units]] [peak-burst peak-burst [burst-units]] [peak-rate value [units]]
5.
conform-action action
6.
exceed-action action
7.
exit
8.
exit
9.
exit
10.
interface type interface-path-id
11.
service-policy {input | output} policy-map
12.
end
or
commit
13.
show policy-map interface type interface-path-id [input | output]
Note
The multi-action set/policer feature allows you to configure multiple conform and exceed actions. Therefore, you can repeat the conform-action and exceed-action commands multiple times in your configuration.
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RSP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
policy-map policy-name
Example:
RP/0/RSP0/CPU0:router(config)# policy-map
policy1
|
Enters policy map configuration mode.
• Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
|
Step 3
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class1
|
Enters policy map class configuration mode.
• Specifies the name of the class whose policy you want to create or change.
|
Step 4
|
police rate {value [units] | percent
percentage} [burst burst-size [burst-units]]
[peak-burst peak-burst [burst-units]]
[peak-rate value [units]]
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# police
rate 250000
|
Configures traffic policing and enters policy map police configuration mode. The traffic policing feature works with a token bucket algorithm.
|
Step 5
|
conform-action action
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
conform-action set mpls experimental topmost 3
|
Configures the action to take on packets that conform to the rate limit. The action argument is specified by one of these keywords:
• drop—Drops the packet.
• set—Has these keywords and arguments:
– discard-class value—Sets the discard class value. Range is 0 to 7.
– dscp value—Sets the differentiated services code point (DSCP) value and sends the packet.
– mpls experimental {topmost | imposition} value—Sets the experimental (EXP) value of the Multiprotocol Label Switching (MPLS) packet topmost label or imposed label. Range is 0 to 7.
– precedence precedence—Sets the IP precedence and sends the packet.
– qos-group—Sets the QoS group value. Range is 0 to 63.
• transmit—Transmits the packets.
|
Step 6
|
exceed-action action
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
exceed-action set mpls experimental topmost 4
|
Configures the action to take on packets that exceed the rate limit. The action argument is specified by one of the keywords specified in Step 5.
|
Step 7
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
exit
|
Returns the router to policy map class configuration mode.
|
Step 8
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 9
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap)# exit
|
Returns the router to global configuration mode.
|
Step 10
|
interface type interface-path-id
Example:
RP/0/RSP0/CPU0:router(config)# interface
gigabitethernet 0/5/0/0
|
Enters configuration mode and configures an interface.
|
Step 11
|
service-policy {input | output} policy-map
Example:
RP/0/RSP0/CPU0:router(config-if)#
service-policy output policy1
|
Attaches a policy map to an input or output interface to be used as the service policy for that interface.
• In this example, the traffic policy evaluates all traffic leaving that interface.
|
Step 12
|
end
or
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
|
Saves configuration changes.
• When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
– Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
– Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
– Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
• Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 13
|
show policy-map interface type
interface-path-id [input | output]
Example:
RP/0/RSP0/CPU0:router# show policy-map
interface gigabitethernet 0/2/0/0
|
(Optional) Displays policy configuration information for all classes configured for all service policies on the specified interface.
|
Configuring Traffic Policing (2R3C)
This section provides the procedure for configuring two-rate three-color traffic policing. It is applicable to SIP 700 line cards on the ingress side only.
SUMMARY STEPS
1.
configure
2.
(Use with SIP 700 line card, ingress only) class-map [match-all] [match-any] class-map-name
3.
(Use with SIP 700 line card, ingress only) match [not] fr-de fr-de-bit-value
4.
policy-map policy-name
5.
class class-name
6.
police rate {value [units] | percent percentage} [burst burst-size [burst-units]] [peak-burst peak-burst [burst-units]] [peak-rate value [units]]
7.
(Use with SIP 700 line card, ingress only) conform-color class-map-name
8.
(Use with SIP 700 line card, ingress only) exceed-color class-map-name
9.
conform-action action
10.
exceed-action action
11.
exit
12.
exit
13.
exit
14.
interface type interface-path-id
15.
service-policy policy-map
16.
end
or
commit
17.
show policy-map interface type interface-path-id
Note
The multi-action set/policer feature allows you to configure multiple conform and exceed actions. Therefore, you can repeat the conform-action and exceed-action commands multiple times in your configuration.
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RSP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
class-map [match-all][match-any] class-map-name
Example:
RP/0/RSP0/CPU0:router(config)# class-map
match-all match-not-frde
|
(Use with SIP 700 line card, ingress only)
Enters class map configuration mode.
• Creates or modifies a class map that can be attached to one or more interfaces to specify a matching policy.
|
Step 3
|
match [not] fr-de fr-de-bit-value
Example:
RP/0/RSP0/CPU0:router(config)# match not
fr-de 1
|
(Use with SIP 700 line card, ingress only)
Specifies the matching condition:
• Match not fr-de 1 is typically used to specify a conform-color packet.
• Match fr-de 1 is typically used to specify an exceed-color packet.
|
Step 4
|
policy-map policy-name
Example:
RP/0/RSP0/CPU0:router(config)# policy-map
policy1
|
Enters policy map configuration mode.
• Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
|
Step 5
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class1
|
Enters policy map class configuration mode.
• Specifies the name of the class whose policy you want to create or change.
|
Step 6
|
police rate {value [units] | percent
percentage} [burst burst-size [burst-units]]
[peak-burst peak-burst [burst-units]]
[peak-rate value [units]]
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# police
rate 768000 burst 288000 peak-rate 1536000
peak-burst 576000
|
Configures traffic policing and enters policy map police configuration mode. The traffic policing feature works with a token bucket algorithm.
|
Step 7
|
conform-color class-map-name
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
conform-color match-not-frde
|
(Use with SIP 700 line card, ingress only)
Configures the class-map name to assign to conform-color packets.
|
Step 8
|
exceed-color class-map-name
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
exceed-color match-frde
|
(Use with SIP 700 line card, ingress only)
Configures the class-map name to assign to exceed-color packets.
|
Step 9
|
conform-action action
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
conform-action set mpls experimental topmost 3
|
Configures the action to take on packets that conform to the rate limit. The action argument is specified by one of these keywords:
• drop—Drops the packet.
• set—Has these keywords and arguments:
– discard-class value—Sets the discard class value. Range is 0 to 7.
– dscp value—Sets the differentiated services code point (DSCP) value and sends the packet.
– mpls experimental {topmost | imposition} value—Sets the experimental (EXP) value of the Multiprotocol Label Switching (MPLS) packet topmost label or imposed label. Range is 0 to 7.
– precedence precedence—Sets the IP precedence and sends the packet.
– qos-group—Sets the QoS group value. Range is 0 to 63.
• transmit—Transmits the packets.
|
Step 10
|
exceed-action action
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
exceed-action set mpls experimental topmost 4
|
Configures the action to take on packets that exceed the rate limit. The action argument is specified by one of the keywords specified in Step 5.
|
Step 11
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
exit
|
Returns the router to policy map class configuration mode.
|
Step 12
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# exit
|
Returns the router to policy map configuration mode.
|
Step 13
|
exit
Example:
RP/0/RSP0/CPU0:router(config-pmap)# exit
|
Returns the router to global configuration mode.
|
Step 14
|
interface type interface-path-id
Example:
RP/0/RSP0/CPU0:router(config)# interface pos
0/5/0/0
|
Enters configuration mode and configures an interface.
|
Step 15
|
service-policy policy-map
Example:
RP/0/RSP0/CPU0:router(config-if)#
service-policy policy1
|
Attaches a policy map to an input interface to be used as the service policy for that interface.
|
Step 16
|
end
or
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
|
Saves configuration changes.
• When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
– Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
– Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
– Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
• Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Step 17
|
show policy-map interface type
interface-path-id
Example:
RP/0/RSP0/CPU0:router# show policy-map
interface POS0/2/0/0
|
(Optional) Displays policy configuration information for all classes configured for all service policies on the specified interface.
|
Configuring Hierarchical Policing
Hierarchical policing provides support at two levels:
•
Parent level
•
Child level
SUMMARY STEPS
1.
configure
2.
policy-map policy-name
3.
class class-name
4.
service-policy policy-map-name
5.
police rate percent percentage
6.
conform-action action
7.
exceed-action action
8.
exit
DETAILED STEPS
| |
Command or Action
|
Purpose
|
Step 1
|
configure
Example:
RP/0/RSP0/CPU0:router# configure
|
Enters global configuration mode.
|
Step 2
|
policy-map policy-name
Example:
RP/0/RSP0/CPU0:router(config)# policy-map
policy1
|
Enters policy map configuration mode.
• Creates or modifies a policy map that can be attached to one or more interfaces to specify a service policy.
|
Step 3
|
class class-name
Example:
RP/0/RSP0/CPU0:router(config-pmap)# class
class1
|
Enters policy map class configuration mode.
• Specifies the name of the class whose policy you want to create or change.
|
Step 4
|
service-policy policy-map-name
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)#
service-policy child
|
Attaches a policy map to an input or output interface to be used as the service policy for that interface.
|
Step 5
|
police rate percent percentage
Example:
RP/0/RSP0/CPU0:router(config-pmap-c)# police
rate percent 50
|
Configures traffic policing and enters policy map police configuration mode.
|
Step 6
|
conform-action action
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
conform-action transmit
|
Configures the action to take on packets that conform to the rate limit. The allowed action is:
transmit—Transmits the packets.
|
Step 7
|
exceed-action action
Example:
RP/0/RSP0/CPU0:router(config-pmap-c-police)#
exceed-action drop
|
Configures the action to take on packets that exceed the rate limit. The allowed action is:
drop—Drops the packet.
|
Step 8
|
end
or
commit
Example:
RP/0/RSP0/CPU0:router(config-if)# end
or
RP/0/RSP0/CPU0:router(config-if)# commit
|
Saves configuration changes.
• When you issue the end command, the system prompts you to commit changes:
Uncommitted changes found, commit them before
exiting(yes/no/cancel)?
[cancel]:
– Entering yes saves configuration changes to the running configuration file, exits the configuration session, and returns the router to EXEC mode.
– Entering no exits the configuration session and returns the router to EXEC mode without committing the configuration changes.
– Entering cancel leaves the router in the current configuration session without exiting or committing the configuration changes.
• Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.
|
Configuration Examples for Configuring QoS Congestion Management on Cisco ASR 9000 Series Routers
This section provides the following configuration examples:
•
Traffic Shaping for an Input Interface: Example
•
Traffic Policing for a Bundled Interface: Example
•
2R3C Traffic Policing: Example
•
Hierarchical Policing: Example
•
Multi-action Set/Policer: Example
Traffic Shaping for an Input Interface: Example
The following example shows how to configure a policy map on an input interface:
interface GigabitEthernet0/4/0/24
RP/0/RSP0/CPU0:Jun 8 16:55:11.819 : config[65546]: %MGBL-LIBTARCFG-6-COMMIT :
Configuration committed by user 'cisco'. Use 'show configuration commit changes
1000006140' to view the changes.
The following example shows the display output for the previous policy map configuration:
RP/0/RSP0/CPU0:router# show policy-map interface GigabitEthernet 0/4/0/24 input
GigabitEthernet0/4/0/24 input: p2
Classification statistics (packets/bytes) (rate - kbps)
Inst-queue-len (packets) : 0
Taildropped(packets/bytes) : 0/0
RED random drops(packets/bytes) : 0/0
Classification statistics (packets/bytes) (rate - kbps)
Transmitted : Un-determined
Total Dropped : Un-determined
Traffic Policing for a Bundled Interface: Example
The following example shows how to configure a policy map for a bundled interface:
RP/0/RSP0/CPU0:Jun 8 16:51:51.679 : config[65546]: %MGBL-LIBTARCFG-6-COMMIT :
Configuration committed by user 'cisco'. Use 'show configuration commit changes
1000006135' to view the changes.
RP/0/RSP0/CPU0:Jun 8 16:52:02.650 : config[65546]: %MGBL-LIBTARCFG-6-COMMIT :
Configuration committed by user 'cisco'. Use 'show configuration commit changes
1000006136' to view the changes.
The following example shows the display output for the policy map configuration in which policing was configured in percentage:
RP/0/RSP0/CPU0:router# show policy-map interface bundle-ether 1
Classification statistics (packets/bytes) (rate - kbps)
Policing statistics (packets/bytes) (rate - kbps)
Policed and dropped : 0/0
Classification statistics (packets/bytes) (rate - kbps)
High watermark (packets) : 0
Inst-queue-len (bytes) : 0
Avg-queue-len (bytes) : 0
TailDrop Threshold(bytes) : 239616000
Taildropped(packets/bytes) : 0/0
2R3C Traffic Policing: Example
These commands create the color-aware policy.
class-map match-any match-frde-0
class-map match-any match-frde-1
policy-map color-aware-policer
police rate 1000 kbps peak-rate 2000 kbps
conform-color match-frde-0
exceed-color match-frde-1
conform-action set qos-group 10
exceed-action set qos-group 20
encapsulation frame-relay
interface POS0/1/0/0.1 l2transport
service-policy input color-aware-policer
This command displays the current configuration commands for the policy.
RP/0/RSP0/CPU0:router# show run policy-map color-aware-policer
Thu Apr 14 09:25:04.752 UTC
policy-map color-aware-policer
police rate 1000 kbps peak-rate 2000 kbps
conform-color match-frde-0
exceed-color match-frde-1
conform-action set qos-group 10
exceed-action set qos-group 20
This command displays the color-aware policy.
/0/RSP0/CPU0:router# show policy-map interface pos 0/1/0/0.1 input
Thu Apr 14 09:24:10.487 UTC
POS0/1/0/0.1 input: color-aware-policer
Classification statistics (packets/bytes) (rate - kbps)
Matched : 66144900/8201967600 498245
Total Dropped : 65879175/8169017700 496245
Policing statistics (packets/bytes) (rate - kbps)
Policed(conform) : 132863/16475012 1000
Policed(exceed) : 132863/16475012 1000
Policed(violate) : 65879175/8169017700 496245
Policed and dropped : 65879175/8169017700
Policed(conform) : 132863/16475012 1000
Policed(exceed) : 51367/6369508 389
Policed(violate) : 46186826/5727166424 347907
Policed(exceed) : 81496/10105504 611
Policed(violate) : 19692349/2441851276 148338
Hierarchical Policing: Example
The following configuration is an example of typical hierarchical policing:
Multi-action Set/Policer: Example
The following example shows how to configure multi-action set/policer in the ingress direction:
police rate 3125000 peak-rate 100000000 peak-burst 3125000
conforfm-action set mpls exp imp 1
conform-action set discard-class 1
Additional References
The following sections provide references related to implementing QoS congestion management.
Related Documents
Related Topic
|
Document Title
|
Initial system bootup and configuration
|
Cisco ASR 9000 Series Aggregation Services Router Getting Started Guide
|
Master command reference
|
Cisco ASR 9000 Series Aggregation Services Router Master Command Listing
|
QoS commands
|
Cisco ASR 9000 Series Aggregation Services Router Modular Quality of Service Command Reference
|
User groups and task IDs
|
"Configuring AAA Services on Cisco ASR 9000 Series Router" module of Cisco Cisco ASR 9000 Series Aggregation Services Router System Security Configuration Guide
|
Standards
Standards
|
Title
|
No new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
|
—
|
MIBs
RFCs
RFCs
|
Title
|
No new or modified RFCs are supported by this feature, and support for existing RFCs has not been modified by this feature.
|
—
|
Technical Assistance
Description
|
Link
|
The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.
|
http://www.cisco.com/techsupport
|