For feedback and comments:
documentation.feedback@alcatel-lucent.com

Table of Contents Previous Next Index PDF

ESMv4: PPPoE Hosts
In This Chapter
This section describes advanced IPv4 Enhanced Subscriber Management (ESM) PPPoE host configurations.
Topics in this section include:
•
Applicability
•
Summary
•
Overview
•
Configuration
•
Conclusion
Applicability
This note is applicable for 7750 SR-C12, SR-7/12 and 7710 on IOM2 and higher and was tested on release 7.0R5 and describes support of PPP termination and aggregation (PTA) hosts. L2TP-hosts are out of scope. Routed CO is supported on 7450 ESS-7 or ESS-12 in mixed-mode since 8.0R1.
This note is related only to the use of IPv4 hosts.
PPPoE has been supported since Release 6.0.
The 7750 SR-c4 is supported from 8.0R4 and higher.
PPPoE hosts are only supported in a Routed CO model (IES or VPRN) using Ethernet SAPs with null, dot1q or QinQ encapsulation.
PPPoE hosts are also supported in external loop/VSM if there is Layer 2 aggregation.
Summary
The delivery of services to residential customers encompassing voice, video and data is covered by Alcatel-Lucent’s Triple Play Service Delivery Architecture (TPSDA).
In the TPSDA, a subscriber is defined as a collection of hosts pertaining to a single access connection (for example, DSL line) and identified by a subscriber identifier. A subscriber host is an end user terminal within the subscriber home (PC, set-top box, home gateway) that is identified in the network with a unique (IP address/MAC address) tuple for IPoE or (PPPoE session ID; MAC address) tuple for PPPoE.
The following host types are distinguished:
Static hosts
•
ip-mac
•
ip-only
Dynamic hosts
•
ARP-host
•
DHCP-host
•
PPPoE-host
This section provides configuration and troubleshooting commands for PPPoE-hosts and will use a local user database (LUDB) for host authentication and ESM (Enhanced Subscriber Management) string assignments.
The IP information in this note is retrieved from a Local DHCP server.
The authentication, IP information and ESM strings can come all from a LUDB, a RADIUS server, a (local) DHCP server, or any combination of them. These combinations are out of scope.
Knowledge of the Alcatel-Lucent TPSDA concept is assumed throughout this document.
 
 
Overview
 
PPPoE Hosts in a Routed CO Environment
The network topology for a Routed CO environment is displayed in Figure 347.
Figure 347: Routed CO Network Topology
The following configuration tasks should already be configured and are not detailed or explained in this section. Refer to the appropriate user guide.
•
Basic service router configuration (system interface, IGP, MPLS, BGP)
•
Routed CO service topology: VPRN or IES service with subscriber- and group-interface on BSR-1
•
ESM
•
LUDB (Local User Data Base)
•
Local (DHCP) Dynamic Host Configuration Protocol) server
This section focuses on PPPoE hosts instantiated in a VPRN service subscriber-interface on BSR-1 (Routed CO). Note that in case of Routed CO, it is also possible to instantiate the PPPoE hosts in the Base routing instance using an IES service.
 
Review of the PPPoE Protocol
PPPoE, Point-to-Point Protocol over Ethernet, is a network protocol for encapsulating PPP frames inside Ethernet frames. The protocol is described as an informational RFC 2516, A Method for Transmitting PPP Over Ethernet (PPPoE), and is based on RFC 1661, The Point-to-Point Protocol (PPP),which provides a standard method for transporting multi-protocol data-grams over point-to-point links.
PPP includes three main components:
•
A method for encapsulating multi-protocol datagrams.
•
A link control protocol (LCP) for establishing, configuring, and testing the data-link connection.
•
A family of network control protocols (NCP) for establishing and configuring different network-layer protocols.
Ethernet networks are packet-based and have no concept of a connection or circuit. By using PPPoE, users can virtually dial from one machine to another over an Ethernet network; establish a point to point connection between them and then transport data packets over the connection.
In a typical wire-line solution with broadband access, PPPoE is used between a client (PC or modem) and a Network Access Server (NAS) (also called Broadband Network Gateway (BNG) or Broadband Service Router (BSR)) through an access node, like a Broadband Service Access Node (BSAN).
PPPoE consists of two phases, the Discovery Stage and the Session Stage.
 
Discovery Stage
The discovery phase offers a stateless client-server model. When the Discovery Stage completes, both peers know the PPPoE SESSION_ID and the peer's Ethernet address, which together uniquely define the PPPoE session. There are four steps in the Discovery Stage:
Step 1.
PPPoE Active Discovery Initiation (PADI)
Initiation (Host broadcast) — This broadcast packet is used by the client to search for an active server (BNG/BSR/NAS) providing access to a service.
Note: Additional attributes on the PADI message could be added if a BSAN is situated between the client and the BRAS.
Step 2.
PPPoE Active Discovery Offer (PADO)
Access concentrator unicast — If the access server can provide the service it will respond with a unicast PADO to signal the client it may request connectivity.
Multiple servers may respond and the client may choose a server to connect.
Step 3.
PPPoE Active Discovery Request (PADR):
Host unicast — After the client receives a PADO it will send a PADR unicast packet to connect to a server.
Step 4.
PPPoE Active Discovery Session-Confirmation (PADS)
Access concentrator unicast — A server will respond to the client with this unicast packet to establish the session and provide the session-id. Once the PADS was provided the Session Stage begins.
Note: Discovery PPPoE Ethernet frames have the ETHER_TYPE field set to the value 0x8863.
 
PPPoE Tags
IANA has set up a registry of PPPoE tag values (16-bit values). PPPoE tag values already in use are specified as reserved values as shown in Table 26. All other tag values between 0 and 65535 are to be assigned by IANA
 
Table 26: Reserved PPPoE Tags
Tag Value
Tag Name
0 0x0000
End-Of-List
257 0x0101
Service-Name
258 0x0102
AC-Name
259 0x0103
Host-Uniq
260 0x0104
AC-Cookie
261 0x0105
Vendor-Specific
262 0x0106
Credits
263 0x0107
Metrics
264 0x0108
Sequence Number
272 0x0110
Relay-Session-Id
273 0x0111
HURL
274 0x0112
MOTM
288 0x0120
PPP-Max-Payload
289 0x0121
IP_Route_Add
513 0x0201
Service-Name-Error
514 0x0202
AC-System-Error
515 0x0203
Generic-Error
 
Explanations for some PPPoE tags (RFC 2516) are shown in the PPPoE discovery debugs messages.
0x0101 Service-Names — This tag indicates that a service name follows. The tag_value is an UTF-8 string that is not null terminated. When the tag_length is zero this tag is used to indicate that any service is acceptable. Examples of the use of the service-name tag are to indicate an ISP name or a class or quality of service.
(0x0102) AC-Names — This tag indicates that a string follows which uniquely identifies this particular Access Concentrator unit from all others. It may be a combination of trademark, model, and serial id information, or simply an UTF-8 rendition of the MAC address of the box. It is not null terminated.
(0x0103) Host-Uniq — This tag is used by a host to uniquely associate an access concentrator response (PADO or PADS) to a particular host request (PADI or PADR). The tag_value is binary data of any value and length that the host chooses. It is not interpreted by the Access Concentrator. The host may include a host-uniq tag in a PADI or PADR. If the access concentrator receives this tag, it must include the tag unmodified in the associated PADO or PADS response.
(0x0104) AC-Cookie — This tag is used by the access concentrator to aid in protecting against denial of service attacks. The access concentrator may include this tag in a PADO packet.
If a host receives this tag, it must return the tag unmodified in the following PADR. The tag_value is binary data of any value and length and is not interpreted by the host.
Figure 348: Discovery Stage Messages
 
Session Stage
This next stage after Discovery is called the Session Stage. Once the MAC address of the peer is known and a session-id is exchanged, the two end points have all the information needed to start building a point-to-point connection over Ethernet and exchange packets over the connection.
This stage can be divided into to the following sections:
•
Setup
•
Maintenance
•
Termination
 
Setup
 
PPP Link Control Protocol (LCP)
Both the NAS and the user open the PPP session based on LCP packets. All post-discovery PPPoE Ethernet frames have the ETHER_TYPE field set to the value 0x8864.
Authentication method and the MRU are negotiated during this phase.
RFC 2516 mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492.
RFC 4638, Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE), relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks.
The 7750 implementation follows RFC 4638 when the client implements these extensions.
LCP uses config_request and config_ack/nack to negotiate parameters:
•
LCP goes to final state opened when configure-ack is send & received.
•
The own options are proposed in configure request.
 
There are three cases for the LCP negations parameters:
•
Peer supports the options and his content.
→
Peer will agree and send config-ack.
•
Peer does not support an option
→
Peer will send configure-reject with the option that is not supported.
→
Resend of configure-request without that option.
→
Peer agrees and sends config-ack.
•
Peer does support the option but not the content.
→
Peer will send config-nack with the option and his new content.
→
Resend of configure-request with same options but new content.
→
Peer agrees and sends config-ack.
 
Table 27: LCP and IPCP Code  
Code
Packet Type
1
Configure-Request
2
Configure-Ack
3
Configure-Nak
4
Configure-Reject
5
Terminate-Request
6
Terminate-Ack
7
Code-Reject
8
Protocol-Reject
9
Echo-Request
10
Echo-Reply
11
Discard-Request
12
Identification
13
Time-Remaining
14
Reset-request CCP
15
Reset-Ack CCP
Figure 349: LCP Phase Messages
 
Authentication Phase
The client authenticates itself through PAP (PPP Password Authentication Protocol) or CHAP (Challenge Handshake Authentication Protocol) to check for access permission.For the CHAP authentication, the BSR initiates the authentication as shown in Figure 350.
Note: The password as a hashed output on the link and plain text in a RADIUS Access-Request message.
Figure 350: CHAP Handshaking Overview Process
 
 
For PAP the client initiates the authentication as shown in Figure 351.
Note: The password is sent as plain text on the link and hashed in a RADIUS Access-Request message.
Figure 351: PAP Overview Process
 
Network-Layer Protocol Phase (PPP IPCP Opening Phase)
At this stage the user requests an IP address to be used for data transmission. During this negotiation the client will also receive a Domain Name Server (DNS), NBNS (Netbios Name Server) address, etc. if they are requested.
Figure 352: IPCP Phase Messages
 
Maintenance
PPP uses keepalives in order to maintain the integrity of the connection. This keepalive mechanism uses an echo-request that is sent to remote PPP peer, following which the remote PPP peer should respond with an echo-reply. The connection is considered down if x-numbers of echo-reply are missed. Both sides can initiate keepalives which run independently.
Figure 353: Keepalive Messages
 
Termination
 
Link Termination Phase
A PPPoE session can be terminated by either the client or by the BRAS and consists of a Terminate-request followed by a PADT.
Figure 354: Link Termination Phase
 
Configuration
 
PPPoE Host Session: Set-Up, Operation and Release
Enable PPPoE termination under the group-interface context.
Enable the local user database under the PPPoE node of the group-interface.
 
B:BSR-1# configure service vprn 1
subscriber-interface "sub-int-1" create
address 10.2.0.254/16
group-interface "group-int-1" create
sap 1/1/3:1 create
sub-sla-mgmt
sub-ident-policy "sub-id-default"
no shutdown
exit
exit
pppoe
user-db "ludb-1"
no shutdown
exit
exit
exit
no shutdown
 
 
The local user database is configured with the following parameters.
 
*A:BSR-1>config>subscr-mgmt# info
----------------------------------------------
local-user-db "ludb-1" create
pppoe
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap "KG35KPbV/9zoZpmco.h0nXFfa0QqZdsT" hash2
identification-strings 254 create
subscriber-id "PPPoE-host-user1@domain1"
sla-profile-string "sla-profile-1"
sub-profile-string "sub-profile-1"
exit
no shutdown
exit
 
 
 
A local DHCP server will be used as a source for the IP addressing of the PPPoE host.
*A:BSR-1>config>service>vprn# info
----------------------------------------------
dhcp
local-dhcp-server "server-1" create
use-gi-address
pool "pool-1" create
subnet 10.2.0.0/16 create
exclude-addresses 10.2.0.254 10.2.0.255
address-range 10.2.0.1 10.2.0.253
exit
exit
no shutdown
exit
exit
 
 
•
The PPPoE policy configuration.
 
 
A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" create
*A:BSR-1>config>subscr-mgmt>pppoe-policy$ info detail
----------------------------------------------
no description
no disable-cookies
keepalive 30 hold-up-multiplier 3
no pado-delay
no ppp-initial-delay
no ppp-mtu
max-sessions-per-mac 1
no reply-on-padt
ppp-authentication pref-chap
ppp-chap-challenge-length min 32 max 64
ppp-options
exit
 
The PPPoE policy defines the parameters which are used in the establishment of the PPPoE session such as:
•
Disable-cookies — This parameter disables the use of cookies.
•
Keepalive — This command defines the keepalive interval and the number of keepalives that can be missed before the session is declared down for this PPPoE policy.
→
[10 — 300] seconds: Specifies the keepalive interval in seconds.
→
hold-up-multiplier [1 — 5]: Specifies the number of keepalives that can be missed.
•
PADO-delay — This parameter configures the delay timeout before sending a PPPoE Active Discovery Offer (PADO) packet.
→
[1 — 30] deciseconds
•
PPP-mtu — This parameter configures the maximum PPP MTU size.
→
[512 — 9212]: possible values for MTU size.
•
Max-sessions-per-mac — This parameter sets the maximum PPPoE sessions that can be opened for the given MAC address.
→
[1 — 63]: possible PPPoE sessions per MAC address.
•
Reply-on-PADT — Some of the PPPoE clients expect reply on PPPoE Active Discovery Terminate (PADT) message before the context of the session is cleared up. To support such client, a command enabling reply to PADT is provided.
→
[Default] no reply-on-padt
•
PPP-options — This parameter enables the context to configure PPP options which is not supported by default
These parameters will be explained later in details according to its existence in which PPPoE phase.
Notes:
•
The default policy cannot be modified nor deleted.
•
Multiple PPPoE policies may be configured.
 
 
* The PPPoE policy is defined within the PPPoE context under the group interface.
*A:BSR-1>config>service>vprn# info
----------------------------------------------
---snip---
subscriber-interface "sub-int-1" create
address 10.2.0.254/16
group-interface "group-int-1" create
--snip---
pppoe
pppoe-policy "pppoe-policy-1"
---snip---
 
Troubleshooting the PPPoE discovery messages (PADI, PADO, PADR, PADS and PADT) is done with PPPoE debugging:
*A:BSR-1# debug service id 1 pppoe packet discovery ?
- discovery [padi] [pado] [padr] [pads] [padt]
- no discovery
 
<padi> : keyword - debug PADI packets
<pado> : keyword - debug PADO packets
<padr> : keyword - debug PADR packets
<pads> : keyword - debug PADS packets
<padt> : keyword - debug PADT packets
 
 
 
For example:
*A:BSR-1# show debug
debug
service
id 1
pppoe
packet
mode egr-ingr-and-dropped
detail-level medium
discovery
ppp
dhcp-client
exit
To display the debugging information, a dedicated log should be created:
*A:BSR-1# configure log
log-id 1
from debug-trace
to session
exit
 
Discovery Stage
The following is an example of PPPoE (PADI discovery packet) debug log output:
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:14:01:02
Ether Type: 0x8863 (Discovery)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x09 (PADI) Session-Id: 0x0000 (0)
Length : 65
PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0103] Host-Uniq: len = 4, value = 00 14 00 00
[0x0105] Vendor-Specific: vendor-id = 0x0de9 (ADSL Forum)
[0x01] Agent-Circuit-Id: "circuit10"
[0x02] Agent-Remote-Id: "remote10"
[0x81] Actual-Upstream: 64
[0x82] Actual-Downstream: 64
[0x90] Access-Loop-Encap: 01 01 00
 
 
 
PPPoE Policy Parameters
Service name — The client can ask a particular service. Empty means that any service is acceptable. The service name can indicate an ISP name, class, QoS.
 
PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
 
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:14:01:02
Ether Type: 0x8863 (Discovery)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x09 (PADI) Session-Id: 0x0000 (0)
Length : 65
 
PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
 
 
 
 
The BSR echoes the service name from the PADI message. Empty means that any service is acceptable.
112 2010/01/07 17:29:32.07 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
 
DMAC: 00:00:67:14:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8863 (Discovery)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x07 (PADO) Session-Id: 0x0000 (0)
Length : 48
 
PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
 
Host-Uniq — The host can include a unique tag of any length inserted In PADI or PADR.The AC should echo back this tag in the PADO or PADS.
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
 
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:14:01:02
Ether Type: 0x8863 (Discovery)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x09 (PADI) Session-Id: 0x0000 (0)
Length : 65
PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0103] Host-Uniq: len = 4, value = 00 14 00 00
 
The following parameters can optionally be added to the PADI by the PPPoE intermediate agent (BSAN):
Vendor-specific information
•
Agent-Circuit-Id
•
Agent-Remote-Id
•
Access-loop-Encapsulation
•
Access loop characteristics (actual-upstream, actual-downstream)
 
 
The debug output:
111 2010/01/07 17:29:32.07 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:14:01:02
Ether Type: 0x8863 (Discovery)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x09 (PADI) Session-Id: 0x0000 (0)
Length : 53
 
PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0103] Host-Uniq: len = 4, value = 00 14 00 00
[0x0105] Vendor-Specific: vendor-id = 0x0de9 (ADSL Forum)
[0x01] Agent-Circuit-Id: "circuit10"
[0x02] Agent-Remote-Id: "remote10"
[0x81] Actual-Upstream: 64
[0x82] Actual-Downstream: 64
[0x90] Access-Loop-Encap: 01 01 00
 
The cookies can be displayed in the PADO message. This tag of any value and length may be included by the AC and is echoed back by the client to the AC in the next PADR .
112 2010/01/07 17:29:32.07 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
 
DMAC: 00:00:67:14:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8863 (Discovery)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x07 (PADO) Session-Id: 0x0000 (0)
Length : 48
 
PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0102] AC-Name: "BSR-1"
[0x0103] Host-Uniq: len = 4, value = 00 14 00 00
[0x0104] AC-Cookie: len = 16, value = d7 91 cd b7 3e 51 76 d6 03 0a f2 68 8c
da ba 74
 
 
•
AC-name — Identifies the string that uniquely identifies the access concentrator (AC).
112 2010/01/07 17:29:32.07 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
 
DMAC: 00:00:67:14:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8863 (Discovery)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x07 (PADO) Session-Id: 0x0000 (0)
Length : 48
 
PPPoE Tags:
[0x0101] Service-Name: "AGILENT"
[0x0102] AC-Name: "BSR-1"
 
When disable-cookies is configured, the use of cookies will be disabled, when omitted the no-disable-cookies will be used.
*A:BSR-1>config>subscr-mgmt>pppoe-policy# info
----------------------------------------------
disable-cookies
 
The cookies are encoded back by the client in the next PADR message.
PPPoE hosts are authenticated based on username-password information (PAP/CHAP authentication) or on information embedded in the PADI message PADI authentication). 
 
ppp-chap-challenge length
 
The min and max values for the ppp-chap-challenge are defined when enabling ppp-chap-challenge length. When omitted, a min of 32 and max of 64 are used.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" ppp-chap-challenge-length ?
- ppp-chap-challenge-length min <minimum-length> max <maximum-length>
- no ppp-chap-challenge-length
<minimum-length> : [8..64]
<maximum-length> : [8..64]
 
Local User Database Authentication
With this authentication method, the client’s PPPoE session is authenticated locally on the BRAS without any constraint of an external radius server.
The local user database is configured with the following parameters.
*A:BSR-1>config>subscr-mgmt# info
----------------------------------------------
local-user-db "ludb-1" create
pppoe
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap "KG35KPbV/9zoZpmco.h0nXFfa0QqZdsT" hash2
identification-strings 254 create
subscriber-id "PPPoE-host-user1@domain1"
sla-profile-string "sla-profile-1"
sub-profile-string "sub-profile-1"
exit
no shutdown
exit
 
Example: PADI authentication through LUDB.
 
*A:BSR-1# configure subscriber-mgmt local-user-db "ludb-1" pppoe match-list ?
- no match-list
- match-list <pppoe-match-type-1> [<pppoe-match-type-2>...(up to 3 max)]
 
<pppoe-match-type> : circuit-id|mac|remote-id|service-name|username
 
To complete the discovery phase, the server must provide a session-id to the client and we allocate always session-id 1 for different MACs.
Note: in VLAN per service model (N: 1 VLAN) where the MACs are the same and the PPPoE interworking will be done at the BSAN.
 
*A:BSR-1# show service id 1 pppoe session
===============================================================================
PPPoE sessions for svc-id 1
===============================================================================
Sap Id Mac Address Sid Up Time IP/L2TP-Id Type
-------------------------------------------------------------------------------
1/1/3:1 00:00:67:14:01:02 1 0d 23:05:40 10.2.0.46 Local
-------------------------------------------------------------------------------
Number of sessions : 1
 
The 7750 has the possibility to delay the sending of the PADO message to the client. This feature could be used if the client is dual homed to 2 BSRs痴 and is explained later in the document.
When PADO-delay is configured, the configured value equals the delay timeout before sending PADO, when omitted the PADO-delay value of 0 msec will be used.
 
*A:BSR-1>config>subscr-mgmt>pppoe-policy# pado-delay ?
- no pado-delay
- pado-delay <deci-seconds>
 
<deci-seconds> : [1..30]
 
Session Stage
 
lcp
During the link establishment phase client and server negotiate options and need to come to an agreement on these options. Options that are unknown by the peer are rejected whereas known options with unknown content are nack’d. In the later case the peer needs to resend the same option but with another content. In case of a reject the peer should remove that option. An Ack will be send if there is a full agreement.
One of the more important options that is exchanged is the maximum receive unit (MRU) and the authentication protocol that will be used later in the authentication phase. The first option, the MRU value (minus overhead) is sent from the BSR towards the client and is the lowest value between the port MTU and the optional configured ppp-mtu in the ppp-policy.
RFC 2516 mandates a maximum negotiated Maximum Receive Unit (MRU) of 1492 but RFC 4638 relaxes this restriction and allows a maximum negotiated MRU greater than 1492 to minimize fragmentation in next-generation broadband networks. The 7750 SR and 7710 SR implementation follows RFC 4638 when the client implements these extensions.
If a PPPoE client wants to use MRU>1492 in the LCP-config request it should include the ppp-max-payload tag with the higher MTU value in the initial PADI message.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" ppp-mtu ?
- no ppp-mtu
- ppp-mtu <mtu-bytes>
 
<mtu-bytes> : [512..9212]
 
PPPoE debug output.
134 2010/01/07 21:04:10.30 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
 
DMAC: 00:00:67:13:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8864 (Session)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x00 Session-Id: 0x0001 (1)
Length : 21
 
PPP:
Protocol : 0xc021 (LCP)
Code : 1 (Configure-Request)
Identifier: 5 Length : 19
 
Options:
[1] MRU: 1492
---snip--
The second important option, the authentication method used in the authentication phase is exchanged between client and server and can be PAP or CHAP authentication. The authentication method is not exchanged when PADI authentication is done. PADI authentication means that the BSR will authenticate the user based on parameters in the PADI message. Authentication based on PADI and PAP/CHAP is possible.
Debug output example for CHAP authentication protocol.
137 2010/01/07 21:04:10.30 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
 
DMAC: 00:03:fa:90:f8:6a
SMAC: 00:00:67:13:01:02
Ether Type: 0x8864 (Session)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x00 Session-Id: 0x0001 (1)
Length : 21
 
PPP:
Protocol : 0xc021 (LCP)
Code : 2 (Configure-Ack)
Identifier: 5 Length : 19
 
Options:
[3] Authentication-Protocol: 0xc223 (CHAP), Algorithm = 5 (MD5)
[5] Magic-Number: 0x60363318
 
Debug output example for PAP authentication protocol.
46 2010/01/13 10:59:45.71 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/3:1
 
DMAC: 00:03:fa:90:f8:6a
SMAC: 00:00:67:13:01:02
Ether Type: 0x8864 (Session)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0x00 Session-Id: 0x0001 (1)
Length : 20
 
PPP:
Protocol : 0xc021 (LCP)
Code : 2 (Configure-Ack)
Identifier: 160 Length : 18
 
Options:
[1] MRU: 1492
[3] Authentication-Protocol: 0xc023 (PAP)
[5] Magic-Number: 0x37df4db2
"
 
•
Fallback case chap->pap
For user authentication, with pap-chap-access, always try CHAP first; if that doesn't succeed, try PAP.
The option to be used first (CHAP/PAP) is defined when enabling the ppp-authentication. When omitted, CHAP is preferred always.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" ppp-authentication ?
- no ppp-authentication
- ppp-authentication {pap|chap|pref-chap}
 
<pap|chap|pref-chap> : keywords
 
PPPoE clients that implement undocumented options also require an agreement on those unknown options. By default, the 7750 SR will reject unknown options but the ppp-option feature in the pppoe-policy allows for support of undocumented client LCP or IPCP options. If the received LCP or IPCP option matches the configured options in the pppoe-policy an ack will be send instead of a reject.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" ppp-options custom-option ?
- custom-option <protocol> <option-number> address <ip-address>
- custom-option <protocol> <option-number> hex <hex-string>
- custom-option <protocol> <option-number> string <ascii-string>
- no custom-option <protocol> <option-number>
 
<protocol> : lcp|ipcp
<option-number> : [0..255]
<ip-address> : a.b.c.d
<ascii-string> : [127 chars max]
<hex-string> : [0x0..0xFFFFFF...(max 254 hex nibbles)]
 
 
 
Troubleshooting the PPPoE LCP session messages is done with PPPoE debugging:
*A:BSR-1>debug>service>id>pppoe>packet# ppp ?
- no ppp
- ppp [lcp] [pap] [chap] [ipcp]
 
<lcp> : keyword - debug LCP packets
<pap> : keyword - debug PAP packets
<chap> : keyword - debug CHAP packets
<ipcp> : keyword - debug IPCP packets
 
 
•
Authentication
The 7750/7710 BSR supports three main methods for PPPoE authentication.
•
PADI or PAP/CHAP authentication through RADIUS
•
PADI or PAP/CHAP authentication through a LUDB
•
PADI authentication via LUDB then PAP/CHAP pre-authentication through RADIUS
DHCP server authentication will not be explained in this section because this is more authorization than authentication
The flow chart of the PPPoE host authentication process is shown in Figure 355.
Figure 355: Authentication Flow Chart
•
PPPoE users get authenticated via the LUDB if this LUDB is configured under the group-interface.
*A:BSR-1>config>service>vprn>sub-if>grp-if>pppoe# info
----------------------------------------------
user-db "ludb-1"
 
 
•
Users get authenticated via RADIUS if we have an authentication-policy under the same group-interface. RADIUS has precedence if both are configured.
 
*A:BSR-1>config>service>vprn>sub-if>grp-if# info
----------------------------------------------
authentication-policy "auth-1"
pppoe
user-db "ludb-1"
exit
 
•
Users that get authenticated via the LUDB can still go to RADIUS if we move the authentication-policy from the group-interface to the LUDB.
A:BSR-1>config>subscr-mgmt>loc-user-db>pppoe>host# info
----------------------------------------------
---snip---
auth-policy "auth-1"
no shutdown
 
This last mechanism is called pre-authentication and could be used to pick up parameters like pado-delay or checking some variables such as circuit-id, remote-id from the LUDB during discovery phase but use RADIUS for PAP/CHAP authentication.
*A:BSR-1>config>subscr-mgmt>loc-user-db>pppoe>host# host-identification ?
[no] circuit-id - Configure the circuit id of this host
[no] mac - Configure the MAC address of this host
[no] remote-id - Configure the remote id of this host
[no] service-name - Configure the service name of this host
[no] username - Configure the user name of this host
 
 
•
Both RADIUS and LUDB support PADI or PAP/CHAP authentication.
•
PPPoE users that are authenticated through the LUDB and have in the LUDB a match-list other than username will get authenticated based on PADI parameters like mac, circuit-id, remote-id.
*A:BSR-1>config>subscr-mgmt>loc-user-db>pppoe# match-list ?
- no match-list
- match-list <pppoe-match-type-1> [<pppoe-match-type-2>...(up to 3 max)]
 
<pppoe-match-type> : circuit-id|mac|remote-id|service-name|username
 
 
•
PPPoE users that have in the LUDB a match-list equal to username will use the PAP/CHAP authentication method.
*A:BSR-1>config>subscr-mgmt# info
----------------------------------------------
local-user-db "ludb-1" create
pppoe
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap "KG35KPbV/9zoZpmco.h0nXFfa0QqZdsT" hash2
---snip---
 
 
•
PPPoE users that are authenticated through RADIUS and have in the authentication policy, a pppoe-access-method equal to PADI will use the mac or circuit-id information from the PADI in their request to RADIUS.
 
*A:BSR-1>config>subscr-mgmt>auth-plcy$ pppoe-access-method ?
- pppoe-access-method {none|padi|pap-chap}
- no pppoe-access-method
 
•
The selection for mac or circuit-id can be altered via the parameter user-name-format.
 
*A:BSR-1>config>subscr-mgmt>auth-plcy$ user-name-format ?
- user-name-format <format> [append domain-name]
- no user-name-format
 
<format> : mac|circuit-id|tuple|ascii-converted-circuit-id|
ascii-converted-tuple
 
 
PPPoE users that are authenticated through RADIUS and have in the authentication policy a pppoe-access-method equal to pap-chap use the username from the authentication phase in their request to RADIUS. The parameter user-name-format is irrelevant in this last case.
 
RADIUS Authentication
When authentication is provided through RADIUS, two methods can be used to authenticate the PPPoE session.
•
PADI authentication
•
PAP/CHAP authentication
The RADIUS policy specifies what parameters are provided in the RADIUS access-request message.
The following parameters can be configured:
•
Circuit-id: Provided through the PADI/PADR PPPoE relay vendor specific tag as specified in TR-101 of the DSL Forum.
•
Remote-id: Provided through the PADI/PADR PPPoE relay vendor specific tag as specified in TR-101 of the DSL Forum.
•
NAS-port-id: SAP ID on which the PPPoE session terminates (e.g. 1/1/3:1).
•
NAS-identifier: System name of the NAS or BNG.
•
PPPoE-service-name: Provided through the PPPoE PADI packet.
•
access-loop-options: Provided through the PAD/PADR PPPoE extensions as specified in TR-101 of the DSL Forum.
The option to use PADI authentication or PAP/CHAP authentication is selected with the following configuration in the RADIUS policy:
*A:BSR>config>subscr-mgmt>auth-plcy# pppoe-access-method ?
- pppoe-access-method {none|padi|pap-chap}
- no pppoe-access-method
 
When PADI authentication is used for PPPoE termination the MAC address or the PPPoE relay tag (Circuit-ID) or a combination of MAC address and circuit ID can be used to identify the subscriber in the RADIUS server.
To determine the iinformation to use in the RADIUS Access-Request message is configured in the RADIUS policy using the following command:
*A:BSR >config>subscr-mgmt>auth-plcy# user-name-format ?
- user-name-format <format>
- no user-name-format
 
<format> : mac|circuit-id|tuple|ascii-converted-circuit-id|ascii-converted-tuple
 
 
Local User Database Authentication
A second authentication option for PPPoE termination is to use the local user database of the BSR 7750/ 7710 for PAP/CHAP authentication (this option will be used in this note). With this authentication method the client’s PPPoE session is authenticated locally on the BSR without any constraint of an external radius server.
The local user database is configured with the following parameters:
*A:BSR-1>config>subscr-mgmt# info
----------------------------------------------
local-user-db "ludb-1" create
pppoe
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap "KG35KPbV/9zoZpmco.h0nXFfa0QqZdsT" hash2
identification-strings 254 create
subscriber-id "PPPoE-host-user1@domain1"
sla-profile-string "sla-profile-1"
sub-profile-string "sub-profile-1"
exit
no shutdown
 
 
With this authentication method, authentication can be provided by the username/password.
To enable the local authentication method, the local user database is configured under the PPPoE node of the group-interface as shown below.
*A:BSR-1>config>service>vprn>sub-if>grp-if# info
----------------------------------------------
---snip---
pppoe
---snip--
user-db "ludb-1"
no shutdown
 
To check LUDB parameters for the PPPoE hosts.
*A:BSR-1# show subscriber-mgmt local-user-db ludb-1 pppoe-host user1
===============================================================================
PPPoE Host "user1"
===============================================================================
Admin State : Up
---snip---
User Name : user1@domain1
 
Matched Objects : userName
 
Address              : pool "pool-1"
Password Type        : CHAP
---snip---
Identification Strings (option 254)   
 Subscriber Id       : PPPoE-host-user1@domain1
 SLA Profile String  : sla-profile-1  
 Sub Profile String  : sub-profile-1  
---snip--
 
To debug the LUDB.
*A:BSR-1# debug subscriber-mgmt local-user-db "ludb-1" detail
- detail {all|failed}
- no detail
 
DHCP Client Authentication
A third authentication method for PPPoE termination is to perform PPPoE to DHCP transformation (where the 7750 SR acts as a DHCP client on behalf of the PPP session) and to use a DHCP server for session authentication. This method is useful when a similar authentication is used for DHCP based clients.
The PPPoE to DHCP authentication method can provide authentication on the basis of MAC address, circuit ID or remote ID.
•
ipcp
IP and DNS information can be obtained from different sources like LUDB and RADIUS for fixed IP addressing or (local) DHCP for dynamic ip-pool management.
DNS and IP-addressing should come from the same source and are ipcp rejected if they are not .
If IP information is returned from a DHCP server. PPPoE options such as the DNS name are retrieved from the DHCP ACK and provided to the PPPoE client.
 
Local DHCP Server
In this note, a local DHCP server will be used as a source for the IP addressing of the PPPoE host.
*A:BSR-1>config>service>vprn# info
----------------------------------------------
dhcp
local-dhcp-server "server-1" create
use-gi-address
pool "pool-1" create
subnet 10.2.0.0/16 create
exclude-addresses 10.2.0.254 10.2.0.255
address-range 10.2.0.1 10.2.0.253 
                        exit
                    exit
                    no shutdown
                exit
 
To check the DHCP server summary:
*A:BSR-1# show router 1 dhcp local-dhcp-server server-1 summary
===============================================================================
DHCP server server-1 router 1
===============================================================================
Admin State : inService
Operational State : inService
---snip---
-------------------------------------------------------------------------------
Pool name : pool-1
-------------------------------------------------------------------------------
Subnet Free Stable Declined Offered Rem-pend
-------------------------------------------------------------------------------
10.2.0.0/16 252 1 0 0 0
Totals for pool 252 1 0 0 0
-------------------------------------------------------------------------------
Totals for server 252 1 0 0 0
-------------------------------------------------------------------------------
Associations Admin
-------------------------------------------------------------------------------
local-dhcp-server-1 Up
===============================================================================
*A:BSR-1#
 
To debug the DHCP server:
*A:BSR-1# show debug
debug
router "1"
ip
dhcp
detail-level medium
mode egr-ingr-and-dropped
exit
 
•
Keepalive
The keepalive timer (defined in seconds) and the hold-up-multiplier are defined when enabling keepalives. When omitted, a 30 sec keepalvie timer and 3 hold-up-multipliers are used.
*A:BSR-1# configure subscriber-mgmt pppoe-policy "pppoe-policy-1" keepalive ?
- keepalive <seconds> [hold-up-multiplier <multiplier>]
- no keepalive
<seconds> : [10..300]
<multiplier> : [1..5]
 
[10-300] seconds: interval between LCP Echo Requests
hold-up-multiplier [1-5] : Number of missed replies before the PPPoE session is considered dead.
 
To check the keepalive statistics:
*A:BSR-1# show service id 1 pppoe session session-id 1 mac 00:00:67:14:01:02 statistics
===============================================================================
PPPoE sessions for svc-id 1
===============================================================================
Sap Id Mac Address Sid Up Time IP/L2TP-Id Type
-------------------------------------------------------------------------------
1/1/3:1 00:00:67:14:01:02 1 0d 04:31:37 10.2.0.37 Local
Packet Type Received Transmitted
-------------------------------------------------------------------------------
--snip--
LCP Echo-Request 543 1086
LCP Echo-Reply 1086 543
 
The 7750/7710 BSR supports an optimised implementation of keepalive mechanism; this is a mechanism where client and/or server can check the aliveness of the peer. This LCP echo-request is sent on expiration of a timer, derived from the configured pppoe-policy keepalive value.
An LCP echo reply is returned to the client after a LCP echo request is received and the above timer on the BSR is reset to the initial keepalive value.
The above mechanism results in an optimised mechanism if the keepalive timers from the client are smaller than the configured values on the BSR.
The client or BSR will terminate the session with a PADT if no LCP echo-reply is received within the time specified by the hold-up-multiplier.
Example for Echo Request from BSR and Echo Reply from the PPPoE host.
Ethernet II, Src: TimetraN_90:f8:6a (00:03:fa:90:f8:6a), Dst: Soft*Rit_14:01:02 (00:00:67:14:01:02)
802.1Q Virtual LAN, PRI: 5, CFI: 0, ID: 1
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
Code: Echo Request (0x09)
Identifier: 0x01
Length: 8
Magic number: 0x2e538af6
 
No. Time Source Destination Protocol Info
4 30.000280 TimetraN_90:f8:6a Soft*Rit_14:01:02 PPP LCP Echo Reply
 
Ethernet II, Src: TimetraN_90:f8:6a (00:03:fa:90:f8:6a), Dst: Soft*Rit_14:01:02 (00:00:67:14:01:02)
802.1Q Virtual LAN, PRI: 5, CFI: 0, ID: 1
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
Code: Echo Reply (0x0a)
Identifier: 0x0b
Length: 8
Magic number: 0x2e538af6
 
To check the PPPoE session for a particular service, use the show service id <service-id> pppoe session command. Detailed output as well as additional output filtering is available:
*A:BSR-1# show service id 1 pppoe session ?
- session [interface <ip-int-name|ip-address> | sap <sap-id>] [type
<pppoe-session-type>] [session-id <session-id>] [mac <ieee-address>]
[ip-address <ip-address[/mask]>] [port <port-id>] [no-inter-dest-id |
inter-dest-id <intermediate-destination-id>] [detail|statistics]
 
*A:BSR-1# show service id 1 pppoe session detail
===============================================================================
PPPoE sessions for svc-id 1
===============================================================================
Sap Id Mac Address Sid Up Time IP/L2TP-Id Type
-------------------------------------------------------------------------------
1/1/3:1 00:00:67:14:01:02 1 0d 04:34:44 10.2.0.37 Local
LCP State : Opened
IPCP State : Opened
PPP MTU : 1492
PPP Auth-Protocol : CHAP
PPP User-Name : user2@domain1
Subscriber-interface : sub-int-1
Group-interface : group-int-1
Subscriber Origin : Local-User-Db
Strings Origin : Local-User-Db
IPCP Info Origin : DHCP
Subscriber : "PPPoE-host-user2@domain1"
Sub-Profile-String : "sub-profile-1"
SLA-Profile-String : "sla-profile-1"
ANCP-String : ""
Int-Dest-Id : ""
App-Profile-String : ""
Category-Map-Name : ""
Primary DNS : N/A
Secondary DNS : N/A
Primary NBNS : N/A
Secondary NBNS : N/A
Address-Pool : "pool-1"
Circuit-Id : circuit10
Remote-Id : remote10
Service-Name : AGILENT
Session-Timeout : N/A
Radius Class :
Radius User-Name :
-------------------------------------------------------------------------------
Number of sessions : 1
 
 
 
An event will be generated when a PPPoE host has been created in the system.
424 2010/01/07 15:28:37.64 UTC WARNING: SVCMGR #2500 Base Subscriber created
"Subscriber PPPoE-host-user1@domain1 has been created in the system"
 
The PPPoE host will appear in the subscriber-host table for the service with origin set to PPPoE.
B:BSR-1# show service id 1 subscriber-hosts
===============================================================================
Subscriber Host table
===============================================================================
Sap IP Address MAC Address PPPoE-SID Origin
Subscriber Fwding state
-------------------------------------------------------------------------------
1/1/3:1 10.2.0.52 00:00:64:02:01:02 1 PPPoE
PPPoE-host-user1@do* Fwding
-------------------------------------------------------------------------------
Number of subscriber hosts : 1
A host route (/32) for its IP address is inserted in the routing table towards the appropriate group-interface.
*A:BSR-1# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.2.0.0/16 Local Local 03d06h17m 0
sub-int-1 0
10.2.0.37/32 Remote Sub Mgmt 04h35m43s 0
[group-int-1] 0
13.13.13.0/24 Remote BGP VPN 01d22h40m 170
192.0.2.3 0
172.16.0.1/32 Local Local 11d00h19m 0
local-dhcp-server-1 0
-------------------------------------------------------------------------------
No. of Routes: 4
===============================================================================
*A:BSR-1# 
 
 
 
 
To advertise the PPPoE host subnets to other protocol/network, a policy statement should be defined with using from protocol direct.
*A:BSR-1>config>router>policy-options# info
----------------------------------------------
policy-statement "policy-1"
entry 10
from
protocol direct
---snip---
 
•
Terminate
Some of the PPPoE clients expect reply on PADT message before the context of the session is cleared up. To support such client, a command enabling reply to PADT is configured.
When reply-on-padt is configured, the BSR will reply with PADT message, when omitted no PADT will be sent from the BSR as a reply on the client’s PADT.
*A:BSR-1#configure subscriber-mgmt pppoe-policy "pppoe-policy-1"
reply-on-padt
 
The pppoe debug output:
77 2010/01/07 20:31:50.32 UTC MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/3:1
 
DMAC: 00:00:67:13:01:02
SMAC: 00:03:fa:90:f8:6a
Ether Type: 0x8863 (Discovery)
 
PPPoE Header:
Version: 1 Type : 1
Code : 0xa7 (PADT) Session-Id: 0x0001 (1)
Lengt
 
A PPPoE host can be manually deleted from the system using following clear command:
*A:BSR-1# clear service id 1 pppoe session
- session all [no-padt]
- session interface <ip-int-name|ip-address> [mac <ieee-address> [session-id
<session-id>]] [type <pppoe-session-type>][ip-address <ip-address[/mask]>]
[port <port-id>] [no-inter-dest-id | inter-dest-id
<intermediate-destination-id>] [no-padt]
- session sap-id <sap-id> [mac <ieee-address> [session-id <session-id>]]
[type <pppoe-session-type>] [ip-address <ip-address[/mask]>] [port
<port-id>] [no-inter-dest-id | inter-dest-id
<intermediate-destination-id>] [no-padt]
*A:BSR-1# clear service id 1 pppoe session sap-id 1/1/3:1 mac 00:00:67:14:01:02
 
Several examples are displayed:
•
Admin Reset — Use the clear command or a RADIUS Disconnect Request.
TERMINATE CAUSE [49] 4 Admin Reset(6)
 
•
User Request — User disconnects the session.
TERMINATE CAUSE [49] 4 User Request(1)
 
•
Accounting OFF
→
When accounting policy has been removed from sap/interface/sub-profile.
→
vprn service which is transporting accounting information has been shutdown.
→
The last RADIUS accounting server has been removed from already applied accounting policy.
TERMINATE CAUSE [49] 4 NAS Request(10)
 
•
PPPoE keepalive timeout
TERMINATE CAUSE [49] 4 Lost Carrier(2)
 
•
RADIUS session timeout
 
PPPoE Hosts Advanced Topics
 
QoS Aspects
VLAN based downstream PPPoE control traffic is generated by default with dot1p value 7 .This value can be overruled with the following commands:
In case of the PPPoE hosts instantiated in the Base routing instance using an IES service.
*B:BSR-1#configure router sgt-qos application pppoe dot1p 5 [0..7]
 
In case of the PPPoE hosts instantiated in a VPRN service subscriber-interface.
*B:BSR-1#configure service vprn 1 sgt-qos application pppoe dot1p 5 [0..7]
 
The show router sgt-qos command displays the configured and default DSCP and default dot1p values per application. Since PPPoE is a Layer 2 protocol we will see only the dot1p settings. The default dot1p value none corresponds with value 7.
 
*A:BSR-1# show router 1 sgt-qos application pppoe
===============================================================================
Dot1p Application Values
===============================================================================
Application Dot1p Value Default Dot1p Value
-------------------------------------------------------------------------------
pppoe 7 none
====================================================================
*A:BSR-1#
 
Limiting the Number of PPPoE Hosts
The maximum number of PPPoE sessions can be controlled by the parameters session-limit, sap-session-limit, host-limit, multi-sub-sap limit and max-sessions-per mac.
session-limit — The maximum number of PPPoE sessions for an IES/VPRN group-interface is defined when enabling session-limit. When omitted, a single PPPoE session is allowed.
B:BSR-1> configure service vprn 1
---snip--
group-interface group-int-1
pppoe
session-limit 1
exit
A trap is generated when trying to instantiate a new pppoe session while the configured number of sessions is reached. Note that the discovery phase is completed before the check on the session-limit is performed.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - Reached the interface session limit (1) for "group-int-1""
 
PPPoE debug output:
"PPPoE: Dropped Packet
VPRN 1, SAP 1/1/3:1
 
Problem: Reached the interface session limit (1) for "group-int-1"sap-session-limit :
The maximum number of pppoe sessions per SAP for an IES/VPRN group-interface is defined when enabling sap-session-limit. When omitted, a single pppoe session per SAP is allowed:
B:BSR-1> configure service vprn 1
---snip--
group-interface group-int-1
pppoe
sap-session-limit 1
exit
A trap is generated when trying to instantiate a new PPPoE session while the configured number of the sessions per sap is reached.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - Reached the per-SAP session limit (1) for "group-int-1""
 
 
PPPoE debug output:
"PPPoE: Dropped Packet
VPRN 1, SAP 1/1/3:1
 
Problem: Reached the per-SAP session limit (1) for "group-int-1"
 
•
max-sessions-per-mac
The BSR 7750/7710 implementation defines a unique PPPoE session based on the PPPoE SESSION_ID and the client’s MAC address.
The maximum number of PPPoE sessions per mac is defined when enabling max-sessions-per-mac. When omitted, a single PPPoE session per mac is allowed.
*B:BSR-1> configure
subscriber-mgmt
pppoe-policy "pppoe-policy-1"
max-sessions-per-mac 63
exit
 
Although the command is max-session-per-mac, actually it means the maximum number of supported sessions-per-MAC-per-SAP especially in N: 1 VLAN model.
A trap is generated when trying to instantiate a new PPPoE session per the same mac while the configured number of max-sessions-per-mac is reached.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - Reached the maximum number (1) of PPPoE sessions for MAC 00:00:67:13:01:02"
•
Host-limit
The maximum number of PPPoE hosts is defined when enabling host-limit. When omitted, a single host is allowed.
*B:BSR-1> configure
subscr-mgmt
sla-profile "sla-profile-1"
host-limit 10
exit
exit
 
If the configured host-limit is reached for a subscriber, access is denied for a new host, and an event is generated.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - subscriber PPPoE-host-user1@domain1 sla-profile sla-profile-1, host-limit (1) exceeded"
 
Note: An optional parameter remove-oldestcan be specified behind the host-limit. In this case the new host is accepted and the old one will be removed.
 
B:BSR-1> configure
subscr-mgmt
sla-profile "sla-profile-1"
host-limit 10 remove-oldest
exit
exit
 
•
multi-sub-sap
This parameter defines the maximum number of subscribers (dynamic and static) that can be simultaneously active on this SAP.
When omitted, a single PPPoE session per sap is allowed (no multi-sub-sap).
*B:BSR-1> configure service vprn 1
---snip---
group-interface "group-int-1" create
sap 1/1/3:1 create
sub-sla-mgmt
multi-sub-sap 100
exit
 
A trap is generated when trying to instantiate a new PPPoE session while the configured number of the multi-sub-sap is reached.
"PPPoE session failure on SAP 1/1/3:1 in service 1 - Number of subscribers exceeds the configured multi-sub-sap limit (1)"
 
Redundancy
Redundancy for PPPoE sessions can be used for load balancing the sessions between the 2 BSRs. PADO-delays (which can come from RADIUS, LUDB, and policy) is using to achieve that.
The redundant BSRs need different IP subnets, and upon failure the PPP sessions will need to be re-established.
Because PADI messages are broadcast on a multi-access network, all BSRs on that network will reply with a PADO to the initiator.
The PADR and PADS are sent in unicast to the MAC address from the first received PADO message.
In order to allow control over the NAS/BSR selection for a given PPPoE session the 7750 and 7710 offer the ability to delay the PADO message. Due to the fact that PPPoE clients select the NAS/BSR for further communication based on the first PADO message that arrives, this functionality provides control over the NAS/BSR who gets selected for a given PPPoE session.
On top if for some reason a NAS/BSR, without PADO delay configured in the PPPoE policy, does not reply on PADI messages to the client another NAS/BSR with a PADO delay configured will reply based on the time configured and ultimately the PPPoE session will be established with the PADO delayed NAS/BSR.
Figure 356: Pado-Delay Scenario
 
 
To check the pado-delay value.
*A:BSR-1# show subscriber-mgmt pppoe-policy pppoe-policy-1 
===============================================================================
PPPoE Policy "pppoe-policy-1"
===============================================================================
Description          : (Not Specified)
Last Mgmt Change     : 01/11/2010 11:21:01     PPP-mtu              : N/A
Keepalive Interval   : 10s                     Keepalive Multiplier : 1
Disable AC-Cookies   : No                      PADO Delay           : 3000msec 
Max Sessions-Per-Mac : 63                      Reply-On-PADT        : No
PPP-Authentication   : pref-CHAP               PPP-CHAP Challenge   : 32 - 64
---snip---
 
High Availability
The PPPoE session state is HA: the session state is synchronised to the standby CPM. When the active CPM fails, all PPPoE hosts stay active without service interruption.
 
Conclusion
This section provides configuration and troubleshooting commands for PPPoE hosts in a Layer 3 Routed CO (IES/VPRN subscriber interface) context.