SYSTEM ADMINISTRATOR GUIDE     64/1543-CRA 119 1170/1-V1 Uen C1

Configuring PPP and PPPoE

Copyright

© Ericsson AB 2009–2010. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List

Contents

1   Overview

1.1   PPP-Encapsulated Circuits and Binding

PPP and PPPoE features comply with the following RFCs:

• RFC 1332, The PPP Internet Protocol Control Protocol (IPCP)

  The current implementation does not support compression.

• RFC 1334, PPP Authentication Protocols
• RFC 1661, The Point-to-Point Protocol (PPP)
• RFC 1877, PPP Internet Protocol Control Protocol Extensions for Name Server Addresses
• RFC 1990, The Multilink Protocol (MP)
• RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP)
• RFC 2364, PPP Over AAL5
• RFC 2516, A Method for Transmitting PPP Over Ethernet, including the Extensions to a Method for Transmitting PPP over Ethernet (PPPoE)
• RFC 2615, PPP over SONET/SDH

The SmartEdge OS supports PPP on the following ports, channels, and circuits:

• POS ports
• Clear-channel DS-3 channels or ports
• Clear-channel E3 ports
• DS-1 channels on channelized DS-3 channels or ports
• Clear-channel E1 channels or ports
• DS-0 channel groups
• ATM PVCs on ATM OC and ATM DS-3 ports

On ATM PVCs, PPP encapsulation types include virtual circuit-multiplexed (VC-multiplexed), logical link control (LLC), Network Layer Protocol Identifier (NLPID), and serial (High-Level Data Link Control [HDLC]) encapsulations as described in RFC 2364.

PPP-encapsulated ATM PVCs, unlike RFC 1483-encapsulated ATM PVCs, can be dynamically bound to an interface; you can use the bind authentication command (in ATM PVC configuration mode) to dynamically bind a PPP-encapsulated ATM PVC to an interface on the basis of authentication.

If you use the bind subscriber command (in ATM PVC configuration mode), the PPP-encapsulated PVC is brought up unauthenticated, meaning that no authentication data is received from the PPP remote peer. The subscriber name and password are then supplied through the command-line interface (CLI), similar to a PVC with RFC 1483 bridged- or routed-encapsulation.

The bind authentication command allows you to specify the authentication protocol to be used in negotiating the PPP link. If you use the chap pap construct, for example, you indicate that both the Challenge Handshake Authentication Protocol (CHAP) and the Password Authentication Protocol (PAP) can be used, with CHAP negotiated first. CHAP uses a challenge and response protocol to provide authentication without sending clear text passwords over the network. The CHAP challenge value is sent in both the Request Authenticator field and the CHAP-Challenge Attribute (60) field of the RADIUS Access-Request messages. Other authentication protocol options are available. For a complete description of all options, see the description of the bind authentication command in the document, Configuring Bindings

If you are using remote authentication using the Remote Authentication Dial-In User Service (RADIUS), the local subscriber records are replaced by the corresponding subscriber records in the RADIUS database.

If you are using the CHAP, PAP, or both authentication protocols, the response from the RADIUS server (in attribute 18) is forwarded to the PPP client with the reason for the acceptance or rejection of the subscriber.

Another binding option is to use the bind authentication command with the optional context ctx-name construct to create a restricted dynamic binding of a PPP-encapsulated PVC to a specific context; this binding method denies the subscriber the ability to dynamically select a context (service).

An IP address is required. This IP address is assigned to the remote end of the PPP link, and there must be an interface with an IP address or network mask range that includes the IP address assigned to a subscriber during the IP Control Protocol (IPCP) or IPv6 Control Protocol (IPv6CP) phase of PPP (or that includes the IP address that has been directly configured for the subscriber). RADIUS servers must return an IP address for the subscriber that falls within the range of the interface that is configured in the appropriate context.

If the authentication procedure is successful, the PPP link is established and the circuit is implicitly bound to the interface with a network address mask that includes the address of the remote PPP endpoint. If no such interface exists, then the bind command fails.

Note:  

When a second PPP session attempts to authenticate using an IP address that is already in use by an established session, the established session is terminated, and the second session is allowed to complete authentication.

If the remote PPP device is a router (or the remote segment of any other encapsulation type contains a router), it might be necessary to configure one or more static routes whenever the link is brought up. This is accomplished by one or more Routing Information Protocol (RIP) configuration commands in the subscriber record.

1.2   PPP Oversubscription

Ordinarily, any bind authentication command causes the subscriber’s session to be counted toward the maximum number of PPP structures allocated (which depends on your router and configuration), whether or not the subscriber is active. The alternative is to configure the system to operate so that only active PPP sessions count toward the maximum number of structures allocated. The effect is that the number of bind authentications you can have is increased, beyond the number that could actually bind and come up (PPP oversubscription).

Oversubscription does not affect the maximum number of subscribers that can be terminated in a particular context (established by the aaa max subscribers command in context configuration mode) or the hard limits allowed by the SmartEdge OS.

You configure PPP oversubscription using ppp auto encapsulation in the atm pvc (or its atm pvc explicit form) command (in ATM OC or ATM DS-3 configuration mode). For a complete description of both forms, see the document, Configuring Circuits.

1.3   Multilink PPP

Multilink PPP (MP) is an extension to PPP that allows a peer to use more than one physical link for communication. When using more than one physical link to connect two peers, you need a mechanism to load balance the connection across the two (or more) links in the bundle. MP is used to fragment the datagrams and send them across the multiple links in the bundle in a way that achieves optimum use of the media.

Both ends of the point-to-point links must be capable of supporting MP connections. The two ends configure the data link by swapping Link Control Protocol (LCP) packets during a link establishment phase. If MP is not successfully negotiated by the two ends of the link, MP is not enabled for the connection.

MP is implemented on the SmartEdge router in four forms:

• MP using PPP-encapsulated DS-1 channels and E1 channels and ports

  Using this form of MP, you create a static MP bundle and add specific DS-1 channels, E1 channels, or E1 ports to it. For more information about configuring this form of MP and the constituent channels or ports, see the document, Configuring Link Aggregation.

• MP using PPP-encapsulated ATM PVCs

  Using this form of MP, you do not create the MP bundles; instead, the SmartEdge OS creates them dynamically, using the endpoint discriminator sent by the peer during the LCP negotiation and the subscriber name to determine whether to create a new MP bundle or add the session to a current MP bundle. The configuration for this form of MP and the constituent ATM PVCs is described later in this document in the MP Configuration on ATM PVCs section.

• MP for Layer 2 Tunneling Protocol (L2TP) subscribers

  Using this form of MP, you do not create the MP bundles; instead, the SmartEdge OS creates them dynamically, using the endpoint discriminator sent by the peer during the LCP negotiation and the subscriber name to determine whether to create a new MP bundle or add the session to a current MP bundle.

  To use this form of MP, you must use ports configured on a GE traffic card that has a packet processing ASIC (PPA) version 2 (PPA2) on the LNS. You must also use ports configured on a GE traffic card on the L2TP access concentrator (LAC). These traffic cards include the 4-port GE version 3 (GE3), 10- and 20-port GE 1020, and 10 GE (10GE) traffic cards. The configuration for this form of MP and the constituent L2TP tunnels is described later in this document, in the section MP Configuration for L2TP Subscribers. For more information about L2TP and MP for L2TP subscribers, see the document, Configuring L2TP.

• MP using PPPoE

  Using this form of MP, you do not create the MP bundles; instead, the SmartEdge OS creates them dynamically, using the endpoint discriminator sent by the peer during the LCP negotiation and the subscriber name to determine whether to create a new MP bundle or add the session to a current MP bundle.

  You can use MP using PPPoE with the following types of Ethernet encapsulation:

  • Ethernet with untagged traffic
  • 802.1Q PVCs
  • 802.1Q tunnels

  The system does not allow MP using PPPoE over ATM (PPPoEoA).

  To use this form of MP, you must use ports configured on a GE traffic card that has a PPA2; these traffic cards include the GE3, GE1020, and 10GE traffic cards. The configuration for this form of MP is described later in this document in the document, Configure MP over PPPoE.

1.4   Single-Stack and Dual-Stack Support

PPP subscriber and non-subscriber circuits can be single-stack or dual-stack. Single-stack circuits exclusively support one type of traffic (IPv4 or IPv6). Dual-stack circuits are authorized for both IPv4 and IPv6, and can simultaneously support both IPv4 and IPv6 traffic.

Dual-stack non-subscribers must be configured to support both IPv4 and IPv6 traffic.

Note:  

Although dual-stack subscriber and non-subscriber circuits can simultaneously support both IPv4 and IPv6 traffic, it is not necessary for both stacks to be active at the same time.

Dual-stack subscribers use IPCP for IPv4 address negotiation and IPv6CP for IPv6 address negotiation. IPCP and IPv6CP are independent of one another; if IPv6CP fails, IPCP still operates and vice-versa. For details on configuring the SmartEdge router to support IPv6 or dual-stack subscriber services, see Configuring IPv6 Subscriber Services.

1.5   PPP Keepalive Checks

Keepalive checks are LCP echo messages sent over PPP sessions in the context to determine if sessions are still active (alive). Normally, when a PPP session is ending, the peer sends the SmartEdge OS an LCP termination request (TERMREQ) message to indicate that it is ending. Keepalive checks detect abnormal disconnects that the SmartEdge OS would not otherwise know about. In addition to facilitating accurate timing of accounting information, it is important to detect these abnormal terminations so that allocated system resources can be reallocated to new sessions.

The keepalive checks feature can be used with or without a data check option. The data check option is recommended when it is preferred to limit the overhead for PPP keepalive processing. However, using the data check option to determine that a session is no longer active can take longer than using the PPP keepalive feature without the data check option, by a length of one check interval. This condition occurs because with the data check enabled, the check interval timer is reset as long as data has been received since the last successful keepalive check.

If a session sends data and then abnormally terminates between keepalive checks, the SmartEdge OS has no indication that the session has terminated until the following check interval timer expires with no data being received. At that point, the SmartEdge OS begins sending LCP echo requests. Without a data check, the SmartEdge OS begins sending LCP echo requests, regardless of whether data has been received since the last check.

Table 1 compares the two scenarios. In both cases, the following configuration applies:

• Keepalive check interval is set to 60 seconds
• Response timer is set to 10 seconds
• Number of retries is set to 2

1.6   PPPoE Features

The SmartEdge OS implementation of PPPoE supports the following features:

• PPPoE encapsulation on Ethernet ports and ATM and 802.1Q PVCs.
• Both IP over Ethernet (IPoE) and PPPoE encapsulation on the same ATM or 802.1Q PVC. You must specify multiprotocol encapsulation (the multi keyword) for these circuits when creating the PVC.
• Policing and rate-limiting on a per-PPP-session basis.
• Rate-limiting the number of PPPoE PADI, PADR, or both messages on a per-MAC address basis within a circuit.
• Ability to configure a maximum number of concurrent sessions allowed on a circuit.
• Multiple simultaneous PPPoE sessions arriving over the same circuit while being bound to different services (contexts).
• Ability to advertise a list of services (domains) to a client during the discovery protocol.
• Ability to send messages to subscribers, including messages of the minute (MOTMs).
• Ability to direct the subscriber’s browser to open at a specific, optionally customized URL.
• Dual-stack session support for PPPoE subscribers and non-subscribers.

The SmartEdge OS supports PPPoE encapsulation on the following ports, channels, and circuits:

• Ethernet ports
• ATM PVCs on ATM OC and ATM DS-3 ports
• 802.1Q PVCs on Ethernet ports
• Child circuits on ATM and 802.1Q PVCs

1.7   Related Information

For information about the tasks and commands used to monitor, troubleshoot, and administer PPP and PPPoE features, see the document, Configuring Circuits.

Other documents with related commands include:

• Configuring ATM, Ethernet, and POS Ports
• Configuring Channels and Clear-Channel and Channelized Ports
• BRAS Troubleshooting Guide
• Configuring Circuits
• Configuring Cross-Connections

  Note:  

  An 802.1Q permanent virtual circuit (PVC) is also referred to as an 802.1Q virtual LAN (VLAN), but in this document, it is the circuit that is being configured.

  
  

  Note:  

  Unless otherwise noted, the SmartEdge 100 router supports all commands described in this document.

  
  

2   Configuration Tasks

To configure PPP or PPPoE perform the tasks in the following sections.

For information about troubleshooting PPP, see the BRAS Troubleshooting Guide.

2.1   Configuring PPP

This section describes how to configure, PPP global attributes, a PPP-encapsulated port, channel, or ATM PVC, to configure MP on ATM PVCs or for L2TP subscribers and to configure a subscriber record for PPP.

2.1.1   Configure PPP Global Attributes

To configure PPP global attributes, perform one or more of the tasks described in Table 2.

2.1.2   Configure a PPP-Encapsulated Port

To configure a PPP-encapsulated port, perform the tasks described in Table 3.

2.1.3   Configure a PPP-Encapsulated Channel

To configure a PPP-encapsulated channel, perform the tasks described in Table 4.

2.1.4   Configure a PPP-Encapsulated ATM PVC

To configure a PPP-encapsulated ATM PVC, perform the tasks described in Table 5.

Note:  

If you are configuring an ATM PVC that will be included in a PPP multilink bundle, you must ensure that it and all other PVCs in that bundle are identical in their configuration and are on ports on the same ATM traffic card.

2.1.5   Configure MP on ATM PVCs

To configure MP using PPP-encapsulated ATM PVCs, perform the tasks described in Table 6. Enter all commands in global configuration mode.

2.1.6   Configure MP for L2TP Subscribers

To configure MP for L2TP subscribers, perform the tasks described in Table 7. Enter all commands in global configuration mode.

2.1.7   Configure a Subscriber Record for PPP

To configure a circuit for PPP in the subscriber record, perform the tasks described in Table 8. Enter all commands in subscriber configuration mode.

For descriptions of the basic tasks needed to configure a subscriber record, see the document, Configuring Subscribers.

2.1.8   Configure an Interface for Static PPP Peer Router IP Address Assignment

To configure an interface for static PPP peer router IP address assignment, perform the tasks described in Table 9. Enter all commands in subscriber configuration mode.

For descriptions of the basic tasks needed to configure a subscriber record, see Configuring Subscribers.

2.2   Configuring PPPoE

2.2.1   Configure PPPoE Global and 802.1Q Profile Attributes

To configure Point-to-Point over Ethernet (PPPoE) global and 802.1Q profile attributes, perform one or more of the tasks described in Table 10. Enter all commands in global configuration mode, unless otherwise noted.

For information about troubleshooting PPPoE, see the BRAS Troubleshooting Guide.

2.2.2   Configure a PPPoE-Encapsulated Ethernet Port

To configure an Ethernet port for PPPoE, perform the tasks described in Table 11. Enter all commands in port configuration mode, unless otherwise noted.

2.2.3   Configure a PPPoE-Encapsulated ATM PVC

To configure a PPPoE-encapsulated ATM PVC, perform the tasks described in Table 12.

2.2.4   Configure a PPPoE-Encapsulated 802.1Q PVC

To configure a PPPoE-encapsulated 802.1Q PVC, perform the tasks described in Table 13.

2.2.5   Configure a PPPoE-Encapsulated Child Circuit on an ATM PVC

To configure a child circuit on an ATM PVC for PPPoE, perform the tasks described in Table 14.

2.2.6   Configure a PPPoE-Encapsulated Child Circuit on an 802.1Q PVC

To configure a child circuit on an 802.1Q PVC for PPPoE, perform the tasks described in Table 15.

2.2.7   Configure a Subscriber Record for PPPoE

To configure a subscriber record for PPPoE, perform the tasks described in Table 16. Enter all commands in subscriber configuration mode.

For descriptions of the basic tasks needed to configure a subscriber record, see the document, Configuring Subscribers.

2.2.8   Configure MP over PPPoE

To configure MP using PPPoE, perform the tasks described in Table 17. Enter all commands in global configuration mode.

3   Operations Tasks

To enable the generation of debug messages for Point-to-Point Protocol (PPP) events and display PPP information, perform the appropriate task listed in Table 18. Enter the clear and debug commands in exec mode; enter the show commands in any mode.

To debug PPP sessions, examine the output from the show ppp counters and show ppp counters detail commands. If debug messages are needed, start with the debug ppp command with the exception keyword to look for events that indicate a malfunction. To display the most concise view of session negotiations, use the debug ppp command with the packet keyword.

4   Configuration Examples

This section provides examples of PPP and PPPoE configurations.

For information about troubleshooting PPP or PPPoE, see the BRAS Troubleshooting Guide.

4.1   PPP Examples

This section provides examples of configuring PPP with dynamic and restricted dynamic binding, configuring MP on ATM PVCs and for L2TP subscribers.

4.1.1   PPP Configuration with Dynamic Binding

In Figure 1, the host on the left is configured to run PPP over ATM. The SmartEdge OS is configured to dynamically bind the user to an IP interface assumed to be previously configured with an IP address of 10.1.3.1 and a mask of 255.255.255.0.

The following example shows how to create the ATM PVC, using an existing ATM profile, adsl, and indicates to the system that the PVC is to be bound using an authentication process:

[local]Redback(config)#port atm 3/1
[local]Redback(config-port)#atm pvc 100 300 profile adsl encapsulation ppp
[local]Redback(config-pvc)#bind authentication chap pap

4.1.2   PPP Configuration with Restricted Dynamic Binding

The following example constrains a PPP-encapsulated ATM PVC on an ATM OC port to be bound only in the isp.net context:

[local]Redback(config)#port atm 3/1
[local]Redback(config-atm-oc)#atm pvc 100 1011 profile ubr encapsulation ppp
[local]Redback(config-pvc)#bind authentication pap context isp.net

4.1.3   MP Configuration on ATM PVCs

The following example shows how to configure MP on PPP-encapsulated ATM PVCs using the IP address of the Ethernet management port, two ATM PVCs with identical configuration on the ATM traffic card in slot 3, and a subscriber with a limit of 2 sessions:

!Configure PPP multilink global attributes with IP address of Ethernet management port
[local]Redback(config)#ppp multilink
[local]Redback(config)#ppp our-options multilink endpoint-discriminator local-ip-address

!Configure the links
[local]Redback(config)#port atm 3/1
[local]Redback(config-port)#atm pvc 200 100 profile adsl encapsulation ppp
[local]Redback(config-pvc)#bind authentication chap pap
[local]Redback(config-pvc)#exit
[local]Redback(config-port)#exit

[local]Redback(config)#port atm 3/2
[local]Redback(config-port)#atm pvc 200 200 profile adsl encapsulation ppp
[local]Redback(config-pvc)#bind authentication chap pap
[local]Redback(config-pvc)#exit
[local]Redback(config-port)#exit

!Configure the subscriber
[local]Redback(config)#context local
[local]Redback(config-ctx)#subscriber joe
[local]Redback(config-sub)#port-limit 2

4.1.4   MP Configuration for L2TP Subscribers

The following example shows how to configure MP for L2TP subscribers using two Ethernet ports with identical configuration on the GE traffic card in slot 4 while configuring an L2TP network server (LNS). The example assumes that an LAC (L2TP access concentrator) has already been configured.

!Configure PPP multilink global attributes with IP address of Ethernet management port
[local]Redback(config)#ppp multilink
[local]Redback(config)#ppp our-options multilink endpoint-discriminator local-ip-address

!Configure the LNS
[local]Redback(config)#context lns
[local]Redback(config-ctx)#no ip domain-lookup
[local]Redback(config-ctx)#interface sub multibind
[local]Redback(config-if)#ip address 100.1.1.1/24
[local]Redback(config-if)#ip pool 100.1.1.0/24
[local]Redback(config-if)#no logging console

!Configure the subscriber
[local]Redback(config-ctx)#subscriber default
[local]Redback(config-ctx)#ip address pool
[local]Redback(config-ctx)#exit

!Configure the links
[local]Redback(config)#card ge-10-port 4
[local]Redback(config)#port ethernet 4/1
[local]Redback(config-port)#no shutdown
[local]Redback(config-ports)#bind interface tolns lac
[local]Redback(config-port)#exit
[local]Redback(config)#exit

4.2   PPPoE Examples

This section provides examples of configuring PPPoE.

4.2.1   Advertise a List of Services (Domains)

The following example shows how to configure a SmartEdge OS to advertise all of its domains (isp1, isp2, and isp3) during the PPPoE discovery protocol:

[local]Redback(config)#context isp1.net
[local]Redback(config-ctx)#domain isp1
[local]Redback(config-ctx)#exit
[local]Redback(config)#context isp2.net
[local]Redback(config-ctx)#domain isp2
[local]Redback(config-ctx)#exit
[local]Redback(config)#context isp3.net
[local]Redback(config-ctx)#domain isp3
[local]Redback(config-ctx)#exit
[local]Redback(config)#pppoe services all-domains

The next example shows how to configure a SmartEdge OS to advertise only the indicated domains, namely isp1 and isp2. Domains, corp1 and corp2, are not advertised, because the advertise keyword is not specified in the definitions of the two domains, and the marked-domains keyword is specified in the pppoe services command.

[local]Redback(config)#context isp1.net
[local]Redback(config-ctx)#domain isp1 advertise
[local]Redback(config-ctx)#exit
[local]Redback(config)#context isp2.net
[local]Redback(config-ctx)#domain isp2 advertise
[local]Redback(config-ctx)#exit
[local]Redback(config)#context corp1.com
[local]Redback(config-ctx)#domain corp1
[local]Redback(config-ctx)#exit
[local]Redback(config)#context corp2.com
[local]Redback(config-ctx)#domain corp2
[local]Redback(config-ctx)#exit
[local]Redback(config)#pppoe services marked-domains

4.2.2   Create and Delete a MOTM

The following example shows how to create a message of the minute (MOTM):

[local]Redback(config-sub)#pppoe motm System down 0400 today for scheduled maintenance

The following example replaces the first MOTM with a new one:

[local]Redback(config-sub)#pppoe motm Scheduled maintenance canceled for 03/29/2003.

The following example shows how to remove the existing MOTM so that no message is sent to subscribers:

[local]Redback(config-sub)#no pppoe motm

4.2.3   Set a PADO Delay

The following example shows how to set the 802.1Q foo profile to have a PADO delay time of 3 seconds:

[local]Redback(config)#dot1q profile foo
[local]Redback(config-dot1q-profile)#pppoe pado delay 3

The following example shows how to remove the existing PADO delay:

[local]Redback(config-dot1q-profile)#no pppoe pado delay

4.2.4   Point a Subscriber’s Browser to a URL

The following example causes a PADM with the URL, http://www.loe.com/members/joe@local to be sent to the PPPoE client when the PPP session is established:

[local]Redback(config-ctx)#subscriber name joe
[local]Redback(config-sub)#pppoe url http://www.loe.com/members/%U

The next example uses the pppoe url command to configure the subscriber default profile. Unless overridden by a named subscriber profile or the subscriber record itself, a PADM containing http://www.loe.com/members/name is sent to the PPPoE client of each subscriber when the PPP session is established:

[local]Redback(config-ctx)#subscriber default
[local]Redback(config-sub)#pppoe url http://www.loe.com/members/%u

4.2.5   MP Configuration on PPPoE

The following example shows how to configure MP on PPPoE with two PPPoE sessions for the subscriber. The configuration below results in two active PPP links for an MP subscriber on port 3/1 and port 3/2. The PPPoE client negotiates the same endpoint discriminator for both links:

!Configure PPP multilink global attributes
[local]Redback(config)#ppp multilink
[local]Redback(config)#ppp our-options multilink endpoint-discriminator local-ip-address

!Configure the links
[local]Redback(config)#port ethernet 3/1
[local]Redback(config-port)#encapsulation pppoe
[local]Redback(config-port)#bind authentication chap pap
[local]Redback(config-port)#exit
[local]Redback(config)#port ethernet 3/2
[local]Redback(config-port)#encapsulation pppoe
[local]Redback(config-port)#bind authentication chap pap
[local]Redback(config-port)#exit

!Configure the subscriber
[local]Redback(config)#context local
[local]Redback(config-ctx)#subscriber joe

Reference List