Upgrade the BNG. Keep the subscribers.
Two things have to survive an upgrade, and they are different problems. Packets must keep being forwarded. Sessions — the PPPoE and IPoE state, the addresses, the accounting records — must still exist afterwards, and must belong to the same subscribers with the same identities. BNGSOFT solves them separately, which is why either half can be upgraded without disturbing the other.
Upgrading the forwarding plane: no interruption at all
The programs that classify, shape, translate and police your traffic can be replaced while traffic is flowing, with no measurable gap. The reason is that no subscriber state lives inside the forwarding program itself — rates, counters, address mappings and policy all live in kernel-resident tables that exist independently of it.
An upgrade therefore reduces to three steps. The new program is loaded and verified against the tables that are live on that box right now — if it is not compatible with them, it is rejected before anything changes. The existing tables are then adopted by the new program, so it inherits every subscriber exactly as they are. Finally the kernel switches the attachment point atomically: the last packet is handled by the old program and the next packet by the new one. There is no window in between.
Critically, the old program is never detached first. On several widely deployed network drivers, detaching a program tears down the NIC's packet buffer rings — the failure mode that turns a routine upgrade into an unreachable box that needs physical intervention. Because the switch is a replacement rather than a detach-then-attach, that entire class of failure is avoided.
Stop forwarding, unload, load, re-attach, then rebuild subscriber state from the control plane.
Traffic stops for the duration. Every subscriber must be re-programmed into the data path, and until that finishes they are forwarded without their QoS, CGNAT or policy.
If the driver mishandles the teardown, the box does not come back.
Verify against live tables, adopt them, switch the attachment atomically.
Nothing is rebuilt because nothing was lost — the tables were never owned by the program being replaced.
No detach, so the driver's buffers are never torn down.
Upgrading the session plane: under a second, no re-authentication
Replacing the daemon that owns PPPoE and IPoE sessions is the harder half, because a session is a live protocol conversation with the customer's router. Restart it naively and every CPE notices, renegotiates, and re-authenticates — which on a full BNG means thousands of simultaneous RADIUS transactions and a visible outage for every subscriber.
BNGSOFT keeps session ownership outside the daemon, in a small supervisor process that does nothing but hold it. The daemon can therefore exit and be replaced while the sessions themselves stay alive in the kernel. When the new binary starts, it re-adopts those sessions and resumes each protocol layer at the state it was already in, rather than starting a fresh negotiation.
The subscriber's router is never told anything happened. It sees its keepalives answered without interruption and continues. Interface names, usernames, rate limits and — importantly for billing — accounting session identifiers are preserved, so an upgrade does not fragment a customer's accounting records.
The same mechanism survives a crash — not just a planned upgrade
This is the part conventional ISSU does not cover. Vendor in-service upgrade features are designed for planned events: an operator initiates them, and the system prepares in advance. They do nothing for an unplanned software failure.
Because BNGSOFT holds session ownership outside the session daemon in the first place, an unplanned termination behaves like a very abrupt upgrade. A supervisor notices within seconds, restarts the daemon, and the same re-adopt-and-resume path runs. Subscribers stay connected through a crash of the process that manages them — and traffic continues to be forwarded throughout, because the forwarding plane never depended on that process.
Measured, not asserted
All figures below were measured on a lab BNG under generated subscriber load. They are engineering measurements, not a production service-level commitment.
Forwarding-plane replacement, under live subscriber load
| What was measured | Result |
|---|---|
| Subscribers present, before → after | 1,601 → 1,601 — none lost |
| Forwarding program | replaced, with no detach |
| Traffic across the replacement | continuous, ~27,000 pps throughout |
| Per-subscriber counters across the replacement | identical — state was never rebuilt |
| Subscriber tables carried across | 124 of 126 reused in place |
| NIC buffer teardown events | none |
| Session daemon | never restarted |
Session-daemon replacement (planned upgrade)
| What was measured | Result |
|---|---|
| Control-plane gap, PPPoE | 824–1,023 ms (from 13,315 ms before this work) |
| Control-plane gap, PPPoE + IPoE together | 1.2–2.1 s |
| Sessions preserved | 1,000 / 1,000 PPPoE; 1,000 + 512 mixed, none dropped |
| Subscriber renegotiations triggered | 0 — the CPE never saw the upgrade |
| Traffic retained across the upgrade | no measurable loss (95.7–105% across equal windows) |
| Identity preserved | interface, username, rate limit and accounting session ID |
Unplanned crash of the session daemon
| What was measured | Result |
|---|---|
| Traffic retained while the control plane was dead | 95.4%; 96.2% after recovery |
| Sessions recovered | 1,000 / 1,000, identical identities |
| Detection and restart | within ~6 s, automatic |
| Subscriber re-authentications | 0 |
| At larger scale (~2,200 sessions) | 2,089 rebuilt; adoption 165 ms |
Why this is hard for traditional platforms
In-service upgrade is not a missing feature on carrier routers — it is a feature with preconditions. Those preconditions are architectural, and they are what BNGSOFT does not require.
They need a second control card
Classic ISSU works by upgrading a standby control processor and switching over to it. No redundant module, no ISSU — so the capability is gated behind buying and powering a duplicate of the most expensive card in the chassis.
It is a whole-system operation
The unit of upgrade is the platform image. There is no way to change only the forwarding behaviour and leave the session layer untouched, so every small fix carries the risk profile of a full upgrade.
Only qualified version pairs
Vendor ISSU is supported between specific release combinations. Falling outside them — or being on a platform where the BNG feature set excludes ISSU — means the upgrade becomes a reboot again.
Planned events only
ISSU is an operator-initiated procedure with a preparation phase. It offers nothing when software fails unexpectedly, which is when subscriber loss actually hurts most.
| Capability | MikroTik CCR | Cisco ASR 9000 | Nokia 7750 SR | BNGSOFT |
|---|---|---|---|---|
| Upgrade without dropping sessions | ✘ every upgrade reboots | ✘ ISSU unsupported with 64-bit BNG | ✔ requires dual CPM | ✔ single server |
| Redundant control hardware required | — | yes, dual RSP | yes, dual CPM | no |
| Forwarding logic upgradeable on its own | ✘ | ✘ platform image | ✘ platform image | ✔ independently, no gap |
| Sessions survive an unplanned software crash | ✘ | redundant pair only | redundant pair only | ✔ on a single box |
| Subscriber re-authentication on upgrade | all sessions | — | none, with redundancy | none |
| Runs on commodity x86 | ✘ | ✘ | ✘ | ✔ |