What Is a BNG (Broadband Network Gateway) and Where It Fits

Between the access network that physically reaches your customers and the IP core that reaches the internet sits a device most subscribers never hear about and most operators cannot live without: the Broadband Network Gateway (BNG). Older documentation calls it a BRAS — Broadband Remote Access Server — and the two terms are used interchangeably. Whatever you call it, its job is singular and critical: it converts thousands of anonymous, untrusted access connections into authenticated, addressed, rate-limited, and metered subscriber sessions. Everything your business depends on — who is connected, at what speed, on which plan, having used how much data — is enforced here.

That concentration of function is exactly why the BNG deserves careful design. It is simultaneously the place where your network meets your billing system and the place where, if it fails, every subscriber behind it goes dark at once. Understanding what the BNG does, where it sits in the traffic path, and how to make it redundant is foundational to running a broadband network that scales past a few thousand customers without nightly fire-fighting.

What a BNG actually does

The BNG is the aggregation and policy-control point for subscriber traffic. Its responsibilities cluster into five jobs that together define a “subscriber on a plan” rather than just “a link that is up.”

The unifying idea: a packet arrives at the BNG as raw access traffic and leaves it as the traffic of a known subscriber whose service level and usage are already accounted for. Strip the BNG out and you have connectivity but no control — no way to tell paid from unpaid, fast plan from slow, or to produce an honest invoice.

PPPoE vs IPoE: two ways to identify a subscriber

The BNG has to know which subscriber each packet belongs to, and there are two dominant models. PPPoE wraps each session in a point-to-point tunnel: the customer device dials in with a username and password, the BNG relays those credentials to RADIUS, and a session is built. It is explicit, easy to authenticate per-user, and maps cleanly to per-subscriber accounting — which is why it remains common in residential broadband. The cost is overhead and the operational weight of managing millions of sessions.

IPoE (IP over Ethernet) skips the PPP tunnel and identifies subscribers by lower-layer signals — DHCP option fields, the access-node circuit identifier, or VLAN — letting the BNG authorize a session without a username/password dialog. IPoE is lighter and increasingly preferred in fiber deployments, but it leans harder on the access network to deliver trustworthy identifying information, and getting that plumbing right (option 82, line identification) is where IPoE deployments tend to stumble. Many networks run both, choosing per service type.

Where the BNG sits in the path

Trace a packet from a residential customer: it leaves the home router, crosses the access network — GPON OLT, DSLAM, or fixed-wireless backhaul — is aggregated upward, and terminates at the BNG. From there it enters your IP/MPLS core and heads to upstream transit or peering. Return traffic retraces the path. The defining characteristic is that every subscriber packet, in both directions, passes through the BNG. Nothing reaches a customer or leaves them without crossing it.

That position is what makes the BNG powerful and dangerous in equal measure. Powerful, because it is the one place to enforce policy consistently for an entire customer base. Dangerous, because it is a textbook single point of failure and a concentration of state — every active session is live context held in the device's memory, which cannot simply be reconstructed instantly elsewhere.

Centralized vs distributed deployment

Two architectures dominate. Centralized places a small number of large BNGs at core sites; all subscriber traffic is backhauled to them. It is simpler to manage, cheaper to license, and easier to keep configuration consistent — but it maximizes backhaul (every customer's traffic travels to the center and back) and maximizes blast radius (one BNG failure can darken a huge region). Distributed pushes smaller BNGs toward the edge, closer to access nodes. That cuts backhaul, localizes failures, and scales more gracefully, at the cost of more devices to operate and more places for configuration to drift.

A very common evolution is to start centralized while subscriber counts are modest, then distribute as the network grows and the blast radius of a single central BNG becomes unacceptable. The decision is rarely permanent — it tracks subscriber density, backhaul economics, and how much an outage now costs you.

Why the BNG is a scaling pressure point and a SPOF

Because all sessions converge here, the BNG hits limits before almost anything else: the number of concurrent sessions it can hold, the routes and queues it can program, the RADIUS transaction rate it can sustain, and the raw throughput of subscriber traffic it forwards. Hit any of those ceilings and the symptoms are ugly — new sessions fail to authenticate, reconnects stall, or the device sheds load. Capacity planning for a BNG is about headroom on the limiting resource, which is often session count or control-plane (RADIUS) rate, not bandwidth.

The single-point-of-failure problem is sharper still. When a BNG goes down, it does not degrade gracefully — every subscriber it served drops simultaneously, and they all attempt to reconnect at once. That reconnect storm hammers RADIUS and the surviving BNGs, sometimes turning one failure into a cascade. A subtle related risk: a brief BNG reboot can desynchronize accounting, so the billing system thinks sessions are still up when they are not, or vice versa. Designing the BNG and its AAA for failure is not optional past a few thousand subscribers.

Redundancy and the RADIUS/billing tie-in

Resilience comes in layers. Spread the risk: run multiple BNGs and distribute subscribers across them so no single failure takes down everyone. Provide failover: mechanisms exist for a backup BNG to take over sessions or for the access network to re-home subscribers to a healthy gateway, reducing the duration of an outage. Make AAA redundant too: a single RADIUS server is its own SPOF — if it is unreachable, no one can authenticate even though the BNGs are fine, so run redundant RADIUS with sane timeouts and retry behavior. Protect the control plane: stagger or rate-limit reconnects where possible so a recovery does not become a self-inflicted denial of service.

The deeper payoff of getting the BNG–RADIUS–billing chain right is operational, not just protective. When these three are tightly integrated, the subscriber's experienced speed, instant reconnection on payment, and the usage figures on the invoice all flow from the same source of truth. Enabling, disabling, upgrading, or rate-limiting a customer becomes a billing event that propagates automatically through RADIUS to the BNG — not a manual router login. ISP management platforms such as ISP Digital exist precisely to keep that chain in sync so provisioning feels automatic. For the broader addressing context the BNG depends on, see IP address planning for an ISP and, where IPv4 is scarce, CGNAT for ISPs.

Common mistakes

• One BNG, one RADIUS — two single points of failure stacked; redundancy on both is the baseline.
• Planning capacity by bandwidth alone — session count and RADIUS rate usually run out first.
• Ignoring the reconnect storm — failover that does not account for mass simultaneous re-auth can cascade.
• Loose accounting integration — desynced session start/stop produces wrong invoices and angry customers.
• Over-centralizing for too long — a single central BNG's blast radius grows quietly until one outage is catastrophic.
• Sloppy IPoE line identification — option 82 / circuit-ID plumbing errors authorize the wrong subscriber or none at all.

The takeaway

The BNG is the unglamorous heart of a broadband operation — invisible to customers, indispensable to the business. It is where a connection becomes a subscriber, where your speed plans and data quotas are actually enforced, and where the numbers on every invoice are born. Treat it accordingly: design it for failure, not just for traffic; plan capacity around session and control-plane limits, not bandwidth alone; and keep the BNG, your AAA, and your billing system in lockstep so provisioning is an automatic consequence of a payment rather than a midnight router login. Get that right and the BNG quietly does its job for years; get it wrong and it is the box that wakes you up.