This is an old revision of the document!
PPPoE configuration and commands
Enabling PPPoE Support
- Activate BRAS. More details.
- Configure parameters in
fastdpi.conf
:bras_pppoe_enable=1
— enable PPPoE.bras_pppoe_session=10000
— set the maximum number of PPPoE sessions. Recommended value: 1.5-2 times the number of PPPoE subscribers.
If Router is not used, then the IP and MAC addresses of the gateway/border located behind SSG (subscriber → SSG → border/gateway) must be specified:
bras_gateway_ip=192.168.0.1 bras_gateway_mac=aa:bb:cc:dd:ee:ff
Authorization Configuration
The list of allowed authorization protocols is set by the bras_ppp_auth_list
parameter in fastdpi.conf
.
Possible values:
1
— PAP (not recommended for use)2
— CHAP-MD53
— MS-CHAPv2
Protocols in the parameter's value list are arranged in order of preference: the first is the most preferred.
Default value: bras_ppp_auth_list=2,3
.
If bras_ppp_mac_auth=1
is specified in fastdpi.conf
, authorization by the subscriber's MAC address is possible. Used when the parties fail to agree on an authorization protocol.
ARP Handling in PPPoE
In networks with PPPoE connections (point-to-point type), sending ARP requests from subscribers has no practical meaning. A subscriber can only send packets to the PPPoE server's address, whose MAC address is known to the subscriber within the established PPPoE connection.
On the WAN side, SSG processes all ARP requests of the form "Who is IP=x.x.x.x?" if the IP address x.x.x.x corresponds to an active PPPoE session. In response to such requests, SSG returns the value of the bras_arp_mac parameter. Thus, SSG responds to ARP requests directed to the IP addresses of current PPPoE subscribers.
If the NAT service is activated for a PPPoE subscriber, ARP requests from the WAN side to the corresponding PPPoE sessions are not processed.
The following BRAS-level functions are implemented for PPPoE sessions:
- Local traffic closure, including traffic between different segment types (e.g., between PPPoE and DHCP networks)
Restoring PPPoE Sessions on SSG Restart
Upon startup, fastDPI attempts to restore PPPoE subscriber sessions based on information saved in UDR. This ensures transparency of a brief service restart for subscribers.
However, automatic restoration of PPPoE sessions can lead to state inconsistency between the billing system and SSG, especially in cases with dynamic IP address assignment. Such a situation is possible if the billing system expects a sequence of Access-Request → Acct-Start messages, while only Acct-Start is transmitted during session restoration.
The configuration parameter bras_pppoe_restore_on_startup
allows disabling automatic restoration of PPPoE sessions at startup.
Possible values:
1
— enabled (default value).0
— disabled. Subscribers will initiate new PPPoE sessions.
If restoration is disabled:
- The subscriber will need to initiate a new PPPoE session and undergo re-authorization;
- When attempting to continue using an old session, SSG will send the subscriber a PADT (PPP Active Discovery Terminate) to terminate the session.
Additional PPPoE Settings
Parameter | Description | Possible Values |
---|---|---|
bras_pppoed_timeout | Sets the PPPoE session establishment timeout in seconds. Since the PPPoE Discovery protocol is susceptible to DOS attacks, this parameter aims to limit the use of internal resources during a PPPoE DOS attack | Default value: 2 seconds. |
bras_pppoe_restore_on_startup | Allow or deny restoration of PPPoE sessions on SSG restart. For more details, see Restoring PPPoE sessions on SSG restart | 1 — allow2 — deny |
CLI Parameters
pppoe term
— termination of all PPPoE sessions. It is possible to specify parameters ip
, mac
, subs_id
, login
or all
:
pppoe term [hard] [ip=X | mac=X | subs_id=X | login=X | all]
For PPPoE sessions, there is no tunnel IP (tunnel-IP=0
).
CLI commands that accept subs_id
as a key (subs prop show
, l2tp show session
, l2tp term
, etc.) may return multiple records with the same l2subs_id
.
Was this information helpful?