ESMv4: PPPoE Hosts
This chapter describes advanced IPv4 Enhanced Subscriber Management (ESM) PPPoE host configurations.
Topics in this chapter include:
Applicability
This chapter applies to SR OS routers and was written for Release 8.0.R4. The CLI is updated to Release 15.0.R2.
This chapter describes support of PPP termination and aggregation (PTA) hosts. L2TP-hosts are out of the scope of this chapter. Only IPv4 PPPoE hosts are handled in this chapter.
PPPoE hosts are only supported in a Routed CO model (IES or VPRN) using Ethernet SAPs with null, dot1q, or QinQ encapsulation.
Overview
The delivery of services to residential customers encompassing voice, video, and data is covered by 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 chapter 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 chapter is retrieved from a Local DHCP server.
The authentication, IP information, and ESM strings can come all from an LUDB, a RADIUS server, a (local) DHCP server, or any combination of them. These combinations are out of the scope of this chapter.
Knowledge of the TPSDA concept is assumed throughout this document.
PPPoE hosts in a routed CO environment
The network topology for a Routed CO environment is displayed in Routed CO network topology.
The following configuration tasks should already be configured and are not detailed or explained in this chapter. See 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
Local User Data Base (LUDB)
Local Dynamic Host Configuration Protocol (DHCP) server
In the Routed CO model, PPPoE hosts can be instantiated in routed services, such as the base router, IES, and VPRN. The configuration section of this chapter focuses on PPPoE hosts instantiated in a VPRN servicelocated in BSR-1 (Routed CO).
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 in 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 datagrams over point-to-point links.
PPP has 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:
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.
Additional attributes on the PADI message could be added if a BSAN is situated between the client and the BRAS.
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.
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.
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.
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 Reserved PPPoE tags. All other tag values between 0 and 65535 are to be assigned by IANA.
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 debug messages:
(0x0101) Service-Name — 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-Name — 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.
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
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.
The 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 SR OS 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 sent & received.
The own options are proposed in configure request.
There are three cases for the LCP negations parameters:
Peer supports the option and its 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 its new content.
Resend of configure-request with same options but new content.
Peer agrees and sends config-ack.
Table 2. 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 3. 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 CHAP handshaking overview process. The password is hashed on the link and plain text in the RADIUS Access-Request message.
For PAP, the client initiates the authentication as shown in PAP overview process. The password is sent as plain text on the link and hashed in a RADIUS Access-Request message.
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.
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 a number of echo replies are missed. Both sides can initiate keepalives which run independently.
Termination
Link termination phase
A PPPoE session can be terminated by either the client or the BRAS and consists of a Terminate-request followed by a PADT.
Configuration
Session setup, operation, and release
Enable PPPoE termination under the group-interface context.
Enable the local user database under the PPPoE node of the group-interface.
configure
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
address 10.2.0.254/16
group-interface "grp-int-1" create
sap 1/1/1:1 create
sub-sla-mgmt
sub-ident-policy "sub-id-default"
no shutdown
exit
exit
pppoe
policy "ppp-policy-1"
user-db "ludb-1"
no shutdown
exit
exit
exit
exit
The local user database is configured with the following parameters.
configure
subscriber-mgmt
local-user-db "ludb-1" create
ppp
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap letmein
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
---snip---
exit
exit
The PPPoE policy ppp-policy-1 is defined as follows:
*A:BSR-1# configure subscriber-mgmt ppp-policy "ppp-policy-1"
*A:BSR-1>config>subscr-mgmt>ppp-policy# info detail
----------------------------------------------
no description
no default-pap-password
no default-user-name
disable-cookies
no force-ppp-mtu-gt-1492
no ipcp-subnet-negotiation
keepalive 30 hold-up-multiplier 3
no pado-ac-name
pado-delay 30
no ppp-initial-delay
no ppp-mtu
no lcp-ignore-magic-numbers
max-sessions-per-mac 63
mlppp
no accept-mrru
no endpoint
no short-sequence-numbers
exit
reply-on-padt
ppp-authentication pref-chap
ppp-chap-challenge-length min 32 max 64
no unique-sid-per-sap
no re-establish-session
no reject-disabled-ncp
no session-timeout
ppp-options
exit
----------------------------------------------
*A:BSR-1>config>subscr-mgmt>ppp-policy#
The PPPoE policy defines the parameters which are used when establishing the PPPoE session, and includes:
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 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 their existence in the respective PPPoE phase.
Multiple PPPoE policies may be configured, but the default policy cannot be modified or deleted.
The PPPoE policy is applied within the PPPoE context under the group interface.
Troubleshooting the PPPoE discovery messages (PADI, PADO, PADR, PADS, and PADT) is done through PPPoE debugging:
*A:BSR-1# debug service id 1 ppp 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
*A:BSR-1#
*A:BSR-1# show debug
debug
service
id 1
ppp
packet
mode egr-ingr-and-dropped
discovery
ppp
dhcp-client
exit
exit
exit
exit
exit
*A:BSR-1#
To display the debugging information, a dedicated log should be created:
configure
log
log-id 1
from debug-trace
to session
no shutdown
exit
exit
exit
Discovery stage
The following is an example of PPPoE (PADI discovery packet) debug log output:
1 2017/05/16 12:07:16.94 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/1: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 = 1, value = 31
[0x0105] Vendor-Specific: vendor-id = 0x0de9 (ADSL Forum)
[0x01] Agent-Circuit-Id: "circuit10"
[0x02] Agent-Remote-Id: "remote10"
[0x81] Actual-Upstream: 1024
[0x82] Actual-Downstream: 16384
[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.
1 2017/05/16 12:07:16.94 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/1: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"
---snip---
"
The BSR echoes the service name present in the PADI message. Empty means that any service is acceptable.
2 2017/05/16 12:07:19.97 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/1:1
DMAC: 00:00:67:14:01:02
SMAC: 14:f2:01:01:00:01
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"
---snip---
"
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.
1 2017/05/16 12:07:16.94 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/1: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:
---snip---
[0x0103] Host-Uniq: len = 1, value = 31
---snip---
"
Vendor-specific information —The following parameters can optionally be added to the PADI by the PPPoE intermediate agent (BSAN):
Agent-Circuit-Id
Agent-Remote-Id
Access-loop-Encapsulation
Access loop characteristics (actual-upstream, actual-downstream)
The debug output:
1 2017/05/16 12:07:16.94 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/1: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:
---snip---
[0x0105] Vendor-Specific: vendor-id = 0x0de9 (ADSL Forum)
[0x01] Agent-Circuit-Id: "circuit10"
[0x02] Agent-Remote-Id: "remote10"
[0x81] Actual-Upstream: 1024
[0x82] Actual-Downstream: 16384
[0x90] Access-Loop-Encap: 01 01 00
"
Cookies — The cookies can be seen 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.
2 2017/05/16 12:07:19.97 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/1:1
DMAC: 00:00:67:14:01:02
SMAC: 14:f2:01:01:00:01
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1 Type : 1
Code : 0x07 (PADO) Session-Id: 0x0000 (0)
Length : 18
PPPoE Tags:
---snip---
[0x0104] ACCookie: len = 16, value = d7 91 ---snip--- ba 74
"
When disable-cookies is configured, the use of cookies will be disabled, when omitted the no-disable-cookies will be used.
*A:BSR-1# configure subscriber-mgmt ppp-policy "ppp-policy-1" disable-cookies
The cookies are encoded back by the client in the next PADR message.
AC-Name — The string that uniquely identifies the access concentrator (AC).
2 2017/05/16 12:07:19.97 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/1:1
DMAC: 00:00:67:14:01:02
SMAC: 14:f2:01:01:00:01
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1 Type : 1
Code : 0x07 (PADO) Session-Id: 0x0000 (0)
Length : 48
PPPoE Tags:
---snip---
[0x0102] AC-Name: "BSR-1"
---snip---
"
PADO-delay — SR OS 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 two BSRs and is explained later in the chapter.
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# configure subscriber-mgmt ppp-policy "ppp-policy-1" pado-delay ?
- no pado-delay
- pado-delay <deci-seconds>
<deci-seconds> : [1..30]
*A:BSR-1#
Authentication — PPPoE hosts are authenticated based on username-password information (PAP/CHAP authentication) or on information embedded in the PADI message in case of PADI authentication.
For CHAP authentication, the min and max values for the ppp-chap-challenge-length 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 ppp-policy "ppp-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]
*A:BSR-1#
To complete the discovery phase, the server must provide a session-id to the client and SR OS allocates session-id 1 when the MACs are different.
*A:BSR-1# show service id 1 pppoe session
===============================================================================
PPPoE sessions for svc-id 1
===============================================================================
Sap Id Mac Address Sid Up Time Type
IP/L2TP-Id/Interface-Id MC-Stdby
-------------------------------------------------------------------------------
1/1/1:1 00:00:67:14:01:02 1 0d 00:01:32 local
10.2.0.1
-------------------------------------------------------------------------------
Number of sessions : 1
===============================================================================
*A:BSR-1#
In the VLAN per service model (N: 1 VLAN), the MACs are the same and the PPPoE interworking is done at the BSAN.
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 latter 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 sent 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 toward 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 SR OS 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 ppp-policy "ppp-policy-1" ppp-mtu ?
- no ppp-mtu
- ppp-mtu <mtu-bytes>
<mtu-bytes> : [512..9212]
*A:BSR-1#
For LCP, the PPPoE debug output is as follows:
5 2017/05/16 12:07:20.12 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/1:1
DMAC: 00:00:67:14:01:02
SMAC: 14:f2:01:01:00:01
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: 239 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.
The debug output for CHAP authentication protocol is as follows:
8 2017/05/16 12:07:20.89 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/1:1
DMAC: 14:f2:01:01:00:01
SMAC: 00:00:67:14: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: 239 Length : 19
Options:
[1] MRU: 1492
[3] Authentication-Protocol: 0xc223 (CHAP), Algorithm = 5 (MD5)
[5] Magic-Number: 0x772a29d2
"
The debug output for PAP authentication is as follows:
72 2017/05/16 14:46:50.68 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/1:1
DMAC: 14:f2:01:01:00:01
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: 134 Length : 18
Options:
[1] MRU: 1492
[3] Authentication-Protocol: 0xc023 (PAP)
[5] Magic-Number: 0x0538a9d5
"
CHAP to PAP fallback case
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 always preferred.
*A:BSR-1# configure subscriber-mgmt ppp-policy "ppp-policy-1" ppp-authentication ?
- no ppp-authentication
- ppp-authentication {pap|chap|pref-chap|pref-pap}
*A:BSR-1#
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-options feature in the pppoe-policy allows for support of undocumented client LCP or IPCP/IPv6CP options. If the received LCP or IPCP/IPv6CP option matches the configured options in the pppoe-policy, an ack will be sent instead of a reject.
*A:BSR-1# configure subscriber-mgmt ppp-policy "ppp-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|ipv6cp
<option-number> : [0..255]
<ip-address> : a.b.c.d
<ascii-string> : [127 chars max]
<hex-string> : [0x0..0xFFFFFF...(max 254 hex nibbles)]
*A:BSR-1#
Troubleshooting the PPPoE LCP session messages is done with PPPoE debugging:
A:BSR-1# debug service id 1 ppp packet ppp ?
- no ppp
- ppp [lcp] [pap] [chap] [ipcp] [ipv6cp]
<lcp> : keyword - debug LCP packets
<pap> : keyword - debug PAP packets
<chap> : keyword - debug CHAP packets
<ipcp> : keyword - debug IPCP packets
<ipv6cp> : keyword - debug IPv6CP packets
A:BSR-1#
At the end of the LCP phase, authentication is started.
SR OS 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 Authentication flow chart and starts with the request to the middle left.
PPPoE users get authenticated via the LUDB if this LUDB is configured under the group-interface, as follows:
configure
service
vprn 1
subscriber-interface "sub-int-1" create
group-interface "grp-int-1" create
pppoe
user-db "ludb-1"
Users get authenticated via RADIUS if an authentication-policy is configured under the same group-interface. RADIUS has precedence if both are configured, as follows:
configure
service
vprn 1
subscriber-interface "sub-int-1" create
group-interface "grp-int-1" create
authentication-policy "auth-1"
pppoe
user-db "ludb-1"
no shutdown
exit
exit
Users that get authenticated via the LUDB can still go to RADIUS if the authentication-policy is moved from the group-interface to the LUDB.
configure
subscriber-mgmt
local-user-db "ludb-1" create
ppp
match-list username
---snip---
host "user2" create
host-identification
username "user2@domain1"
exit
auth-policy "auth-1"
address pool "pool-1"
password pap letmein
identification-strings 254 create
subscriber-id "PPPoE-host-user2@domain1"
sla-profile-string "sla-profile-1"
sub-profile-string "sub-profile-1"
exit
no shutdown
exit
---snip---
exit
exit
exit
exit
This last mechanism could be used to pick up parameters like pado-delay or to check some variables such as circuit-id, remote-id from the LUDB during discovery phase and subsequently to use RADIUS for PAP/CHAP authentication.
*A:BSR-1# configure subscriber-mgmt local-user-db "ludb-1" ppp host "user2"
host-identification ?
- host-identification
[no] circuit-id - Configure the circuit id of this host
[no] derived-id - Configure the host ID to be derived by a python script from
DHCP packets during a DHCP transaction
[no] encap-tag-range - Configure the SAP encap range tags for this host
[no] mac - Configure the MAC address of this host
[no] remote-id - Configure the remote id of this host
[no] sap-id - Configure the SAP identifier of this host
[no] service-name - Configure the service name of this host
[no] username - Configure the user name of this host
*A:BSR-1#
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# configure subscriber-mgmt local-user-db "ludb-1" ppp match-list ?
- no match-list
- match-list <ppp-match-type-1> [<ppp-match-type-2>...(up to 3 max)]
<ppp-match-type> : circuit-id|derived-id|mac|remote-id|sap-id|
encap-tag-range|service-name|username
*A:BSR-1#
PPPoE users that have in the LUDB a match-list equal to username will use the PAP/CHAP authentication method.
configure
subscriber-mgmt
local-user-db "ludb-1" create
ppp
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap letmein
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
---snip---
exit
exit
exit
exit
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# configure subscriber-mgmt authentication-policy "auth-1"
pppoe-access-method ?
- no pppoe-access-method
- pppoe-access-method {none|padi|pap-chap}
*A:BSR-1#
The selection for mac or circuit-id can be altered via the parameter user-name-format.
*A:BSR-1# configure subscriber-mgmt authentication-policy "auth-1"
user-name-format ?
- no user-name-format
- user-name-format <format> [mac-format <mac-format>]
- user-name-format <format> append [<domain-name>]
[mac-format <mac-format>]
- user-name-format <format> append domain-name
- user-name-format <format> default-domain <domain-name>
[mac-format <mac-format>]
- user-name-format <format> replace <domain-name>
[mac-format <mac-format>]
- user-name-format <format> strip [mac-format <mac-format>]
<format> : ascii-converted-circuit-id|ascii-converted-tuple|
circuit-id|dhcp-client-vendor-opts|mac|
mac-giaddr|ppp-user-name|tuple
<domain-name> : max 128 chars, no @ needed
<mac-format> : (only when format is dhcp-client-vendor-opts)
like ab: for 00:0c:f1:99:85:b8
or XY- for 00-0C-F1-99-85-B8
or mmmm. for 0002.03aa.abff
or xx for 000cf19985b8
*A:BSR-1#
PPPoE users that are authenticated through RADIUS and having a pppoe-access-method equal to pap-chap in the authentication policy 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 which 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-1# configure subscriber-mgmt authentication-policy "auth-1" pppoe-access-method ?
- no pppoe-access-method
- pppoe-access-method {none|padi|pap-chap}
*A:BSR-1#
When PADI authentication is used 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.
The attributes included in the RADIUS Access-Request message is configured in the RADIUS policy using the following command:
*A:BSR-1# configure subscriber-mgmt authentication-policy "auth-" include-radius-attribute ?
- include-radius-attribute
- no include-radius-attribute
[no] access-loop-op* - Enable/disable generation of the DSL Forum access loop
characteristics RADIUS attributes
[no] acct-session-id - Enable/disable generation of the Acct-Session-Id RADIUS
attribute
[no] called-station* - Enable/disable generation of the called-station-id RADIUS
attribute
[no] calling-statio* - Enable/disable generation of the calling-station-id RADIUS
attribute
[no] circuit-id - Enable/disable generation of the agent-circuit-id RADIUS
attribute
[no] dhcp-options - Enable/disable generation of the dhcp-options RADIUS attribute
[no] dhcp-vendor-cl* - Enable/disable generation of the dhcp-vendor-class-id RADIUS
attribute
[no] dhcp6-options - Enable/disable generation of the dhcp6-options RADIUS attribute
[no] mac-address - Enable/disable generation of the client MAC address RADIUS
attribute
[no] nas-identifier - Enable/disable generation of the NAS-Identifier RADIUS
attribute
[no] nas-port - Enable/disable include of the NAS-Port attribute
[no] nas-port-id - Enable/disable generation of the NAS-Port-Id RADIUS attribute
[no] nas-port-type - Enable/disable generation of the NAS-Port-Type RADIUS attribute
[no] pppoe-service-* - Enable/disable generation of the pppoe-service-name RADIUS
attribute
[no] remote-id - Enable/disable generation of the agent-remote-id RADIUS
attribute
[no] sap-session-in* - Enable/disable generation of the per-SAP unique session index
[no] tunnel-server-* - Enable/disable generation of the tunnel-server-attrs RADIUS
attribute
[no] wifi-num-attac* - Enable/disable including the Alc-Num-Attached-UEs RADIUS
attribute
[no] wifi-ssid-vlan - Enable/disable including the per-SSID VLAN ID in Alc-Wlan
-SSID-VLAN
*A:BSR-1#
Local User Database authentication
A second authentication option for PPPoE termination is to use the local user database of the BSR 7750 for PAP/CHAP authentication (this option will be used in this example). 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:
configure
subscriber-mgmt
local-user-db "ludb-1" create
ppp
match-list username
host "user1" create
host-identification
username "user1@domain1"
exit
address pool "pool-1"
password chap letmein
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
---snip---
With the LUDB authentication method, authentication can be provided by the username/password combination.
To enable the local authentication method, the local user database is configured under the PPPoE node of the group-interface as follows.
configure
service
vprn 1
subscriber-interface "sub-int-1" create
group-interface "grp-int-1" create
pppoe
policy "ppp-policy-1"
user-db "ludb-1"
no shutdown
exit
exit
exit
The properties of LUDB user user-1 are as follows:
*A:BSR-1# show subscriber-mgmt local-user-db "ludb-1" ppp-host "user1"
===============================================================================
PPP Host "user1"
===============================================================================
Admin State : Up
Last Mgmt Change : 05/16/2017 11:57:57
Host Identification
Mac Address : N/A
Circuit Id : N/A
Remote Id : N/A
Sap Id : N/A
Service Name : N/A
User Name : user1@domain1
Encap Tag Range : N/A
Derived Id : N/A
Matched Objects : userName
Address : pool "pool-1"
Password Type : CHAP
PADO Delay : 0msec
Pre Auth Policy : N/A
Auth Policy : N/A
Padi Auth Policy : N/A
---snip---
DHCPv6 lease times
Renew timer : > 9999 days
Rebind timer : > 9999 days
Preferred lifetime : 0d 00:00:00
Valid lifetime : 0d 00:00:00
Identification Strings (option 254)
Subscriber Id : PPPoE-host-user1@domain1
SLA Profile String : sla-profile-1
Sub Profile String : sub-profile-1
App Profile String : N/A
ANCP String : N/A
Inter Destination Id: N/A
Category Map Name : N/A
---snip---
Access loop info
Circuit ID format : none
Circuit ID : N/A
Remote ID format : none
Remote ID : N/A
===============================================================================
*A:BSR-1#
To debug the LUDB, use the command as follows:
*A:BSR-1# debug subscriber-mgmt local-user-db "ludb-1" detail ?
- detail {all|failed}
- no detail
*A:BSR-1#
See the LUBD Basics chapter for further information.
DHCP client authentication
A third authentication method for PPPoE termination is to perform PPPoE to DHCP transformation (where the router 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.
If IP information is returned from a DHCP server, then the PPPoE options such as the DNS name are retrieved from the DHCP ACK and provided to the PPPoE client.
Local DHCP server
This chapter uses a local DHCP server as a source for the IP address information of the PPPoE host.
configure
service
vprn 1 customer 1 create
dhcp
local-dhcp-server "server-1" create
use-pool-from-client
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
exit
exit
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
Persistency State : shutdown
User Data Base : N/A
Use gateway IP address : disabled
Use pool from client : enabled
---snip---
-------------------------------------------------------------------------------
Pool name : pool-1
-------------------------------------------------------------------------------
Failover Admin State : outOfService
Failover Oper State : shutdown
Failover Persist Key : N/A
Administrative MCLT : 0h10m0s
Operational MCLT : 0h10m0s
Startup wait time : 0h2m0s
Partner down delay : 23h59m59s
Ignore MCLT : disabled
-------------------------------------------------------------------------------
Subnet Free % Stable Declined Offered Rem-pend Drain
-------------------------------------------------------------------------------
10.2.0.0/16 252 99% 1 0 0 0 N
Totals for pool 252 99% 1 0 0 0
-------------------------------------------------------------------------------
Totals for server 252 99% 1 0 0 0
-------------------------------------------------------------------------------
Interface associations
Interface Admin
-------------------------------------------------------------------------------
local-dhcp-server-1 Up
-------------------------------------------------------------------------------
Local Address Assignment associations
Group interface Admin
-------------------------------------------------------------------------------
===============================================================================
*A:BSR-1#
To debug the DHCP server:
debug
router "1"
local-dhcp-server "server-1"
detail-level high
mode egr-ingr-and-dropped
exit
exit
exit
Keepalive
The keepalive timer (defined in seconds) and the hold-up-multiplier are defined when enabling keepalives. When omitted, a 30 second keepalive timer and three hold-up-multipliers are used.
*A:BSR-1# configure subscriber-mgmt ppp-policy "ppp-policy-1" keepalive ?
- keepalive <seconds> [hold-up-multiplier <multiplier>]
- no keepalive
<seconds> : [4..300]
<multiplier> : [1..5]
*A:BSR-1#
The keepalive defines the interval between LCP Echo Requests in seconds. The hold-up-multiplier defines the 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 Type
IP/L2TP-Id/Interface-Id MC-Stdby
-------------------------------------------------------------------------------
1/1/1:1 00:00:67:14:01:02 1 0d 00:05:45 local
10.2.0.4
Packet Type Received Transmitted
-------------------------------------------------------------------------------
LCP Configure-Request 1 1
LCP Configure-Ack 1 1
LCP Configure-Nak 0 0
LCP Configure-Reject 0 0
LCP Terminate-Request 0 0
LCP Terminate-Ack 0 0
LCP Code-Reject 0 0
LCP Echo-Request 35 0
LCP Echo-Reply 0 35
LCP Protocol-Reject 0 0
LCP Discard-Request 0 0
-------------------------------------------------------------------------------
PAP Authenticate-Request 0 -
---snip---
-------------------------------------------------------------------------------
CHAP Challenge - 1
CHAP Response 1 -
---snip---
-------------------------------------------------------------------------------
IPCP Configure-Request 2 1
IPCP Configure-Ack 1 1
---snip---
-------------------------------------------------------------------------------
IPV6CP Configure-Request 0 0
IPV6CP Configure-Ack 0 0
---snip---
-------------------------------------------------------------------------------
Unknown Protocol 0 -
-------------------------------------------------------------------------------
Number of sessions : 1
===============================================================================
*A:BSR-1#
The BSR supports an optimized 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 preceding timer on the BSR is reset to the initial keepalive value.
The preceding mechanism results in an optimized 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.
An example for Echo Request from BSR and Echo Reply from the PPPoE host is as follows:
15:36:27.907363 00:00:67:14:01:02 > 14:f2:01:01:00:01, ethertype 802.1Q (0x8100),
length 64: vlan 1, p 7, ethertype PPPoE S, PPPoE [ses 0x1] LCP (0xc021),
length 10: LCP, Echo-Request (0x09), id 249, length 10
encoded length 8 (=Option(s) length 4)
0x0000: c021 09f9 0008
Magic-Num 0x00000000
15:36:27.907844 14:f2:01:01:00:01 > 00:00:67:14:01:02, ethertype 802.1Q (0x8100),
length 60: vlan 1, p 5, ethertype PPPoE S, PPPoE [ses 0x1] LCP (0xc021),
length 10: LCP, Echo-Reply (0x0a), id 249, length 10
encoded length 8 (=Option(s) length 4)
0x0000: c021 0af9 0008
Magic-Num 0x3298fadc
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-prefix[/prefix-length]>] [port <port-id>]
[no-inter-dest-id | inter-dest-id <intermediate-destination-id>]
[steering-profile <steering-profile>] [router-advertisement-policy
<router-adv-policy>] [detail|statistics]
- session l2tp-connection-id <connection-id> [detail|statistics]
The details of the PPPoE session for MAC address 00:00:67:14:01:02 are as follows:
*A:BSR-1# show service id 1 pppoe session mac 00:00:67:14:01:02 detail
===============================================================================
PPPoE sessions for svc-id 1
===============================================================================
Sap Id Mac Address Sid Up Time Type
IP/L2TP-Id/Interface-Id MC-Stdby
-------------------------------------------------------------------------------
1/1/1:1 00:00:67:14:01:02 1 0d 00:14:05 local
10.2.0.4
LCP State : Opened
IPCP State : Opened
IPv6CP State : Closed
PPP MTU : 1492
PPP Auth-Protocol : CHAP
PPP User-Name : user1@domain1
Subscriber-interface : sub-int-1
Group-interface : grp-int-1
IP Origin : dhcp
DNS Origin : none
NBNS Origin : none
Subscriber : "PPPoE-host-user1@domain1"
Sub-Profile-String : "sub-profile-1"
SLA-Profile-String : "sla-profile-1"
ANCP-String : ""
Int-Dest-Id : ""
App-Profile-String : ""
Category-Map-Name : ""
Acct-Session-Id : "14F2FF00000009591AFDFA"
Sap-Session-Index : 1
IP Address : 10.2.0.4/32
Primary DNS : N/A
Secondary DNS : N/A
Primary NBNS : N/A
Secondary NBNS : N/A
Address-Pool : pool-1
IPv6 Prefix : N/A
IPv6 Prefix Origin : none
IPv6 Prefix Pool : ""
IPv6 Del.Pfx. : N/A
IPv6 Del.Pfx. Origin : none
IPv6 Del.Pfx. Pool : ""
IPv6 Address : N/A
IPv6 Address Origin : none
IPv6 Address Pool : ""
Primary IPv6 DNS : N/A
Secondary IPv6 DNS : N/A
Router adv. policy : N/A
Ignoring DF bit : false
Radius sub-if prefix : N/A
Circuit-Id : circuit10
Remote-Id : remote10
Radius Session-TO : N/A
Radius Class :
Radius User-Name : user1@domain1
Logical-Line-Id :
Service-Name :
Data link : ethernet
Encaps 1 : untagged-ethernet
Encaps 2 : not-available
Origin : tags
Link Rate Down : 16384
Rate Origin : tags
-------------------------------------------------------------------------------
Number of sessions : 1
===============================================================================
*A:BSR-1#
An event will be generated when a PPPoE host has been created in the system.
*A:BSR-1# show log log-id 99
===============================================================================
Event Log 99
===============================================================================
Description : Default System Log
Memory Log contents [size=500 next event=75 (not wrapped)]
73 2017/05/16 15:26:18.19 CEST WARNING: SVCMGR #2500 Base Subscriber created
"Subscriber PPPoE-host-user1@domain1 has been created in the system"
---snip---
*A:BSR-1#
The PPPoE host will appear in the subscriber-host table for the service with origin set to IPCP.
*A:BSR-1# show service id 1 subscriber-hosts
=============================================================
Subscriber Host table
=============================================================
Sap Subscriber
IP Address
MAC Address PPPoE-SID Origin Fwding State
-------------------------------------------------------------
1/1/1:1 PPPoE-host-user1@domain1
10.2.0.4
00:00:67:14:01:02 1 IPCP Fwding
-------------------------------------------------------------
Number of subscriber hosts : 1
=============================================================
*A:BSR-1#
A host route (/32) for its IP address is inserted in the routing table toward the appropriate group-interface.
*A:BSR-1# show router 1 route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
10.2.0.0/16 Local Local 03h47m06s 0
sub-int-1 0
10.2.0.4/32 Remote Sub Mgmt 00h18m50s 0
[grp-int-1] 0
172.16.0.1/32 Local Local 03h47m12s 0
local-dhcp-server-1 0
-------------------------------------------------------------------------------
No. of Routes: 3
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
*A:BSR-1#
To advertise the PPPoE host subnets to other protocol/network, a policy statement should be defined with using from protocol direct.
configure
router
policy-options
begin
policy-statement "policy-1"
entry 10
from
protocol direct
exit
---snip---
exit
exit
commit
exit
exit
exit
Terminate
Some PPPoE clients expect a reply on PADT message before the context of the session is cleared up. To support such clients, 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 ppp-policy "ppp-policy-1" reply-on-padt
The PPPoE debug output:
116 2017/05/16 15:47:16.67 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: RX Packet
VPRN 1, SAP 1/1/1:1
DMAC: 14:f2:01:01:00:01
SMAC: 00:00:67:14:01:02
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1 Type : 1
Code : 0xa7 (PADT) Session-Id: 0x0001 (1)
Length : 0
"
117 2017/05/16 15:47:16.68 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: TX Packet
VPRN 1, SAP 1/1/1:1
DMAC: 00:00:67:14:01:02
SMAC: 14:f2:01:01:00:01
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1 Type : 1
Code : 0xa7 (PADT) Session-Id: 0x0001 (1)
Length : 0
"
A PPPoE host can be manually deleted from the system using following clear command:
*A:BSR-1# clear service id 1 ppp session ?
- session [sap-id <sap-id>] [interface <ip-int-name|ip-address>]
[mac <ieee-address>] [session-id <session-id>]
[type <pppoe-session-type>] [ip-address <ip-prefix[/prefix-length]>]
[port <port-id>] [inter-dest-id <intermediate-destination-id>]
[no-inter-dest-id] [user-name <user-name>]
[sub-ppp-type {oa|oe|oeoa|ol2tp}] [no-padt]
- session all [no-padt]
---snip---
*A:BSR-1#
The logs indicate a cause for terminating the PPP session:
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.
The VPRN service which is transporting accounting information has been shutdown.
The last RADIUS accounting server has been removed from an 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 encapsulated 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.
*A:BSR-1# configure router sgt-qos application pppoe dot1p 5
In case of the PPPoE hosts instantiated in a VPRN service subscriber-interface.
*A:BSR-1# configure service vprn 1 sgt-qos application pppoe dot1p 5
The show router sgt-qos command displays the configured and default DSCP and default dot1p values per application. Because 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 Configured Dot1p Value Default Dot1p Value
-------------------------------------------------------------------------------
pppoe 5 7
===============================================================================
*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.
configure
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "grp-int-1" create
pppoe
policy "ppp-policy-1"
session-limit 1
user-db "ludb-1"
no shutdown
exit
exit
The discovery phase is completed before the session-limit check is executed.
The debug log shows a message when the session-limit is reached, as follows:
199 2017/05/16 16:03:22.14 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: Dropped Packet
VPRN 1, SAP 1/1/1:1
Problem: Reached the interface session limit (1) for "grp-int-1"
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:13:01:02
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1 Type : 1
Code : 0x09 (PADI) Session-Id: 0x0000 (0)
Length : 37
PPPoE Tags:
[0x0101] Service-Name: ""
[0x0103] Host-Uniq: len = 1, value = 32
[0x0105] Vendor-Specific: vendor-id = 0x0de9 (ADSL Forum)
[0x01] Agent-Circuit-Id: "cicuit11"
[0x02] Agent-Remote-Id: "remote11"
"
Also a trap is generated, as follows:
*A:BSR-1# show log log-id 99
===============================================================================
Event Log 99
===============================================================================
Description : Default System Log
Memory Log contents [size=500 next event=88 (not wrapped)]
87 2017/05/16 16:03:22.15 CEST WARNING: PPPOE #2001 vprn1 PPPoE session failure
"PPPoE session failure on SAP 1/1/1:1 in service 1 - Reached the interface session
limit (1) for "grp-int-1""
---snip---
*A:BSR-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:
configure
service
vprn 1 customer 1 create
subscriber-interface "sub-int-1" create
group-interface "grp-int-1" create
pppoe
policy "ppp-policy-1"
session-limit 10
sap-session-limit 1
user-db "ludb-1"
no shutdown
exit
exit
exit
exit
exit
exit
The debug log shows a message when the session-limit is reached, as follows:
201 2017/05/16 16:10:34.00 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: Dropped Packet
VPRN 1, SAP 1/1/1:1
Problem: Reached the per-SAP session limit (1) for "grp-int-1"
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:13:01:02
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1 Type : 1
Code : 0x09 (PADI) Session-Id: 0x0000 (0)
Length : 37
PPPoE Tags:
[0x0101] Service-Name: ""
[0x0103] Host-Uniq: len = 1, value = 32
[0x0105] Vendor-Specific: vendor-id = 0x0de9 (ADSL Forum)
[0x01] Agent-Circuit-Id: "cicuit11"
[0x02] Agent-Remote-Id: "remote11"
"
A trap is generated when trying to instantiate a new PPPoE session while the configured number of the sessions per sap is reached.
*A:BSR-1# show log log-id 99
===============================================================================
Event Log 99
===============================================================================
Description : Default System Log
Memory Log contents [size=500 next event=89 (not wrapped)]
88 2017/05/16 16:10:34.00 CEST WARNING: PPPOE #2001 vprn1 PPPoE session failure
"PPPoE session failure on SAP 1/1/1:1 in service 1 - Reached the per-SAP session limit
(1) for "grp-int-1""
---snip---
*A:BSR-1#
Max-sessions-per-mac
The BSR 7750 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.
configure
subscriber-mgmt
ppp-policy "ppp-policy-1"
disable-cookies
max-sessions-per-mac 256
reply-on-padt
exit
exit
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.
The debug log shows a message when the max-sessions-per-mac limit is reached, as follows:
226 2017/05/16 16:30:38.82 CEST MINOR: DEBUG #2001 vprn1 PPPoE
"PPPoE: Dropped Packet
VPRN 1, SAP 1/1/1:1
Problem: Reached the maximum number (1) of PPPoE sessions for MAC
00:00:67:13:01:02
DMAC: ff:ff:ff:ff:ff:ff
SMAC: 00:00:67:13:01:02
Ether Type: 0x8863 (Discovery)
PPPoE Header:
Version: 1 Type : 1
Code : 0x09 (PADI) Session-Id: 0x0000 (0)
Length : 37
---snip---
"
A trap is generated when trying to instantiate a new PPPoE session using the same MAC while the configured number of max-sessions-per-mac is reached.
*A:BSR-1# show log log-id 99
===============================================================================
Event Log 99
===============================================================================
Description : Default System Log
Memory Log contents [size=500 next event=92 (not wrapped)]
91 2017/05/16 16:30:38.82 CEST WARNING: PPPOE #2001 vprn1 PPPoE session failure
"PPPoE session failure on SAP 1/1/1:1 in service 1 - Reached the maximum number (1)
of PPPoE sessions for MAC 00:00:67:13:01:02"
---snip---
*A:BSR-1#
Host-limit
The maximum number of PPPoE hosts is defined when enabling host-limit. When omitted, a single host is allowed.
configure
subscriber-mgmt
sla-profile "sla-profile-1"
host-limits
overall 10
exit
exit
exit
exit
If the configured host-limit is reached for a subscriber, access is denied for a new host, and an event is generated.
*A:BSR-1# show log log-id 99
===============================================================================
Event Log 99
===============================================================================
Description : Default System Log
Memory Log contents [size=500 next event=110 (not wrapped)]
108 2017/05/16 16:38:30.68 CEST WARNING: PPPOE #2001 vprn1 PPPoE session failure
"PPPoE session failure on SAP 1/1/1:1 in service 1 -
[00:00:67:13:01:02,6,user3@domain1] sla-profile sla-profile-1 : host-limit overall
(1) exceeded for subscriber PPPoE-host-user3@domain1 on SAP 1/1/1:1 "
---snip---
*A:BSR-1#
An optional command remove-oldestcan be specified. In this case, the new host is accepted and the old one will be removed.
configure
subscriber-mgmt
sla-profile "sla-profile-1"
host-limits
overall 10
remove-oldest
exit
exit
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).
configure
service
vprn 1
subscriber-interface "sub-int-1"
group-interface "grp-int-1"
sap 1/1/1:1
sub-sla-mgmt
multi-sub-sap 100
---snip---
exit
exit
exit
A trap is generated when trying to instantiate a new PPPoE session while the configured number of the multi-sub-sap is reached.
*A:BSR-1# show log log-id 99
===============================================================================
Event Log 99
===============================================================================
Description : Default System Log
Memory Log contents [size=500 next event=127 (not wrapped)]
125 2017/05/16 16:43:57.28 CEST WARNING: PPPOE #2001 vprn1 PPPoE session failure
"PPPoE session failure on SAP 1/1/1:1 in service 1 -
[00:00:67:13:01:02,1,user3@domain1] Number of subscribers exceeds the configured
multi-sub-sap limit (1)"
---snip---
*A:BSR-1#
Redundancy
Redundancy for PPPoE sessions can be used for load balancing sessions between the two BSRs. PADO-delays (which can come from RADIUS, LUDB, and policy) are used 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 PPPoE session, SR OS offers 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 that gets selected for a 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.
Check the PADO delay value, as follows:
*A:BSR-1# show subscriber-mgmt ppp-policy "ppp-policy-1"
===============================================================================
PPP Policy "ppp-policy-1"
===============================================================================
Description : (Not Specified)
Last Mgmt Change : 05/16/2017 16:37:04
PPP-mtu : N/A Force PPP-mtu >1492 : No
Keepalive Interval : 30s Keepalive Multiplier : 3
Disable AC-Cookies : Yes PADO Delay : 3000msec
Max Sessions-Per-Mac : 2 Reply-On-PADT : Yes
Allow Same CID : No Re-establish Session : Disabled
PPP-Authentication : pref-CHAP PPP-CHAP Challenge : 32 - 64
PPP-Init-Delay (ms) : 0 IPCP negotiate subnet: No
Unique SIDs-Per-SAP : disabled Reject-Disabled-Ncp : No
Ignore-Magic-Num : No Session Timeout : unlimited
PADO AC-Name : (Not Specified)
Default username : (Not Specified)
Default password : (Not Specified)
-------------------------------------------------------------------------------
PPP Custom Options
-------------------------------------------------------------------------------
Protocol Number Value
-------------------------------------------------------------------------------
No options configured.
-------------------------------------------------------------------------------
MLPPP
-------------------------------------------------------------------------------
Accept MRRU : false
Request short sequence nr. : false
Endpoint class : null
Endpoint address : (Not Specified)
-------------------------------------------------------------------------------
*A:BSR-1#
Another option to achieve redundancy is through Multi Chassis Synchronization (MCS), but that is beyond the scope of this chapter.
High availability
The PPPoE session state is HA: the session state is synchronized to the standby CPM. When the active CPM fails, all PPPoE hosts stay active without service interruption.
Conclusion
This chapter provides configuration and troubleshooting commands for PPPoE hosts in a Layer 3 Routed CO (IES/VPRN subscriber interface) context.