Table Of Contents
Configuring Weighted Fair Queueing
Flow-Based Weighted Fair Queueing Configuration Task List
Distributed Weighted Fair Queueing Configuration Task List
Configuring QoS-Group-Based DWFQ
Configuring Type of Service-Based DWFQ
Class-Based Weighted Fair Queueing Configuration Task List
Configuring Class Policy in the Policy Map
Configuring Class Policy Using Tail Drop
Configuring Class Policy Using WRED Packet Drop
Configuring the Class-Default Class Policy
Attaching the Service Policy and Enabling CBWFQ
Modifying the Bandwidth for an Existing Policy Map Class
Modifying the Queue Limit for an Existing Policy Map Class
Configuring the Bandwidth Limiting Factor
Verifying Configuration of Policy Maps and Their Classes
Distributed Class-Based Weighted Fair Queueing Configuration Task List
Modifying the Bandwidth for an Existing Traffic Class
Modifying the Queue Limit for an Existing Traffic Class
Monitoring and Maintaining DCBWFQ
IP RTP Priority Configuration Task List
Configuring the Bandwidth Limiting Factor
Monitoring and Maintaining IP RTP Priority
Frame Relay IP RTP Priority Configuration Task List
Configuring Frame Relay IP RTP Priority
Verifying Frame Relay IP RTP Priority
Monitoring and Maintaining Frame Relay IP RTP Priority
Frame Relay PVC Interface Priority Configuration Task List
Configuring PVC Priority in a Map Class
Enabling Frame Relay PIPQ and Setting Queue Limits
Assigning a Map Class to a PVC
Monitoring and Maintaining Frame Relay PIPQ
Low Latency Queueing Configuration Task List
Configuring the Bandwidth Limiting Factor
Monitoring and Maintaining LLQ
Distributed LLQ Configuration Task List
Configuring a Priority Queue for an Amount of Available Bandwidth
Configuring a Priority Queue for a Percentage of Available Bandwidth
Configuring a Transmission Ring Limit
Verifying a Transmission Ring Limit
Monitoring and Maintaining Distributed LLQ
Low Latency Queueing for Frame Relay Configuration Task List
Configuring Class Policy in the Policy Map
Configuring Class Policy for a LLQ Priority Queue
Configuring Class Policy Using a Specified Bandwidth and WRED Packet Drop
Configuring the Class-Default Class Policy
Attaching the Service Policy and Enabling LLQ for Frame Relay
Verifying Configuration of Policy Maps and Their Classes
Monitoring and Maintaining LLQ for Frame Relay
Configuring Burst Size in LLQ Configuration Task List
Configuring the LLQ Burst Size
Per-VC Hold Queue Support for ATM Adapters Configuration Task List
Configuring the per-VC Hold Queue on an ATM Adapter
Verifying the Configuration of the per-VC Hold Queue on an ATM Adapter
Flow-Based WFQ Configuration Examples
Class Map Configuration: Example
Policy Attachment to Interfaces: Example
CBWFQ Using WRED Packet Drop: Example
Display Service Policy Map Content Examples
All Classes for a Specified Service Policy Map
All Classes for All Service Policy Maps
Specified Class for a Service Policy Map
All Classes for All Service Policy Maps on a Specified Interface
Distributed CBWFQ Configuration Examples
Traffic Class Configuration: Example
Traffic Policy Creation: Example
Traffic Policy Attachment to an Interface: Example
IP RTP Priority Configuration Examples
Virtual Template Configuration: Example
Multilink Bundle Configuration: Example
Frame Relay IP RTP Priority Configuration Examples
Strict Priority Service to Matching RTP Packets: Example
Frame Relay PVC Interface PQ Configuration Examples
ATM PVC Configuration: Example
Virtual Template Configuration: Example
Multilink Bundle Configuration: Example
Distributed LLQ Configuration Examples
Enabling PQ for an Amount of Available Bandwidth on an ATM Subinterface: Example
Enabling PQ for a Percentage of Available Bandwidth on an ATM Subinterface: Example
Limiting the Transmission Ring Limit on an ATM Interface: Example
Limiting the Transmission Ring Limit on an ATM PVC Subinterface: Example
LLQ for Frame Relay Configuration Examples
Burst Size in LLQ Configuration Examples
Per-VC Hold Queue Support for ATM Adapters Examples
Configuring Weighted Fair Queueing
Feature History
Release ModificationCisco IOS
For information about feature support in Cisco IOS software, use Cisco Feature Navigator.
This chapter describes the tasks for configuring flow-based weighted fair queueing (WFQ), distributed WFQ (DWFQ), and class-based WFQ (CBWFQ), and distributed class-based WFQ (DCBWFQ) and the related features described in the following section, which provide strict priority queueing (PQ) within WFQ or CBWFQ:
•
IP RTP Priority Queueing
•
Frame Relay IP RTP Priority Queueing
•
Frame Relay PVC Interface Priority Queueing
•
Low Latency Queueing
•
Distributed Low Latency Queueing
•
Low Latency Queueing (LLQ) for Frame Relay
•
Burst Size in Low Latency Queueing
•
Per-VC Hold Queue Support for ATM Adapters
For complete conceptual information, see the "Congestion Management Overview" module.
For a complete description of the QoS commands in this chapter, see the Cisco IOS Quality of Service Solutions Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Flow-Based Weighted Fair Queueing Configuration Task List
WFQ provides traffic priority management that automatically sorts among individual traffic streams without requiring that you first define access lists. WFQ can also manage duplex data streams such as those between pairs of applications, and simplex data streams such as voice or video. There are two categories of WFQ sessions: high bandwidth and low bandwidth. Low-bandwidth traffic has effective priority over high-bandwidth traffic, and high-bandwidth traffic shares the transmission service proportionally according to assigned weights.
When WFQ is enabled for an interface, new messages for high-bandwidth traffic streams are discarded after the configured or default congestive messages 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.
With standard WFQ, packets are classified by flow. Packets with the same source IP address, destination IP address, source TCP or User Datagram Protocol (UDP) port, or destination TCP or UDP port belong to the same flow. WFQ allocates an equal share of the bandwidth to each flow. Flow-based WFQ is also called fair queueing because all flows are equally weighted.
The Cisco IOS software provides two forms of flow-based WFQ:
•
Standard WFQ, which is enabled by default on all serial interfaces that run at 2 Mbps or below, and can run on all Cisco serial interfaces.
•
Distributed WFQ, which runs only on Cisco 7000 series routers with a Route Switch Processor (RSP)-based RSP7000 interface processor or Cisco 7500 series routers with a Versatile Interface Processor (VIP)-based VIP2-40 or greater interface processor. (A VIP2-50 interface processor is strongly recommended when the aggregate line rate of the port adapters on the VIP is greater than DS3. A VIP2-50 interface processor is required for OC-3 rates.) For configuration information on DWFQ, see the section "Distributed Weighted Fair Queueing Configuration Task List" later in this chapter.
To configure flow-based WFQ, perform the tasks described in the following sections. The task in the first section is required; the task in the remaining section is optional.
•
Configuring WFQ (Required)
•
Monitoring Fair Queueing (Optional)
Flow-based WFQ is supported on unavailable bit rate (UBR), variable bit rate (VBR), and available bit rate (ABR) ATM connections.
See the end of this chapter for the section "Flow-Based WFQ Configuration Examples."
Configuring WFQ
To configure flow-based WFQ on an interface, use the following command in interface configuration mode:
Command PurposeRouter(config-if)# fair-queue [congestive-discard-threshold [dynamic-queues [reservable-queues]]]
Configures an interface to use WFQ.
Flow-based WFQ uses a traffic data stream discrimination registry service to determine to which traffic stream a message belongs. Refer to the table accompanying the description of the fair-queue (WFQ) command in the Cisco IOS Quality of Service Solutions Command Reference for the attributes of a message that are used to classify traffic into data streams.
Defaults are provided for the congestion threshold after which messages for high-bandwidth conversations are dropped, and for the number of dynamic and reservable queues; however, you can fine-tune your network operation by changing these defaults. Refer to the tables accompanying the description of the fair-queue (WFQ) command in the Cisco IOS Quality of Service Solutions Command Reference for the default number of dynamic queues that WFQ and CBWFQ use when they are enabled on an interface or ATM VC. These values do not apply for DWFQ.
Note
WFQ is the default queueing mode on interfaces that run at E1 speeds (2.048 Mbps) or below. It is enabled by default for physical interfaces that do not use Link Access Procedure, Balanced (LAPB), X.25, or Synchronous Data Link Control (SDLC) encapsulations. WFQ is not an option for these protocols. WFQ is also enabled by default on interfaces configured for Multilink PPP (MLP). However, if custom queueing (CQ) or priority queueing (PQ0 is enabled for a qualifying link, it overrides fair queueing, effectively disabling it. Additionally, WFQ is automatically disabled if you enable autonomous or silicon switching.
Monitoring Fair Queueing
To monitor flow-based fair queueing services in your network, use the following commands in EXEC mode, as needed:
Distributed Weighted Fair Queueing Configuration Task List
To configure DWFQ, perform one of the mutually exclusive tasks described in the following sections:
•
Configuring QoS-Group-Based DWFQ
•
Configuring Type of Service-Based DWFQ
•
Monitoring DWFQ (Optional)
If you enable flow-based DWFQ and then enable class-based DWFQ (either QoS-group based or ToS-based), class-based DWFQ will replace flow-based DWFQ.
If you enable class-based DWFQ and then want to switch to flow-based DWFQ, you must disable class-based DWFQ using the no fair-queue class-based command before enabling flow-based DWFQ.
If you enable one type of class-based DWFQ and then enable the other type, the second type will replace the first.
DWFQ runs only on Cisco 7000 series routers with an RSP-based RSP7000 interface processor or Cisco 7500 series routers with a VIP-based VIP2-40 or greater interface processor. (A VIP2-50 interface processor is strongly recommended when the aggregate line rate of the port adapters on the VIP is greater than DS3. A VIP2-50 interface processor is required for OC-3 rates.)
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 MLP.
See the end of this chapter for the section "DWFQ Configuration Examples."
Configuring Flow-Based DWFQ
To configure flow-based DWFQ, use the following commands in interface configuration mode:
For flow-based DWFQ, packets are classified by flow. Packets with the same source IP address, destination IP address, source TCP or UDP port, destination TCP or UDP port, and protocol belong to the same flow.
In general, you should not change the aggregate or individual limit value from the default. Use the fair-queue aggregate-limit and fair-queue individual-limit commands only if you have determined that you would benefit from using different values, based on your particular situation.
Configuring QoS-Group-Based DWFQ
To configure QoS-group-based DWFQ, use the following commands in interface configuration mode:
In general, you should not change the aggregate, individual, or class limit value from the default. Use the fair-queue aggregate-limit, fair-queue individual-limit, and fair-queue limit commands only if you have determined that you would benefit from using different values, based on your particular situation.
Configuring Type of Service-Based DWFQ
To configure type of service (ToS)-based DWFQ, use the following commands in interface configuration mode:
In general, you should not change the aggregate, individual, or class limit value from the default. Use the fair-queue aggregate-limit, fair-queue individual-limit, and fair-queue limit commands only if you have determined that you would benefit from using different values, based on your particular situation.
Monitoring DWFQ
To monitor DWFQ, use the following commands in EXEC mode, as needed:
Command PurposeRouter# show interfaces [interface]
Displays the statistical information specific to an interface.
Router# show queueing fair-queue
Displays status of the fair queueing configuration.
Class-Based Weighted Fair Queueing Configuration Task List
To configure CBWFQ, perform the tasks described in the following sections. The tasks in the first three sections are required; the tasks in the remaining sections are optional.
•
Defining Class Maps (Required)
•
Configuring Class Policy in the Policy Map (Required)
•
Attaching the Service Policy and Enabling CBWFQ (Required)
•
Modifying the Bandwidth for an Existing Policy Map Class (Optional)
•
Modifying the Queue Limit for an Existing Policy Map Class (Optional)
•
Configuring the Bandwidth Limiting Factor (Optional)
•
Deleting Classes (Optional)
•
Deleting Policy Maps (Optional)
•
Verifying Configuration of Policy Maps and Their Classes (Optional)
CBWFQ is supported on VBR and ABR ATM connections. It is not supported on UBR connections.
See the end of this chapter for the section "CBWFQ Configuration Examples."
For information on how to configure per-VC WFQ and CBWFQ, see the "Configuring IP to ATM Class of Service" module.
Defining Class Maps
To create a class map containing match criteria against which a packet is checked to determine if it belongs to a class—and to effectively create the class whose policy can be specified in one or more policy maps—use the first command in global configuration mode to specify the class map name, then use one of the following commands in class-map configuration mode, as needed:
Other match criteria can be used when defining class maps. For additional match criteria, see "Applying QoS Features Using the MQC" module.
Configuring Class Policy in the Policy Map
To configure a policy map and create class policies that make up the service policy, use the policy-map command to specify the policy map name, then use one or more of the following commands to configure policy for a standard class or the default class:
•
class
•
bandwidth (policy-map class)
•
fair-queue (for class-default class only)
•
queue-limit or random-detect
For each class that you define, you can use one or more of the listed commands to configure class policy. For example, you might specify bandwidth for one class and both bandwidth and queue limit for another class.
The default class of the policy map (commonly known as the class-default class) is the 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.
You can configure class policies for as many classes as are defined on the router, up to the maximum of 64. However, the total amount of bandwidth allocated for all classes included in a policy map must not exceed 75 percent of the available bandwidth on the interface. The other 25 percent is used for control and routing traffic. (To override the 75 percent limitation, use the max-reserved bandwidth command.) If not all of the bandwidth is allocated, the remaining bandwidth is proportionally allocated among the classes, based on their configured bandwidth.
To configure class policies in a policy map, perform the optional tasks described in the following sections. If you do not perform the steps in these sections, the default actions are used.
•
Configuring Class Policy Using Tail Drop (Optional)
•
Configuring Class Policy Using WRED Packet Drop (Optional)
•
Configuring the Class-Default Class Policy (Optional)
Configuring Class Policy Using Tail Drop
To configure a policy map and create class policies that make up the service policy, use the first command in global configuration mode to specify the policy map name, then use the following commands in policy-map class configuration mode, as needed, to configure policy for a standard class. To configure policy for the default class, see the section "Configuring the Class-Default Class Policy" in this chapter.
To configure policy for more than one class in the same policy map, repeat Step 2 through Step 4. Note that because this set of commands uses the queue-limit command, the policy map uses tail drop, not Weighted Random Early Detection (WRED) packet drop.
Configuring Class Policy Using WRED Packet Drop
To configure a policy map and create class policies comprising the service policy, use the first command in global configuration mode, as needed, to specify the policy map name, then use the following commands in policy-map class configuration mode, as needed, to configure policy for a standard class. To configure policy for the default class, see the section "Configuring the Class-Default Class Policy" in this chapter.
To configure policy for more than one class in the same policy map, repeat Step 2 through Step 5. Note that this set of commands uses WRED packet drop, not tail drop.
Note
If you configure a class in a policy map to use WRED for packet drop instead of tail drop, you must ensure that WRED is not configured on the interface to which you intend to attach that service policy.
Configuring the Class-Default Class Policy
The class-default class is used to classify traffic that does not fall into one of the defined classes. Once a packet is classified, all of the standard mechanisms that can be used to differentiate service among the classes apply. The class-default class was predefined when you created the policy map, but you must configure it. If no default class is configured, then by default the traffic that does not match any of the configured classes is flow classified and given best-effort treatment.
By default, the class-default class is defined as flow-based WFQ. However, configuring the default class with the bandwidth policy-map class configuration command disqualifies the default class as flow-based WFQ.
To configure a policy map and configure the class-default class to use tail drop, use the first command in global configuration mode to specify the policy map name, then to configure policy for the default class use the following commands in policy-map class configuration mode:
Command PurposeStep 1
Router(config)# policy-map policy-map
Specifies the name of the policy map to be created or modified.
Step 2
Router(config-pmap)# class class-default default-class-name
Specifies the default class so that you can configure or modify its policy.
Step 3
Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}
or
Router(config-pmap-c)# fair-queue [number-of-dynamic-queues]
Specifies the amount of bandwidth, in kbps, or percentage of available bandwidth to be assigned to the class. The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead.
Specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class. The number of dynamic queues is derived from the bandwidth of the interface. Refer to the tables accompanying the description of the fair-queue (WFQ) command in the Cisco IOS Quality of Service Solutions Command Reference for the default number of dynamic queues that WFQ and CBWFQ use when they are enabled on an interface or ATM VC.
Step 4
Router(config-pmap-c)# queue-limit number-of-packets
Specifies the maximum number of packets that the queue for the default class can accumulate.
To configure a policy map and configure the class-default class to use WRED packet drop, use the first command in global configuration mode to specify the policy map name, then to configure policy for the default class use the following commands in policy-map class configuration mode:
Command PurposeStep 1
Router(config)# policy-map policy-map
Specifies the name of the policy map to be created or modified.
Step 2
Router(config-pmap)# class class-default default-class-name
Specifies the default class so that you can configure or modify its policy.
Step 3
Router(config-pmap-c)# bandwidth {bandwidth-kbps | percent percent}
or
Router(config-pmap-c)# fair-queue [number-of-dynamic-queues]
Specifies the amount of bandwidth, in kbps, or percentage of available bandwidth to be assigned to the class. The amount of bandwidth configured should be large enough to also accommodate Layer 2 overhead.
Specifies the number of dynamic queues to be reserved for use by flow-based WFQ running on the default class The number of dynamic queues is derived from the bandwidth of the interface. Refer to the tables accompanying the description of the fair-queue (WFQ) command in the Cisco IOS Quality of Service Solutions Command Reference for the default number of dynamic queues that WFQ and CBWFQ use when they are enabled on an interface or ATM VC.
Step 4
Router(config-pmap-c)# random-detect
Enables WRED. The class policy will drop packets using WRED instead of tail drop.
Step 5
Router(config-pmap-c)# random-detect exponential-weighting-constant exponent
or
Router(config-pmap-c)# random-detect precedence precedence min-threshold max-threshold mark-prob-denominator
Configures the exponential weight factor used in calculating the average queue length.
Configures WRED parameters for packets with a specific IP precedence. Repeat this command for each precedence.
Attaching the Service Policy and Enabling CBWFQ
To attach a service policy to the output interface and enable CBWFQ on the interface, use the following command in interface configuration mode. When CBWFQ is enabled, all classes configured as part of the service policy map are installed in the fair queueing system.
Command PurposeRouter(config-if)# service-policy output policy-map
Enables CBWFQ and attaches the specified service policy map to the output interface.
Configuring CBWFQ on a physical interface is only possible if the interface is in the default queueing mode. Serial interfaces at E1 (2.048 Mbps) and below use WFQ by default—other interfaces use FIFO by default. Enabling CBWFQ on a physical interface overrides the default interface queueing method. Enabling CBWFQ on an ATM permanent virtual circuit (PVC) does not override the default queueing method.
Modifying the Bandwidth for an Existing Policy Map Class
To change the amount of bandwidth allocated for an existing class, use the following commands beginning in global configuration mode:
Modifying the Queue Limit for an Existing Policy Map Class
To change the maximum number of packets that can accrue in a queue reserved for an existing class, use the following commands beginning in global configuration mode:
Configuring the Bandwidth Limiting Factor
To change the maximum reserved bandwidth allocated for Resource Reservation Protocol (RSVP), CBWFQ, LLQ, IP RTP Priority, Frame Relay IP RTP Priority, and Frame Relay PVC Interface Priority Queueing (PIPQ), use the following command in interface configuration mode:
Deleting Classes
To delete one or more class maps from a service policy map, use the following commands beginning in global configuration mode:
Deleting Policy Maps
To delete a policy map, use the following command in global configuration mode:
Command PurposeRouter(config)# no policy-map policy-map
Specifies the name of the policy map to be deleted.
Verifying Configuration of Policy Maps and Their Classes
To display the contents of a specific policy map, a specific class from a specific policy map, or all policy maps configured on an interface, use the following commands in EXEC mode, as needed:
The counters displayed after issuing the show policy-map interface command are updated only if congestion is present on the interface.
Distributed Class-Based Weighted Fair Queueing Configuration Task List
To configure DCBWFQ, perform the tasks described in the following sections. Although all the tasks are listed as optional, you must complete the task in either the first or second section.
•
Modifying the Bandwidth for an Existing Traffic Class (Optional)
•
Modifying the Queue Limit for an Existing Traffic Class (Optional)
•
Monitoring and Maintaining DCBWFQ (Optional)
DCBWFQ is configured using user-defined traffic classes and service policies. Traffic classes and service policies are configured using the Modular Quality of Service Command-Line Interface (CLI) feature. For information on how to configure QoS with the Modular QoS CLI, see the "Applying QoS Features Using the MQC" module.
See the end of this chapter for the section "Verifying Configuration of Policy Maps and Their Classes."
Modifying the Bandwidth for an Existing Traffic Class
To change the amount of bandwidth allocated for an existing traffic class in congested environments, use the following commands beginning in global configuration mode:
After configuring the traffic policy with the policy-map command, you must still attach the traffic policy to an interface before it is successfully enabled. For information on attaching a traffic policy to an interface, see the "Applying QoS Features Using the MQC" module.
Modifying the Queue Limit for an Existing Traffic Class
To change the maximum number of packets that can accrue in a queue reserved for an existing traffic class, use the following commands beginning in global configuration mode:
After configuring the service policy with the policy-map command, you must still attach the traffic policy to an interface before it is successfully enabled. For information on attaching a traffic policy to an interface, see the "Applying QoS Features Using the MQC" module.
Monitoring and Maintaining DCBWFQ
To display the configuration of a traffic policy and its associated traffic classes, use the following commands in EXEC mode, as needed:
IP RTP Priority Configuration Task List
To configure IP RTP Priority, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.
•
Configuring IP RTP Priority (Required)
•
Configuring the Bandwidth Limiting Factor (Optional)
•
Verifying IP RTP Priority (Optional)
•
Monitoring and Maintaining IP RTP Priority (Optional)
See the end of this chapter for the section "IP RTP Priority Configuration Examples."
Frame Relay Traffic Shaping (FRTS) and Frame Relay Fragmentation (FRF.12 or higher) must be configured before the Frame Relay IP RTP Priority feature is used. For information about configuring FRTS and FRF.12, see the "MQC-Based Frame Relay Traffic Shaping" module and the "FRF.20 Support" modules, respectively.
Configuring IP RTP Priority
To reserve a strict priority queue for a set of RTP packet flows belonging to a range of UDP destination ports, use the following command in interface configuration mode:
CautionBecause the ip rtp priority command gives absolute priority over other traffic, it should be used with care. In the event of congestion, if the traffic exceeds the configured bandwidth, then all the excess traffic is dropped.
The ip rtp reserve and ip rtp priority commands cannot be configured on the same interface.
The frame-relay ip rtp priority command provides strict PQ for Frame Relay PVCs. For more information about this command, see the Cisco IOS Quality of Service Solutions Command Reference.
Configuring the Bandwidth Limiting Factor
To change the maximum reserved bandwidth allocated for CBWFQ, LLQ, and the IP RTP Priority feature, use the following command in interface configuration mode:
Command PurposeRouter(config-if)# max-reserved-bandwidth percent
Changes the maximum configurable bandwidth for CBWFQ, LLQ, and IP RTP Priority. The default is 75 percent.
Verifying IP RTP Priority
To display the contents of the priority queue (such as queue depth and the first packet queued), use the following command in EXEC mode:
Command PurposeRouter# show queue interface-type interface-number
Displays queueing configuration and statistics for a particular interface.
Monitoring and Maintaining IP RTP Priority
To tune your RTP bandwidth or decrease RTP traffic if the priority queue is experiencing drops, use the following commands in EXEC mode, as needed:
Frame Relay IP RTP Priority Configuration Task List
To configure Frame Relay IP RTP Priority, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.
•
Configuring Frame Relay IP RTP Priority (Required)
•
Verifying Frame Relay IP RTP Priority (Optional)
•
Monitoring and Maintaining Frame Relay IP RTP Priority (Optional)
See the end of this chapter for the section "Frame Relay IP RTP Priority Configuration Examples."
Configuring Frame Relay IP RTP Priority
To reserve a strict priority queue on a Frame Relay PVC for a set of RTP packet flows belonging to a range of UDP destination ports, use the following command in map-class configuration mode:
CautionBecause the frame-relay ip rtp priority command gives absolute priority over other traffic, it should be used with care. In the event of congestion, if the traffic exceeds the configured bandwidth, then all the excess traffic is dropped.
Verifying Frame Relay IP RTP Priority
To verify the Frame Relay IP RTP Priority feature, use the following commands in EXEC mode, as needed:
Monitoring and Maintaining Frame Relay IP RTP Priority
To tune your RTP bandwidth or decrease RTP traffic if the priority queue is experiencing drops, use the following command in EXEC mode:
Command PurposeRouter# debug priority
Displays priority queueing output if packets are dropped from the priority queue.
Frame Relay PVC Interface Priority Configuration Task List
To configure the Frame Relay PVC Interface Priority feature, perform the tasks described in the following sections. The tasks in the first three sections are required; the tasks in the remaining sections are optional.
•
Configuring PVC Priority in a Map Class (Required)
•
Enabling Frame Relay PIPQ and Setting Queue Limits (Required)
•
Assigning a Map Class to a PVC (Required)
•
Verifying Frame Relay PIPQ (Optional)
•
Monitoring and Maintaining Frame Relay PIPQ (Optional)
See the end of this chapter for the section "Frame Relay PVC Interface PQ Configuration Examples."
Configuring PVC Priority in a Map Class
To configure PVC priority within a map class, use the following commands beginning in global configuration mode:
Enabling Frame Relay PIPQ and Setting Queue Limits
To enable Frame Relay (FR) PIPQ and set the priority queue sizes, use the following commands beginning in global configuration mode:
Assigning a Map Class to a PVC
To assign a map class to a specific PVC, use the following commands beginning in interface configuration mode:
Verifying Frame Relay PIPQ
To verify the configuration of Frame Relay (FR) PIPQ, use the following commands in privileged EXEC mode, as needed:
Monitoring and Maintaining Frame Relay PIPQ
To monitor and maintain Frame Relay (FR) PIPQ, use the following commands in privileged EXEC mode, as needed:
Low Latency Queueing Configuration Task List
To configure LLQ, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.
•
Configuring LLQ (Required)
•
Configuring the Bandwidth Limiting Factor (Optional)
•
Verifying LLQ (Optional)
•
Monitoring and Maintaining LLQ (Optional)
See the end of this chapter for the section "LLQ Configuration Examples."
Configuring LLQ
To give priority to a class within a policy map, use the following command in policy-map class configuration mode:
Command PurposeRouter(config-pmap-c)# priority bandwidth
Reserves a strict priority queue for this class of traffic.
Configuring the Bandwidth Limiting Factor
To change the maximum reserved bandwidth allocated for CBWFQ, LLQ, and IP RTP Priority, use the following command in interface configuration mode:
Command PurposeRouter(config-if)# max-reserved-bandwidth percent
Changes the maximum configurable bandwidth for CBWFQ, LLQ, and IP RTP Priority. The default is 75 percent.
Verifying LLQ
To display the contents of the priority queue, such as queue depth and the first packet queued, use the following command in EXEC mode:
Command PurposeRouter# show queue interface-type interface-number
Displays queueing configuration and statistics for a particular interface.
The priority queue is the queue whose conversation ID is equal to the number of dynamic queues plus 8. The packets in the priority queue have a weight of 0.
Monitoring and Maintaining LLQ
To tune your RTP bandwidth or decrease RTP traffic if the priority queue is experiencing drops, use the following commands in EXEC mode, as needed:
Distributed LLQ Configuration Task List
To configure Distributed LLQ, perform the tasks described in the following sections. The tasks in the first two sections are required; the tasks in the remaining sections are optional.
•
Configuring a Priority Queue for an Amount of Available Bandwidth (Required)
•
Configuring a Priority Queue for a Percentage of Available Bandwidth (Required)
•
Configuring a Transmission Ring Limit (Optional)
•
Verifying Distributed LLQ (Optional)
•
Verifying a Transmission Ring Limit (Optional)
•
Monitoring and Maintaining Distributed LLQ (Optional)
See the end of this chapter for the section "Distributed LLQ Configuration Examples."
Configuring a Priority Queue for an Amount of Available Bandwidth
To give priority to a traffic class based on the amount of available bandwidth within a traffic policy, use the following commands beginning in global configuration mode:
The traffic policy configured in this section is not yet attached to an interface. For information on attaching a traffic policy to an interface, see the "Applying QoS Features Using the MQC" module.
Configuring a Priority Queue for a Percentage of Available Bandwidth
To give priority to a class based on a percentage of available bandwidth, use the following commands beginning in global configuration mode:
The traffic policy configured in this section is not yet attached to an interface. For information on attaching a traffic policy to an interface, see the "Applying QoS Features Using the MQC" module.
Configuring a Transmission Ring Limit
To limit the number of allowable particles on a transmission ring on an ATM PVC, use the following commands beginning in global interface configuration mode:
To limit the number of allowable particles on a transmission ring on an ATM subinterface, use the following commands beginning in global configuration mode:
Verifying Distributed LLQ
To view the contents of the priority queue, such as queue depth and the first packet queued, use the following commands in EXEC mode, as needed:
The priority queue is the queue in which the conversation ID is equal to the number of dynamic queues plus 8. The packets in the priority queue have a weight of 0.
Verifying a Transmission Ring Limit
To display the contents of the interface or the PVC, use the following command in EXEC mode:
Monitoring and Maintaining Distributed LLQ
To tune your Real-Time Transport Protocol (RTP) bandwidth or to decrease RTP traffic if the priority queue is experiencing drops, use the following commands in EXEC mode, as needed:
Low Latency Queueing for Frame Relay Configuration Task List
To configure LLQ for Frame Relay, perform the tasks described in the following sections. The tasks in the first three sections are required; the tasks in the remaining section are optional.
•
Defining Class Maps (Required)
•
Configuring Class Policy in the Policy Map (Required)
•
Attaching the Service Policy and Enabling LLQ for Frame Relay (Required)
•
Verifying Configuration of Policy Maps and Their Classes (Optional)
•
Monitoring and Maintaining LLQ for Frame Relay (Optional)
See the end of this chapter for the section "LLQ for Frame Relay Configuration Examples."
Defining Class Maps
To create a class map containing match criteria against which a packet is checked to determine if it belongs to a class, use the following commands beginning in global configuration mode:
Configuring Class Policy in the Policy Map
To configure a policy map and create class policies that make up the service policy, begin with the policy-map command to specify the policy map name. Then use one or more of the following commands to configure the policy for a standard class or the default class:
•
priority
•
bandwidth
•
queue-limit or random-detect
•
fair-queue (for class-default class only)
For each class that you define, you can use one or more of the commands listed to configure the class policy. For example, you might specify bandwidth for one class and both bandwidth and queue limit for another class.
The default class of the policy map (commonly known as the class-default class) is the class to which traffic is directed if that traffic does not satisfy the match criteria of the other classes defined in the policy map.
You can configure class policies for as many classes as are defined on the router, up to the maximum of 64. However, the total amount of bandwidth allocated for all classes in a policy map must not exceed the minimum committed information rate (CIR) configured for the VC minus any bandwidth reserved by the frame-relay voice bandwidth and frame-relay ip rtp priority commands. If the minimum CIR is not configured, the bandwidth defaults to one half of the CIR. If all of the bandwidth is not allocated, the remaining bandwidth is allocated proportionally among the classes on the basis of their configured bandwidth.
To configure class policies in a policy map, perform the tasks described in the following sections. The task in the first section is required; the tasks in the remaining sections are optional.
•
Configuring Class Policy for a LLQ Priority Queue (Required)
•
Configuring Class Policy Using a Specified Bandwidth and WRED Packet Drop (Optional)
•
Configuring the Class-Default Class Policy (Optional)
Configuring Class Policy for a LLQ Priority Queue
To configure a policy map and give priority to a class within the policy map, use the following commands beginning in global configuration mode:
Configuring Class Policy Using a Specified Bandwidth and WRED Packet Drop
To configure a policy map and create class policies that make up the service policy, use the following commands beginning in global configuration mode:
To configure policy for more than one class in the same policy map, repeat Step 2 through Step 4.
Configuring the Class-Default Class Policy
The class-default class is used to classify traffic that does not fall into one of the defined classes. Even though the class-default class is predefined when you create the policy map, you still have to configure it. If a default class is not configured, then traffic that does not match any of the configured classes is given best-effort treatment, which means that the network will deliver the traffic if it can, without any assurance of reliability, delay prevention, or throughput.
To configure a policy map and the class-default class, use the following commands beginning in global configuration mode:
Attaching the Service Policy and Enabling LLQ for Frame Relay
To attach a service policy to the output interface and enable LLQ for Frame Relay, use the following command in map-class configuration mode. When LLQ is enabled, all classes configured as part of the service policy map are installed in the fair queueing system.
Command PurposeRouter(config-map-class)# service-policy output policy-map
Attaches the specified service policy map to the output interface and enables LLQ for Frame Relay.
Verifying Configuration of Policy Maps and Their Classes
To display the contents of a specific policy map or all policy maps configured on an interface, use the following commands in EXEC mod, as needed:
Monitoring and Maintaining LLQ for Frame Relay
For a list of commands that can be used to monitor LLQ for Frame Relay, see the previous section "Verifying Configuration of Policy Maps and Their Classes."
Configuring Burst Size in LLQ Configuration Task List
To configure the burst size in LLQ, perform the tasks described in the following sections. The tasks in the first two sections are required; the task in the remaining section is optional.
•
Configuring the LLQ Bandwidth (Required)
•
Configuring the LLQ Burst Size (Required)
•
Verifying the LLQ Burst Size (Optional)
See the end of this chapter for "Burst Size in LLQ Configuration Examples."
Configuring the LLQ Bandwidth
To configure the LLQ bandwidth, use the following command in policy-map class configuration mode:
Command PurposeRouter(config)# priority bandwidth
Specifies the maximum amount of bandwidth, in kpbs, for the priority traffic.
Configuring the LLQ Burst Size
To configure the LLQ burst size, use the following command in policy-map class configuration mode:
Command PurposeRouter(config)# priority bandwidth burst
Specifies the burst size in bytes. The range is from 32 to 2 million.
Verifying the LLQ Burst Size
To verify the LLQ burst size, use the following commands in EXEC mode, as needed:
Per-VC Hold Queue Support for ATM Adapters Configuration Task List
To configure the per-VC hold queue support for ATM adapters, perform the tasks described in the following sections. The task in the first section is required; the task in the remaining section is optional.
•
Configuring the per-VC Hold Queue on an ATM Adapter (Required)
•
Verifying the Configuration of the per-VC Hold Queue on an ATM Adapter (Optional)
See the end of this chapter for "Per-VC Hold Queue Support for ATM Adapters Examples."
For related information about per-VC and ATM configurations, see the "IP to ATM Class of Service Overview" and "Configuring IP to ATM Class of Service" modules.
Configuring the per-VC Hold Queue on an ATM Adapter
To configure the per-VC hold queue on an ATM adapter, use the following command in global configuration mode:
Command PurposeRouter(config)# vc-hold-queue number-of-packets
Specifies the number of packets contained in the per-VC hold queue. This can be a number from 5 to 1024.
Verifying the Configuration of the per-VC Hold Queue on an ATM Adapter
To verify the configuration of the per-VC hold queue on an ATM adapter, use the following command in EXEC mode:
Command PurposeRouter# show queueing interface
Displays the queueing statistics of an interface or VC.
Flow-Based WFQ Configuration Examples
The following example requests a fair queue with a congestive discard threshold of 64 messages, 512 dynamic queues, and 18 RSVP queues:
Router(config)# interface Serial 3/0Router(config-if)# ip unnumbered Ethernet 0/0Router(config-if)# fair-queue 64 512 18For information on how to configure WFQ, see the section "Flow-Based Weighted Fair Queueing Configuration Task List" in this chapter.
DWFQ Configuration Examples
The following sections provide DWFQ configuration examples:
For information on how to configure DWFQ, see the section "Distributed Weighted Fair Queueing Configuration Task List" in this chapter.
Flow-Based DWFQ : Example
The following example enables DWFQ on the HSSI interface 0/0/0:
Router(config)# interface Hssi0/0/0Router(config-if)# description 45Mbps to R2Router(config-if)# ip address 200.200.14.250 255.255.255.252Router(config-if)# fair-queueThe following is sample output from the show interfaces fair-queue command for this configuration:
Router# show interfaces hssi 0/0/0 fair-queueHssi0/0/0 queue size 0packets output 35, drops 0WFQ: global queue limit 401, local queue limit 200QoS-Group-Based DWF: Example
The following example configures QoS-group-based DWFQ. Committed access rate (CAR) policies are used to assign packets with an IP Precedence value of 2 to QoS group 2, and packets with an IP Precedence value of 6 are assigned to QoS group 6.
Router(config)# interface Hssi0/0/0Router(config-if)# ip address 188.1.3.70 255.255.255.0Router(config-if)# rate-limit output access-group rate-limit 6 155000000 2000000 8000000 conform-action set-qos-transmit 6 exceed-action dropRouter(config-if)# rate-limit output access-group rate-limit 2 155000000 2000000 8000000 conform-action set-qos-transmit 2 exceed-action dropRouter(config-if)# fair-queue qos-groupRouter(config-if)# fair-queue qos-group 2 weight 10Router(config-if)# fair-queue qos-group 2 limit 27Router(config-if)# fair-queue qos-group 6 weight 30Router(config-if)# fair-queue qos-group 6 limit 27!Router(config)# access-list rate-limit 2 2Router(config)# access-list rate-limit 6 6The following sample output shows how to view WFQ statistics using the show interfaces fair-queue command:
Router# show interfaces fair-queueHssi0/0/0 queue size 0packets output 806232, drops 1WFQ: aggregate queue limit 54, individual queue limit 27max available buffers 54Class 0: weight 60 limit 27 qsize 0 packets output 654 drops 0Class 2: weight 10 limit 27 qsize 0 packets output 402789 drops 0Class 6: weight 30 limit 27 qsize 0 packets output 402789 drops 1ToS-Based DWFQ: Example
The following example configures type of service (ToS)-based DWFQ using the default parameters:
Router# configure terminalRouter(config)# interface Hssi0/0/0Router(config-if)# fair-queue tosRouter(config-if)# endThe following is output of the show running-config command for the HSSI interface 0/0/0. Notice that the router automatically adds the default weights and limits for the ToS classes to the configuration.
interface Hssi0/0/0ip address 188.1.3.70 255.255.255.0fair-queue tosfair-queue tos 1 weight 20fair-queue tos 1 limit 27fair-queue tos 2 weight 30fair-queue tos 2 limit 27fair-queue tos 3 weight 40fair-queue tos 3 limit 27The following sample output shows how to view DWFQ statistics using the show interfaces fair-queue command:
Router# show interfaces fair-queueHssi0/0/0 queue size 0packets output 1417079, drops 2WFQ: aggregate queue limit 54, individual queue limit 27max available buffers 54Class 0: weight 10 limit 27 qsize 0 packets output 1150 drops 0Class 1: weight 20 limit 27 qsize 0 packets output 0 drops 0Class 2: weight 30 limit 27 qsize 0 packets output 775482 drops 1Class 3: weight 40 limit 27 qsize 0 packets output 0 drops 0CBWFQ Configuration Examples
The following sections provide CBWFQ configuration examples:
•
Class Map Configuration: Example
•
Policy Attachment to Interfaces: Example
•
CBWFQ Using WRED Packet Drop: Example
•
Display Service Policy Map Content Examples
For information on how to configure CBWFQ, see the section "Class-Based Weighted Fair Queueing Configuration Task List" in this chapter.
Class Map Configuration: Example
In the following example, ACLs 101 and 102 are created. Next, two class maps are created and their match criteria are defined. For the first map class, called class1, the numbered ACL 101 is used as the match criterion. For the second map class, called class2, the numbered ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the class.
Router(config)# access-list 101 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000Router(config# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000Router(config)# class-map class1Router(config-cmap)# match access-group 101Router(config-cmap)# exitRouter(config-cmap)# class-map class2Router(config-cmap)# match access-group 102Router(config-cmap)# exitPolicy Creation: Example
In the following example, a policy map called policy1 is defined to contain policy specification for the two classes, class1 and class2. The match criteria for these classes were defined in the previous "Class Map Configuration: Example" section.
For class1, the policy specifies the bandwidth allocation request and the maximum number of packets that the queue for this class can accumulate. For class2, the policy specifies only the bandwidth allocation request, so the default queue limit of 64 packets is assumed.
Router(config)# policy-map policy1Router(config-pmap)# class class1Router(config-pmap-c)# bandwidth 3000Router(config-pmap-c)# queue-limit 30Router(config-pmap-c)# exitRouter(config-pmap)# class class2Router(config-pmap-c)# bandwidth 2000Router(config-pmap-c)# exitPolicy Attachment to Interfaces: Example
The following example shows how to attach an existing policy map. After you define a policy map, you can attach it to one or more interfaces to specify the service policy for those interfaces. Although you can assign the same policy map to multiple interfaces, each interface can have only one policy map attached at the input and one policy map attached at the output.
The policy map in this example was defined in the previous section, "Policy Creation: Example."
Router(config)# interface e1/1Router(config-if)# service output policy1Router(config-if)# exitRouter(config)# interface fa1/0/0Router(config-if)# service output policy1Router(config-if)# exitCBWFQ Using WRED Packet Drop: Example
In the following example, the class map called class1 is created and defined to use the input FastEthernet interface 0/1 as a match criterion to determine if packets belong to the class. Next, the policy map policy1 is defined to contain policy specification for class1, which is configured for WRED packet drop.
Router(config)# class-map class1Router(config-cmap)# match input-interface FastEthernet0/1!Router(config)# policy-map policy1Router(config-pmap)# class class1Router(config-pmap-c)# bandwidth 1000Router(config-pmap-c)# random-detect!Router(config)# interface serial0/0Router(config-if)# service-policy output policy1!Display Service Policy Map Content Examples
The following examples show how to display the contents of service policy maps. Four methods can be used to display the contents.
•
Display all classes that make up a specified service policy map
•
Display all classes configured for all service policy maps
•
Display a specified class of a service policy map
•
Display all classes configured for all service policy maps on a specified interface
All Classes for a Specified Service Policy Map
The following example displays the contents of the service policy map called pol1:
Router# show policy-map po1Policy Map po1 Weighted Fair Queueing Class class1Bandwidth 937 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 937 (kbps) Max thresh 64 (packets)Class class3 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class4 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class5 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class6Bandwidth 937 (kbps) Max thresh 64 (packets) Class class7 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class8 Bandwidth 937 (kbps) Max thresh 64 (packets)All Classes for All Service Policy Maps
The following example displays the contents of all policy maps on the router:
Router# show policy-mapPolicy Map poH1 Weighted Fair Queueing Class class1 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 937 (kbps) Max thresh 64 (packets)Class class3 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class4 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class5 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class6 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class7 Bandwidth 937 (kbps) Max thresh 64 (packets) Class class8 Bandwidth 937 (kbps) Max thresh 64 (packets)Policy Map policy2Weighted Fair QueueingClass class1 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class2 Bandwidth 300 (kbps) Max thresh 64 (packets)Class class3 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class4 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class5 Bandwidth 300 (kbps) Max thresh 64 (packets) Class class6 Bandwidth 300 (kbps) Max thresh 64 (packets)Specified Class for a Service Policy Map
The following example displays configurations for the class called class7 that belongs to the policy map called po1:
Router# show policy-map po1 class class7Class class7 Bandwidth 937 (kbps) Max Thresh 64 (packets)All Classes for All Service Policy Maps on a Specified Interface
The following example displays configurations for classes on the output Ethernet interface 2/0. The numbers shown in parentheses are for use with the Management Information Base (MIB).
Router# show policy-map interface e2/0Ethernet2/0Service-policy output:p1 (1057)Class-map:c1 (match-all) (1059/2)19 packets, 1140 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:ip precedence 0 (1063)Weighted Fair QueueingOutput Queue:Conversation 265Bandwidth 10 (%) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:c2 (match-all) (1067/3)0 packets, 0 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:ip precedence 1 (1071)Weighted Fair QueueingOutput Queue:Conversation 266Bandwidth 10 (%) Max Threshold 64 (packets)(pkts matched/bytes matched) 0/0(depth/total drops/no-buffer drops) 0/0/0Class-map:class-default (match-any) (1075/0)8 packets, 2620 bytes5 minute offered rate 0 bps, drop rate 0 bpsMatch:any (1079)Distributed CBWFQ Configuration Examples
The following sections provide DCBWFQ configuration examples:
•
Traffic Class Configuration: Example
•
Traffic Policy Creation: Example
•
Traffic Policy Attachment to an Interface: Example
For information on how to configure DCBWFQ, see the section "Distributed Class-Based Weighted Fair Queueing Configuration Task List" in this chapter.
Traffic Class Configuration: Example
In the following example, two traffic classes are created and their match criteria are defined. For the first traffic class, called class1, the numbered ACL 101 is used as the match criterion. For the second traffic class, called class2, the numbered ACL 102 is used as the match criterion. Packets are checked against the contents of these ACLs to determine if they belong to the traffic class.
Router(config)# class-map class1 Router(config-cmap)# match access-group 101Router(config-cmap)# exitRouter(config)# class-map class2 Router(config-cmap)# match access-group 102Router(config-cmap)# exitFor additional information on traffic classes, see the "Applying QoS Features Using the MQC" module.
Traffic Policy Creation: Example
In the following example, a traffic policy called policy1 is defined to associate QoS features with the two traffic classes, class1 and class2. The match criteria for these traffic classes were defined in the previous "Class Map Configuration: Example" section.
For class1, the QoS policies include bandwidth allocation request and maximum packet count limit for the queue reserved for the traffic class. For class2, the policy specifies only a bandwidth allocation request, so the default queue limit of 64 packets is assumed.
Router(config)# policy-map policy1Router(config-pmap)# class class1Router(config-pmap-c)# bandwidth 3000Router(config-pmap-c)# queue-limit 30Router(config-pmap)# exitRouter(config-pmap)# class class2Router(config-pmap-c)# bandwidth 2000Router(config-pmap)# exitFor additional information on traffic policy configurations, see the "Applying QoS Features Using the MQC" module.
Traffic Policy Attachment to an Interface: Example
The following example shows how to attach an existing traffic policy to an interface. After you define a traffic policy, you can attach it to one or more interfaces to specify a traffic policy for those interfaces. Although you can assign the same traffic policy to multiple interfaces, each interface can have only one traffic policy attached at the input and one policy map attached at the output at one time.
Router(config)# interface fe1/0/0 Router(config-if)# service output policy1Router(config-if)# exitFor additional information on attaching traffic policy configurations to interfaces, see the "Applying QoS Features Using the MQC" module.
IP RTP Priority Configuration Examples
The following sections provide IP RTP Priority configuration examples:
•
Virtual Template Configuration: Example
•
Multilink Bundle Configuration: Example
For information on how to configure IP RTP Priority, see the section "IP RTP Priority Configuration Task List" in this chapter.
CBWFQ Configuration: Example
The following example first defines a CBWFQ configuration and then reserves a strict priority queue:
! The following commands define a class map:Router(config)# class-map class1Router(config-cmap)# match access-group 101Router(config-cmap)# exit! The following commands create and attach a policy map:Router(config)# policy-map policy1Router(config-pmap)# class class1Router(config-pmap-c)# bandwidth 3000Router(config-pmap-c)# queue-limit 30Router(config-pmap-c)# random-detectRouter(config-pmap-c)# random-detect precedence 0 32 256 100Router(config-pmap-c)# exitRouter(config)# interface Serial1Router(config-if)# service-policy output policy1! The following command reserves a strict priority queue:Router(config-if)# ip rtp priority 16384 16383 40The queue-limit and random-detect commands are optional commands for CBWFQ configurations. The queue-limit command is used for configuring tail drop limits for a class queue. The random-detect command is used for configuring RED drop limits for a class queue, similar to the random-detect command available on an interface.
Virtual Template Configuration: Example
The following example configures a strict priority queue in a virtual template configuration with CBWFQ. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for CBWFQ and IP RTP Priority from the default (75 percent) to 80 percent.
Router(config)# multilink virtual-template 1Router(config)# interface virtual-template 1Router(config-if)# ip address 172.16.1.1 255.255.255.0Router(config-if)# no ip directed-broadcastRouter(config-if)# ip rtp priority 16384 16383 25Router(config-if)# service-policy output policy1Router(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment-delay 20Router(config-if)# ppp multilink interleaveRouter(config-if)# max-reserved-bandwidth 80Router(config-if)# endRouter(config)# interface Serial0/1Router(config-if)# bandwidth 64Router(config-if)# ip address 1.1.1.2 255.255.255.0Router(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation pppRouter(config-if)# ppp multilinkRouter(config-if)# end
Note
To make the virtual access interface function properly, the bandwidth policy-map class configuration command should not be configured on the virtual template. It needs to be configured on the actual interface, as shown in the example.
Multilink Bundle Configuration: Example
The following example configures a strict priority queue in a multilink bundle configuration with WFQ. The advantage to using multilink bundles is that you can specify different ip rtp priority parameters on different interfaces.
The following commands create multilink bundle 1, which is configured for a maximum ip rtp priority bandwidth of 200 kbps. The max-reserved-bandwidth command changes the maximum reserved bandwidth allocated for WFQ and IP RTP Priority.
Router(config)# interface multilink 1Router(config-if)# ip address 172.17.254.161 255.255.255.248Router(config-if)# no ip directed-broadcastRouter(config-if)# ip rtp priority 16384 16383 200Router(config-if)# no ip mroute-cacheRouter(config-if)# fair-queue 64 256 0Router(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment-delay 20Router(config-if)# ppp multilink interleaveRouter(config-if)# max-reserved-bandwidth 80The following commands create multilink bundle 2, which is configured for a maximum ip rtp priority bandwidth of 100 kbps:
Router(config)# interface multilink 2Router(config-if)# ip address 172.17.254.162 255.255.255.248Router(config-if)# no ip directed-broadcastRouter(config-if)# ip rtp priority 16384 16383 100Router(config-if)# no ip mroute-cacheRouter(config-if)# fair-queue 64 256 0Router(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment-delay 20Router(config-if)# ppp multilink interleaveIn the next part of the example, the multilink-group command configures serial interface 2/0 to be part of multilink bundle 1:
Router(config)# interface serial 2/0Router(config-if)# bandwidth 256Router(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation pppRouter(config-if)# no ip mroute-cacheRouter(config-if)# no fair-queueRouter(config-if)# clockrate 256000Router(config-if)# ppp multilinkRouter(config-if)# multilink-group 1Next, serial interface 2/1 is configured to be part of multilink bundle 2.
Router(config)# interface serial 2/1Router(config-if)# bandwidth 128Router(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation pppRouter(config-if)# no ip mroute-cacheRouter(config-if)# no fair-queueRouter(config-if)# clockrate 128000Router(config-if)# ppp multilinkRouter(config-if)# multilink-group 2Debug: Example
The following example shows sample output from the debug priority command. In this example, 64 indicates the actual priority queue depth at the time the packet was dropped.
Router# debug priority*Feb 28 16:46:05.659:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.671:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.679:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.691:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.699:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.711:WFQ:dropping a packet from the priority queue 64*Feb 28 16:46:05.719:WFQ:dropping a packet from the priority queue 64Frame Relay IP RTP Priority Configuration Examples
This "Strict Priority Service to Matching RTP Packets: Example" section provides a configuration example.
For information on how to configure Frame Relay IP RTP Priority queueing, see the section "Frame Relay IP RTP Priority Configuration Task List" in this chapter.
Strict Priority Service to Matching RTP Packets: Example
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. In this example, RTP packets on PVC 100 with UDP ports in the range 16384 to 32764 will be matched and given strict priority service.
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 dceFrame Relay PVC Interface PQ Configuration Examples
This section provides configuration examples for Frame Relay PIPQ.
For information on how to configure Frame Relay PIPQ, see the section "Frame Relay PVC Interface Priority Configuration Task List" in this chapter.
This example shows the configuration of four PVCs on serial interface 0. DLCI 100 is assigned high priority, DLCI 200 is assigned medium priority, DLCI 300 is assigned normal priority, and DLCI 400 is assigned low priority.
The following commands configure Frame Relay map classes with PVC priority levels:
Router(config)# map-class frame-relay HIRouter(config-map-class)# frame-relay interface-queue priority highRouter(config-map-class)# exitRouter(config)# map-class frame-relay MEDRouter(config-map-class)# frame-relay interface-queue priority mediumRouter(config-map-class)# exitRouter(config)# map-class frame-relay NORMRouter(config-map-class)# frame-relay interface-queue priority normalRouter(config-map-class)# exitRouter(config)# map-class frame-relay LOWRouter(config-map-class)# frame-relay interface-queue priority lowRouter(config-map-class)# exitThe following commands enable Frame Relay encapsulation and Frame Relay PIPQ on serial interface 0. The sizes of the priority queues are set at a maximum of 20 packets for the high priority queue, 40 for the medium priority queue, 60 for the normal priority queue, and 80 for the low priority queue.
Router(config)# interface Serial0Router(config-if)# encapsulation frame-relayRouter(config-if)# frame-relay interface-queue priority 20 40 60 80The following commands assign priority to four PVCs by associating the DLCIs with the configured map classes:
Router(config-if)# frame-relay interface-dlci 100Router(config-fr-dlci)# class HIRouter(config-fr-dlci)# exitRouter(config-if)# frame-relay interface-dlci 200Router(config-fr-dlci)# class MEDRouter(config-fr-dlci)# exitRouter(config-if)# frame-relay interface-dlci 300Router(config-fr-dlci)# class NORMRouter(config-fr-dlci)# exitRouter(config-if)# frame-relay interface-dlci 400Router(config-fr-dlci)# class LOWRouter(config-fr-dlci)# exitLLQ Configuration Examples
The following sections provide LLQ configuration examples:
•
ATM PVC Configuration: Example
•
Virtual Template Configuration: Example
•
Multilink Bundle Configuration: Example
For information on how to configure LLQ, see the section "Low Latency Queueing Configuration Task List" in this chapter.
ATM PVC Configuration: Example
In the following example, a strict priority queue with a guaranteed allowed bandwidth of 50 kbps is reserved for traffic that is sent from the source address 10.10.10.10 to the destination address 10.10.10.20, in the range of ports 16384 through 20000 and 53000 through 56000.
First, the following commands configure access list 102 to match the desired voice traffic:
Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000Next, the class map voice is defined, and the policy map called policy1 is created; a strict priority queue for the class voice is reserved, a bandwidth of 20 kbps is configured for the class bar, and the default class is configured for WFQ. The service-policy command then attaches the policy map to the PVC interface 0/102 on the subinterface atm1/0.2.
Router(config)# class-map voiceRouter(config-cmap)# match access-group 102Router(config)# policy-map policy1Router(config-pmap)# class voiceRouter(config-pmap-c)# priority 50Router(config-pmap)# class barRouter(config-pmap-c)# bandwidth 20Router(config-pmap)# class class-defaultRouter(config-pmap-c)# fair-queueRouter(config)# interface atm1/0.2Router(config-subif)# pvc 0/102Router(config-subif-vc)# service-policy output policy1Virtual Template Configuration: Example
The following example configures a strict priority queue in a virtual template configuration with CBWFQ. Traffic on virtual template 1 that is matched by access list 102 will be directed to the strict priority queue.
First, the class map voice is defined, and the policy map called policy1 is created. A strict priority queue (with a guaranteed allowed bandwidth of 50 kbps) is reserved for the class called voice.
Router(config)# class-map voiceRouter(config-cmap)# match access-group 102Router(config)# policy-map policy1Router(config-pmap)# class voiceRouter(config-pmap-c)# priority 50Next, the service-policy command attaches the policy map called policy1 to virtual template 1.
Router(config)# multilink virtual-template 1Router(config)# interface virtual-template 1Router(config-if)# ip address 172.16.1.1 255.255.255.0Router(config-if)# no ip directed-broadcastRouter(config-if)# service-policy output policy1Router(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment-delay 20Router(config-if)# ppp multilink interleaveRouter(config-if)# endRouter(config)# interface serial 2/0Router(config-if)# bandwidth 256Router(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation pppRouter(config-if)# no fair-queueRouter(config-if)# clockrate 256000Router(config-if)# ppp multilinkMultilink Bundle Configuration: Example
The following example configures a strict priority queue in a multilink bundle configuration with CBWFQ. Traffic on serial interface 2/0 that is matched by access list 102 will be directed to the strict priority queue. The advantage to using multilink bundles is that you can specify different priority parameters on different interfaces. To specify different priority parameters, you would configure two multilink bundles with different parameters.
First, the class map voice is defined, and the policy map called policy1 is created. A strict priority queue (with a guaranteed allowed bandwidth of 50 kbps) is reserved for the class called voice.
Router(config)# class-map voiceRouter(config-cmap)# match access-group 102Router(config)# policy-map policy1Router(config-pmap)# class voiceRouter(config-pmap-c)# priority 50The following commands create multilink bundle 1. The policy map called policy1 is attached to the bundle by the service-policy command.
Router(config)# interface multilink 1Router(config-if)# ip address 172.17.254.161 255.255.255.248Router(config-if)# no ip directed-broadcastRouter(config-if)# no ip mroute-cacheRouter(config-if)# service-policy output policy1Router(config-if)# ppp multilinkRouter(config-if)# ppp multilink fragment-delay 20Router(config-if)# ppp multilink interleaveIn the next part of the example, the multilink-group command configures serial interface 2/0 to be part of multilink bundle 1, which effectively directs traffic on serial interface 2/0 that is matched by access list 102 to the strict priority queue:
Router(config)# interface serial 2/0Router(config-if)# bandwidth 256Router(config-if)# no ip addressRouter(config-if)# no ip directed-broadcastRouter(config-if)# encapsulation pppRouter(config-if)# no fair-queueRouter(config-if)# clockrate 256000Router(config-if)# ppp multilinkRouter(config-if)# multilink-group 1Distributed LLQ Configuration Examples
The following sections provide distributed LLQ configuration examples:
•
Enabling PQ for an Amount of Available Bandwidth on an ATM Subinterface: Example
•
Enabling PQ for a Percentage of Available Bandwidth on an ATM Subinterface: Example
•
Limiting the Transmission Ring Limit on an ATM Interface: Example
•
Limiting the Transmission Ring Limit on an ATM PVC Subinterface: Example
For information on how to configure distributed LLQ, see the section "Distributed LLQ Configuration Task List" in this chapter.
Enabling PQ for an Amount of Available Bandwidth on an ATM Subinterface: Example
The priority command can be enabled on an ATM subinterface, and that subinterface must have only one enabled ATM PVC. This configuration provides a sufficient amount of ATM PVC support.
In the following example, a priority queue with a guaranteed allowed bandwidth of 50 kbps is reserved for traffic that is sent from the source address 10.10.10.10 to the destination address 10.10.10.20, in the range of ports 16384 through 20000 and 53000 through 56000.
First, the following commands configure access list 102 to match the desired voice traffic:
Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000Next, the traffic class called voice is defined, and the policy map called policy1 is created; a priority queue for the class voice is reserved with a guaranteed allowed bandwidth of 50 kpbs and an allowable burst size of 60 bytes, a bandwidth of 20 kbps is configured for the class called bar, and the default class is configured for flow-based fair queuing. The service-policy command then attaches the policy map to the PVC interface 0/102 on the subinterface atm1/0.
Router(config)# class-map voiceRouter(config-cmap)# match access-group 102Router(config)# policy-map policy1Router(config-pmap)# class voiceRouter(config-pmap-c)# priority 50 60Router(config-pmap)# class barRouter(config-pmap-c)# bandwidth 20Router(config-pmap)# class class-defaultRouter(config-pmap-c)# fair-queueRouter(config)# interface atm1/0Router(config-subif)# pvc 0/102Router(config-subif)# service-policy output policy1Enabling PQ for a Percentage of Available Bandwidth on an ATM Subinterface: Example
The priority percent command can be enabled on an ATM subinterface, and that subinterface must have only one enabled ATM PVC. This configuration provides a sufficient amount of ATM PVC support.
In the following example, a priority queue with a guaranteed allowed bandwidth percentage of 15 percent is reserved for traffic that is sent from the source address 10.10.10.10 to the destination address 10.10.10.20, in the range of ports 16384 through 20000 and 53000 through 56000.
First, the following commands configure access list 102 to match the desired voice traffic:
Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 16384 20000Router(config)# access-list 102 permit udp host 10.10.10.10 host 10.10.10.20 range 53000 56000Next, the traffic class called voice is defined, and the policy map called policy1 is created; a priority queue for the class voice is reserved with a guaranteed allowed bandwidth percentage of 15 percent, a bandwidth percentage of 20 percent is configured for the class called bar, and the default class is configured for flow-based fair queueing. The service-policy command then attaches the policy map to the ATM subinterface 1/0.2.
Router(config)# class-map voiceRouter(config-cmap)# match access-group 102Router(config)# policy-map policy1Router(config-pmap)# class voiceRouter(config-pmap-c)# priority percent 15Router(config-pmap)# class barRouter(config-pmap-c)# bandwidth percent 20Router(config-pmap)# class class-defaultRouter(config-pmap-c)# fair-queueRouter(config)# interface atm1/0.2Router(config-subif)# service-policy output policy1Limiting the Transmission Ring Limit on an ATM Interface: Example
In the following example, the number of particles on the transmission ring of an ATM interface is limited to seven particles:
Router(config)# interface atm 1/0/0Router(config-if)# atm pvc 32 0 32 tx-ring-limit 7Limiting the Transmission Ring Limit on an ATM PVC Subinterface: Example
In the following example, the number of particles on the transmission ring of an ATM PVC subinterface is limited to ten particles:
Router(config)# interface ATM1/0/0.1 point-to-pointRouter(config-subif)# pvc 2/200Router(config-if-atm-vc)# tx-ring-limit 10The tx-ring-limit command can be applied to several ATM PVC subinterfaces on a single interface. Every individual PVC can configure a transmission ring limit.
LLQ for Frame Relay Configuration Examples
The following section provides a LLQ for Frame Relay configuration examples.
For information on how to configure LLQ for Frame Relay, see the section "Low Latency Queueing for Frame Relay Configuration Task List" in this chapter.
The following example shows how to configure a PVC shaped to a 64K CIR with fragmentation. The shaping queue is configured with a class for voice, two data classes for IP precedence traffic, and a default class for best-effort traffic. WRED is used as the drop policy on one of the data classes.
The following commands define class maps and the match criteria for the class maps:
!class-map voicematch access-group 101!class-map immediate-datamatch access-group 102!class-map priority-datamatch access-group 103!access-list 101 permit udp any any range 16384 32767access-list 102 permit ip any any precedence immediateaccess-list 103 permit ip any any precedence priorityThe following commands create and define a policy map called mypolicy:
!policy-map mypolicyclass voicepriority 16class immediate-databandwidth 32random-detectclass priority-databandwidth 16class class-defaultfair-queue 64queue-limit 20The following commands enable Frame Relay fragmentation and attach the policy map to DLCI 100:
!interface Serial1/0.1 point-to-pointframe-relay interface-dlci 100class fragment!map-class frame-relay fragmentframe-relay cir 64000frame-relay mincir 64000frame-relay bc 640frame-relay fragment 50service-policy output mypolicyBurst Size in LLQ Configuration Examples
For information on how to configure the burst size in LLQ, see the section "Configuring Burst Size in LLQ Configuration Task List" in this chapter.
The following example configures the burst parameter to 1250 bytes for the class called Voice, which has an assigned bandwidth of 1000 kbps:
policy policy1class Voicepriority 1000 1250Per-VC Hold Queue Support for ATM Adapters Examples
For information on how to configure per-VC hold queue support for ATM Adapters, see the section "Per-VC Hold Queue Support for ATM Adapters Configuration Task List" in this chapter.
The following example sets the per-VC hold queue to 55:
interface atm2/0.1pvc 1/101vc-hold-queue 55CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0809R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2007 Cisco Systems, Inc. All rights reserved.


