RADIUS is the single most load-bearing dependency a BNG has, and the one most likely to have a bad day. A well-built BNG turns a RADIUS outage into a minor event: existing subscribers never notice, and the box stays responsive instead of freezing against a dead server. A badly-built one turns the same outage into a full broadband outage and then amplifies it. The difference is entirely in how the BNG handles no answer.
Separate the three things RADIUS does
During an outage, three concerns behave differently, and conflating them is the usual mistake.
- Existing sessions. Subscribers who are already authenticated keep forwarding. The data plane does not consult RADIUS to move packets, so a RADIUS failure does not drop live sessions. This is the single most important fact: a RADIUS outage is a "no new logins" event, not an "everyone offline" event.
- New authentication. Subscribers connecting or reconnecting cannot be authenticated while RADIUS is unreachable, so they do not come up until it returns. That is the real user-visible impact, and it is bounded to people who happen to connect during the window.
- Accounting delivery. Interim and stop records generated during the outage cannot be delivered when they are produced, so they must be retried rather than silently dropped, or your usage and session records develop holes.
| Concern | During a RADIUS outage |
|---|---|
| Established sessions | Keep forwarding, unaffected |
| New / reconnecting logins | Blocked until RADIUS returns |
| Accounting | Must be retried, not lost |
The amplification trap
The dangerous case is not a plain RADIUS outage. It is a RADIUS outage that coincides with a reconnect storm, an upstream blip that drops every session at once, so that the moment RADIUS is slow or dead, every subscriber tries to re-authenticate together. A naive client then retransmits hard against the unresponsive server, and the retries pile on top of the reconnect flood. You have built a denial-of-service attack on your own AAA, and recovery takes far longer than the original fault.
Avoiding that is about how the client treats no answer, and about one distinction in particular.
An Access-Reject is not a server failure
A server that answers with Access-Reject is working perfectly; it has told you the credential is wrong. A failover or retry triggered by a reject is both pointless and harmful: it doubles load for a result that will not change. Failover logic must key on no response within the timeout, never on a negative response. Getting this wrong is a classic way to turn a handful of bad passwords into a RADIUS overload.
What Netavo's client does
Netavo's RADIUS client is built for exactly this failure mode:
- Multiple servers, round-robin. Requests are spread across the configured servers, so no single server is the whole dependency.
- Dead-server detection with Status-Server probing (RFC 5997). A server that stops answering is marked dead and taken out of rotation, then health-probed so it rejoins automatically when it recovers. Requests are not wasted on a server that is known to be down.
- Retransmission with a bounded timeout and retry count. A lost UDP request is retried within configured limits, not indefinitely.
- A circuit breaker when every server is dead. If all servers are down, a request would otherwise block for the full timeout times the retry count against each, and because the control plane drains authentication from a punt queue, that stall would back up the whole box. Instead, requests are fast-rejected while all servers are dead, with a single probe allowed through per cooldown to detect recovery. One known-dead RADIUS cannot freeze the BNG.
The combination means a RADIUS outage degrades gracefully: live traffic is untouched, new logins fail fast and cleanly rather than hanging, the box stays responsive, and service resumes on its own the moment a server answers a probe.
Policy choices that matter
- Run at least two RADIUS servers, and enable Status-Server so the client can tell "dead" from "slow" without waiting out every timeout.
- Size the timeout and retry count for the amplification case, not the happy path. Aggressive retries help a single lost packet but hurt a flood; the circuit breaker is the backstop when the whole estate reconnects at once.
- Make accounting durable across a server blip so usage records survive the outage rather than vanishing.
The test that matters is not "does authentication work," it is "what happens when RADIUS is slow while everyone reconnects." Inject that: hold RADIUS unresponsive, drop every session, and confirm the box stays up, fast-rejects cleanly, and recovers on its own when the server returns. That behaviour, not the happy-path login, is what keeps an AAA outage from becoming a broadband outage.
Exercise the failure
The free evaluation build runs the production RADIUS client with round-robin, dead-server detection and the circuit breaker. Point it at a test RADIUS you can take offline, drop sessions under load, and watch how it degrades and recovers. Start at netavobng.com/evaluation; the AAA driver behaviour is in the manual.