TLDR
- AAA (Authentication, Authorization, and Accounting) emergency mode is the set of rules an AAA server follows when it can’t reach its subscriber database.
- The three common policies are fail-closed, cached authentication, and fail-open with limits.
- Usage records are written to disk and replayed when the database returns, so billing data survives.
- Testing must cover the switch back to normal, not just the switch into emergency mode.
Definition
AAA (Authentication, Authorization, and Accounting) emergency mode keeps existing and returning subscribers online when the subscriber database or directory is unreachable. Instead of rejecting everyone, the AAA applies a predefined policy, such as accepting known subscribers from cache with limited service, while buffering accounting until the database returns. This article is for network architects and Network Operations Center (NOC) leads. For a refresher, see how an AAA server works and where RADIUS (Remote Authentication Dial In User Service) fits.
What happens when the AAA database fails without emergency mode?
Most AAA servers don’t hold subscriber profiles themselves. They check each login against a subscriber database or an LDAP (Lightweight Directory Access Protocol) directory and write usage records back.
A database failure hits authentication first. The AAA can’t verify anyone, so it either drops each new request or answers with an Access-Reject (RFC 2865, Section 4.3).
Subscribers already online stay connected for now. Trouble starts when someone reconnects after a router restart, or when a session hits its RADIUS Session-Timeout (RFC 2865, Section 5.27).
In deployments, we see the first complaints come from these returning subscribers. Every rejected login becomes a support call, so the business impact of an AAA outage grows by the minute. We break down the cost of authentication downtime separately.
Usage records stall too. RFC 2866, Section 2, says the server must not acknowledge a record it can’t store, so the gateway keeps retransmitting it.
Adding AAA servers won’t help, since they share the same database. Sound AAA resilience design pairs high availability AAA for server failures with a plan for losing the database.
The National Institute of Standards and Technology (NIST) calls this goal “withstand,” continuing essential functions despite adversity (SP 800-160 Vol. 2 Rev. 1, Section 2.1.1). For operators, that means authentication survivability.
A slow database causes different backend failures: requests time out instead of failing cleanly. Our RADIUS protocol guide explains the request-and-reply flow behind them.
AAA emergency mode vs fail-open: what are the three policy options?
Emergency mode, also called AAA degraded mode, is a policy you set in advance. It decides who can connect during an outage and what service they get.
Alepo AAA Server switches to emergency mode automatically when database connectivity is lost, so authenticated subscribers keep their service and accounting revenue stays protected. It is a carrier-grade AAA server built for 99.999% availability, according to the published datasheet.
Table 1. AAA emergency mode policy options
| Policy | Who can connect | Service during the outage | Main risk | Best suited to |
| Fail-closed | Only subscribers already online | Unchanged for them; others refused | Outage spreads as sessions end; mass reconnect on recovery | Services where an unchecked login is worse than downtime |
| Cached authentication | Subscribers checked recently | Reduced service, short time limit | A stale cache entry may admit a recently suspended subscriber | Most broadband and carrier Wi-Fi networks |
| Fail-open with limits | Any device on the operator’s access network | Very limited access, short sessions | Unknown or suspended users get some access | Short outages where staying reachable matters most |
Cached emergency mode admits only subscribers the AAA has already verified, while fail-open admits anyone who reaches it.
Fail-closed authentication
Fail-closed refuses every new login until the database is back. No one gets in unchecked, which makes it the easiest policy to defend in an audit.
Over time, every router restart or expired session strands another subscriber. When the database recovers, they all reconnect at once.
Cached authentication
Each AAA node keeps a local copy of subscriber profiles, refreshed on a schedule from the main database. During an outage, the AAA checks each RADIUS Access-Request (RFC 2865, Section 4.1) against that copy instead of rejecting it.
Subscribers added after the last refresh aren’t in the copy, so keep the refresh interval short and store account status with every profile. A short Session-Timeout (RFC 2865, Section 5.27) makes sessions log in again regularly, so they return to the live database soon after it recovers. Secure the local copy as you would the database.
Fail-open with limits
Fail-open accepts connections without checking credentials, then restricts what they can do. Typical limits are a low speed cap, short sessions, or access to the operator’s portal only.
It keeps the most people online with the least control, since the AAA can’t confirm who anyone is or bill usage to the right account. Keep it brief, and alert the network operations center (NOC) the moment it starts.
What gets buffered and reconciled after a database outage?
During a database outage, broadband subscribers keep generating usage records. Under RFC 2866, the server may send an Accounting-Response only after a record is stored (Sections 4.1 and 4.2). So the AAA writes records to local disk, where a restart won’t wipe them.
Consider a regional Internet Service Provider (ISP) whose broadband subscribers authenticate against an LDAP directory. One evening, a storage fault causes an LDAP outage, and authentication falls back to cached emergency mode.
Returning subscribers reconnect from the cache on a reduced-speed plan, and their usage records go to local disk. When the directory returns, the AAA replays the records and rechecks each emergency session. One subscriber suspended that afternoon is disconnected; everyone else returns to their normal plan.
Table 2. What the AAA saves and catches up on
| Item | During the outage | When the database returns |
| Usage records | Written to disk, then acknowledged | Replayed in order, with retransmitted duplicates removed |
| Emergency sessions | Marked with the policy that let them in | Rechecked, then updated with a CoA-Request (Change of Authorization, RFC 5176, Section 2.2) or ended with a Disconnect-Request (Section 2.1) |
| Usage allowances | Tracked per session | Applied to each account, with anything unusual flagged |
| Login history | Each emergency login logged with its policy | Passed to the security team for review |
Accounting buffering on disk keeps an AAA server compliant with RFC 2866 during a database outage and protects the revenue in every usage record.
Exiting AAA degraded mode safely
Leaving emergency mode needs as much planning as entering it. A freshly recovered database is fragile, and a flood of replayed records, session rechecks, and new logins can knock it over again.
Once the database has stayed healthy for an agreed period, replay records at a controlled rate and recheck sessions in small batches. Any session not yet rechecked ends at its Session-Timeout, and the subscriber logs in normally.
How should you test AAA emergency mode?
The most useful AAA emergency mode test copies a real outage: cut the network path to the database instead of shutting it down cleanly. Real failures don’t close connections politely. Use a lab that mirrors your live network.
Agree beforehand on what a pass looks like, including who must stay online and when the NOC escalates.
- Record a baseline of normal login, accounting, and retransmission rates.
- Block the AAA’s path to the database without warning.
- Confirm the AAA detects the loss, raises an alarm, and applies your policy.
- Log in with returning, new, and recently suspended test accounts, and check each result.
- Verify that Accounting-Responses go out only after records reach disk and that gateway retransmissions stay near the baseline.
- Restore the database, then check for duplicate records and confirm sessions return to their normal plans.
- Repeat with partial failures, such as a slow directory or one database replica offline.
Add the results to the NOC runbook, and rerun the test after major upgrades.
Conclusion
No subscriber database stays up forever, so make three decisions before yours fails. Choose a policy for each service, cap how long emergency mode runs, and set the catch-up pace. Then test all three, so the next outage costs a slower evening, not a wave of support calls.
See how Alepo AAA Server keeps subscribers online through a database outage.
FAQs
Q1. What is AAA emergency mode?
AAA emergency mode is a predefined policy for emergency authentication when the subscriber database or directory can’t be reached. It keeps selected subscribers online and stores usage records until the database is back.
Q2. What happens when the subscriber database is down?
Without emergency mode, new and returning logins fail, and usage records go unacknowledged. Subscribers already online stay connected only until they need to log in again.
Q3. Is AAA emergency mode the same as fail-open?
No. Fail-open is one emergency mode policy, and it admits users without verifying them. Fail-closed and cached authentication are stricter.
Q4. What are the risks of AAA emergency mode?
The main risks are admitting someone who should be blocked, losing usage records, and overloading the database as it recovers. Cache expiry, disk-based buffering, and a paced catch-up address each in turn.
Q5. How long should AAA emergency mode last?
Only as long as the outage lasts, up to a maximum you set in the policy. There’s no standard figure; it depends on how often account status changes on your network.
Q6. How do you test AAA emergency mode?
Cut the database connection in a lab, then check the switch into emergency mode, login results, usage records, and the switch back. Repeat after major upgrades.
Before the next database outage, choose a policy for each service, cap how long emergency mode runs, and set the catch-up pace.
