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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. |
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.
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.