Subscriber Edge on Commodity Servers
Broadband Gateway · CGNAT · QoS · Protection
Broadband Gateway · CGNAT · QoS · Protection
Operations · Upgrades
Upgrade the Network at Two in the Afternoon
Most software upgrades on our subscriber edge are invisible to your customers. Sessions do not drop, connections do not break, and there is nothing to schedule, announce or apologise for. The occasional deeper upgrade takes about half a minute — and even then, the connections your subscribers already have open keep working. This page explains the difference honestly, because knowing which upgrade you are about to run is the part that actually changes how you operate.
Every operator has a list of upgrades they have been putting off. Not because the change is risky — because the maintenance window is expensive, and the apology afterwards is worse.
None
subscriber sessions dropped
by a routine upgrade
by a routine upgrade
No window
nothing to schedule and
no customers to notify
no customers to notify
~30 sec
worst case, for the rare
deeper upgrade
deeper upgrade
Calls stay
connected
connected
open connections survive
even the deeper upgrade
even the deeper upgrade
Traditionally there are two ways to upgrade the software on a broadband gateway. You can restart it and take the hit — thousands of customers knocked offline at once, all reconnecting together, in a window scheduled for three in the morning. Or you can buy a second, redundant chassis whose only job is to carry the traffic while the first one is being upgraded. One costs you an outage and a night's sleep; the other costs you a duplicate of your most expensive hardware. We think you should have to do neither.
1 · Two kinds of upgrade — and we will always tell you which one you are running
Not all upgrades are the same, and a vendor who tells you they are all free is a vendor you will eventually catch out. Here is the real division, and it is only three lines long.
MOST
UPGRADES
UPGRADES
Everyday changes — invisible
New features, fixes, tuning and configuration changes. Your subscribers experience nothing at all: their sessions stay up, their traffic never pauses, and no connection is interrupted. There is no window to book and nobody to tell. This is the large majority of what you will ever install.
OCCASIONAL
Deeper changes — about half a minute
Now and then an upgrade reorganises something fundamental inside the system. This one is not completely invisible: there is a brief interruption of roughly half a minute. But subscriber sessions stay up and their open connections survive — each subscriber keeps the same public address they already had, so downloads resume, calls continue, and logins do not need repeating. Most operators run these in a quiet hour out of habit, not necessity.
RARE ·
PLANNED
PLANNED
Replacing the operating system — a real window
Replacing the underlying operating system requires a genuine restart of the machine, and that does disconnect subscribers. It is infrequent and always planned, and operators handle it the same way they handle any hardware maintenance: a booked window, or move the traffic to another node first. We are not going to pretend otherwise.
Two lanes per tier: whether the subscriber's session survives, and whether their traffic pauses. The distinction between the middle row and the bottom row is the one worth planning against — and the one most vendors leave out.
Why we lead with the boundary instead of burying it. "Zero downtime" as an unqualified claim is easy to write and easy to disprove — and the first time a customer discovers the exception, every other claim on the page becomes suspect. Two honest tiers are worth more than one absolute one. You can plan against the version above. You cannot plan against a slogan.
2 · What "connections survive" actually means to a subscriber
This is the distinction that separates a real hitless upgrade from a fast one, and it is worth being precise about — because from a subscriber's chair, they feel completely different.
WHAT YOUR SUBSCRIBER NOTICES
Nothing worth phoning about
No reconnect
the session, and the address, both stay
- A film keeps playing. A download keeps going rather than restarting from zero.
- A video call stays connected — the participant does not drop out and rejoin.
- A remote-desktop or VPN session into the office stays logged in.
- Nothing on their router blinks, and nothing needs restarting.
WHY THAT IS HARD
Keeping the address is the difficult half
Same address
before the upgrade and after it
- Where many subscribers share one public address, an upgrade that reshuffles those addresses breaks every open connection — even if no session technically "dropped".
- Our upgrades carry those assignments across rather than handing them out again.
- So the connections your subscribers already have open keep working, instead of quietly failing a few seconds later.
- This is the part cheaper implementations get wrong, and the part your support desk hears about.
The support-desk test. The honest measure of an upgrade is not a number in a release note — it is whether your call volume moves. An upgrade that drops sessions generates calls. An upgrade that keeps sessions but silently breaks everyone's open connections generates worse calls, because nothing looks broken. We optimise for the second one, because that is the one that damages trust.
ILLUSTRATIVE Addresses shown are fictional and use a range reserved for documentation. The point is the pairing, not the values: an upgrade that re-issues shared public addresses breaks every connection that was open across it, even though no session technically dropped.
3 · Proven where it is hardest — a node that cannot be taken offline
Any upgrade mechanism works on an idle lab machine. We tested this one on a live production node carrying real subscribers and performing address translation for all of them — the least forgiving place to try it, and a node that genuinely cannot be taken out of service. The upgrade run was the deeper kind: the half-a-minute case, not the invisible one.
SESSIONS
Everyone stayed on.
- Subscribers were carried straight through — no reconnection, no re-authentication.
- Each one resumed on the same public address they already had.
- More than 22,000 active connections were in flight at the time and were carried across.
THE NETWORK
Nothing flapped.
- Every network link stayed up for the entire observation — none went down, even briefly.
- The bonded link group never re-formed or renegotiated.
- Neighbouring equipment saw no change at all.
THE MACHINE
Never restarted.
- The server itself was not rebooted — it had been running continuously for nine days before the upgrade, and simply carried on afterwards.
- Watched continuously from well before the change until well after it.
- No adverse event of any kind was recorded during or after.
Four things a subscriber would notice if they broke, none of which did. The node performs address translation for live customers and cannot be taken out of service — which is why it was chosen.
And the same day, the other tier. An earlier upgrade to the very same node was the everyday kind — and it was completely uninterrupted. Nothing was taken down, nothing paused, and no subscriber was affected in any way. Both tiers on one node, on one day, on live traffic. That is the two-tier story being demonstrated rather than described.
4 · Compared with the two traditional options
| What you care about | BNGSOFT | Restart the software | Buy a redundant chassis |
|---|---|---|---|
| Subscribers during a routine upgrade | Unaffected — nothing drops | All disconnected at once | Unaffected, by switching to the spare |
| Their open connections | Keep working | All broken | Usually kept |
| Maintenance window | Not needed | Required, every single time | Not needed |
| Customer notification | None | Every time | None |
| Extra hardware required | None — one ordinary server | None, but you pay in outages | A second chassis, permanently idle |
| What the capability costs | Included — it is how the software works | Nothing up front | Substantial, and recurring at refresh |
| Replacing the operating system | Planned restart | Planned restart | Often handled without one |
Reading that last row honestly. A redundant chassis can ride out an operating-system replacement too, which we handle with a planned restart. That is a genuine advantage of buying two of everything, and we are not going to hide it. What we would put to you is the trade: you get the upgrade you run constantly — features and fixes — for free and without a window, on one ordinary server, instead of paying for duplicate hardware to cover the upgrade you run once or twice a year.
5 · What this actually changes about running the network
Upgrades without windows · what it is worth to you
No more three-in-the-morningRoutine upgrades go in during working hours, by whoever is on shift. No overtime, no standby rota, no engineer awake at 3am for a change that takes a minute.
No customer notificationsNothing to draft, nothing to send, no service-status page to update, and no complaints from customers who did not read it.
Security fixes go in the same dayWhen installing costs you nothing, you stop deferring. Fixes ship when they are ready instead of waiting weeks for the next window — so your exposure window shrinks with them.
No reconnection stormThousands of subscribers reconnecting simultaneously is its own outage risk. Not dropping them in the first place removes that failure mode entirely.
No duplicate hardware to buyYou are not purchasing a second chassis whose only purpose is to let you upgrade the first one safely — and not refreshing it every cycle either.
Upgrades stop being eventsWhen an upgrade is routine rather than an incident, your team stays current instead of running old software because moving is frightening.
The bottom line
The upgrades you run constantly — features, fixes, configuration — are invisible to your subscribers. There is no window, no notification and no interruption. The occasional deeper upgrade takes about half a minute, and your subscribers' open connections survive it. Replacing the operating system still needs a planned restart, and we will tell you that before you buy rather than after.
All of it on one ordinary server, with no duplicate chassis bought purely for the privilege of upgrading safely — and demonstrated on a live network carrying paying customers, not on a lab bench.
About these figures. The upgrade described in section 3 was performed on the day of publication on a production node that carries live subscribers and performs carrier-grade address translation for them. It was an upgrade of the deeper category described in section 1 — the roughly-half-a-minute case — chosen deliberately because it is the harder of the two to demonstrate. The node was monitored continuously at fixed intervals from before the upgrade began until well after it completed. Across the entire monitored period, every network interface remained up without a single interruption, the bonded link group's membership and identity never changed, and no adverse system event was recorded. The server was not restarted at any point; it had been running continuously for nine days before the upgrade and continued without interruption afterwards. More than 22,000 active translated connections were open on the node at the time and were carried across the upgrade, with each subscriber retaining the public address already assigned to them. An earlier upgrade to the same node on the same day was of the everyday category and involved no interruption to forwarding at all. The interruption figure for the deeper category is stated as approximately half a minute; the monitored window bounding the interruption on this run was shorter than that, and roughly half a minute is quoted as the conservative planning figure rather than the best observed result. Timings and behaviour vary with node size, configuration and the specific change being installed, and should be confirmed for your deployment during design review. The operating-system replacement case described in section 1 does require a planned restart and does disconnect subscribers; this is stated as a limitation of the product and not as an exception to it. No subscriber-identifying information was accessed or is reproduced anywhere in this document.