Bluedot Quantum IPoE BNG — Theory of Operations
This document explains how the BlueDot Quantum IPoE BNG works in operation — what it does with a subscriber's traffic, how a subscriber moves from "just plugged in" to "connected and paying," and what you, the operator, see and control while the box runs. It is a theory of operations, not an installation guide or an API reference. The goal is that after reading it you can look at the BNG's health page, its session list, and its metrics and know what the numbers mean and why they move.
A BNG (Broadband Network Gateway) sits at the edge of your access network. Its job is to take raw packets coming in from subscriber routers and turn them into managed, authenticated, rate-limited, and accounted sessions — deciding who is allowed on, how fast they may go, where their traffic is sent, and how much they used. The BlueDot BNG does this job for IPoE subscribers on commodity x86 hardware, and it is built to replace a chain of MikroTik-class boxes with a single architecture that grows by adding nodes rather than by swapping in a bigger box.
The single most important idea in this document — the one everything else hangs on — is the split between two "planes":
- The data plane forwards every byte of subscriber traffic at line rate. It is fast, simple, and never talks to a subscriber-management database on a per-packet basis.
- The control plane holds all the intelligence: who is who, what plan they are on, when their session started, when it expires, and what to tell the data plane to do.
Understanding where a given behaviour lives — in the fast data plane or in the thinking control plane — is the key to operating and troubleshooting the BNG. This document is organised around that split: first the shape of the system, then the data plane, then the control plane, then a walk-through of the full life of a subscriber, and finally the practical business of running the box.
Scope and one caveat. The product is deliberately narrow: IPoE only (no PPPoE), IPv4 only in this phase, an L3-routed access network (no VLAN per subscriber), and commodity hardware. One caveat colours the whole document and is repeated where it matters: this Alpha, Community Edition build ships with a local authentication back-end standing in for a full RADIUS server. Everything else — the data plane, DHCP, the session lifecycle, captive portal, accounting counters, persistence, and the management API — is real and running. The production RADIUS client is a well-defined future addition, noted at each point where it changes what you would see.
The System at a Glance: Two Planes, Three Processes
The BNG is not one program. It is three cooperating processes, and knowing which one does what is the foundation for everything that follows.
Operator / Carrier systems
RADIUS · OSS/BSS · Captive Portal · NMS (Prometheus, Syslog)
│ (management NIC, ordinary Linux)
┌────────────────▼─────────────────────────────────┐
│ CONTROLLER (Node.js) │ ← the "brain"
│ Session Manager (the lifecycle state machine) │
│ Embedded DHCP server + address pools │
│ AAA client (RADIUS / local) │
│ Accounting · Persistence (SQLite) · REST API │
└────────────────┬─────────────────────────────────┘
│ gRPC (secure, can cross hosts)
┌────────────────▼─────────────────────────────────┐
│ VPP_BRIDGE (Go) │ ← the "translator"
│ Turns controller requests into VPP API calls │
└────────────────┬─────────────────────────────────┘
│ VPP binary API (shared memory)
┌────────────────▼─────────────────────────────────┐
│ VPP DATA PLANE (DPDK) │ ← the "muscle"
│ IPoE plugin: per-subscriber session table, │
│ inline rate limiting, captive filter, forwarding│
│ Access NIC ⇄ Core / Uplink NIC (Intel E810) │
└───────────────────────────────────────────────────┘
│ │
Edge routers Upstream / core
(relay DHCP, insert Option 82) (default route out)The data plane — VPP. This is the muscle. It runs in userspace on DPDK and drives the two high-speed NICs: an access-facing NIC (toward subscribers, via edge routers) and a core/uplink-facing NIC (toward the internet). Once a subscriber is set up, every one of their packets is handled here, at line rate, with no involvement from the controller. This is what lets a single node carry on the order of 100,000 concurrent subscribers on a commodity Dell R360-class server.
The translator — vpp_bridge. A small Go process that connects the controller to VPP. The controller does not speak VPP's low-level API directly; it makes a handful of high-level requests ("add this session," "change this rate," "give me the counters") and vpp_bridge turns them into VPP calls. Because the link between them is gRPC, the controller can even run on a different machine from the data plane.
The brain — controller. A Node.js process that holds everything intelligent: the Session Manager (the state machine that tracks each subscriber's lifecycle), the embedded DHCP server and address pools, the AAA client that authenticates subscribers, the accounting engine, the persistence store that survives restarts, and the REST API that you and your other systems use to see and control the box.
The management NIC is an ordinary Linux interface — not DPDK. All of your out-of-band traffic rides here: RADIUS (UDP 1812/1813, and 3799 for CoA), the gRPC link to vpp_bridge, the REST API, Prometheus scrapes, and SSH.
Start-up order matters: VPP first, then vpp_bridge, then the controller. The controller expects the data plane to be reachable when it comes up so it can reconcile and, if needed, re-program sessions.