RADIUS survivability & cold standby
Network access control sits in the login path of every port, so the honest questions are: what happens while this appliance is down, and how fast can a replacement take over? This page is the answer — the fail mode, the switch-side configuration we ship, and the cold-standby recovery procedure.
What happens when the appliance is unreachable
The worst failure mode for a RADIUS server is answering
Access-Reject while unhealthy: switches dutifully bounce every
endpoint off the network. This appliance’s decision bridge is
fail-quiet by design — if the decision service cannot be consulted,
FreeRADIUS does not respond rather than rejecting. To a
switch, a silent server is a dead server, which is exactly the state
switch-side survivability is built for:
Already-authenticated sessions stay up on the switch regardless: 802.1X authorization lives in the switch’s session table, not in a connection to the server.
Switch-side survivability, shipped as templates
Two system templates ship under NOC › Configuration › Config Templates › RADIUS survivability; push them from the template screen or the device’s push-config dialog.
| Template | Variables | What it does |
|---|---|---|
| RADIUS survivability — Cisco IOS/IOS‑XE | interface, critical_vlan |
Sets radius-server dead-criteria/deadtime,
enables dot1x critical eapol, authorizes the port into the
critical VLAN (data + voice) while servers are dead, and
re-initializes when they return. |
| RADIUS survivability — Juniper EX (Junos) | server_ip, interface, critical_vlan (optional) |
Configures server-fail use-cache so authenticated
sessions persist, optionally admits new clients into a critical VLAN,
and reverts to RADIUS on revert-interval. |
Size the critical VLAN deliberately: it is the network your ports fall into during an outage. Many sites use the device’s normal access VLAN for data and keep guests out of scope.
Cold-standby recovery
A single appliance plus a current export recovers in well under an hour. The procedure, end to end:
- Keep exports current. ADMIN › Backups & export produces the configuration/database export; schedule it and store it off-box. See Backups & export.
- Stand up a fresh appliance. Import the current OVA (or install from ISO). First boot mints new per-appliance identities (vault key, TLS pair, bridge secret) — that is expected; the restore brings your data, not the old box’s identity.
- Restore the export from the same Backups screen on the new appliance.
- Take over the network identity. Give the standby the old appliance’s IP (or update DNS): switches address RADIUS and TACACS+ by that IP, and the restored NAS secrets match as-is.
- Re-trust device SSH host keys. SSH pins are per-device trust decisions: the restored inventory reconnects with the pins it carried; a device you rebuilt in the meantime needs its pin re-accepted (Forget & re-trust on the device page).
- Re-activate the headend link. Settings › Software Updates › Activation: enter an activation code if the restored key was revoked, otherwise the restored key keeps working.
- Verify, in order: an 802.1X endpoint authenticates and lands in its policy VLAN; a MAB endpoint is profiled; a TACACS+ login to a device succeeds and is authorized per command; a CoA (reauth) from Endpoint Sessions is ACKed; the auth log is filling.
During the window between failure and takeover, the fail mode above is what carries the floor: ports keep working, new endpoints get the critical VLAN, and nothing is rejected.
Protecting the TACACS+ management path
TACACS+ (RFC 8907) obfuscates packet bodies but carries no integrity protection — an on-path attacker on the management network could in principle flip a REJECT into an ACCEPT. The appliance mitigates what a server can (per-host shared secrets with a rotation ledger; unknown peers get no TACACS+ conversation at all), and the rest is network design:
- Keep device management interfaces and this appliance on an isolated management VLAN/VRF; TACACS+ and RADIUS should never transit networks endpoints can reach.
- Rotate shared secrets on a schedule — the Credential Vault does device + server + ledger in lockstep.
- TLS for TACACS+ (RFC 9887) requires very recent network OS releases (for example IOS-XE 17.18+); enable it as your fleet gets there. The appliance side will follow fleet support.