TLDR
- Start in mid-November, so the failover drill lands before the December freeze.
- Size against last year’s measured peak plus growth, with one node or site down.
- A restart at peak causes a mass reconnect, so retry timers matter as much as capacity.
Introduction
AAA peak traffic planning, which readies your authentication, authorization, and accounting platform for year-end, comes down to a few checks done in order. Confirm headroom against last year’s peak, run a failover drill, freeze non-essential changes, tune storm protection, and lock the on-call and escalation plan. During the peak, watch authentication rate, reject ratio, and latency, then review afterward.
This article is for NOC (network operations center) leads and AAA owners working out how to prepare AAA for New Year traffic. Newer to the platform? Start with what an AAA server does and why every operator needs one.
Why New Year’s Eve network traffic is different for AAA
A normal busy hour builds slowly, so last month’s trend line predicts it well. Year-end doesn’t. Activity bunches up around midnight in each time zone, and every new session has to clear the AAA server first.
In RADIUS (Remote Authentication Dial-In User Service) terms, the authentication surge arrives as Access-Request login messages (RFC 2865). Accounting-Request usage records (RFC 2866) follow close behind. BNGs (broadband network gateways) and Wi-Fi controllers send them on behalf of each subscriber.
Meanwhile, the NOC runs on a holiday rotation and a change freeze slows every fix. A BNG restart the platform would absorb on a Tuesday becomes a mass reauthentication at 12:05 a.m., with fewer people awake.
Your Q4 network operations checklist, week by week
This Q4 peak readiness calendar gives each week one owner and one check.
Starting late? Run Weeks 1 and 2 together.
Week 1, mid-November: check capacity headroom against last year’s peak
Owner: AAA platform owner. Check: Last year’s peak plus growth sits below your tested ceiling, with one node or site out of service.
Pull the busiest five minutes from last New Year’s Eve and add growth since then. Headroom is the gap between that figure and your tested ceiling. Count accounting separately, since interim updates (RFC 2869, Section 2.1) keep arriving while sessions stay up.
Our capacity planning guide has the full method. The Alepo AAA Server datasheet lists more than 36,000 TPS (transactions per second), but plan on the ceiling you measured with your own traffic mix. If the gap is tight on a cloud-native deployment, self-scaling AAA for peaks adds capacity as load climbs, though a reconnect wave can outrun it.
Week 2, late November: run a failover drill before the holidays
Owner: NOC lead. Check: The standby path carried live authentication and accounting with no dropped sessions or lost records.
A failover drill moves live traffic to the standby path to prove it works. One that fails in late November leaves three weeks for repairs, while one booked inside the freeze usually gets canceled.
Our failover drill guide covers a staged approach, from traffic shadowing to a small live segment. Confirm every NAS (network access server) points at a working secondary.
Week 3, first week of December: set the holiday change freeze
Owner: Change manager. Check: The freeze list is signed, with start and end dates and a named emergency change path.
A change freeze is a fixed period when production changes stop, apart from emergency fixes. Name what is frozen, such as AAA configuration, policy rules, NAS firmware, and database schema. Leave monitoring changes open for Week 5.
In ITIL 4 change enablement terms, the freeze raises the approval bar on the change schedule. Start it in mid-December, after Week 4.
Week 4, second week of December: tune storm protection before the freeze
Owner: AAA engineer. Check: Rate limits, noise filters, and retry settings held up under a simulated mass reconnect in the lab.
Review the rate limits and filters behind your signaling storm protection, so a looping router can’t crowd out real logins. RFC 5080, Section 2.2.2 requires a server to resend its cached reply to a repeated Access-Request rather than process it twice.
Section 2.2.1 also says RADIUS clients should add jitter (a small random delay) and congestive backoff (a wait that doubles after each failed try).
Week 5, mid-December: set peak traffic monitoring thresholds
Owner: NOC monitoring lead. Check: Alerts on authentication rate, reject ratio, and latency fired in a test and reached the on-call phone.
Reject ratio is the share of Access-Requests answered with Access-Reject. Base thresholds on last year’s peak night, or weekday baselines will page all evening. Add rate-of-change alerts too, since outages and reconnects show up as sudden steps.
Week 6, before Christmas: lock the on-call plan for AAA
Owner: NOC manager. Check: The on-call rotation and escalation tree are published, and every contact answered a test call.
Staff the plan in three layers: first-line NOC staff, an engineer who can read RADIUS traces, and someone with authority to break the freeze. Walk through the reconnect runbook once, and check remote access from home.
Week 7, New Year’s Eve: watch the night, time zone by time zone
Owner: On-call AAA engineer. Check: The three signals were reviewed around midnight in every time zone you serve.
Multi-time-zone operators get the peak in waves, so plan breaks around them. A timestamped log saves hours of guesswork in January. If a signal looks wrong, use the table below.
Week 8, mid-January: run the post-holiday review
Owner: AAA platform owner. Check: The measured peak is recorded against the forecast and becomes next year’s baseline.
Hold the review while logs are fresh. Lift the freeze in stages, because the backlog of deferred changes is a risk of its own.
How a reconnect storm after an outage plays out
A reconnect storm is the burst of RADIUS Access-Request and Accounting-Request traffic after a BNG or Wi-Fi controller restarts. Every subscriber behind it reconnects at once.
At 12:07 a.m. on January 1, a regional fiber internet provider’s BNG reloads after a software fault. Within seconds it sends an Access-Request for every home router behind it.
If the AAA server answers more slowly than the BNG’s retry timer, each request goes out again, and load climbs with no new subscribers. Accounting records pile up behind them, and each one is resent until acknowledged.
RFC 5080, Section 2.2.1 describes 3,000 NAS devices on a fixed one-second timer sending 3,000 Access-Requests every second after a power failure.
In deployments we see the second wave do more damage than the first. It usually traces back to NAS retry timers shorter than the server’s response time under load.
A carrier-grade AAA server also prioritizes logins already in progress. RFC 5080, Section 2.2.3 suggests an overloaded server favor Access-Requests with a valid State attribute (RFC 2865, Section 5.24). That way, EAP (Extensible Authentication Protocol) logins are more likely to finish than restart.”
Healthy reconnect or real trouble?
| Signal | Healthy wave | Sign of trouble | First move |
| Authentication rate | Sharp spike, then falls back | Stays high or climbs in steps | Check NAS retry timers and storm filters |
| Reject ratio | Close to its usual level | Keeps rising as subscriber lookups fail | Check subscriber database health |
| Latency | Rises briefly, then recovers | Keeps climbing as queues build | Shed noise, then shift traffic to the secondary site |
Conclusion
The January review sets next November’s baseline, so AAA peak traffic planning starts from measured numbers. If time is short, protect Weeks 2 and 4: the drill and retry timers are hardest to fix once the freeze starts.
| If the drill is the step your team keeps putting off, read the failover drill guide before the freeze begins. | To see how the Alepo AAA Server filters signaling noise and scales under peak load, book a demo. |
FAQs
Q1. How much capacity headroom does an AAA server need for New Year’s Eve?
There’s no universal percentage. Take last year’s measured peak, add growth, and confirm the platform carries it with one node or site down. Then leave room for a reconnect wave on top.
Q2. Should you run a failover drill before the change freeze?
Yes. A late-November drill tests the standby path while fixes are still allowed. Inside the freeze, a drill either breaks the freeze or gets canceled.
Q3. How do you handle a mass reconnect after an outage?
Let devices back in at a pace the platform can absorb, using client backoff (RFC 5080, Section 2.2.1), duplicate detection (Section 2.2.2), and storm filters. Don’t restart AAA nodes mid-storm, because each restart pushes a fresh wave of retries onto the rest.
Q4. What should on-call teams watch during the peak?
Watch authentication rate, reject ratio, and latency, per node and per NAS group.
Q5. What should you review after the holiday peak?
Compare the measured peak with the forecast and record it as next year’s baseline. Then review late or noisy alerts, incident timelines, and gaps the drill missed.
