-
Cisco IOS Quality of Service Solutions Command Reference, Release 12.3
-
Introduction for the QoS Command Reference, 12.3
-
Quality of Service Commands, 12.3: a through f
-
Quality of Service Commands, 12.3: ip nbar pdlm through ip rtp priority
-
Quality of Service Commands, 12.3: m through n
-
Quality of Service Commands, 12.3: o through p
-
Quality of Service Commands, 12.3: q through r
-
Quality of Service Commands 12.3: send qdm message through show ip nbar pdlm
-
Quality of Service Commands, 12.3: show ip nbar port-map through show qdm status
-
Quality of Service Commands, 12.3: show queue through vc-hold-queue
-
Table Of Contents
clear ip rsvp signalling rate-limit
clear ip rsvp signalling refresh reduction
exponential-weighting-constant
frame-relay interface-queue priority
frame-relay ip rtp compression-connections
frame-relay ip rtp header-compression
frame-relay map ip rtp header-compression
Quality of Service Commands
The following are quality of service (QoS) commands. The commands are arranged alphabetically.
access-list rate-limit
To configure an access list for use with committed access rate (CAR) policies, use the access-list rate-limit command in global configuration mode. To remove the access list from the configuration, use the no form of this command.
access-list rate-limit acl-index {precedence | mac-address | exp | mask mask}
no access-list rate-limit acl-index {precedence | mac-address | exp | mask mask}
Syntax Description
Defaults
No CAR access lists are configured.
Command Modes
Global configuration
Command History
Usage Guidelines
Use this command to classify packets by the specified IP precedence, MAC address, or MPLS experimental field values for a particular CAR access list. You can then apply CAR policies, using the rate-limit command, to individual rate-limit access lists. When packets in an access list are classified in this manner, the packets with different IP precedences, MAC addresses, or MPLS experimental field values are treated differently by the CAR process.
You can specify only one command for each rate-limit access list. If you enter this command multiple times using the same access list number, the new command overwrites the previous command.
Use the mask keyword to assign multiple IP precedences or MPLS experimental field values to the same rate-limit list. To ascertain the mask value, perform the following steps:
Step 1
Decide which precedences you want to assign to this rate-limit access list.
Step 2
Step 3
Step 4
A mask of FF matches any precedence, and 00 does not match any precedence.
Examples
In the following example, MPLS experimental fields with the value of 7 are assigned to the rate-limit access list 200:
Router(config)# access-list rate-limit 200 7You can then use the rate-limit access list in a rate-limit command so that the rate limit is applied only to packets matching the rate-limit access list.
Router(config)# interface atm4/0.1 mplsRouter(config-if)# rate-limit input access-group rate-limit 200 8000 8000 8000 conform-action set-mpls-exp-transmit 4 exceed-action set-mpls-exp-transmit 0Related Commands
rate-limit
Configures CAR and DCAR policies.
show access-lists rate-limit
Displays information about rate-limit access lists.
auto qos voip
To configure the AutoQoS — VoIP feature on an interface, use the auto qos voip command in interface configuration mode or Frame Relay DLCI configuration mode. To remove the AutoQoS — VoIP feature from an interface, use the no form of this command.
auto qos voip [trust] [fr-atm]
no auto qos voip [trust] [fr-atm]
Syntax Description
Defaults
Disabled
Command Modes
Interface configuration
Frame Relay DLCI configuration (for use with Frame Relay DLCIs)
Command History
Usage Guidelines
To enable the AutoQoS — VoIP feature for Frame Relay-to-ATM interworking, the fr-atm keyword must be configured explicitly. However, the fr-atm keyword affects low-speed DLCIs only. It does not affect high-speed DLCIs.
Note
Depending on whether the trust keyword has been configured for this command, the AutoQoS — VoIP feature automatically creates one of the two following policy maps:
•
•
Both of these policy maps, designed to handle the Voice over IP (VoIP) traffic on an interface or a permanent virtual circuit (PVC), can be modified to suit the quality of service (QoS) requirements of the network. To modify these policy maps, use the appropriate Cisco IOS command.
These policy maps should not be attached to an interface or PVC by using the service-policy command. If the policy maps are attached in this manner, the AutoQoS — VoIP feature (that is, the policy maps, class maps, and access control lists (ACLs)) will not be removed properly when the no auto qos voip command is configured.
For low-speed Frame Relay DLCIs interconnected with ATM PVCs in the same network, the fr-atm keyword must be explicitly configured in the auto qos voip command to configure the AutoQoS — VoIP feature properly. That is, the command must be configured as auto qos voip fr-atm.
For low-speed Frame Relay DLCIs configured with Frame Relay-to-ATM, Multilink PPP (MLP) over Frame Relay (MLPoFR) is configured automatically. The subinterface must have an IP address. When MLPoFR is configured, this IP address is removed and put on the MLP bundle. The AutoQoS — VoIP feature must also be configured on the ATM side by using the auto qos voip command.
The auto qos voip command is not supported on subinterfaces.
The auto qos voip command is available for Frame Relay DLCIs.
Disabling AutoQoS — VoIP
The no auto qos voip command disables the AutoQoS — VoIP feature and removes the configurations associated with the feature.
When the no auto qos voip command is used, the no forms of the individual commands originally generated by the AutoQoS — VoIP feature are configured. With the use of individual no forms of the commands, the system defaults are reinstated. The no forms of the commands will be applied just as if the user had entered the commands individually. As the configuration reinstating the default setting is applied, any messages resulting from the processing of the commands are displayed.
Note
Examples
The following example shows the AutoQoS — VoIP feature configured on a serial point-to-point subinterface 4/1.2. In this example, both the trust and fr-atm keywords are configured.
Router> enableRouter# configure terminalRouter(config)# interface serial4/1.2 point-to-point
Router(config-if)# bandwidth 100
Router(config-if)# ip address 192.168.0.0 255.255.255.0
Router(config-if)# frame-relay interface-dlci 102
Router(config-fr-dlci)# auto qos voip trust fr-atm
Router(config-if# exit
Related Commands
bandwidth (policy-map class)
To specify or modify the bandwidth allocated for a class belonging to a policy map, use the bandwidth command in policy-map class configuration mode. To remove the bandwidth specified for a class, use the no form of this command.
bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage}
no bandwidth {bandwidth-kbps | remaining percent percentage | percent percentage}
Syntax Description
Defaults
No bandwidth is specified
Command Modes
Policy-map class configuration
Command History
Usage Guidelines
You should use the bandwidth command when you configure a policy map for a class defined by the class-map command. The bandwidth command specifies the bandwidth for traffic in that class. Class-based weighted fair queueing (CBWFQ) derives the weight for packets belonging to the class from the bandwidth allocated to the class. CBWFQ then uses the weight to ensure that the queue for the class is serviced fairly.
Specifying Bandwidth as a Percentage
Besides specifying the amount of bandwidth in kbps, you can specify bandwidth as a percentage of either the available bandwidth or the total bandwidth. During periods of congestion, the classes are serviced in proportion to their configured bandwidth percentages. Available bandwidth is equal to the interface bandwidth minus the sum of all bandwidths reserved by the Resource Reservation Protocol (RSVP) feature, the IP RTP Priority feature, and the Low Latency Queueing (LLQ) feature.
Note
Bandwidth Command Restrictions
The following restrictions apply to the bandwidth command:
•
•
•
For more information on bandwidth allocation, refer to the chapter "Congestion Management Overview" in the Cisco IOS Quality of Service Solutions Configuration Guide.
Note that when the policy map containing class policy configurations is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed. If a policy map cannot be attached to a particular interface because of insufficient interface bandwidth, then the policy is removed from all interfaces to which it was successfully attached.
Queue Limits
The bandwidth command can be used with the Modular Command-Line Interface (MQC) to specify the bandwidth for a particular class. When used with the MQC, the bandwidth command uses a default queue limit for the class. This queue limit can be modified using the queue-limit command, thereby overriding the default set by the bandwidth command.
Note
Examples
CBWFQ Bandwidth Guarantee Example
The following example shows how bandwidth is guaranteed when only CBWFQ is configured:
! The following commands create a policy map with two classes:policy-map policy1class class1bandwidth percent 50exitclass class2bandwidth percent 25exitend!The following commands attach the policy to interface serial3/2:interface serial3/2service output policy1endThe following output from the show policy-map command shows the configuration for the policy map called policy1:
Router# show policy-map policy1Policy Map policy1Class class1Weighted Fair QueueingBandwidth 50 (%) Max Threshold 64 (packets)Class class2Weighted Fair QueueingBandwidth 25 (%) Max Threshold 64 (packets)The output from the show policy-map interface command shows that 50 percent of the interface bandwidth is guaranteed for the class called class1, and 25 percent is guaranteed for the class called class2. The output displays the amount of bandwidth as both a percentage and a number of kbps.
Router# show policy-map interface serial3/2Serial3/2Service-policy output:policy1Class-map:class1 (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:noneWeighted Fair QueueingOutput Queue:Conversation 265Bandwidth 50 (%)Bandwidth 772 (kbps) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:class2 (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:noneWeighted Fair QueueingOutput Queue:Conversation 266Bandwidth 25 (%)Bandwidth 386 (kbps) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:class-default (match-any)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:anyIn this example, interface serial3/2 has a total bandwidth of 1544 kbps. During periods of congestion, 50 percent (or 772 kbps) of the bandwidth is guaranteed to the class called class1, and 25 percent (or 386 kbps) of the link bandwidth is guaranteed to the class called class2.
CBWFQ and LLQ Bandwidth Allocation Example
The following output from the show policy-map command shows the configuration for a policy map called p1:
Router# show policy-map p1Policy Map p1Class voiceWeighted Fair QueueingStrict PriorityBandwidth 500 (kbps) Burst 12500 (Bytes)Class class1Weighted Fair QueueingBandwidth remaining 50 (%) Max Threshold 64 (packets)Class class2Weighted Fair QueueingBandwidth remaining 25 (%) Max Threshold 64 (packets)The following output from the show policy-map interface command on serial interface 3/2 shows that 500 kbps of bandwidth is guaranteed for the class called voice1. The classes called class1 and class2 receive 50 percent and 25 percent of the remaining bandwidth, respectively. Any unallocated bandwidth is divided proportionally among class1, class2, and any best-effort traffic classes.
Note
Router# show policy-map interface serial3/2Serial3/2Service-policy output:p1Class-map:voice (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:ip precedence 5Weighted Fair QueueingStrict PriorityOutput Queue:Conversation 264Bandwidth 500 (kbps) Burst 12500 (Bytes)(pkts matched/bytes matched) 0/0(total drops/bytes drops) 0/0Class-map:class1 (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:noneWeighted Fair QueueingOutput Queue:Conversation 265Bandwidth remaining 50 (%) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:class2 (match-all)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:noneWeighted Fair QueueingOutput Queue:Conversation 266Bandwidth remaining 25 (%) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:class-default (match-any)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:anyRelated Commands
bump
To configure the bumping rules for a virtual circuit (VC) class that can be assigned to a VC bundle, use the bump command in VC-class configuration mode. To remove the explicit bumping rules for the VCs assigned to this class and return to the default condition of implicit bumping, use the no bump explicit command or the bump implicit command. To specify that the VC bundle members do not accept any bumped traffic, use the no form of this command.
To configure the bumping rules for a specific VC or permanent virtual circuit (PVC) member of a bundle, use the bump command in bundle-vc or SVC (switched virtual circuit)-bundle-member configuration mode. To remove the explicit bumping rules for the VC or PVC bundle member and return to the default condition of implicit bumping, use the bump implicit command. To specify that the VC or PVC bundle member does not accept any bumped traffic, use the no bump traffic command.
bump {explicit precedence-level | implicit | traffic}
no bump {explicit precedence-level | implicit | traffic}
Syntax Description
Defaults
Implicit bumping
Permit bumping (VCs accept bumped traffic)
Command Modes
VC-class configuration (for a VC class)
Bundle-vc configuration (for an ATM VC bundle member)
SVC-bundle-member configuration (for an SVC bundle member)
Command History
Usage Guidelines
Use the bump command in bundle-vc configuration mode (for an ATM VC bundle member), SVC-bundle-member configuration mode (for an SVC bundle member) to configure bumping rules for a discrete VC or PVC bundle member. Use the bump command in vc-class configuration mode to configure a VC class that can be assigned to a bundle member.
The effects of different bumping configuration approaches are as follows:
•
•
•
•
Note
To use this command in VC-class configuration mode, you must enter the vc-class atm global configuration command before you enter this command.
To use this command to configure an individual bundle member in bundle-VC configuration mode, first issue the bundle command to enter bundle configuration mode for the bundle to which you want to add or modify the VC member to be configured. Then use the pvc-bundle command to specify the VC to be created or modified and enter bundle-vc configuration mode.
This command has no effect if the VC class that contains the command is attached to a standalone VC; that is, if the VC is not a bundle member. In this case, the attributes are ignored by the VC.
VCs in a VC bundle are subject to the following configuration inheritance guidelines (listed in order of next-highest precedence):
•
•
•
Examples
The following example configures the class called "five" to define parameters applicable to a VC in a bundle. If the VC goes down, traffic will be directed (bumped explicitly) to a VC mapped with precedence level 7.
vc-class atm fiveubr 5000precedence 5bump explicit 7The following example configures the class called "premium-class" to define parameters applicable to a VC in a bundle. Unless overridden with a bundle-vc bump configuration, the VC that uses this class will not allow other traffic to be bumped onto it.
vc-class atm premium-classno bump trafficbump explicit 7Related Commands
bundle
To create a bundle or modify an existing bundle to enter bundle configuration mode, use the bundle command in subinterface configuration mode. To remove the specified bundle, use the no form of this command.
bundle bundle-name
no bundle bundle-name
Syntax Description
Defaults
No bundle is specified.
Command Modes
Subinterface configuration
Command History
Usage Guidelines
From within bundle configuration mode you can configure the characteristics and attributes of the bundle and its members, such as the encapsulation type for all virtual circuits (VCs) in the bundle, the bundle management parameters, the service type, and so on. Attributes and parameters you configure in bundle configuration mode are applied to all virtual circuit (VC) members of the bundle.
VCs in a VC bundle are subject to the following configuration inheritance guidelines (listed in order of next highest precedence):
•
•
•
To display status on bundles, use the show atm bundle and show atm bundle statistics commands.
Examples
The following example configures a bundle called new-york. The example specifies the IP address of the subinterface and the router protocol—the router uses Intermediate System-to-Intermediate System (IS-IS) as an IP routing protocol—then configures the bundle.
interface a1/0.1 multipoint ip address 10.0.0.1 255.255.255.0 ip router isis bundle new-yorkRelated Commands
bundle svc
To create or modify a switched virtual circuit (SVC) bundle, use the bundle svc command in interface configuration mode. To remove the specified bundle, use the no form of this command.
bundle svc bundle-name nsap nsap-address
no bundle svc bundle-name nsap nsap-address
Syntax Description
Defaults
No SVC bundle is created or modified.
Command Modes
Interface configuration
Command History
Usage Guidelines
This command causes the system to enter SVC-bundle configuration mode. The bundle name must be the same on both sides of the VC.
From SVC-bundle configuration mode, you can configure the characteristics and attributes of the bundle and its members, such as the encapsulation type for all virtual circuits (VCs) in the bundle, the bundle management parameters, the service type, and so on. Attributes and parameters you configure in SVC-bundle configuration mode are applied to all VC members of the bundle.
VCs in a VC bundle are subject to the following configuration inheritance guidelines (listed in order of next-highest precedence):
•
•
•
To display the status of bundles, use the show atm bundle svc and show atm bundle svc statistics commands.
Examples
The following example configures an SVC bundle called "sanfrancisco":
interface ATM1/0.1 multipointip address 170.100.9.2 255.255.255.0atm esi-address 111111111111.11bundle svc sanfrancisco nsap 47.0091810000000003E3924F01.999999999999.99protocol ip 170.100.9.1broadcastoam retry 4 3 10encapsulation aal5snapoam-bundle managesvc-bundle sevenclass-vc sevensvc-bundle sixclass-vc sixsvc-bundle fiveclass-vc fivesvc-bundle fourclass-vc foursvc-bundle threeclass-vc threesvc-bundle twoclass-vc twosvc-bundle oneclass-vc onesvc-bundle zeroclass-vc zeroRelated Commands
class (policy-map)
To specify the name of the class whose policy you want to create or change or to specify the default class (commonly known as the class-default class) before you configure its policy, use the class command in QoS policy-map configuration mode. To remove a class from the policy map, use the no form of this command.
class {class-name | class-default}
no class {class-name | class-default}
Syntax Description
class-name
The name of the class for which you want to configure or modify policy.
class-default
Specifies the default class so that you can configure or modify its policy.
Defaults
No class is specified.
Command Modes
QoS policy-map configuration
Command History
Usage Guidelines
Policy Map Configuration Mode
Within a policy map, the class (policy-map) command can be used to specify the name of the class whose policy you want to create or change. First, the policy map must be identified.
To identify the policy map (and enter the required QoS policy-map configuration mode), use the policy-map command before you use the class (policy-map) command. After you specify a policy map, you can configure policy for new classes or modify the policy for any existing classes in that policy map.
Class Characteristics
The class name that you specify in the policy map ties the characteristics for that class—that is, its policy—to the class map and its match criteria, as configured using the class-map command.
When you configure policy for a class and specify its bandwidth and attach the policy map to an interface, class-based weighted fair queueing (CBWFQ) determines if the bandwidth requirement of the class can be satisfied. If so, CBWFQ allocates a queue for the bandwidth requirement.
When a class is removed, available bandwidth for the interface is incremented by the amount previously allocated to the class.
The maximum number of classes you can configure for a router—and, therefore, within a policy map—is 64.
Predefined Default Class
The predefined default class called class-default is available for you to use. The class class-default is the class to which traffic is directed if that traffic does not match any of the match criteria in the configured class maps.
Tail Drop or WRED
You can define a class policy to use either tail drop by using the queue-limit command or Weighted Random Early Detection (WRED) by using the random-detect command. When using either tail drop or WRED, note the following points:
•
•
•
Examples
The following example configures three class policies included in the policy map called policy1. Class1 specifies policy for traffic that matches access control list 136. Class2 specifies policy for traffic on interface ethernet101. The third class is the default class to which packets that do not satisfy configured match criteria are directed.
! The following commands create class-maps class1 and class2! and define their match criteria:class-map class1match access-group 136class-map class2match input-interface ethernet101! The following commands create the policy map, which is defined to contain policy! specification for class1, class2, and the default class:policy-map policy1class class1bandwidth 2000queue-limit 40class class2bandwidth 3000random-detectrandom-detect exponential-weighting-constant 10class class-defaultfair-queue 16queue-limit 20Class1 has these characteristics: A minimum of 2000 kbps of bandwidth are expected to be delivered to this class in the event of congestion, and the queue reserved for this class can enqueue 40 packets before tail drop is enacted to handle additional packets.
Class2 has these characteristics: A minimum of 3000 kbps of bandwidth are expected to be delivered to this class in the event of congestion, and a weight factor of 10 is used to calculate the average queue size. For congestion avoidance, WRED packet drop is used, not tail drop.
The default class has these characteristics: 16 dynamic queues are reserved for traffic that does not meet the match criteria of other classes whose policy is defined by the policy map called policy1, and a maximum of 20 packets per queue are enqueued before tail drop is enacted to handle additional packets.
Note
The following example configures policy for the default class included in the policy map called policy2. The default class has these characteristics: 20 dynamic queues are available for traffic that does not meet the match criteria of other classes whose policy is defined by the policy map called policy2, and a weight factor of 14 is used to calculate the average queue size. For congestion avoidance, WRED packet drop is used, not tail drop.
policy-map policy2class class-defaultfair-queue 20random-detectrandom-detect exponential-weighting-constant 14The following example configures policy for a class called acl136 included in the policy map called policy1. Class acl136 has these characteristics: a minimum of 2000 kbps of bandwidth are expected to be delivered to this class in the event of congestion, and the queue reserved for this class can enqueue 40 packets before tail drop is enacted to handle additional packets. Note that when the policy map containing this class is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed, taking into account all class policies and RSVP, if configured.
policy-map policy1class acl136bandwidth 2000queue-limit 40The following example configures policy for a class called int101 included in the policy map called policy8. Class int101 has these characteristics: a minimum of 3000 kbps of bandwidth are expected to be delivered to this class in the event of congestion, and a weight factor of 10 is used to calculate the average queue size. For congestion avoidance, WRED packet drop is used, not tail drop. Note that when the policy map containing this class is attached to the interface to stipulate the service policy for that interface, available bandwidth is assessed.
policy-map policy8class int101bandwidth 3000random-detect exponential-weighting-constant 10The following example configures policy for the class-default default class included in the policy map called policy1. The class-default default class has these characteristics: 10 hashed queues for traffic that does not meet the match criteria of other classes whose policy is defined by the policy map called policy1, and a maximum of 20 packets per queue before tail drop is enacted to handle additional enqueued packets.
policy-map policy1class class-defaultfair-queue 10queue-limit 20The following example configures policy for the class-default default class included in the policy map called policy8. The class-default default class has these characteristics: 20 hashed queues for traffic that does not meet the match criteria of other classes whose policy is defined by the policy map called policy8, and a weight factor of 14 is used to calculate the average queue size. For congestion avoidance, WRED packet drop is used, not tail drop.
policy-map policy8class class-defaultfair-queue 20random-detect exponential-weighting-constant 14Related Commands
class-bundle
To configure a virtual circuit (VC) bundle with the bundle-level commands contained in the specified VC class, use the class-bundle command in bundle or SVC (switched virtual circuit)-bundle configuration mode. To remove the VC class parameters from a VC bundle, use the no form of this command.
class-bundle vc-class-name
no class-bundle vc-class-name
Syntax Description
Defaults
No VC class is assigned to the VC bundle.
Command Modes
Bundle configuration
SVC-bundle configuration
Command History
12.0 T
This command was introduced, replacing the class command for configuring ATM VC bundles.
12.2(4)T
This command was made available in SVC-bundle configuration mode.
Usage Guidelines
To use this command, you must first enter the bundle or bundle svc command to create the bundle and enter bundle or SVC-bundle configuration mode.
Use this command to assign a previously defined set of parameters (defined in a VC class) to an ATM VC bundle. Parameters set through bundle-level commands that are contained in a VC class are applied to the bundle and its VC members.
You can add the following commands to a VC class to be used to configure a VC bundle: broadcast, encapsulation, inarp, oam-bundle, oam retry, and protocol.
Bundle-level parameters applied through commands that are configured directly on a bundle supersede bundle-level parameters applied through a VC class by the class-bundle command. Some bundle-level parameters applied through a VC class or directly to the bundle can be superseded by commands that you directly apply to individual VCs in bundle-VC configuration mode.
Examples
In the following example, a class called "class1" is created and then applied to the bundle called "bundle1":
! The following commands create the class class1:vc-class atm class1encapsulation aal5snapbroadcastprotocol ip inarpoam-bundle manage 3oam 4 3 10! The following commands apply class1 to the bundle called bundle1:bundle bundle1class-bundle class1With hierarchy precedence rules taken into account, VCs belonging to the bundle called "bundle1" will be characterized by these parameters: aal5snap, encapsulation, broadcast on, use of Inverse Address Resolution Protocol (Inverse ARP) to resolve IP addresses, and Operation, Administration, and Maintenance (OAM) enabled.
Related Commands
class-map
To create a class map to be used for matching packets to a specified class, use the class-map command in global configuration mode. To remove an existing class map from the router, use the no form of this command.
class-map [match-all | match-any] class-map-name
no class-map [match-all | match-any] class-map-name
Syntax Description
Defaults
No default behavior or values
Command Modes
Global configuration
Command History
Usage Guidelines
Use this command to specify the name of the class for which you want to create or modify class map match criteria. Use of the class-map command enables class-map configuration mode in which you can enter one of the match commands to configure the match criteria for this class. Packets arriving at either the input or output interface (determined by how the service-policy command is configured) are checked against the match criteria configured for a class map to determine if the packet belongs to that class.
When configuring a class map, you can use one or more match commands to specify match criteria. For example, you can use the match access-group command, the match protocol command, or the match input-interface command. The match commands vary according to the Cisco IOS release. For more information about match criteria and match commands, refer to the "Modular Quality of Service Command-Line Interface (CLI)" chapter of the Cisco IOS Quality of Service Solutions Configuration Guide.
Examples
The following example specifies class101 as the name of a class, and it defines a class map for this class. The class called class101 specifies policy for traffic that matches access control list 101.
class-map class101match access-group 101Related Commands
clear ip rsvp authentication
To eliminate Resource Reservation Protocol (RSVP) security associations before their lifetimes expire, use the clear ip rsvp authentication command in EXEC mode.
clear ip rsvp authentication [ip-address | hostname]
Syntax Description
ip-address
(Optional) Frees security associations with a specific neighbor.
hostname
(Optional) Frees security associations with a specific host.
Note
Defaults
The default behavior is to clear all security associations.
Command Modes
EXEC
Command History
Usage Guidelines
Use the clear ip rsvp authentication command for the following reasons:
•
•
•
•
You can delete all RSVP security associations if you do not enter an IP address or a host name, or just the ones with a specific RSVP neighbor or host.
If you delete a security association, it is re-created as needed when the trusted RSVP neighbors start sending more RSVP messages.
Examples
The following command shows how to clear all security associations before they expire:
Router# clear ip rsvp authenticationRelated Commands
clear ip rsvp counters
To clear (set to zero) all IP Resource Reservation Protocol (RSVP) counters that are being maintained by the router, use the clear ip rsvp counters command in EXEC mode.
clear ip rsvp counters [confirm]
Syntax Description
Command Modes
EXEC
Command History
12.0(14)ST
This command was introduced.
12.2(13)T
This command was integrated into Cisco IOS Release 12.2(13)T.
Usage Guidelines
Use the clear ip rsvp counters command to reset all IP RSVP counters to zero so that you can see changes easily.
Examples
The following command shows that all IP RSVP counters that are being maintained are cleared:
Router# clear ip rsvp countersClear rsvp counters [confirm]
Note
The following command shows the non-zero counters for the interfaces that have RSVP enabled:
Router# show ip rsvp countersPOS0/0 Recv Xmit Recv XmitPath 0 300 Resv 371 0PathError 0 0 ResvError 0 0PathTear 0 150 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 20 28 Srefresh 10 10DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/0 Recv Xmit Recv XmitPath 300 0 Resv 0 300PathError 0 0 ResvError 0 0PathTear 150 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0POS1/3 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Loopback0 Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Non RSVP i/f's Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0All Interfaces Recv Xmit Recv XmitPath 0 0 Resv 0 0PathError 0 0 ResvError 0 0PathTear 0 0 ResvTear 0 0ResvConf 0 0 RTearConf 0 0Ack 0 0 Srefresh 0 0DSBM_WILLING 0 0 I_AM_DSBM 0 0Unknown 0 0 Errors 0 0Table 1 describes the fields shown in the display.
Related Commands
show ip rsvp counters
Displays the number of RSVP messages that were sent and received.
clear ip rsvp reservation
To remove Resource Reservation Protocol (RSVP) RESV-related receiver information currently in the database, use the clear ip rsvp reservation command in EXEC mode.
clear ip rsvp reservation {session-ip-address sender-ip-address {tcp | udp | ip-protocol} session-dport sender-sport | *}
Syntax Description
Command Modes
EXEC
Command History
Usage Guidelines
Use the clear ip rsvp reservation command to remove the RESV-related sender information currently in the database so that when reservation requests arrive, based on the RSVP admission policy, the relevant ones can be reestablished.
Whenever you change the clockrate or bandwidth of an interface, RSVP does not update its database to reflect the change. This is because such a change requires that RSVP reestablish reservations based on the new clockrate or bandwidth value and arbitrarily dropping some reservations while retaining others is not desired. The solution is to clear the RESV state by issuing the clear ip rsvp reservation command.
The clear ip rsvp reservation command clears the RESV state from the router on which you issued the command and causes the router to send a PATH TEAR message to the upstream routers thereby clearing the RESV state for that reservation on all the upstream routers.
Examples
The following example clears all the RESV-related receiver information currently in the database:
Router# clear ip rsvp reservation *
The following example clears all the RESV-related receiver information for a specified reservation currently in the database:
Router# clear ip rsvp reservation 10.2.1.1 10.1.1.2 udp 10 20
Related Commands
clear ip rsvp sender
Removes RSVP PATH-related sender information currently in the database.
clear ip rsvp sender
To remove Resource Reservation Protocol (RSVP) PATH-related sender information currently in the database, use the clear ip rsvp sender command in EXEC mode.
clear ip rsvp sender {session-ip-address sender-ip-address {tcp | udp | ip-protocol} session-dport sender-sport | *}
Syntax Description
Command Modes
EXEC
Command History
Usage Guidelines
Use the clear ip rsvp sender command to remove the PATH-related sender information currently in the database so that when reservation requests arrive, based on the RSVP admission policy, the relevant ones can be reestablished.
Whenever you change the clockrate or bandwidth of an interface, RSVP does not update its database to reflect the change. This is because such a change requires that RSVP reestablish reservations based on the new clockrate or bandwidth value and arbitrarily dropping some reservations while retaining others is not desired. The solution is to clear the PATH state by issuing the clear ip rsvp sender command.
The clear ip rsvp sender command clears the PATH state from the router on which you issued the command and causes the router to send a PATH TEAR message to the downstream routers thereby clearing the PATH state for that reservation on all the downstream routers.
Examples
The following example clears all the PATH-related sender information currently in the database:
Router# clear ip rsvp sender *
The following example clears all the PATH-related sender information for a specified reservation currently in the database:
Router# clear ip rsvp sender 10.2.1.1 10.1.1.2 udp 10 20
Related Commands
clear ip rsvp reservation
Removes RSVP RESV-related receiver information currently in the database.
clear ip rsvp signalling rate-limit
To clear (set to zero) the number of Resource Reservation Protocol (RSVP) messages that were dropped because of a full queue, use the clear ip rsvp signalling rate-limit command in EXEC mode.
clear ip rsvp signalling rate-limit
Syntax Description
This command has no arguments or keywords.
Command Modes
EXEC
Command History
Usage Guidelines
Use the clear ip rsvp signalling rate-limit command to clear the counters recording dropped messages.
Examples
The following command shows how all dropped messages are cleared:
Router# clear ip rsvp signalling rate-limitRelated Commands
clear ip rsvp signalling refresh reduction
To clear (set to zero) the counters associated with the number of retransmissions and the number of out-of-order Resource Reservation Protocol (RSVP) messages, use the clear ip rsvp signalling refresh reduction command in EXEC mode.
clear ip rsvp signalling refresh reduction
Syntax Description
This command has no arguments or keywords.
Command Modes
EXEC
Command History
Usage Guidelines
Use the clear ip rsvp signalling refresh reduction command to clear the counters recording retransmissions and out-of-order RSVP messages.
Examples
The following command shows how all the retransmissions and out-of-order messages are cleared:
Router# clear ip rsvp signalling refresh reductionRelated Commands
ip rsvp signalling refresh reduction
Enables refresh reduction.
show ip rsvp signalling refresh reduction
Displays refresh-reduction parameters for RSVP messages.
compression header ip
To configure Real-Time Transport Protocol (RTP) or TCP IP header compression for a specific class, use the compression header ip command in policy-map class configuration mode. To remove RTP or TCP IP header compression for a specific class, use the no form of this command.
compression header ip [rtp | tcp]
no compression header ip
Syntax Description
Defaults
If you do not specify either RTP or TCP header compression (that is, you press the enter key after the command name) both RTP and TCP header compressions are configured. This is intended to cover the "all compressions" scenario.
Command Modes
Policy-map class configuration
Command History
Usage Guidelines
Using any form of the compression header ip command overrides any previously entered form.
The compression header ip command can be used at any level in the policy map hierarchy configured with the Modular Quality of Service (QoS) Command-Line Interface (CLI) (MQC) feature.
Examples
In the following example, the compression header ip command has been configured to use RTP header compression for a class called "class1". Class1 is part of policy map called "policy1".
Router(config)# policy-map policy1Router(config-pmap)# class-map class1Router(config-pmap-c)# compression header ip rtpRouter(config-pmap-c)# exitRelated Commands
custom-queue-list
To assign a custom queue list to an interface, use the custom-queue-list command in interface configuration mode. To remove a specific list or all list assignments, use the no form of this command.
custom-queue-list [list-number]
no custom-queue-list [list-number]
Syntax Description
Defaults
No custom queue list is assigned.
Command Modes
Interface configuration
Command History
Usage Guidelines
Only one queue list can be assigned per interface. Use this command in place of the priority-list interface command (not in addition to it). Custom queueing allows a fairness not provided with priority queueing. With custom queueing, you can control the bandwidth available on the interface when the interface is unable to accommodate the aggregate traffic enqueued. Associated with each output queue is a configurable byte count, which specifies how many bytes of data should be delivered from the current queue by the system before the system moves on to the next queue. When a particular queue is being processed, packets are sent until the number of bytes sent exceeds the queue byte count or until the queue is empty.
Use the show queueing custom and show interfaces commands to display the current status of the custom output queues.
Examples
In the following example, custom queue list number 3 is assigned to serial interface 0:
interface serial 0custom-queue-list 3Related Commands
disconnect qdm
To disconnect a Quality of Service Device Manager (QDM) client, use the disconnect qdm command in EXEC mode.
disconnect qdm [client client-id]
Syntax Description
Command Modes
EXEC
Command History
12.1(1)E
This command was introduced.
12.1(5)T
This command was integrated into Cisco IOS Release 12.1(5)T.
Usage Guidelines
Use the disconnect qdm command to disconnect all QDM clients that are connected to the router.
Use the disconnect qdm [client client-id] command to disconnect a specific QDM client connected to a router. For instance, using the disconnect qdm client 42 command will disconnect the QDM client with the ID 42.
Examples
The following example shows how to disconnect all connected QDM clients:
Router# disconnect qdmThe following example shows how to disconnect a specific QDM client with client ID 9:
Router# disconnect qdm client 9Related Commands
drop
To configure a traffic class to discard packets belonging to a specific class, use the drop command in policy-map class configuration mode. To disable the packet discarding action in a traffic class, use the no form of this command.
drop
no drop
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Policy-map class configuration
Command History
Usage Guidelines
Note the following points when configuring the drop command to unconditionally discard packets in a traffic class:
•
•
•
Examples
In the following example a traffic class called "class1" has been created and configured for use in a policy map called "policy1." The policy map (service policy) is attached to an output serial interface 2/0. All packets matching access-group 101 are placed in a class called "c1." Packets belonging to this class are discarded.
Router(config)# class-map class1Router(config-cmap)# match access-group 101Router(config-cmap)# policy-map policy1Router(config-pmap)# class c1Router(config-pmap-c)# dropRouter(config-pmap-c)# interface s2/0Router(config-if)# service-policy output policy1Router(config-if)# exitRelated Commands
dscp
To change the minimum and maximum packet thresholds for the differentiated services code point (DSCP) value, use the dscp command in cfg-red-grp configuration mode. To return the minimum and maximum packet thresholds to the default for the DSCP value, use the no form of this command.
dscp dscpvalue min-threshold max-threshold [mark-probability-denominator]
no dscp dscpvalue min-threshold max-threshold [mark-probability-denominator]
Syntax Description
Defaults
If WRED is using the DSCP value to calculate the drop probability of a packet, all entries of the DSCP table are initialized with the default settings shown in Table 2 in the "Usage Guidelines" section of this command.
Command Modes
cfg-red-grp configuration
Command History
Usage Guidelines
This command must be used in conjunction with the random-detect-group command.
Additionally, the dscp command is available only if you specified the dscp-based argument when using the random-detect-group command.
Table 2 lists the DSCP default settings used by the dscp command. Table 2 lists the DSCP value, and its corresponding minimum threshold, maximum threshold, and mark probability. The last row of the table (the row labeled "default") shows the default settings used for any DSCP value not specifically shown in the table.
Examples
The following example enables WRED to use the DSCP value af22. The minimum threshold for the DSCP value af22 is 28, the maximum threshold is 40, and the mark probability is 10.
dscp af22 28 40 10Related Commands
exponential-weighting-constant
To configure the exponential weight factor for the average queue size calculation for a Weighted Random Early Detection (WRED) parameter group, use the exponential-weighting-constant command in random-detect-group configuration mode. To return the exponential weight factor for the group to the default, use the no form of this command.
exponential-weighting-constant exponent
no exponential-weighting-constant
Syntax Description
Defaults
The default weight factor is 9.
Command Modes
Random-detect-group configuration
Command History
Usage Guidelines
When used, this command is issued after the random-detect-group command is entered.
Use this command to change the exponent used in the average queue size calculation for a WRED parameter group. The average queue size is based on the previous average and the current size of the queue. The formula is:
average = (old_average * (1-1/2^x)) + (current_queue_size * 1/2^x)
where x is the exponential weight factor specified in this command. Thus, the higher the factor, the more dependent the average is on the previous average.
Note
For high values of x, the previous average becomes more important. A large factor smooths out the peaks and lows in queue length. The average queue size is unlikely to change very quickly. The WRED process will be slow to start dropping packets, but it may continue dropping packets for a time after the actual queue size has fallen below the minimum threshold. The resulting slow-moving average will accommodate temporary bursts in traffic.
If the value of x gets too high, WRED will not react to congestion. Packets will be sent or dropped as if WRED were not in effect.
For low values of x, the average queue size closely tracks the current queue size. The resulting average may fluctuate with changes in the traffic levels. In this case, the WRED process will respond quickly to long queues. Once the queue falls below the minimum threshold, the process will stop dropping packets.
If the value of x gets too low, WRED will overreact to temporary traffic bursts and drop traffic unnecessarily.
Examples
The following example configures the WRED group called sanjose with a weight factor of 10:
random-detect-group sanjoseexponential-weighting-constant 10Related Commands
fair-queue (class-default)
To specify the number of dynamic queues to be reserved for use by the class-default class as part of the default class policy, use the fair-queue command in policy-map class configuration mode. To delete the configured number of dynamic queues from the class-default policy, use the no form of this command.
fair-queue [number-of-dynamic-queues]
no fair-queue [number-of-dynamic-queues]
Syntax Description
number-of-dynamic-queues
(Optional) A power of 2 number in the range from 16 to 4096 specifying the number of dynamic queues.
Defaults
The number of dynamic queues is derived from the interface or ATM permanent virtual circuit (PVC) bandwidth. See Table 3 in the "Usage Guidelines" section of this command for the default number of dynamic queues that weighted fair queueing (WFQ) and class-based WFQ (CBWFQ) use when they are enabled on an interface. See Table 4 in the "Usage Guidelines" section of this command for the default number of dynamic queues used when WFQ or CBWFQ is enabled on an ATM PVC.
Command Modes
Policy-map class configuration
Command History
Usage Guidelines
This command can be used for the default class (commonly known as the class-default class) only. You can use it in conjunction with either the queue-limit command or the random-detect command.
The class-default class is the default class to which traffic is directed if that traffic does not satisfy the match criteria of other classes whose policy is defined in the policy map.
Table 3 lists the default number of dynamic queues that weighted fair queueing (WFQ) and class-based WFQ (CBWFQ) use when they are enabled on an interface.
Table 4 lists the default number of dynamic queues used when WFQ or CBWFQ is enabled on an ATM PVC.
Examples
The following example configures policy for the default class included in the policy map called policy9. Packets that do not satisfy match criteria specified for other classes whose policies are configured in the same service policy are directed to the default class, for which 16 dynamic queues have been reserved. Because the queue-limit command is configured, tail drop is used for each dynamic queue when the maximum number of packets are enqueued and additional packets arrive.
policy-map policy9class class-defaultfair-queue 16queue-limit 20The following example configures policy for the default class included in the policy map called policy8. The fair-queue command reserves 20 dynamic queues to be used for the default class. For congestion avoidance, Weighted Random Early Detection (WRED) packet drop is used, not tail drop.
policy-map policy8class class-defaultfair-queue 20random-detectRelated Commands
queue-limit
Specifies or modifies the maximum number of packets the queue can hold for a class policy configured in a policy map.
random-detect (interface)
Enables WRED or DWRED.
fair-queue (DWFQ)
To enable VIP-distributed weighted fair queueing (DWFQ), use the fair-queue command in interface configuration mode. The command enables DWFQ on an interface using a VIP2-40 or greater interface processor. To disable DWFQ, use the no form of this command.
fair-queue
no fair-queue
Syntax Description
This command has no arguments or keywords.
Defaults
DWFQ is enabled by default for physical interfaces whose bandwidth is less than or equal to 2.048 Mbps.
DWFQ can be configured on interfaces but not subinterfaces. It is not supported on Fast EtherChannel, tunnel, or other logical or virtual interfaces such as Multilink PPP (MLP).
See Table 5 in the "Usage Guidelines" section of this command for a list of the default queue lengths and thresholds.
Command Modes
Interface configuration
Command History
Usage Guidelines
With DWFQ, packets are classified by flow. Packets with the same source IP address, destination IP address, source TCP or User Datagram Protocol (UDP) port, destination TCP or UDP port, and protocol belong to the same flow.
DWFQ allocates an equal share of the bandwidth to each flow.
Table 5 lists the default queue lengths and thresholds.
Table 5 Default Fair Queue Lengths and Thresholds
Congestive discard threshold
64 messages
Dynamic queues
256 queues
Reservable queues
0 queues
Examples
The following example enables DWFQ on the High-Speed Serial Interface (HSSI) interface 0/0/0:
interface Hssi0/0/0description 45Mbps to R2ip address 10.200.14.250 255.255.255.252fair-queueRelated Commands
fair-queue (policy-map class)
To specify the number of queues to be reserved for use by a traffic class, use the fair-queue command in QoS policy-map class configuration mode. To delete the configured number of queues from the traffic class, use the no form of this command.
fair-queue [dynamic-queues]
no fair-queue [dynamic-queues]
Syntax Description
dynamic-queues
(Optional) A number specifying the number of dynamic conversation queues. The number can be in the range of 16 to 4096.
Defaults
No queues are reserved.
Command Modes
QoS policy-map class configuration
Command History
Usage Guidelines
On a VIP, the fair-queue command can be used for any traffic class (as opposed to non-VIP platforms, which can only use the fair-queue command in the default traffic class). The fair-queue command can be used in conjunction with either the queue-limit command or the random-detect exponential-weighting-constant command.
Examples
The following example configures the default traffic class for the policy map called policy9 to reserve ten queues for packets that do not satisfy match criteria specified for other traffic classes whose policy is configured in the same service policy. Because the queue-limit command is configured, tail drop is used for each queue when the maximum number of packets is enqueued and additional packets arrive.
policy-map policy9 class class-default fair-queue 10queue-limit 20The following example configures a service policy called policy8 that is associated with a user-defined traffic class called class1. The fair-queue command reserves 20 queues to be used for the service policy. For congestion avoidance, Weighted Random Early Detection (WRED) or distributed WRED (DWRED) packet drop is used, not tail drop.
policy-map policy8 class class1 fair-queue 20random-detect exponential-weighting-constant 14Related Commands
fair-queue (WFQ)
To enable weighted fair queueing (WFQ) for an interface, use the fair-queue command in interface configuration mode. To disable WFQ for an interface, use the no form of this command.
fair-queue [congestive-discard-threshold [dynamic-queues [reservable-queues]]]
no fair-queue
Syntax Description
Defaults
Fair queueing is enabled by default for physical interfaces whose bandwidth is less than or equal to 2.048 Mbps and that do not use the following:
•
•
•
•
•
•
•
Fair queueing is not an option for the protocols listed above. However, if custom queueing or priority queueing is enabled for a qualifying link, it overrides fair queueing, effectively disabling it. Additionally, fair queueing is automatically disabled if you enable the autonomous or silicon switching engine mechanisms.
Note
The number of dynamic queues is derived from the interface or ATM permanent virtual circuit (PVC) bandwidth. See Table 3 in the fair-queue (class-default) command for the default number of dynamic queues that WFQ and class-based WFQ (CBWFQ) use when they are enabled on an interface. See Table 4 in the fair-queue (class-default) command for the default number of dynamic queues used when WFQ and CBWFQ are enabled on an ATM PVC.
Command Modes
Interface configuration
Command History
Usage Guidelines
This command enables WFQ. With WFQ, packets are classified by flow. For example, packets with the same source IP address, destination IP address, source TCP or User Datagram Protocol (UDP) port, destination TCP or UDP port, and protocol belong to the same flow; see Table 6 for a full list of protocols and traffic stream discrimination fields.
When enabled for an interface, WFQ provides traffic priority management that automatically sorts among individual traffic streams without requiring that you first define access lists. Enabling WFQ requires use of this command only.
When WFQ is enabled for an interface, new messages for high-bandwidth traffic streams are discarded after the configured or default congestive discard threshold has been met. However, low-bandwidth conversations, which include control message conversations, continue to enqueue data. As a result, the fair queue may occasionally contain more messages than its configured threshold number specifies.
WFQ uses a traffic data stream discrimination registry service to determine which traffic stream a message belongs to. For each forwarding protocol, Table 6 shows the attributes of a message that are used to classify traffic into data streams.
It is important to note that IP Precedence, congestion in Frame Relay switching, and discard eligible (DE) flags affect the weights used for queueing.
IP Precedence, which is set by the host or by policy maps, is a number in the range from 0 to 7. Data streams of precedence number are weighted so that they are given an effective bit rate of number+1 times as fast as a data stream of precedence 0, which is normal.
In Frame Relay switching, message flags for forward explicit congestion notification (FECN), backward explicit congestion notification (BECN), and DE message flags cause the algorithm to select weights that effectively impose reduced queue priority. The reduced queue priority provides the application with "slow down" feedback and sorts traffic, giving the best service to applications within their committed information rate (CIR).
Fair queueing is supported for all LAN and line (WAN) protocols except X.25, including LAPB and SDLC; see the notes in the section "Defaults." Because tunnels are software interfaces that are themselves routed over physical interfaces, fair queueing is not supported for tunnels. Fair queueing is on by default for interfaces with bandwidth less than or equal to 2 Mbps.
Note
When Resource Reservation Protocol (RSVP) is configured on an interface that supports fair queueing or on an interface that is configured for fair queueing with the reservable queues set to 0 (the default), the reservable queue size is automatically configured using the following method: interface bandwidth divided by 32 kbps. You can override this default by specifying a reservable queue other than 0. For more information on RSVP, refer to the chapter "Configuring RSVP" in the Cisco IOS Quality of Service Solutions Configuration Guide.
Examples
The following example enables use of WFQ on serial interface 0, with a congestive threshold of 300. This threshold means that messages will be discarded from the queueing system only when 300 or more messages have been queued and the message is in a data stream that has more than one message in the queue. The transmit queue limit is set to 2, based on the 384-kilobit (Kb) line set by the bandwidth command:
interface serial 0bandwidth 384fair-queue 300Unspecified parameters take the default values.
The following example requests a fair queue with a congestive discard threshold of 64 messages, 512 dynamic queues, and 18 RSVP queues:
interface Serial 3/0ip unnumbered Ethernet 0/0fair-queue 64 512 18Related Commands
fair-queue aggregate-limit
To set the maximum number of packets in all queues combined for VIP-distributed weighted fair queueing (DWFQ), use the fair-queue aggregate-limit command in interface configuration mode. To return the value to the default, use the no form of this command.
fair-queue aggregate-limit aggregate-packets
no fair-queue aggregate-limit
Syntax Description
aggregate-packets
Total number of buffered packets allowed before some packets may be dropped. Below this limit, packets will not be dropped.
Defaults
The total number of packets allowed is based on the transmission rate of the interface and the available buffer space on the Versatile Interface Processor (VIP).
Command Modes
Interface configuration
Command History
Usage Guidelines
In general, you should not change the maximum number of packets allows in all queues from the default. Use this command only if you have determined that you would benefit from using a different value, based on your particular situation.
DWFQ keeps track of the number of packets in each queue and the total number of packets in all queues.
When the total number of packets is below the aggregate limit, queues can buffer more packets than the individual queue limit.
When the total number of packets reaches the aggregate limit, the interface starts enforcing the individual queue limits. Any new packets that arrive for a queue that is over its individual queue limit are dropped. Packets that are already in the queue will not be dropped, even if the queue is over the individual limit.
In some cases, the total number of packets in all queues put together may exceed the aggregate limit.
Examples
The following example sets the aggregate limit to 54 packets:
interface Fddi9/0/0fair-queue tosfair-queue aggregate-limit 54Related Commands
fair-queue individual-limit
To set the maximum individual queue depth for Versatile Interface Processor (VIP)-distributed weighted fair queueing (DWFQ), use the fair-queue individual-limit command in interface configuration mode. To return the value to the default, use the no form of this command.
fair-queue individual-limit individual-packet
no fair-queue individual-limit
Syntax Description
individual-packet
Maximum number of packets allowed in each per-flow or per-class queue during periods of congestion.
Defaults
Half of the aggregate queue limit
Command Modes
Interface configuration
Command History
Usage Guidelines
In general, you should not change the maximum individual queue depth from the default. Use this command only if you have determined that you would benefit from using a different value, based on your particular situation.
DWFQ keeps track of the number of packets in each queue and the total number of packets in all queues.
When the total number of packets is below the aggregate limit, queues can buffer more packets than the individual queue limit.
When the total number of packets reaches the aggregate limit, the interface starts enforcing the individual queue limits. Any new packets that arrive for a queue that is over its individual queue limit are dropped. Packets that are already in the queue will not be dropped, even if the queue is over the individual limit.
In some cases, the total number of packets in all queues put together may exceed the aggregate limit.
Examples
The following example sets the individual queue limit to 27:
interface Fddi9/0/0mac-address 0000.0c0c.2222ip address 10.1.1.1 255.0.0.0fair-queue tosfair-queue individual-limit 27Related Commands
fair-queue limit
To set the maximum queue depth for a specific Versatile Interface Processor (VIP)-distributed weighted fair queueing (DWFQ) class, use the fair-queue limit command in interface configuration mode. To return the value to the default, use the no form of this command.
fair-queue {qos-group number | tos number} limit class-packet
no fair-queue {qos-group number | tos number} limit class-packet
Syntax Description
Defaults
The individual queue depth, as specified by the fair-queue individual-limit command. If the fair-queue individual-limit command is not configured, the default is half of the aggregate queue limit.
Command Modes
Interface configuration
Command History
Usage Guidelines
Use this command to specify the number queue depth for a particular class for class-based DWFQ. This command overrides the global individual limit specified by the fair-queue individual-limit command.
In general, you should not change this value from the default. Use this command only if you have determined that you would benefit from using a different value, based on your particular situation.
Examples
The following example sets the individual queue limit for ToS group 3 to 20:
interface Fddi9/0/0mac-address 0000.0c0c.2222ip address 10.1.1.1 255.0.0.0fair-queue tosfair-queue tos 3 limit 20Related Commands
fair-queue qos-group
To enable Versatile Interface Processor (VIP)-distributed weighted fair queueing (DWFQ) and classify packets based on the internal QoS-group number, use the fair-queue qos-group command in interface configuration mode. To disable QoS-group-based DWFQ, use the no form of this command.
fair-queue qos-group
no fair-queue qos-group
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Interface configuration
Command History
Usage Guidelines
Use this command to enable QoS-group-based DWFQ, a type of class-based DWFQ. Class-based DWFQ overrides flow-based DWFQ. Therefore, this command overrides the fair-queue (DWFQ) command.
When this command is enabled, packets are assigned to different queues based on their QoS group. A QoS group is an internal classification of packets used by the router to determine how packets are treated by certain QoS features, such as DWFQ and committed access rate (CAR). Use a CAR policy or the QoS Policy Propagation via Border Gateway Protocol (BGP) feature to assign packets to QoS groups.
Specify a weight for each class. In periods of congestion, each group is allocated a percentage of the output bandwidth equal to the weight of the class. For example, if a class is assigned a weight of 50, packets from this class are allocated at least 50 percent of the outgoing bandwidth during periods of congestion.
Examples
The following example enables QoS-based DWFQ and allocates bandwidth for nine QoS groups (QoS groups 0 through 8):
interface Hssi0/0/0description 45Mbps to R2ip address 10.200.14.250 255.255.255.252fair-queue qos-groupfair-queue qos-group 1 weight 5fair-queue qos-group 2 weight 5fair-queue qos-group 3 weight 10fair-queue qos-group 4 weight 10fair-queue qos-group 5 weight 10fair-queue qos-group 6 weight 15fair-queue qos-group 7 weight 20fair-queue qos-group 8 weight 29Related Commands
fair-queue tos
To enable Versatile Interface Processor (VIP)-distributed weighted fair queueing (DWFQ) and classify packets using the type of service (ToS) field of packets, use the fair-queue tos command in interface configuration command. To disable ToS-based DWFQ, use the no form of this command.
fair-queue tos
no fair-queue tos
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
By default, class 0 is assigned a weight of 10; class 1 is assigned a weight of 20; class 2 is assigned a weight of 30; and class 3 is assigned a weight of 40.
Command Modes
Interface configuration
Command History
Usage Guidelines
Use this command to enable ToS-based DWFQ, a type of class-based DWFQ. Class-based DWFQ overrides flow-based DWFQ. Therefore, this command overrides the fair-queue (DWFQ) command.
When this command is enabled, packets are assigned to different queues based on the two low-order IP Precedence bits in the ToS field of the packet header.
In periods of congestion, each group is allocated a percentage of the output bandwidth equal to the weight of the class. For example, if a class is assigned a weight of 50, packets from this class are allocated at least 50 percent of the outgoing bandwidth during periods of congestion.
If you wish to change the weights, use the fair-queue weight command.
Examples
The following example enables ToS-based DWFQ on the High-Speed Serial Interface (HSSI) interface 0/0/0:
interface Hssi0/0/0description 45Mbps to R2ip address 10.200.14.250 255.255.255.252fair-queuefair-queue tosRelated Commands
fair-queue weight
To assign a weight to a class for Versatile Interface Processor (VIP)-distributed weighted fair queueing (DWFQ), use the fair-queue weight command in interface configuration mode. To remove the bandwidth allocated for the class, use the no form of this command.
fair-queue {qos-group number | tos number} weight weight
no fair-queue {qos-group number | tos number} weight weight
Syntax Description
Defaults
For QoS DWFQ, unallocated bandwidth is assigned to QoS group 0.
For ToS-based DWFQ, class 0 is assigned a weight of 10; class 1 is assigned a weight of 20; class 2 is assigned a weight of 30; and class 3 is assigned a weight of 40.
Command Modes
Interface configuration
Command History
Usage Guidelines
Use this command to allocate percentages of bandwidth for specific DWFQ classes. You must also enable class-based DWFQ on the interface with either the fair-queue qos-group or fair-queue tos command.
Enter this command once for every class to allocate bandwidth to the class.
For QoS-group-based DWFQ, packets that are not assigned to any QoS groups are assigned to QoS group 0. When assigning weights to QoS group class, remember the following guidelines:
•
•
•
For ToS-based DWFQ, remember the following guidelines:
•
•
•
Examples
The following example allocates bandwidth to different QoS groups. The remaining bandwidth (5 percent) is allocated to QoS group 0.
interface Fddi9/0/0fair-queue qos-groupfair-queue qos-group 1 weight 10fair-queue qos-group 2 weight 15fair-queue qos-group 3 weight 20fair-queue qos-group 4 weight 20fair-queue qos-group 5 weight 30Related Commands
frame-relay interface-queue priority
To enable the Frame Relay PVC Interface Priority Queueing (FR PIPQ) feature, use the frame-relay interface-queue priority command in interface configuration mode. To disable FR PIPQ, use the no form of this command.
frame-relay interface-queue priority [high-limit medium-limit normal-limit low-limit]
no frame-relay interface-queue priority
To assign priority to a permanent virtual circuit (PVC) within a Frame Relay map class, use the frame-relay interface-queue priority command in map-class configuration mode. To remove priority from a PVC within a Frame Relay map class, use the no form of this command.
frame-relay interface-queue priority {high | medium | normal | low}
no frame-relay interface-queue priority
Syntax Description
Defaults
The default sizes of the high, medium, normal, and low priority queues are 20, 40, 60, and 80 packets, respectively.
When FR PIPQ is enabled on the interface, the default PVC priority is normal priority.
Command Modes
Interface configuration
Map-class configuration
Command History
Usage Guidelines
FR PIPQ must be enabled on the interface in order for the map-class configuration of PVC priority to be effective.
Before you configure FR PIPQ using the frame-relay interface-queue priority command, the following conditions must be met:
•
•
You will not be able to configure FR PIPQ if any queueing other than first-in first out (FIFO) queueing is already configured at the interface level. You will be able to configure FR PIPQ when weighted fair queueing (WFQ) is in use, as long as WFQ is the default interface queueing method. Disabling FR PIPQ will restore the interface to dual FIFO queueing if FRF.12 is enabled, FIFO queueing if Frame Relay Traffic Shaping (FRTS) is enabled, or the default queueing method for the interface.
Examples
In the following example, FR PIPQ is enabled on serial interface 0, and the limits of the high, medium, normal, and low priority queues are set to 10, 20, 30, and 40 packets, respectively. PVC 100 is assigned high priority, so all traffic destined for PVC 100 will be sent to the high priority interface queue.
interface serial0encapsulation frame-relayframe-relay interface-queue priority 10 20 30 40frame-relay interface-dlci 100class high_priority_class!map-class frame-relay high_priority_classframe-relay interface-queue priority highRelated Commands
frame-relay ip rtp compression-connections
To specify the maximum number of Real-Time Transport Protocol (RTP) header compression connections that can exist on a Frame Relay interface, use the frame-relay ip rtp compression-connections command in interface configuration mode. To restore the default, use the no form of this command.
frame-relay ip rtp compression-connections number
no frame-relay ip rtp compression-connections
Syntax Description
Defaults
256 header compression connections
Command Modes
Interface configuration
Command History
Usage Guidelines
Before you can configure the maximum number of connections, RTP header compression must be configured on the interface using the frame-relay ip rtp header-compression command.
The number of RTP header compression connections must be set to the same value at each end of the connection.
Examples
The following example shows the configuration of a maximum of 150 RTP header compression connections on serial interface 0:
interface serial 0encapsulation frame-relayframe-relay ip rtp header-compressionframe-relay ip rtp compression-connections 150Related Commands
frame-relay ip rtp header-compression
To enable Real-Time Transport Protocol (RTP) header compression for all Frame Relay maps on a physical interface, use the frame-relay ip rtp header-compression command in interface configuration mode. To disable the compression, use the no form of this command.
frame-relay ip rtp header-compression [active | passive]
no frame-relay ip rtp header-compression [active | passive]
Syntax Description
Defaults
RTP header compression for Frame Relay maps on a physical interface is disabled
If the command is configured, active is the default keyword.
Command Modes
Interface configuration
Command History
Usage Guidelines
When this command is used on the physical interface, all the interface maps inherit the command; that is, all maps will perform IP/UDP/RTP header compression.
Examples
The following example enables RTP header compression for all Frame Relay maps on a physical interface:
frame-relay ip rtp header-compressionRelated Commands
frame-relay ip rtp priority
To reserve a strict priority queue on a Frame Relay permanent virtual circuit (PVC) for a set of Real-Time Transport Protocol (RTP) packet flows belonging to a range of User Datagram Protocol (UDP) destination ports, use the frame-relay ip rtp priority command in map-class configuration mode. To disable the strict priority queue, use the no form of this command.
frame-relay ip rtp priority starting-rtp-port-number port-number-range bandwidth
no frame-relay ip rtp priority
Syntax Description
Defaults
No default behavior or values
Command Modes
Map-class configuration
Command History
Usage Guidelines
This command is most useful for voice applications, or other applications that are delay-sensitive. To use this command, you must first enter the map-class frame-relay command. After the Frame Relay map class has been configured, it must then be applied to a PVC.
This command extends the functionality offered by the ip rtp priority command by supporting Frame Relay PVCs. The command allows you to specify a range of UDP ports whose voice traffic is guaranteed strict priority service over any other queues or classes using the same output interface. Strict priority means that if packets exist in the priority queue, they are dequeued and sent first—that is, before packets in other queues are dequeued.
Frame Relay Traffic Shaping (FRTS) and Frame Relay Fragmentation (FRF.12) must be configured before the frame-relay ip rtp priority command is used.
Compressed RTP (CRTP) can be used to reduce the bandwidth required per voice call. When using CRTP with Frame Relay, you must use the encapsulation frame-relay cisco command instead of the encapsulation frame-relay ietf command.
Remember the following guidelines when configuring the bandwidth parameter:
•
•
•
•
For more information on IP RTP Priority bandwidth allocation, refer to the section "IP RTP Priority" in the chapter "Congestion Management Overview" in the Cisco IOS Quality of Service Solutions Configuration Guide.
Examples
The following example first configures the Frame Relay map class called voip and then applies the map class to PVC 100 to provide strict priority service to matching RTP packets:
map-class frame-relay voipframe-relay cir 256000frame-relay bc 2560frame-relay be 600frame-relay mincir 256000no frame-relay adaptive-shapingframe-relay fair-queueframe-relay fragment 250frame-relay ip rtp priority 16384 16380 210interface Serial5/0ip address 10.10.10.10 255.0.0.0no ip directed-broadcastencapsulation frame-relayno ip mroute-cacheload-interval 30clockrate 1007616frame-relay traffic-shapingframe-relay interface-dlci 100class voipframe-relay ip rtp header-compressionframe-relay intf-type dceIn this example, RTP packets on PVC 100 with UDP ports in the range from 16384 to 32764 (32764 = 16384 + 16380) will be matched and given strict priority service.
Related Commands
frame-relay map ip compress
To enable both Real-Time Transport Protocol (RTP) and TCP header compression on a link, use the frame-relay map ip compress command in interface configuration mode.
frame-relay map ip ip-address dlci [broadcast] compress [active | passive] [connections number]
Syntax Description
Defaults
RTP and TCP header compression are disabled.
The default maximum number of header compression connections is 256.
Command Modes
Interface configuration
Command History
11.3
This command was introduced.
12.1(2)T
This command was modified to enable the configuration of the maximum number of header compression connections.
Examples
The following example enables both RTP and TCP header compression on serial interface 1 and sets the maximum number of RTP and TCP header connections at 16:
interface serial 1encapsulation frame-relayip address 10.108.175.110 255.255.255.0frame-relay map ip 10.108.175.220 180 compress connections 16Related Commands
frame-relay map ip nocompress
To disable both Real-Time Transport Protocol (RTP) and TCP header compression on a link, use the frame-relay map ip nocompress command in interface configuration mode.
frame-relay map ip ip-address dlci [broadcast] nocompress
Syntax Description
ip-address
IP address of the destination or next hop.
dlci
Data-link connection identifier (DLCI) number.
broadcast
(Optional) Forwards broadcasts to the specified IP address.
Defaults
No default behaviors or values
Command Modes
Interface configuration
Command History
Examples
The following example disables RTP and TCP header compression on DLCI 180:
interface serial 1encapsulation frame-relayframe-relay map ip 10.108.175.220 180 nocompressRelated Commands
frame-relay map ip rtp header-compression
To enable Real-Time Transport Protocol (RTP) header compression per data-link connection identifier (DLCI), use the frame-relay map ip rtp header-compression command in interface configuration mode.
frame-relay map ip ip-address dlci [broadcast] rtp header-compression [active | passive]
[connections number]Syntax Description
Defaults
RTP header compression per DLCI is disabled.
If the command is configured, active is the default keyword.
The default maximum number of header compression connections is 256.
Command Modes
Interface configuration
Command History
11.3
This command was introduced.
12.1(2)T
This command was modified to enable the configuration of the maximum number of header compression connections.
Usage Guidelines
When this command is configured, the specified maps inherit RTP header compression. You can have multiple Frame Relay maps, with and without RTP header compression. If you do not specify the number of RTP header compression connections, the map will inherit the current value from the interface.
Examples
The following example enables RTP header compression on serial interface 1 and sets the maximum number of RTP header compression connections at 64:
interface serial 1encapsulation frame-relayip address 10.108.175.110 255.255.255.0frame-relay map ip 10.108.175.220 180 rtp header-compression connections 64
