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:
Modular QoS command-line interface (CLI) (MQC)—Refer to Modular Quality of Service Command-Line Interface for more information.
PPPoE—Refer to PPPoE Baseline Architecture for the Cisco UAC 6400 for more information on PPPoE.
This document is not restricted to specific software and hardware versions.
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.
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 -routed 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.
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.
PPPoE |
---|
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.
PPPoE over ATM VC |
---|
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 |
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:
shashi@pepsi.com 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.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
15-Feb-2008 |
Initial Release |