QoS Congestion Management (queueing)

Document ID: 10102

Contents

Introduction
Prerequisites
      Requirements
      Components Used
      Conventions
Apply Queuing to Interfaces with a Variety of Bandwidths
CBWFQ and LLQ on Dialer Interfaces
LLQ and CBWFQ with Distributed MLPPP
CBWFQ and LLQ with PPPoA and MLPPPoA
NetPro Discussion Forums - Featured Conversations
Related Information

Introduction

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.

Prerequisites

Requirements

There are no specific prerequisites for this document.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Apply Queuing to Interfaces with a Variety of Bandwidths

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.

CBWFQ and LLQ on Dialer Interfaces

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.

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.

LLQ and CBWFQ with Distributed MLPPP

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:

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:

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.

CBWFQ and LLQ with PPPoA and MLPPPoA

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. Cisco IOS Software Release 12.2(8) supports this configuration:

interface ATM2/0.100 point-to-point 
 pvc 0/100 
  abr 704 200 
  broadcast 
  encapsulation aal5mux ppp Virtual-Template20 
  service-policy output dscp

Note: These restrictions exist when you configure QoS over PPPoA:

1. For Class-based Marking or Class-based Policing, the service-policy command must be configured under the virtual-template interface.

Refer to this example:

Class-based Marking:

policy-map MARK_PEER2PEER
 class PEER2PEER
  set dscp default
!
interface Virtual-Template1
ip address negotiated 
service-policy output MARK_PEER2PEER

Class-based Policing:

policy-map POLICE_PEER2PEER
  class PEER2PEER
    police 8000 conform-action transmit exceed-action drop
!
interface Virtual-Template1
ip address negotiated 
service-policy output POLICE_PEER2PEER

2. For Class-based Queuing (ie. bandwidth, shape, priority, random-detect), the service-policy command must be configured under the ATM PVC.

Refer to this example:

Class-based Queuing:

policy-map QUEUE_PEER2PEER
 class PEER2PEER
  bandwidth 768
!
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 negotiated

3. When you use a combination of Class-based Marking or Class- based Policing and Class-based Queuing, the order of operations is this:

1. The service-policy command configured on the Virtual-Template interface marks or polices the packets.

2. 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.

NetPro Discussion Forums - Featured Conversations

Related Information

• Per-VC Class-Based, Weighted Fair Queuing (Per-VC CBWFQ) on the Cisco 7200, 3600, and 2600 Routers
• Low Latency Queueing
• QoS Technology Support
• Technical Support & Documentation - Cisco Systems