The service-policy command normally applies a policy map configured with the commands of the modular QoS CLI (MQC) to a main interface, subinterface, or virtual circuit. You can also apply this command to a virtual template interface, multilink interface, and a dialer interface configured with point-to-point protocol (PPP) encapsulation and multilink PPP (MLPPP). Such interfaces result in a virtual-access interface, where queuing functionally takes place. This document provides a single reference for understanding recommended configurations and related caveats to apply class-based weighted fair queuing (CBWFQ) and low latency queuing (LLQ) to MLPPP bundle interfaces and dialer interfaces.
There are no specific prerequisites for this document.
This document is not restricted to specific software and hardware versions.
Refer to the Cisco Technical Tips Conventions for more information on document conventions.
RFC 1990 defines multilink PPP, which combines one or more physical interfaces into a virtual "bundle" interface. The bandwidth of the bundle interface is equal to the sum of the component links' bandwidth. Thus, the bundle interface has a maximum bandwidth value that varies at an instantaneous moment in time.
Originally, the bandwidth and priority commands supported only an absolute kbps value. If you applied a service policy with CBWFQ and LLQ to a bundle interface and the first active interface did not support the absolute kbps value, the service policy failed admission control. The router removed the service policy and printed error messages similar to this output:
May 18 17:32:34.766 MEST: CBWFQ: Not enough available bandwidth for all classes Available 48 (kbps) Needed 96 (kbps) May 18 17:32:34.766 MEST: CBWFQ: Removing service policy on Dialer100
As of Cisco IOS® Software Release 12.2T, the router now tries to reapply the policy when it detects that an additional interface (such as a second BRI B-channel) is added to the bundle. A superior approach is to configure the priority and bandwidth commands as a percent of the available bandwidth. The use of a percentage value configures the router to assign a relative amount of bandwidth that adjusts as the bundle contains one or more member links. Cisco IOS Software Release 12.2(2)T introduced support for the priority percentage command on the Cisco 7500 Series Routers and other platforms. For more information, refer to Low Latency Queuing with Priority Percentage Support.
Dial-on-demand routing (DDR) can be configured in two ways:
Legacy DDR—Applies the dial and protocol parameters directly to the physical interface.
Dialer profiles—Applies the dial and protocol parameters dynamically to a dialer interface, which in turn binds to physical interfaces. For example, a dialer interface includes one or more dial strings to reach a remote site, PPP authentication type, and MLPPP.
Legacy DDR originally supported first in, first out (FIFO) queuing only when a serial or ISDN interface was configured with MLPPP. This restriction applied even when the two ends of the connection did not negotiate MLPPP and used the physical interface as a non-bundle interface that runs PPP encapsulation. Traditional weighted fair queuing (WFQ) via the fair-queue command is now supported.
If you choose to configure dialer profiles, both the dialer interface and the underlying physical interfaces support the service-policy command. If you apply a policy on the physical interface, issue either the show policy-map interface serial command or the show policy-map interface bri 0/0:1 (and bri0/0:2) command to confirm the configuration. The D-channel, identified in IOS as BRI0/0, supports signaling and not data traffic. If you apply a policy to the dialer interface, issue the show queueing interface dial <0-255> command to confirm the configuration.
Cisco IOS Software Releases 12.2(4) and 12.2(4)T introduced support for queuing-based service policies on virtual-access interfaces created from a dialer interface configured with MLPPP. In previous releases, the service-policy parameters are not copied over to the cloned virtual-access interface, where the queuing actually takes place. This output illustrates these symptoms:
Router#show policy interface dialer1 Dialer1 Service-policy output: foo Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Weighted Fair Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 256 (total queued/total drops/no-buffer drops) 0/0/0 Router#show policy interface virtual-access 2 Router#
Note: Cisco IOS Software Release 12.2(8) and 12.2(8)T are recommended to avoid Cisco bug ID CSCdu87408, which resolves router reloads as a rare side-effect of this configuration.
This sample configuration shows how to apply CBWFQ and LLQ to a dialer interface. This configuration results in:
Uses a dialer interface to apply dynamically the protocol parameters of the connection to the ISDN BRI interfaces. The dialer interface is said to be "bound" to the ISDN BRI interfaces.
Places two ISDN BRI interfaces in a multilink bundle.
Uses the dialer load-threshold load [outbound | inbound | either] command to determine when the router needs to activate additional B-channels and increase the bandwidth of the bundle interface.
Creates a virtual-access interface with the ppp multilink command.
Applies a service policy with CBWFQ and LLQ to the virtual-access interface by way of the dialer interface.
Sample Configuration |
---|
access-list 101 permit udp any any range 16384 32767 access-list 101 permit tcp any any eq 1720 ! access-list 102 permit tcp any any eq 23 ! class-map voice match access-group 101 !--- Traffic that matches ACL 101 is classified as class voice. class-map data match access-group 102 !--- Traffic that matches ACL 102 is classified as class data. policy-map mlppp class voice priority percent 50 class data bandwidth percent 25 class class-default fair-queue ! interface BRI2/1 no ip address encapsulation ppp dialer pool-member 1 !--- Member of dialer pool 1. isdn switch-type basic-net3 no cdp enable ppp authentication chap ! interface BRI2/2 no ip address encapsulation ppp dialer pool-member 1 !--- Member of dialer pool 1. isdn switch-type basic-net3 no cdp enable ppp authentication chap ! interface Dialer2 ip unnumbered Loopback0 encapsulation ppp dialer pool 1 dialer load-threshold 1 either !--- Load level (in either direction) for !--- traffic at which additional connections !--- are added to the MPPP bundle !--- load level values that range from 1 (unloaded) !--- to 255 (fully loaded). dialer string 6113 dialer string 6114 dialer-group 1 ppp authentication chap ppp multilink !--- Allow MLPPP for the four BRI channels. service-policy output mlppp !--- Apply the service policy to the dialer interface. |
The Cisco 7500 series uses a distributed architecture that ensures high packet throughput by moving the packet-forwarding decisions from the Route Switch Processor (RSP) to the Versatile Interface Processors (VIPs). This architecture also enables the deployment of large-scale enhanced IP services, such as QoS, by spreading the processing load across the multiple independent processors of the VIPs.
Based on the interface hardware, the Cisco 7500 series supports two forms of QoS:
QoS | How Enabled | Where Supported | Where Processed |
---|---|---|---|
RSP-Based | Automatically on Legacy Interface Processors. | Legacy Interface Processors. Can no longer be enabled on VIPs. | RSP CPU |
VIP-Based (Distributed) | Automatically when these two commands are configured:
|
VIPs | VIP CPU |
The VIP-based QoS mechanisms applied via the modular QoS CLI (MQC) are introduced in these three Cisco IOS Software release trains:
Cisco IOS Software Release 12.0(XE), which became Cisco IOS Software Release 12.1(E)
Cisco IOS Software Release 12.0(9)S
Cisco IOS Software Release 12.1(5)T, which became Cisco IOS Software Release 12.2 mainline and Cisco IOS Software Release 12.2T
The distributed MLPPP feature allows you to combine the bandwidth of multiple T1/E1 interfaces on a VIP into a bundle interface. For more information, refer to Distributed Multilink Point-to-Point Protocol for Cisco 7500 Series Routers. Cisco IOS Software Release 12.2(13)T introduces support for Distributed MLPPP (dMLPPP) on non-channelized port adapters, such as the PA-4T+ and PA-8T.
Cisco IOS Software Release 12.2(8)T introduced support for distributed LLQ and CBWFQ on dMLPPP bundle interfaces on channelized port adapters such as PA-MC-xT1/E1 and PA-MC-xT3/E3. Like the non-distributed version of this feature, dMLPPP uses an interface multilink to create a virtual-access interface where the queuing functionally takes place. Refer to New and Changed Information for Cisco IOS Software Release 12.2T. When you apply distributed queuing with dMLPPP, Cisco IOS Software Release 12.2(10)T or later is recommended in order to avoid Cisco bug ID CSCdw47678.
Only CBWFQ and LLQ as applied with the service-policy command is supported with dMLPPP/dLFI. Legacy queuing features, such as fair queuing with the fair-queue command, priority queuing with the priority-group command, and custom queuing with the queue-list command, are not supported.
The FlexWAN for the Cisco 7600 series supports dLLQ on non-bundle interfaces. It does not support dLLQ on MLPPP bundle interfaces. This support is available with Cisco IOS Software Release 12.2S.
This sample configuration applies dLLQ on an interface multilink:
Sample Configuration of dLLQ on an MLPPP Bundle Interface |
---|
Interface ! access-list 100 permit udp any any range 16384 32000 access-list 100 permit tcp any any eq 1720 access-list 101 permit tcp any any eq 80 access-list 102 permit tcp any any eq 23 ! class-map voip match access-group 100 class-map data1 match access-group 101 class-map data2 match access-group 102 ! policy-map llq-policy class voip bandwidth 40 class data1 bandwidth 15 class data2 bandwidth 15 class class-default fair-queue ! policy-map set-policy class voip bandwidth 40 class data1 bandwidth 15 class data2 bandwidth 15 class class-default fair-queue ! interface Serial5/0/0:0 no ip address encapsulation ppp keepalive 10 ppp chap hostname G2 ppp multilink multilink-group 2 ! interface Serial5/1/0:0 no ip address encapsulation ppp keepalive 10 ppp chap hostname G2 ppp multilink multilink-group 2 ! interface Multilink2 ip address 106.0.0.2 255.0.0.0 ppp multilink service-policy output llq-policy service-policy input set-policy multilink-group 2 |
Link fragmentation and interleaving (LFI) add the ppp multilink fragment-delay and ppp multilink interleave commands to an interface virtual-template configured with MLPPP and a service policy. This configuration reduces delay on slower-speed links by breaking up large datagrams and interleaving low-delay traffic packets with the smaller packets that result from the fragmented datagram. For more information, refer to Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits.
Cisco IOS Software Release 12.2(8)T introduced support for distributed LFI (dLFI) over-channelized serial lines on the Cisco 7500 series with VIPs. This feature is also available with the Catalyst 6500 Series Switches and the Cisco 7600 Series Routers. For information on the releases that support dLFI, refer to the Feature Navigator Tool (registered customers only) and Release Notes for the respective products. For more information on this feature, refer to Distributed Link Fragmentation and Interleaving over Leased Lines.
The FlexWAN for the Cisco 7600 series with Cisco IOS Software Release Train 12.1E does not support dLFI.
After you configure the maximum fragment delay with the ppp multilink fragment-delay <msec> command, dLFI feature calculates the actual fragment size on channelized serial interfaces with the use of this formula (where bandwidth is in kbps):
fragment size = bandwidth x fragment-delay / 8
In addition, fragment size is calculated based on the member link with the smallest bandwidth amount. For example, in a configuration with member links of 64 k and 128 k, the fragment size is calculated based on the 64 k link.
Cisco IOS Software Release 12.2(8) introduced support for per-VC queuing on ATM virtual circuits configured with generic PPP over ATM (PPPoA) encapsulation. These subsections give you the configuration examples of Class-Based Marking, Policing, and Queuing.
1. Class-Based Marking
The service-policy command can be attached to the Virtual-template interface or ATM PVC for Class-Based Marking.
In this example, the class map PEER2PEER is defined, the policy map MARK_PEER2PEER is created, and the dscp default is configured for the class PEER2PEER; then the service-policy is attached to the virtual template or ATM PVC.
Router(config)#class-map PEER2PEER Router(config-cmap)#match access-group 100 Router(config-cmap)#exit Router(config)#policy-map MARK_PEER2PEER Router(config-pmap)#class PEER2PEER Router(config-pmap-c)#set dscp default Router(config-pmap-c)#end Attaching Service-policy to Virtual Template Router(config-subif)#int atm1/0.1 point-to-point Router(config-subif)#ip address 10.10.10.1 255.255.255.0 Router(config-subif)#pvc 1/50 Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 1 Router(config)#interface Virtual-Template1 Router(config-if)#ip address negotiated Router(config-if)#service-policy output MARK_PEER2PEER Attaching Service-policy to ATM pvc Router(config)#int atm1/0.1 point-to-point Router(config-subif)#ip address 10.10.10.1 255.255.255.0 Router(config-subif)#pvc 1/50 Router(config-if-atm-vc)#service-policy output MARK_PEER2PEER
2. Class-Based Policing:
The service-policy command can be attached to the Virtual-template interface or ATM pvc for Class-Based Policing.
Router(config)#policy-map POLICE_PEER2PEER Router(config-pmap)#class PEER2PEERRouter(config-pmap-c)#police 8000 conform-action transmit exceed-action drop Attaching Service-policy to Virtual Template Router(config-subif)#int atm1/0.2 multipoint Router(config-subif)#no ip address Router(config-subif)#pvc 1/100 Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 2 Router(config)#interface Virtual-Template2 Router(config-if)#ip address negotiated Router(config-if)#service-policy output POLICE_PEER2PEER Attaching Service-policy to ATM pvc Router(config)#int atm1/0.2 multipoint Router(config-subif)#no ip address Router(config-subif)#pvc 1/100 Router(config-if-atm-vc)#service-policy output POLICE_PEER2PEER
3. Class-Based Queuing:
For Class-Based Queuing, that is, bandwidth, shape, priority, and random-detect, the service-policy command can be attached to the Virtual Template or the ATM PVC.
Router(config)#policy-map QUEUE_PEER2PEER Router(config-pmap)#class PEER2PEER Router(config-pmap-c)#bandwidth 768 Attaching Service-policy to Virtual Template Router(config-subif)#int atm1/0 Router(config-subif)#no atm ilmi-keepalive Router(config-subif)#pvc 1/150 Router(config-if-atm-vc)#encapsulation aal5mux ppp virtual-Template 3 Router(config)#interface Virtual-Template3 Router(config-if)#ip address negotiated Router(config-if)#service-policy output QUEUE_PEER2PEER Attaching Service-policy to ATM pvc Router(config)#int atm1/0 Router(config-subif)#no atm ilmi-keepalive Router(config-subif)#pvc 1/150 Router(config-if-atm-vc)#service-policy output QUEUE_PEER2PEER
Note: When you use a combination of Class-Based Marking or Class-Based Policing and Class-Based Queuing, the order of operations is this:
The service-policy command configured on the Virtual-Template interface marks or polices the packets.
The service-policy command on the ATM PVC queues the packets.
Refer to this example:
policy-map MARK_PEER2PEER class PEER2PEER set dscp default ! interface ATM0/0 no ip address no atm ilmi-keepalive pvc 1/100 encapsulation aal5mux ppp Virtual-Template1 service-policy output QUEUE_PEER2PEER ! interface Virtual-Template1 ip address negotiate service-policy output MARK_PEER2PEER
If you run an earlier Cisco IOS Software release, you can configure on ATM VC with MLPPPoA encapsulation and apply a queuing-based service policy to the virtual-template interface. For more information, refer to Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits and the Link Efficiency Mechanisms Overview.
Cisco IOS Software Release 12.2(4)T3 introduces a distributed version of this feature for the Cisco 7500 series. For more information on this feature, refer to Distributed Link Fragmentation and Interleaving for ATM and Frame Relay.