QTECH SmartEdge 100 User Manual

Configuring PPP and PPPoE

SYSTEM ADMINISTRATOR GUIDE

64/1543-CRA 119 1170/1 Uen K

Copyright

© Ericsson AB 2009–2012. 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

SmartEdge

NetOp

is a registered trademark of Telefonaktiebolaget LM
Ericsson.

is a trademark of Telefonaktiebolaget LM Ericsson.

64/1543-CRA 119 1170/1 Uen K | 2012-12-04

Contents

Contents

1 Overview 1

1.1 PPP-Encapsulated Circuits and Binding 1

1.2 PPP Oversubscription 3

1.3 Single-Stack and Dual-Stack Support 3

1.4 PPP Keepalive Checks 4

1.5 PPPoE Features 6

1.6 Using IPCP Option 144 to Reserve IP Addresses and
Install Subnet Routes 6

2 Multilink PPP 9

3 Configuration Tasks 11

3.1 Configuring PPP 11

3.1.1 Configure PPP Global Attributes 11

3.1.2 Configure a PPP-Encapsulated Port 12

3.1.3 Configure a PPP-Encapsulated ATM PVC 12

3.1.4 Configure a Subscriber Record for PPP 13

3.1.5 Configure an Interface for Static PPP Peer Router IP
Address Assignment 13

3.1.6 Configure MLPPP on ATM PVCs 13

3.1.7 Example: MLPPP Configuration on ATM PVCs 14

3.1.8 Configure MLPPP for L2TP Subscribers 14

3.1.9 Example: MLPPP Configuration for L2TP Subscribers 15

3.2 Configuring PPPoE 15

3.2.1 Configure PPPoE Global and 802.1Q Profile Attributes 15

3.2.2 Configure a PPPoE-Encapsulated Ethernet Port 16

3.2.3 Configure a PPPoE-Encapsulated ATM PVC 17

3.2.4 Configure a PPPoE-Encapsulated 802.1Q PVC 17

3.2.5 Configure a PPPoE-Encapsulated Child Circuit on an ATM
PVC 18

3.2.6 Configure a PPPoE-Encapsulated Child Circuit on an

802.1Q PVC 19

3.2.7 Configure a Subscriber Record for PPPoE 19

3.2.8 Configure IPCP Netmask Negotiation 20

3.2.9 Configure MLPPP over PPPoE 20

3.2.10 Example: MLPPP Configuration on PPPoE 21

4 Operations Tasks 23

5 Configuration Examples 25

5.1 PPP Examples 25

5.1.1 PPP Configuration with Dynamic Binding 25

64/1543-CRA 119 1170/1 Uen K | 2012-12-04

Configuring PPP and PPPoE

5.1.2 PPP Configuration with Restricted Dynamic Binding 25

5.2 PPPoE Examples 26

5.2.1 Advertise a List of Services (Domains) 26

5.2.2 Create and Delete a MOTM 26

5.2.3 Set a PADO Delay 27

5.2.4 Point a Subscriber’s Browser to a URL 27

5.2.5 Configure IPCP Netmask Negotiation 27

5.2.6 Verify Reserved IP Addresses or Subnets and Installed
Routes 28

Reference List 31

64/1543-CRA 119 1170/1 Uen K | 2012-12-04

1 Overview

This document describes how to configure, monitor, and troubleshoot
Point-to-Point Protocol (PPP) or PPP over Ethernet (PPPoE) on ports,
channels, and PPP or PPPoE encapsulated circuits.

®

Note: Unless otherwise noted, the SmartEdge

commands described in this document.

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)

100 router supports all

Overview

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 (MLPPP)

• 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

• ATM PVCs on ATM OC 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

64/1543-CRA 119 1170/1 Uen K | 2012-12-04

1

Configuring PPP and PPPoE

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.

2

64/1543-CRA 119 1170/1 Uen K | 2012-12-04

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

Overview

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 configuration
mode). For a complete description of both forms, see the document,
Configuring Circuits.

1.3 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
router to support IPv6 or dual-stack subscriber services, see Configuring IPv6
Subscriber Services.

64/1543-CRA 119 1170/1 Uen K | 2012-12-04

3

Configuring PPP and PPPoE

1.4 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

Table 1 Time Elapsed Before an Abnormally Terminated Session Is Torn Down

PPP Keepalives Without Data Check
Enabled PPP Keepalives with Data Check Enabled

Step in the
Process

Seconds
Elapsed
Since
Previous
Step

Cumu
lative
Seconds
Elapsed

Step in the
Process

Seconds
Elapsed
Since
Previous
Step

Cumu
lative
Seconds
Elapsed

Successful
keepalive
check—check
interval timer reset
to zero

4 64/1543-CRA 119 1170/1 Uen K | 2012-12-04

0

Successful keepa
live check—check
interval timer reset
to zero

0

Overview

Table 1 Time Elapsed Before an Abnormally Terminated Session Is Torn Down

PPP Keepalives Without Data Check
Enabled PPP Keepalives with Data Check Enabled

Step in the
Process

Packets sent by
the session

Abnormal
termination

Check interval
timer expires; LCP
echo request sent

Response timer
expires; first retry
LCP echo request
sent

Seconds
Elapsed
Since
Previous
Step

Cumu
lative
Seconds
Elapsed

55

2

7

53 60

10 70

Step in the
Process

Packets sent by the
session

Abnormal
termination

Check interval timer
expires; data check
indicates data has
been received since
the last successful
keepalive check;
check interval timer
is reset

Check interval
timer expires; data
check indicates
no data has been
received since the
last successful
keepalive check;
LCP echo request
sent

Seconds
Elapsed
Since
Previous
Step

Cumu
lative
Seconds
Elapsed

55

2

7

53 60

60 120

Response timer

10 80
expires; second
retry LCP echo
request sent

Response timer

10 90
expires; retry limit
reached; session
is torn down

Time elapsed between abnormal
session termination and tear
down

83

Response timer

10 130
expires; first retry
LCP echo request
sent

Response timer

10 140
expires; second
retry LCP echo
request sent

Response timer

10 150
expires; retry limit
reached; session is
torn down

Time elapsed between abnormal
session termination and tear
down

143

564/1543-CRA 119 1170/1 Uen K | 2012-12-04

Configuring PPP and PPPoE

1.5 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 ports

• 802.1Q PVCs on Ethernet ports

• Child circuits on ATM and 802.1Q PVCs

1.6 Using IPCP Option 144 to Reserve IP Addresses and
Install Subnet Routes

Usually, residential customers need only a single reserved IP address, but
business subscribers require entire subnets to assign to their customers.
Using IP Control Protocol (IPCP) option 144, you can control which addresses
are reserved and which subnet routes are installed; Point-to-Point Protocol
over Ethernet (PPPoE) and Point-to-Point Protocol over Asynchronous

6

64/1543-CRA 119 1170/1 Uen K | 2012-12-04

Overview

Transfer Mode (PPPoA) subscribers are supported for IPv4 or in dual-stack
environments.

You can configure three possible variations for a subscriber that has a valid /32
netmask configured:

• Reserve one IP address for the subscriber and install only the host
/32 route. The system rejects IPCP netmask option requests received
from the Customer Premise Equipment (CPE) client. This is the default
configuration; no additional configuration is required.

• Reserve an entire subnet range for the subscriber and install the subnet
route.

• Reserve one IP address for the subscriber and install the subnet route.

Without this configuration, the SmartEdge OS rejects IPCP option 144 requests
received from CPE clients.

64/1543-CRA 119 1170/1 Uen K | 2012-12-04

7