QoS Policing

QoS Solutions for PPPoE and DSL Environments

Cisco - QoS Solutions for PPPoE and DSL Environments

Document ID: 23706

Updated: Feb 15, 2008



This document describes quality of service (QoS) options for Point-to-Point Protocol over Ethernet (PPPoE) and digital subscriber line (DSL) environments. After you read this document, you can understand the QoS features supported on PPPoE interfaces, as well as the required Cisco IOS® software releases.



Readers of this document should have knowledge of these topics:

Components Used

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

PPPoE Overview

As customers deploy asymmetric DSL (ADSL) they must support PPP-style authentication and authorization over a large installed base of legacy bridging customer premises equipment (CPE). PPPoE provides the ability to connect a network of hosts over a simple bridging access device to a remote access concentrator or aggregation concentrator. With this model, each host uses its own PPP stack. This presents the user with a familiar user interface. Access control, billing, and type of service can be done on a per user, rather than a per site, basis.

PPPoE first creates a PPP session. These sessions are initiated by PPPoE client software, such as Routerware, on the PC or by client functionality on a Cisco IOS router. For example, Cisco IOS Software Release 12.1(3)XG introduced a PPPoE client feature for the Cisco SOHO77. In this case, multiple PCs can be installed behind the Cisco SOHO77 and before their traffic is sent to the PPPoE session, it can be encrypted, filtered, and Network Address Translation (NAT) can run. Refer to Configuring a Cisco SOHO77 Router as a PPPoE Client with NAT for more information.

After a PPP session is established, both the host, or client, and the terminating access concentrator allocate resources for a PPP virtual access interface.

Feature Overview and Restrictions

When you configure a QoS service policy that applies fancy queueing, such as class-based weighted fair queueing (CBWFQ) or low latency queueing (LLQ), in a PPPoE environment, note these restrictions:

  • If the router runs the PPPoE client or server software, the virtual-template and virtual-access interfaces do not support a service policy that implements per-session queueing. However, a service policy that applies QoS features other than queueing can be applied to the interface virtual-template or interface dialer, and the MQC features work on per-session basis.

  • If the router has a DSL interface configured for RFC 1483 virtual circuits (VCs) through the ATM DSL network and the single VC carries multiple PPPoE sessions initiated by the PCs, then standard per-VC queueing and backpressure mechanisms work in Cisco IOS Software Releases 12.2(4)T and 12.2(4) and later. These releases support fancy queueing and packet classification mechanisms on virtual-access interfaces using PPP encapsulation.

  • If the egress interface facing the DSL network is an Ethernet port which connects to a DSL modem, you can implement a hierarchical policy in which you shape a rate at the parent level which matches the upstream speed on the DSL modem, and then queue at a child policy level. In order to do so, you must use Cisco IOS Software Release 12.2(4)T and 12.2(4) or later.

Cisco IOS Software Release 12.2(4)T introduced support for a PPPoE client on the Cisco 2600 series. However, the DSL interfaces do not support service policies that apply fancy queueing since these interfaces do not implement the "back-pressure algorithm" necessary to signal that excess packets should be queued by the Layer 3 (L3) queueing system. However, if you connect to a DSL modem using a regular Ethernet port, you can implement queueing when you configure a hierarchical policy which shapes at the parent layer, and then apply a child policy which queues and optionally implements LLQ. The DSL uplink is much slower than the Ethernet interface, so the Ethernet needs to match the DSL rate and actually congest, and then queueing mechanisms apply to the buffered excess.

When PPPoE runs over an ATM interface, consider one of these options to achieve QoS for voice in DSL environments. These options assume that the backpressure mechanism to signal congestion is done per VC. Providing QoS for voice is premised on the router's ability to correctly propagate the congestion status of a permanent VC (PVC) to Layer 3 queuing.

  • Configure RFC 1483-routed PVCs with transmit ring tuning on the VC when a service policy applies LLQ.

  • Configure separate VCs, such as a variable bit rate non-real-time (VBR-nrt) VC for voice and a unspecified bit rate (UBR) VC for data.

  • Configure PVC bundles, which are separate, parallel VCs between the same two routers. Each VC carries a unique set of IP predence values and is assigned (typically) to a unique ATM service category, such as VBR-nrt. Refer to IP to ATM CoS on an ATM Bundle Configuration Task List for more information.

  • Configure Configuring Link Fragmentation and Interleaving for Frame Relay and ATM Virtual Circuits, in which large packets are segmented and interleaved using MLPPP's fragmentation mechanism. Also configure LLQ and apply transmit ring tuning. Along with public and private interface pools, Cisco IOS creates special buffer control structures called rings. When carrying VoIP packets, it is important to tune down the transmit ring, which supports first in, first out (FIFO) queueing only, and push all the queueing to the Layer 3 hold queue where fancy queueing mechanisms and a service policy apply. Refer to Understanding and Tuning the tx-ring-limit Value for more information.

Sample Configuration

This sample configuration shows the necessary commands to configure CBWFQ or LLQ in a PPPoE environment.

A typical design in this environment is shown here. In this example, the DSL network transports Voice over IP (VoIP).


You can apply a hierarchical policymap (see the PPPoE configuration) to the Ethernet interface where PPPoE is enabled. Ensure you configure the correct speed for the shaping. For example, in the DSL environment, if your upstream limit is 128 kbps, you should shape to 128 kbps.

A typical hierarchical policy uses only class-default in the parent policy since the objective of the parent policy is to create a bandwidth-limited stream and not sort traffic into classes. The child policy specifies multiple traffic classes and either the priority command and/or the bandwidth command to implement LLQ and CBWFQ, respectively.

policymap parent_shaping  
 class class-default  
  shape average {speed} 
  service-policy child_queueing  
policymap child_queueing  
 class c1  
  priority Y  
 class c2  
  bandwidth X  

interface ethernet 1/0  
 pppoe enable  
 service-policy output parent_shaping


You can apply a policy-map with CBWFQ and LLQ (see the PPPoE over ATM VC configuration) to the ATM PVC where PPPoE is configured.

policymap P2  
 class c1  
  priority Y  
 class c2  
  bandwidth X 
interface ATM0/0/0.132 point-to-point  
 pvc 1/32  
  vbr-nrt 2000 2000  
  encapsulation aal5snap  
  protocol pppoe  
  service-policy output P2

Bandwidth Limiting

On the Cisco 7200 series with the Broadband feature set, Cisco IOS Software Release 12.2(4)B1 introduces support for rate limiting on the RADIUS user profile applied to the virtual access interface in a PPPoE environment. A sample configuration is provided: Password = "cisco" 
Service-Type = Framed, 
Framed-Protocol = PPP, 
Framed-MTU = 1400, 
Framed-Routing = 1 
Cisco-Avpair = "lcp:interface-config=rate-limit output 
access-group 101 64000 16000 32000 conform-action transmit exceed-action drop", 
interface Virtual-Access2 
  mtu 1492 
  ip unnumbered Loopback1 
  rate-limit output access-group 101 64000 
16000 32000 conform-action transmit exceed-action drop

You also can use class-based policing to accomplish this configuration and attach a QoS service policy to the virtual template.

Related Information

Updated: Feb 15, 2008
Document ID: 23706