BNG Cluster

New sessions land on the lightest gateway — immediately, not eventually
bngclusterd · a control plane for the BNGs you already run

When every customer VLAN is enabled on every BNG, which gateway a subscriber lands on is decided by whichever one answers first. Load evens out eventually, by accident, over days. BNG Cluster replaces that accident with a decision: each gateway knows what the others are carrying, and the lightest one answers first.

0 ms Lightest node answers immediately — computed from live load at 53% of capacity
160 ms Busiest node holds back — computed at 80% of capacity, matching the formula exactly
6 s Peer loss noticed a gateway that stops gossiping is marked down
Observe Default mode computes and logs; changes nothing until you arm it

What it does

Every gateway in the cluster tells the others what it is carrying — sessions, capacity, health, which VLANs it serves. From that shared picture each one works out its own rank, and turns that rank into a single number: how long to wait before answering a new PPPoE connection request.

The lightest gateway waits zero. The busiest waits longest. The customer's router talks to whichever replies first, so new sessions go where there is room — from the first connection, not after two days of drift.

Without a cluster every gateway answers at once — the winner is arbitrary 0 ms Gateway A53% loaded Gateway B65% loaded Gateway C80% loaded all three reply together load evens out over days, by accident With BNG Cluster each gateway waits in proportion to what it already carries 0 ms 70 ms 160 ms Gateway A53% loaded replies first — the session lands here Gateway B65% loaded Gateway C80% loaded The bar is how long that gateway holds back before answering.
Delays computed from live load on a two-node cluster: a node ranked at 53% of its capacity answered at 0 ms, one ranked at 80% at 160 ms. The gap is the difference in how full they are, not a fixed setting.

How a session gets placed

1
Gateways share what they carry Each one gossips its session count, capacity, health and VLAN coverage to the others. Every gateway holds the full table, so any of them can describe the whole cluster.
2
Each works out its own rank Load as a share of its own capacity, compared against the rest. A 3,000-session gateway at 1,600 is lighter than a 2,000-session gateway at 1,600.
3
Rank becomes a delay The lightest answers at once; the others hold back in proportion. No traffic is redirected and no session is touched — only the order in which gateways reply.
4
The customer's router chooses Most routers accept the first offer they receive, which is what the delay relies on. Nothing changes on the subscriber side and no CPE configuration is involved.

Planned maintenance

A gateway can be told to drain. It stops competing for new sessions, so the cluster stops sending it work, and its existing sessions can be ended deliberately rather than dropped by a reboot nobody scheduled.

The cluster reports what actually happened afterwards: how many sessions left that gateway, and how many arrived on the others. If it cannot read a peer's load it says so, rather than reporting zero arrivals as though it had measured them.

What it runs on

The BNGs you already own. It is a control process on each gateway — not a licensed capability tier, not a redundant chassis, and not new hardware. It reads state, computes, and adjusts one setting. Its resource use has not yet been characterised on a gateway at full subscriber load; ask us for the current figure rather than assuming one.

No controller, no leader

Gateway A A 1600 / 3000 53% B 1300 / 2000 65% C 1600 / 2000 80% holds the whole picture Gateway B A 1600 / 3000 53% B 1300 / 2000 65% C 1600 / 2000 80% holds the whole picture Gateway C A 1600 / 3000 53% B 1300 / 2000 65% C 1600 / 2000 80% holds the whole picture Each gateway tells every other what it is carrying. Any one of them can describe the whole cluster.
There is no controller to deploy and nothing to fail over. A gateway that loses contact with the others keeps serving its own subscribers — its address range never overlaps theirs.

What happens when a gateway fails

The honest answer first, because it is the one that matters at 3am: the sessions on that gateway end. They are not carried across to another BNG. Those subscribers reconnect, and the question is only where they land.

Gateway lost Its sessions end. Subscribers begin reconnecting. t = 0 Peers notice It has stopped gossiping. Marked down, kept visible. ~6 s Survivors re-rank The dead gateway is dropped from the sum. Delays recomputed. ~6–12 s Subscribers land On whichever surviving gateway has the most room, not the fastest. CPE retry Only in enforce mode. In the default observing mode the recalculation happens and is written to the log — it is not applied. On a default install, losing a gateway changes nothing about where reconnecting subscribers go.
The 6–12 second figure is the cluster's reaction time, taken from the code, not the subscriber's outage. What the customer experiences is their own router's PPPoE retry cycle, which is longer and varies by CPE.

What the survivors do

A gateway that stops gossiping is marked down after six seconds and taken out of the ranking. The remaining gateways are now measured against each other alone, so whichever has the most room becomes the one that answers first — and the subscribers reconnecting from the failure are drawn to it rather than piling onto whichever gateway happens to be quickest to reply.

The failed gateway stays visible in the cluster as down. It does not quietly disappear from the picture, which is what makes it obvious that something is missing rather than merely quiet.

Two things to plan for

Addresses. Each gateway keeps its own pool. A failed gateway's range goes unused until it returns — nothing hands it to a survivor. Size pools for the load a gateway may have to absorb, not the load it carries on an ordinary evening.

Losing contact is not losing the gateway. If gateways stay up but can no longer reach each other, each keeps serving its own subscribers on its own address range. Balancing reverts to what it was before the cluster existed. Nothing breaks and nothing is double-allocated — it simply stops optimising until they can talk again.

What we have observed, and what we have not

The timings above are what the software does, read from its own behaviour and its code. They are not a service-level commitment, and we will not present them as one until they have been measured against a real failure.

What it does not do

Read this section twice. These are the limits, stated plainly.

What you see

Every gateway in the cluster is asked, not just one — because disagreement between them is how a network split shows itself, and a gateway cannot report that it is the one out of touch. Session counts name the sensor they came from, and a gateway that cannot count itself is shown as such rather than as empty.

The cluster view in NOC2: members, load, PADO delay, VLAN coverage and gossip age per gateway.
The cluster view in NOC2. Mode is shown at the top — this cluster is observing, not acting.

Sizing — the one thing to get right first

Because each gateway keeps its own address pool, a pool sized to exactly what that gateway normally carries leaves nothing spare when subscribers arrive from elsewhere. Size pools for the load a gateway may have to absorb, not the load it has on an ordinary evening. This is worth settling before the cluster is armed, not during the first busy night.

How this differs from the usual approaches

This is an architectural comparison, not a benchmark. We have not tested other vendors' equipment and we do not present measurements of it. What follows is how the approaches differ in shape — and where the chassis platforms do something we do not.

  Chassis BNG
Cisco ASR 9000 · Nokia 7750 SR
Router-as-BNG
MikroTik and similar
BNGSOFT with BNG Cluster
Adding capacity Another line card, or another chassis. Another box, then re-carve VLANs and pools by hand. Another commodity server. It joins the cluster and starts taking its share.
Where new sessions land Decided per chassis; distribution across chassis is a design exercise. Wherever the operator has carved them, fixed until changed by hand. On the gateway with the most room, recalculated continuously from live load.
Rebalancing after growth Re-plan and migrate subscribers. Re-carve and migrate subscribers. New sessions bias toward the emptier gateway automatically. Existing sessions are left alone.
Session survives node loss Yes — inter-chassis subscriber redundancy, where licensed and configured. No. No. Subscribers reconnect, and land where there is room.
Licensing Per subscriber, or per licence unit, on top of the hardware. Per box. Per traffic or per subscriber. The cluster itself is not a separate tier.
Cost to evaluate Procurement. A spare box. A configuration file on gateways you already run.
What the chassis platforms genuinely do better

They can carry a subscriber session through the loss of a node. Inter-chassis subscriber redundancy on an ASR 9000 or a 7750 SR synchronises session state between systems so that a failure is survivable without the subscriber reconnecting. We do not do that, and this document does not claim to. If uninterrupted sessions through a hardware failure is your requirement, that capability is real and it is theirs.

What we do instead is decide where new sessions go, continuously, across ordinary servers — a different problem, solved without purpose-built silicon, a chassis, or a per-subscriber licence book. Many operators need the second far more often than the first, and are currently paying for the first to get neither.

Where this is today

Measured on real hardware Not yet demonstrated in service

We would rather tell you what has been measured and what has not than describe both in the same voice. Ask us for the current position before you plan around either.

Built on bngxdpd — the XDP-native software BNG deployed in production across India, Pakistan, Nepal, Brazil, Argentina, Peru, Mexico, Senegal, South Africa and Canada, serving tens of thousands of subscribers per operator.