High-Performance XDP BNG · CGNAT · QoS · Low-Latency · Subscriber Management & AAA
Broadband Gateway · Subscriber Management & AAA
Standards-Based AAA That Plugs Into Your RADIUS — and Enforces Every Plan in the XDP Fast Path
PPPoE and IPoE subscribers on the same box, authenticated and accounted through your existing RADIUS, with live CoA to change a rate, suspend for collections, or reactivate on payment — no reconnect, no truck roll. The control plane authorizes the session; the XDP data plane enforces per-plan rate and forwarding at line rate. Static-public and CGNAT subscribers run concurrently on one server.
Authentication is a control-plane decision. Enforcement is a data-plane job. BNGSOFT keeps them separate: RADIUS authorizes the subscriber, and the moment it does, the plan is pushed into the XDP pinned maps so forwarding and shaping happen at line rate — not in a slow software path.
PPPoE
+ IPoE
+ IPoE
both access models on the
same box, concurrently
same box, concurrently
RADIUS
+ CoA
+ CoA
auth · accounting · live
Change-of-Authorization
Change-of-Authorization
~64k
concurrent sessions per
commodity server
commodity server
Line
RATE
RATE
per-plan rate enforced in
the XDP fast path
the XDP fast path
The BNGSOFT BNG is a standards-based NAS: it speaks RADIUS authentication, accounting and CoA to your RADIUS/billing server, so it drops into an existing operator stack without bespoke integration. The BNGSOFT BNG service terminates PPPoE and IPoE sessions and, on every successful authentication, writes the subscriber's IP→interface mapping and per-plan QoS into the bngxdpd pinned maps. From that instant, the high-performance XDP data plane forwards and rate-shapes that subscriber without ever returning to the control plane.
1 · Two access models, one box — PPPoE and IPoE
Operators rarely have a single, clean access model. Some plant is PPPoE; some is DHCP/IPoE; some sites stack VLANs. BNGSOFT terminates all of it on the same server, with dynamic per-customer VLANs created automatically on the first packet seen — including QinQ / stacked VLANs — so you do not pre-provision a VLAN per subscriber.
PPPoE · PER-SESSION NETDEV
A real interface per session.
- Each PPPoE session terminates on its own subscriber netdev (
ppp<N>). - Clean per-session attach point for policy, accounting and the XDP fast path.
- Standard PPPoE discovery/auth (PAP/CHAP) toward your AAA.
- Natural fit for per-subscriber static IPs and routed subnets.
IPoE · IP-KEYED SESSIONS
DHCP access, shared interface.
- IPoE (DHCP-based) sessions share an interface and are keyed by IP.
- No per-session netdev — the IP is the session identity in the data plane.
- Suits large DHCP estates without a netdev explosion.
- Same RADIUS auth/accounting/CoA pipeline as PPPoE.
Dynamic VLANs, including QinQ. VLAN monitoring watches the wire and auto-creates a subscriber VLAN on the first packet — single-tagged or stacked (QinQ). You don't maintain a static VLAN map per customer; the box learns it as subscribers come online.
2 · AAA via RADIUS — authentication, accounting and CoA
The BNG is the NAS (authenticator and accounting client). Your RADIUS server makes the policy decision; the BNG carries it out. Three legs of AAA work exactly as the standard defines them, so any compliant RADIUS/billing platform interoperates.
AUTHENTICATION
Access-Request → Accept / Reject.
- Subscriber connects (PPPoE/IPoE) → BNG sends
Access-Request. Access-Acceptcarries the policy attributes;Access-Rejectrefuses the line.- Local chap-secrets mode for deployments without RADIUS.
ACCOUNTING
Start · Interim-Update · Stop.
Acct-Status-TypeStart / Interim-Update / Stop.- Carries
Acct-Input/Output-Octets,-Packets,-Gigawords,Acct-Session-Time. Acct-Interim-Intervalsets the usage-report cadence.
CoA
Change a live session.
- Change-of-Authorization mutates an already-connected session.
- Rate change · reactivate · disconnect — no subscriber reconnect.
- The lever behind collections and instant plan changes.
A session lifecycle, end to end ILLUSTRATIVE FORMAT
The exchange below shows the standard RADIUS message flow for a PPPoE subscriber on a generic node — authentication, the data-plane push, accounting, and a mid-session CoA rate change — in the form these messages take. Attribute names follow the RADIUS standard; the vendor rate-limit attribute is deployment-specific (see note).
node-a aaa[ctl] — subscriber connects on ppp0 (PPPoE, dynamic VLAN auto-created)
→ Access-Request User-Name="cust48217" Service-Type=Framed
← Access-Accept
Framed-IP-Address = 203.0.113.42
rate-limit = "120M/120M" (vendor attr; up/down)
Acct-Interim-Interval = 300
⇒ data-plane push: customer_ip_map[203.0.113.42] = ppp0; iface_config_map[ppp0] = plan(120M/120M)
— XDP now forwards + shapes this subscriber at line rate —
→ Accounting Acct-Status-Type=Start Acct-Session-Id="0x4f1a…"
→ Accounting Acct-Status-Type=Interim-Update In-Octets=8.4G Out-Octets=42.1G Session-Time=3600
node-a aaa[ctl] — operator upgrades the plan in billing; RADIUS issues CoA
↺ CoA-Request rate-limit="300M/300M" (same live session)
← CoA-ACK ⇒ iface_config_map[ppp0] = plan(300M/300M) — no reconnect, shaping updated in place
→ Access-Request User-Name="cust48217" Service-Type=Framed
← Access-Accept
Framed-IP-Address = 203.0.113.42
rate-limit = "120M/120M" (vendor attr; up/down)
Acct-Interim-Interval = 300
⇒ data-plane push: customer_ip_map[203.0.113.42] = ppp0; iface_config_map[ppp0] = plan(120M/120M)
— XDP now forwards + shapes this subscriber at line rate —
→ Accounting Acct-Status-Type=Start Acct-Session-Id="0x4f1a…"
→ Accounting Acct-Status-Type=Interim-Update In-Octets=8.4G Out-Octets=42.1G Session-Time=3600
node-a aaa[ctl] — operator upgrades the plan in billing; RADIUS issues CoA
↺ CoA-Request rate-limit="300M/300M" (same live session)
← CoA-ACK ⇒ iface_config_map[ppp0] = plan(300M/300M) — no reconnect, shaping updated in place
Illustrative format — a representation of the standard RADIUS auth/acct/CoA exchange and the corresponding pinned-map writes, not a captured log. The RADIUS attribute names (Framed-IP-Address, Acct-Status-Type, Acct-Interim-Interval, CoA-Request/ACK) are standards-defined; the
rate-limit "120M/120M" attribute is vendor/dictionary-specific to the deployment. Pinned map names customer_ip_map and iface_config_map are real bngxdpd maps.3 · The attributes that drive the data plane
The value of RADIUS here is that the Access-Accept attributes are not just policy metadata — they program the forwarding plane. When the control plane parses the accept, it translates these attributes into concrete pinned-map state that the XDP program reads on every packet.
| RADIUS attribute | What it means for the subscriber | How the data plane uses it |
|---|---|---|
| Framed-IP-Address | The subscriber's IP — a static per-subscriber address or one assigned from a pool. | Becomes the key in customer_ip_map → identifies the subscriber's interface for fast-path forwarding. |
| Framed-Route | A routed subnet handed to the customer (e.g. a business with a /29 behind the CPE). | Installed as a subscriber route so the whole block forwards to that session. |
| rate-limit (vendor) | The plan cap, e.g. "120M/120M" upload/download. |
Written into iface_config_map → the XDP program shapes to this rate at line rate. |
| Acct-Interim-Interval | How often the BNG reports usage back to billing. | Sets the cadence of Interim-Update accounting records (octets/packets/gigawords). |
| Session / Idle-Timeout | Maximum session life / idle cut-off for the subscriber. | Drives control-plane session teardown and a clean Acct-Stop. |
| Service-Type | The kind of service the subscriber is being granted (e.g. Framed). | Shapes how the session is set up in the control plane. |
Static-public and CGNAT on one box. A subscriber with a
Framed-IP-Address of a per-subscriber /30 or /32 public address and a CGNAT subscriber on a private address behind the carrier NAT run concurrently on the same server. The attribute set decides which path a subscriber takes — there's no separate box, image or licence tier for "static" versus "CGNAT" customers.4 · Account lifecycle — expire, suspend, reactivate without a truck roll
Billing state is enforced cleanly at the access edge. An account that is expired or suspended is refused at authentication; an account that pays is restored the instant the payment posts — by CoA, on the live session, with no manual intervention on the box.
EXPIRED / SUSPENDED
Refused cleanly at auth.
- RADIUS answers
Access-Rejectwith aReply-Message— e.g. "Your Account has been expired" or "…suspended". - The CPE is cleanly refused, or steered to a captive portal — no half-up session.
- No bandwidth is granted, so there's nothing to police or leak.
REACTIVATION ON PAYMENT
Restored by CoA, instantly.
- Payment posts → RADIUS issues a CoA reactivate / rate-restore.
- Service returns the moment payment clears — no reconnect, no session kill.
- No truck roll, no manual intervention on the BNG.
What a suspended subscriber sees ILLUSTRATIVE FORMAT
node-b aaa[ctl] — subscriber "cust90431" attempts to connect; account is past due
→ Access-Request User-Name="cust90431"
← Access-Reject Reply-Message="Your Account has been suspended"
— CPE is refused; subscriber can be steered to a captive/payment portal —
node-b aaa[ctl] — payment posts in billing → RADIUS sends CoA to reactivate
↺ CoA-Request reactivate rate-limit="120M/120M"
← CoA-ACK ⇒ service restored on the live attempt — no truck roll, no manual kill
→ Access-Request User-Name="cust90431"
← Access-Reject Reply-Message="Your Account has been suspended"
— CPE is refused; subscriber can be steered to a captive/payment portal —
node-b aaa[ctl] — payment posts in billing → RADIUS sends CoA to reactivate
↺ CoA-Request reactivate rate-limit="120M/120M"
← CoA-ACK ⇒ service restored on the live attempt — no truck roll, no manual kill
Illustrative format — the Reply-Message strings shown ("Your Account has been expired/suspended") are real operator-facing messages used in this lifecycle; the surrounding log layout is a representation, not a captured transcript. The reactivation decision is made by the operator's RADIUS/billing system; the BNG carries it out.
Collections without a phone call. Suspend-on-non-payment and reactivate-on-payment become billing-system events, not field operations. The subscriber experience is immediate in both directions, and your NOC never touches the box.
5 · Control plane authorizes, data plane enforces
This is the architectural core. Authentication and policy decisions are a control-plane concern; per-packet forwarding and shaping are a data-plane concern. BNGSOFT binds them through the XDP pinned maps so that authorization is rich and flexible while enforcement is fast and cheap.
CONTROL PLANE · AUTHORIZE
Integrated PPPoE / IPoE access service
RADIUS
auth · accounting · CoA
- Terminates PPPoE / IPoE sessions and speaks RADIUS to your AAA.
- Parses Access-Accept attributes into a concrete per-subscriber policy.
- On auth (and on CoA) writes the pinned maps: IP→interface and per-plan QoS.
- Handles lifecycle: Start/Interim/Stop accounting, timeouts, teardown.
DATA PLANE · ENFORCE
bngxdpd · XDP fast path
Line rate
forward · shape · per packet
- Reads
customer_ip_mapto forward each packet to its subscriber. - Reads
iface_config_mapto shape to the subscriber's plan rate. - No round-trip to the control plane on the hot path — it's all in XDP.
- Same maps drive QoS, CGNAT and the rest of the data plane.
Why the split matters: the control plane can be as rich as RADIUS and your billing logic demand — per-plan policy, lifecycle, CoA — without putting any of that cost in the forwarding path. The data plane only ever reads a small, fast pinned-map lookup. Authorize once, in software; enforce every packet, in XDP.
6 · Scale — ~64k sessions per box, built for the mass reconnect
A 2×100G commodity server carries roughly 64,000 concurrent sessions (throughput-driven; see methodology). Just as important as the steady-state number is what happens during a mass reconnect — an upstream flap, a maintenance window, a PPP/DHCP storm where tens of thousands of session events arrive in a burst. The session intake queue is sized for exactly that bulk re-sync, so session events are absorbed rather than dropped.
STEADY STATE
~64k sessions / box.
- Per commodity server, PPPoE + IPoE combined.
- Static-public and CGNAT subscribers concurrently.
BULK RE-SYNC
Sized for the storm.
- Intake queue holds tens of thousands of events.
- A mass reconnect after an upstream flap is absorbed, not dropped.
CLEAN RECOVERY
No lost sessions.
- Session events survive the burst → subscribers re-establish cleanly.
- Accounting and policy stay consistent through the event.
The failure mode this prevents: an under-sized intake queue silently drops session events during a reconnect storm, leaving subscribers half-provisioned — online but with no policy, or invisible to accounting. Sizing the queue for the bulk re-sync case is what keeps a routine upstream flap from turning into a fleet of mis-provisioned sessions.
7 · What it means for the business
Subscriber Management & AAA · operator value
Plugs into your existing stackStandards-based RADIUS auth/accounting/CoA means the BNG is a drop-in NAS for the RADIUS and billing platform you already run — no bespoke integration.
Instant policy by CoAPlan upgrades, suspends and reactivations are live changes to the running session — no subscriber reconnect, no manual session kill on the box.
Collections without a truck rollSuspend-on-non-payment and reactivate-on-payment become billing events; service returns the moment the payment posts.
One box, every subscriber typePPPoE and IPoE, static-public and CGNAT subscribers all run concurrently on the same server — fewer boxes, fewer images, simpler ops.
Per-plan rate at line rateThe control plane authorizes; the XDP data plane enforces each plan's shaping per packet with no hot-path round-trip — rich policy, cheap enforcement.
Scales and survives the storm~64k sessions per box, with an intake queue sized for mass-reconnect bulk re-sync so an upstream flap doesn't drop session events.
The bottom line
BNGSOFT gives you standards-based AAA that speaks to the RADIUS and billing systems you already own, with live CoA for plan changes, suspends and reactivations that need no reconnect — and an architecture that authorizes in the control plane while enforcing every packet in the XDP data plane.
PPPoE and IPoE, static-public and CGNAT, all on one commodity box at ~64k sessions. The RADIUS server stays yours; the BNG is the fast, line-rate enforcer that does exactly what it authorizes.
Methodology and honest framing: This document describes the Subscriber Management & AAA feature set of the BNGSOFT XDP BNG. The BNG functions as the NAS (authenticator and accounting client); the RADIUS/AAA server is the operator's own external system, and all authorization, lifecycle and CoA decisions are made there — the BNG carries them out. Access protocols supported are PPPoE and IPoE (DHCP-based) on the same box, with dynamic per-customer VLANs auto-created on first packet by VLAN monitoring, including QinQ / stacked VLANs. The per-session netdev model (
ppp<N>) applies to PPPoE; IPoE sessions share an interface and are keyed by IP. The control plane is the BNGSOFT BNG access service; on each successful authentication (and on CoA) it writes the subscriber's IP→interface mapping and per-plan QoS into the bngxdpd pinned maps (customer_ip_map, iface_config_map), after which the XDP data plane forwards and rate-shapes that subscriber in the fast path. RADIUS behaviour described is standards-based: authentication (Access-Request → Access-Accept/Access-Reject), accounting (Acct-Status-Type Start / Interim-Update / Stop carrying Acct-Input/Output-Octets, -Packets, -Gigawords, Acct-Session-Time), and CoA (Change-of-Authorization) for live rate change / reactivate / disconnect without a subscriber reconnect. A local chap-secrets mode is supported for deployments without RADIUS. Policy attributes referenced — Framed-IP-Address, Framed-Route, Acct-Interim-Interval, Session/Idle-Timeout, Service-Type — are standards-defined; the vendor rate-limit attribute (shown as "120M/120M") and its exact name are deployment/dictionary-specific and will differ per RADIUS dictionary. The account-lifecycle Reply-Message strings ("Your Account has been expired" / "…suspended") are real operator-facing messages used to refuse expired/suspended accounts at authentication. Both static-public-IP subscribers (a per-subscriber /30 or /32) and CGNAT-private subscribers run concurrently on the same box. Scale figure: approximately 64,000 concurrent sessions per 2×100G commodity server (throughput-driven — NIC usable line rate ÷ ~3 Mbps busy-hour per-subscriber rate, capped by a ~131,072-entry per-node table ceiling; exact numbers depend on hardware, NIC and traffic mix); the session intake queue is sized for bulk re-sync (tens of thousands of events) so a mass reconnect — e.g. after an upstream flap — is absorbed without dropping session events. ILLUSTRATIVE FORMAT Every terminal/log block in this document (the session-lifecycle RADIUS exchange in Section 2 and the suspended-subscriber exchange in Section 4) is an illustrative representation of the standard RADIUS message flow and the corresponding pinned-map writes — not a verbatim captured log; generic node names (node-a, node-b) and example user identifiers are used. The standards-defined RADIUS attribute and message names within them are accurate; the surrounding layout, IP addresses, session IDs and usage figures are illustrative. Prepared as a management and operations overview for large-scale operators. Subscriber Management & AAA is a feature set of the BNGSOFT XDP BNG product.