Glossary

PPPoE

Point-to-Point Protocol over Ethernet

What is PPPoE

PPPoE (Point-to-Point Protocol over Ethernet), defined in RFC 2516, carries PPP (Point-to-Point Protocol) over an Ethernet network. Its purpose is to establish a subscriber session over Ethernet access infrastructure, much like a traditional dial-up connection did over a phone line — and once that session is up, the network can assign the subscriber an IP address, authenticate them, apply service policies, and handle accounting and billing.

A PPPoE packet is, mechanically, a standard PPP packet encapsulated directly inside an Ethernet frame — carrying a version and type field, a packet-type code, a 16-bit Session ID (which, together with the source and destination MAC addresses, uniquely identifies one PPP session), and a length field.

PPPoE is the standard access mechanism in broadband networks run by telecom operators, ISPs, and enterprise campuses. Subscriber-side devices — routers, ONTs, CPEs — run as PPPoE clients, while network-side devices — BNGs (Broadband Network Gateways) and BRAS platforms — run as PPPoE servers, using the protocol to handle authentication, IP assignment, accounting, billing, and policy enforcement for every connected subscriber.

How PPPoE Works

Establishing a PPPoE session happens in three phases.

The Discovery phase is where a client finds a server and gets a session assigned, using four defined message types. The client broadcasts a PADI (PPPoE Active Discovery Initiation) announcing the service it wants; any capable server replies with a unicast PADO (PPPoE Active Discovery Offer) carrying its Access Concentrator name and the services it provides — a client may receive several PADOs from different servers. The client picks one and sends a PADR (PPPoE Active Discovery Request) to that server; the server confirms with a PADS (PPPoE Active Discovery Session-confirmation), assigning the Session ID that — combined with the source and destination MAC addresses — uniquely identifies the session from that point on.

The Session phase is where standard PPP negotiation actually happens, in three sub-phases. LCP (Link Control Protocol) negotiation sets up the PPP link itself — agreeing on MRU, link-quality monitoring, and which authentication protocol to use (typically PAP or CHAP). Authentication then runs, with the server (BNG) forwarding credentials to a RADIUS server for verification: PAP sends the username/password in plain text for the RADIUS server to check directly, while CHAP is stronger, having the server issue a random challenge that the client must correctly hash with its password, without ever sending the password itself over the wire. Either way, RADIUS responds with Access-Accept or Access-Reject, and the client learns whether it's in. Finally, NCP (Network Control Protocol) negotiation — typically IPCP for IPv4 — assigns the client's IP address, either from a local pool on the server or from a RADIUS-supplied attribute like Framed-IP-Address, plus other parameters like DNS servers.

Once negotiation completes, the session enters data transfer: user traffic is encapsulated in PPP frames, carried inside PPPoE frames, and transported over Ethernet — with the server maintaining per-session forwarding state and applying subscriber-specific QoS, ACLs, accounting, and billing throughout.

The Termination phase ends the session, either voluntarily (the subscriber disconnects) or by operator action (forced logoff, service suspension). Either side can send a PADT (PPPoE Active Discovery Terminate) message; once that exchange completes, the server removes the session entry, releases the Session ID, and returns any assigned IP address to the pool for reuse.

Why PPPoE is Beneficial

  • Combines Ethernet access with PPP's AAA capabilities: PPPoE's real value is bringing Authentication, Authorization, and Accounting to an Ethernet access network — something Ethernet alone doesn't provide — which is exactly what subscriber-based network management needs.

  • Enables true per-subscriber management: Per-user authentication, per-user IP assignment, and per-user QoS/ACL/accounting mean a network can treat every subscriber individually, rather than applying one policy to everyone on a shared segment.

  • Centralizes policy through RADIUS: Authentication, authorization, and billing logic live on the RADIUS server rather than being configured locally on every access device, which is what makes managing thousands of subscribers actually practical.

  • Makes usage-based billing straightforward: Because PPPoE is session-based, tracking exactly how much a given subscriber used — the basis for differentiated service tiers and billing — falls naturally out of the protocol's own session model.

  • Resources get reclaimed automatically: PADT-driven termination means a disconnected subscriber's IP address and session state return to the pool immediately, rather than staying tied up until some other process notices the subscriber is gone.

At Asteraix

What We Can Do at Asteraix

AsterNOS-VPP implements both PPPoE client and PPPoE server functionality, turning a standard Layer 3 gateway into a carrier-grade BNG capable of handling client dial-ups, centralized AAA billing, and NAT-based Internet access — with the PPPoE server feature fully optimized for the ET2508 open gateway's Marvell OCTEON 10 hardware.

  • Straightforward PPPoE client setup: Binding a physical interface with pppoe-client <id> and configuring authentication on the resulting dialer interface with interface dialer <id> → ppp chap username <user> <password> gets a branch or edge device dialed in and authenticated in just a few commands — as used directly in AsterNOS's own documented WireGuard-over-PPPoE and IPSec-over-PPPoE deployment examples.

  • Full PPPoE server configuration: pppoe-server enable turns on the server function globally, and interface pppoe-server <id> — configured with service-name and ac-name — defines exactly what a client's PADI discovery request will actually find and connect to.

  • RADIUS-integrated AAA out of the box: radius server <ip> mode pppoe (with auth-type chap and a configured passkey) ties subscriber authentication directly to a RADIUS backend, letting AsterNOS-VPP function as a real vBNG with centralized authentication rather than a local-only credential store.

  • Flexible IP allocation models: A local IP pool can handle address assignment on the gateway itself, or that responsibility can be shifted entirely to RADIUS (no remote-ip-pool <pool-name> unbinds the local pool), supporting both a simple baseline deployment and a fully centralized, RADIUS-driven architecture as a network scales.

  • Clear operational behavior on RADIUS failure: AsterNOS-VPP does not automatically fall back to a local credential database if a configured RADIUS server becomes unreachable — the RADIUS binding has to be removed manually before local authentication takes over — a deliberate design choice operators should plan around rather than a bug to work around.

  • Purpose-built for cost-effective, carrier-grade access: With PPPoE support delivered on the Marvell OCTEON 10-based ET2508, AsterNOS-VPP brings carrier-grade BNG capability to a whitebox platform at a fraction of the cost of traditional vendor BNG hardware.