This is the starting point for dismantling Aether, a multi-vBNG ISP emulation system that I created. Since networking has historically been more closed-source, this is my effort on sharing knowledge on production grade networking machines that usually hide behind white papers.
Topics
Broadband Network Gateways
Broadband Network Gateways ( BNG ) or also interchangebly called Network Access Servers ( NAS ) are the brains of the ISP infrastructure. They are the critical plane where user traffic funnels through towards the internet border- critical infrastructure that makes the modern internet possible.
Why do we need a BNG ?
When you have millions of subscribers sharing network infrastructure, you need something that knows who is connected, what they are allowed to do, and how much they’re allowed to use. Authentication, authorization, policy enforcement, traffic shapping all at line rate, per subscriber. That is the BNG’s job.
Split it in two- Control Plane and Data Plane
BNGs are split into two parts: the control plane, which handles the authentication, authorization, QoS etc. logic; the data plane, which contains packets moving at line rate. Most of the complexity comes from syncing these two planes at scale
The Control Plane
Control plane is a commonly used term in networking which means the brain of the system. In networking, the control plane is responsible for identifying a subscriber, session management, traffic shaping ( limiting speeds ), and policy application. Authentication are handled through different protocols like RADIUS, DIAMETER, 802.1x and so on. Aether, my custom implementation of a virtual BNG ( vBNG ) uses RADIUS for authentication and authorization.
Subscribers authenticate through PPPoE or IPoE. PPPoE carries its own link-layer authentication via PPP- CHAP being the standard, where the password never travels in plaintext. IPoE skips the PPP handshake entirely- the BNG identifies the subscriber through Option 82, a field injected by the DHCP relay agent at the access switch that tells the BNG where the subscriber is physically connected. Another blog on Option 82 coming up.
This is also where session state lives. The control plane maintains a table of active subscribers: who is online, what IP they were assigned, what policy is applied, how long they have been connected. That table is the source of truth for everything the data plane does.
The Data Plane
The data plane is where the actual packet forwarding happens- taking subscriber traffic and moving it toward the internet border at line rate, with per-subscriber policy enforced on every packet.
It consumes policies defined by the control plane and applies those policies at a per-packet level. Complex logic should never reside in the data plane, since it prioritizes speed and throughput the most. For Aether, I use the default linux networking stack as the data plane, which is not production-grade but more approachable for a first-timer.
Aether
Aether is my implementation of a python-based emulation of the ISP infrastructure, which includes writing my own vBNG in Python.
I chose python because it was convinient and high performance was not of concern.
In the hosted demo, it features two vBNGs, a simulation layer so that demo users are able to test host-related features out ( authentication, traffic shaping etc.). It contains a Next.js Dashboard to showcase the features such as CRUD for subscribers and plan, simulation, BNG health monitoring, RADIUS Disconnects, and adding a plan to a subscriber.
Resources
A few of these are the resources I used when creating Aether. The broadband forums white papers are something I discovered after talking with network operators after Aether was already built. Hence, Aether does not comply with the specifications of Broadband forums TRs.
- TR-101: Migration to Ethernet-Based Broadband Aggregation
- TR-178: Multi-service Broadband Network Architecture and Nodal Requirements
- TR-459: Multi-Service Disaggregated BNG with CUPS Issue 2
- RFC 3046: DHCP Relay Agent Information Option
- RFC 2131: Dynamic Host Configuration Protocol
What’s next?
This post serves as the starting point of the series of posts where I dive deep into the implementation of Aether and its different components. For upcoming posts, with tag #Aether, we will be going technically deep over the multiple components and services that make up Aether.