"Is it highly available?" is too blunt a question to answer usefully. A BNG faces three different failures, a control-plane restart, a whole-server loss, and a routing or uplink failure, and they have three different answers. Treating them as one leads either to over-engineering or to a nasty surprise during an outage. This note separates them and says plainly what survives each on Netavo.
Failure one: the control plane restarts
This is the common case, and the one a software BNG should handle without anyone noticing: a control-plane crash, or a routine software upgrade.
Netavo runs the data plane and the control plane as separate processes that share memory, and the shared memory is the source of truth for forwarding. When the control plane restarts, the data plane keeps forwarding. Established subscriber traffic does not stop. On restart the control plane rebuilds its view from a durable store rather than from nothing: each access circuit's session is persisted as a binding in an on-disk database (SQLite in WAL mode, on persistent disk), and sessions are reinstalled from it at startup. L2TP calls are handled by warm recovery, matching the persisted tunnel and session keys back up after the restart.
So a control-plane restart is a non-event for forwarding, and sessions come back without re-authenticating. That covers the large majority of real-world "BNG down" moments, because most of them are a process restart or an upgrade, not a dead server.
Failure two: the whole server is lost
A failed PSU, a kernel panic, a pulled cable to the box itself: now forwarding does stop on that box, and the question is how fast service moves elsewhere.
Be clear about what Netavo does and does not do here. It does not replicate session or NAT state to a standby box in real time; active/standby binding sync and stateful NAT failover are on the roadmap, not in the product. So recovery is by re-establishment on another box, not by seamless stateful takeover:
- PPPoE and IPoE subscribers reconnect and re-authenticate on the surviving BNG.
- L2TP lines redial: the LAC brings the tunnel back up to another LNS. This is fast re-establishment, not resumption of the original session, and it is exactly how carrier LNS pools are run.
- CGN mappings are rebuilt on the new box. Outbound flows re-establish quickly; any long-lived inbound mapping is lost, which is one more reason inbound services belong on IPv6 or a dedicated address rather than a shared NAT mapping.
The practical model for server-level redundancy is therefore an N+1 pool of boxes with the access layer or routing steering subscribers to a survivor, the same pattern used for chassis LNS estates, rather than a hot-standby pair holding mirrored state. If your requirement is genuinely seamless stateful failover, raise it: it is a roadmap item with a timeline, not a claim we make today.
Failure three: a route or uplink is lost
FRR handles routing, and a failed uplink or peer reconverges traffic the usual way. The trap is assuming that routing convergence alone equals service recovery. It does not: traffic can be rerouted to a box that does not hold the subscriber's session, in which case the session still has to exist there. Route convergence is necessary, not sufficient. Pair it with the session-recovery model above so the box that ends up carrying the traffic is one that can serve it.
The failure matrix
| Failure | Forwarding | Existing sessions | Existing flows | Recovery mechanism |
|---|---|---|---|---|
| Control-plane restart | Continues | Survive (binding DB) | Survive | Data plane holds; CP reinstalls from bindings |
| Whole-server loss | Stops on that box | Re-established elsewhere | Dropped, then re-open | Reconnect / L2TP redial on an N+1 survivor |
| Route / uplink loss | Continues | Survive if the session is on the box now carrying traffic | May drop briefly | FRR reconvergence plus session placement |
Test it, do not assume it
High availability is a property you demonstrate by injecting the failure, not one you infer from an architecture diagram. Build a short acceptance suite that actually causes each failure and measures recovery:
- Restart the control plane under load and confirm forwarding never pauses and sessions remain.
- Kill a box and measure how long subscribers take to re-establish on the survivor, including a reconnect storm (see the note on scale and the flap storm).
- Drop an uplink and confirm both that routing reconverges and that the subscribers land somewhere that can serve them.
Record the recovery time for each, because those three numbers, not a single "HA: yes", are what your service commitment is really made of.
The distinction that trips people up is redial versus resumption. On a box failure, L2TP lines redial and subscribers reconnect quickly, but the original sessions and their NAT state are not resumed. Design your service levels around fast re-establishment, and do not assume mirrored state you do not have.
Prove it on your own failure modes
The free evaluation build is the full production build, so you can exercise a control-plane restart and a reconnect on your own hardware and time the recovery. Start at netavobng.com/evaluation; the binding-persistence design is in the manual.