RADIUS Request Load Calculator

{{ result.statusText }} {{ result.clusterBadge }} {{ result.retryBadge }} {{ result.failoverBadge }} {{ result.mixBadge }}

NAS devices:

Count the RADIUS clients that can send requests during the same busy minute.

clients

Access events per NAS:

Use observed busy-minute access events per NAS, before retransmits.

events/min

Access requests per event:

Use 1.0 for single-request flows; raise it for EAP challenge conversations.

Access-Req/event

Accounting requests per NAS:

Include normal accounting starts/stops here; optional interval updates can be modeled in Advanced.

req/min

Retransmission factor:

Use 1.0 for clean traffic; 1.2 means 20% extra request pressure.

RADIUS servers:

Enter the active servers receiving traffic after load balancer or NAS server-order behavior.

servers

Per-server budget:

Use tested safe throughput, not a vendor maximum. The result compares modeled load against this ceiling.

req/s

Peak burst multiplier:

Leave 1.0 for steady-state math; raise it only for a known busy-minute burst.

Reserved or failed servers:

Leave 0 for normal active-active sharing; set 1 for an N-1 pool check.

servers

Active accounting sessions:

Leave 0 when the accounting requests per NAS already include interval updates.

sessions

Interim update interval:

Example: 15 means each active session contributes one accounting request every 15 minutes.

min

Average request packet:

Leave the default unless you have packet captures for your attributes and EAP method.

bytes

Average response packet:

Use a capture-derived value if Access-Accept attributes are large.

bytes

Load component	Value	Detail	Copy
{{ row.component }}	{{ row.value }}	{{ row.detail }}

Pool state	Servers	Per-server load	Budget use	Action	Copy
{{ row.state }}	{{ row.servers }}	{{ row.perServer }}	{{ row.budgetUse }}	{{ row.action }}

Retry factor	Total load	Active-pool load	N-1 load	Budget signal	Copy
{{ row.factor }}	{{ row.totalLoad }}	{{ row.activePool }}	{{ row.nMinusOne }}	{{ row.signal }}

Checkpoint	Signal	Action	Detail	Copy
{{ row.checkpoint }}	{{ row.signal }}	{{ row.action }}	{{ row.detail }}

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

A busy wireless controller, switch stack, VPN gateway, or broadband access shelf can create more RADIUS work than the login count suggests. RADIUS, short for Remote Authentication Dial-In User Service, sits between network access servers and a shared policy service. It answers authentication and authorization requests, then often receives accounting records after access has already been granted.

The sizing question is not mainly how many bytes cross the network. RADIUS packets are small compared with application traffic, but each request may touch policy rules, certificates, directory lookups, multi-factor checks, logging, or an accounting database. A server that has plenty of network bandwidth can still miss client timeouts when request rate, retry behavior, or back-end latency rises together.

RADIUS request-load terms and planning impact
Term	Plain meaning	Capacity impact
NAS	The switch, controller, access point, VPN concentrator, or gateway that sends RADIUS packets.	More active RADIUS clients can create synchronized busy-minute traffic.
Access-Request	The packet asking whether a user, device, or session should be allowed.	One visible connection may create several requests during challenge, Extensible Authentication Protocol (EAP), or multi-factor flows.
Accounting-Request	A start, stop, or usage record sent after or during a session.	Accounting can dominate load in session-heavy networks even when new logins are low.
Interim update	A periodic accounting record for an active session.	Short update intervals multiply with active sessions and can produce steady write pressure.
Retransmission	A duplicate request sent after a slow or missing response.	Loss, overloaded servers, or synchronized timers can turn a safe average into an overload.

RADIUS request pressure from NAS clients, access exchanges, accounting updates, retry amplification, and server pool capacity.

Good planning separates normal request creation from amplification. Base access and accounting traffic explain ordinary busy-minute load. Retry and burst assumptions explain reconnect storms, slow identity stores, packet loss, or maintenance events that remove a server from the active pool.

The common mistake is treating a vendor maximum as a safe production budget. A reliable RADIUS plan needs measured request-per-second headroom, an N-1 view for maintenance or failure, and a reminder that arithmetic does not prove latency, certificate cost, directory response time, or accounting write capacity.

How to Use This Tool:

Build a busy-minute model, then compare the modeled request rate with the safe request-per-second budget for the servers that will actually receive traffic.

Set NAS devices to the RADIUS clients that can send traffic in the same busy minute. Count the devices that appear to the server pool as clients, not always the number of end users.
Enter Access events per NAS and Access requests per event. Use 1 for a single Access-Request flow and raise it for EAP, challenge, multi-factor, or policy checks that create several request packets.
If the real flow is unknown, compare 1.0, 1.5, and 2.0 requests per event in the result tabs before accepting a rollout estimate.
Add Accounting requests per NAS. Open Advanced when active sessions also send periodic interim updates, then enter Active accounting sessions and Interim update interval.
Set Retransmission factor and Peak burst multiplier. A 1.20 retransmission factor means duplicate requests add 20% load after the base access and accounting rate is calculated.
Enter RADIUS servers, Per-server budget, and Reserved or failed servers. Use a tested safe budget for your policy stack, not a best-case packet-forwarding number.
If a server is reserved or failed, the active-pool result divides traffic across fewer servers. The N-1 row still shows the one-server-down case from the configured pool.
Read Load Breakdown, Server Ledger, Retry Sensitivity Curve, and Capacity Guidance together. A tight, over-budget, or N-1 warning means the scenario needs lower load, more capacity, longer retry spacing, or a smaller per-site blast radius before it is used for a change plan.

Interpreting Results:

Start with RADIUS server load and the capacity status, then check whether the same scenario remains acceptable in the N-1 failover check. A comfortable active-pool result can still be a weak design when one server is removed for patching or when retries rise during a network problem.

RADIUS request load result cues
Output cue	What it means	What to verify
RADIUS server load	Modeled requests per second for each active server after burst and retry assumptions.	Confirm the per-server budget with the same policies, directories, certificate checks, and accounting writes used in production.
Capacity clear/watch/tight/over	Utilization band based on the selected per-server budget.	Watch and tight bands need load-test evidence before a large rollout.
N-1 failover check	Per-server load after one configured server is unavailable.	Use it for maintenance windows, site failure, and load-balancer or NAS server-order planning.
Retry sensitivity	How the active pool and N-1 case move as retransmissions rise.	Small retry changes crossing a budget line point to timeout, jitter, packet-loss, or duplicate-request work.
Accounting share	How much base traffic comes from accounting and interim updates.	Accounting-heavy results need database and log-path checks, not only authentication-policy tests.
Estimated wire rate	Approximate request-plus-response bits per second from the average packet sizes entered in Advanced.	Use this for links and tunnels, but do not treat it as the main CPU or database capacity result.

A low utilization number is not proof that users will authenticate quickly. Directory latency, certificate validation, database writes, overloaded logging, uneven server selection, and RADIUS client timeout behavior can still cause failures while the modeled request rate looks safe.

Technical Details:

RADIUS uses a request and response exchange between a NAS and a server. Authentication and authorization traffic begins with Access-Request packets and may continue through Access-Challenge responses before an Access-Accept or Access-Reject. EAP and challenge flows matter for capacity because one user-facing connection can generate more than one Access-Request.

Accounting is a separate request stream. Starts, stops, and interim updates can continue while sessions remain active, so a quiet login period can still create steady accounting load. RADIUS clients also retransmit when responses are late or missing. RFC guidance around retry behavior and jitter exists because synchronized retransmissions can add load at the same moment that the service is already slow.

Formula Core:

The calculation converts busy-minute request sources to requests per second, applies retry and burst multipliers, and divides the result across the active server count.

\begin{array}{lcl} R_{access_min} & = & N_{NAS} \times E_{access} \times Q_{event} \\ R_{accounting_min} & = & N_{NAS} \times Q_{accounting} + \frac{S_{active}}{T_{interim}} \\ R_{base} & = & \frac{R_{access_min} + R_{accounting_min}}{60} \\ R_{modeled} & = & R_{base} \times F_{retry} \times F_{burst} \\ R_{server} & = & \frac{R_{modeled}}{max (1, N_{servers} - N_{reserved})} \\ Utilization & = & \frac{R_{server}}{C_{server}} \times 100 % \\ B_{wire} & = & R_{modeled} \times (L_{request} + L_{response}) \times 8 \end{array}

RADIUS request load formula symbols
Symbol	Meaning	Unit or source
`N_NAS`	RADIUS clients that can send requests in the same busy minute.	NAS devices
`E_access`	Access events per NAS during the busy minute.	Events per minute
`Q_event`	Access-Request packets created by each access event.	Requests per event
`Q_accounting`	Normal accounting requests per NAS before optional interim updates.	Requests per minute
`S_active / T_interim`	Active accounting sessions divided by the interim update interval.	Additional accounting requests per minute
`F_retry`	Retransmission multiplier for duplicate request pressure.	1.00 means no extra duplicate load
`F_burst`	Busy-minute burst multiplier after retries are applied.	1.00 means no extra burst factor
`C_server`	Safe request-per-second budget for one server.	Measured planning budget

Capacity Bands:

RADIUS server utilization bands
Band	Utilization boundary	Meaning
Capacity clear	At or below 60%	Enough arithmetic headroom for a first planning pass.
Capacity watch	Above 60% and at or below 80%	Confirm with realistic policy and accounting load.
Capacity tight	Above 80% and at or below 100%	Retry, failover, and directory latency may consume the remaining headroom.
Over budget	Above 100%	The modeled active-pool load exceeds the selected per-server budget.

With the default busy-minute model, 120 NAS devices at 18 access events per NAS create 2,160 access events per minute. At one Access-Request per event and 35 accounting requests per NAS, base load is 6,360 requests per minute, or 106 requests per second. A 1.20 retransmission factor raises total modeled load to 127.2 requests per second. Three active servers each carry 42.4 requests per second, or about 28.3% of a 150 req/s budget.

The N-1 value is calculated from one fewer configured server, never fewer than one. Required servers are rounded up because fractional capacity cannot be deployed as a server. Wire-rate output multiplies total modeled request rate by average request and response bytes, so it is best read as a link-planning estimate rather than a server sizing proof.

Limitations and Privacy Notes:

This is a planning calculator, not a RADIUS probe, traffic generator, or performance test. It does not send RADIUS packets, validate shared secrets, test certificates, measure directory latency, or inspect accounting databases.

Use RADIUS server counters, packet captures, and synthetic load tests before committing to a major access change.
Model sites or NAS classes separately when timeout policy, server order, WAN path, or accounting behavior differs.
Average packet sizes only support the wire-rate estimate; CPU, directory latency, certificate work, and database writes often matter more.
Entered sizing values are evaluated in the browser. Avoid sharing screenshots or copied output when site size, identity architecture, or failover posture is confidential.

Advanced Tips:

Use observed busy-minute counters when possible. Average hourly login counts hide reconnect storms and shift-change spikes.
Keep Access requests per event separate from Retransmission factor. Challenge and EAP exchanges are normal request creation; retransmissions are duplicate pressure caused by timeout or loss.
Model interim accounting in Advanced when active sessions are large. Short intervals can make accounting the main request source.
Use Reserved or failed servers for a planned reduced-pool scenario, then compare it with the automatic N-1 failover check.
Read the Retry Sensitivity Curve before changing only the server count. A steep curve usually points to retry policy, packet loss, or slow dependencies as much as raw capacity.
Set Per-server budget from a load test that includes the real identity source, policy checks, certificates, accounting writes, and logging path.

Worked Examples:

Campus Busy Minute

With 120 NAS devices, 18 access events per NAS per minute, 1 Access-Request per event, 35 accounting requests per NAS per minute, a 1.20 retransmission factor, 3 servers, and a 150 req/s per-server budget, the base rate is 106 req/s. The modeled total is 127.2 req/s, so each active server carries 42.4 req/s and stays in Capacity clear. The N-1 case is 63.6 req/s per server, still below the watch band.

Reconnect Storm With EAP and Accounting

A larger environment with 200 NAS devices, 25 access events per NAS, 2 requests per event, 50 accounting requests per NAS, 120,000 active sessions, 15-minute interim updates, a 1.50 retransmission factor, and a 1.40 burst multiplier reaches about 980 req/s. Five servers with a 150 req/s budget would carry about 196 req/s each, which is over budget before the N-1 check raises the per-server load to about 245 req/s.

Accounting-Heavy Remote Sites

Forty NAS devices with 2 access events per NAS may look small until 24,000 active sessions send 10-minute interim updates. With 8 normal accounting requests per NAS, a 1.10 retransmission factor, 2 servers, and a 60 req/s server budget, each active server carries about 25.7 req/s. The N-1 case rises to about 51.3 req/s, so maintenance planning and WAN loss deserve more attention than the access-event count alone suggests.

FAQ:

Should I count access points, controllers, switches, or gateways as NAS devices?

Count the devices that send RADIUS requests to the server pool during the busy minute. In some wireless designs that is the controller; in others each access point or switch appears as a RADIUS client.

What should I enter for access requests per event?

Use 1 for a simple one-request access flow. Raise it when EAP, challenge-response, multi-factor, policy redirects, or other access methods create several Access-Request packets for one visible connection.

Why does accounting need its own input?

Authentication decides whether access is allowed. Accounting records session start, stop, and usage information, so it can continue long after the original access decision and can stress write paths.

How should I choose a retransmission factor?

Use duplicate-request or timeout counters when you have them. Without measurements, compare several factors in the retry outputs because retransmissions multiply every modeled request source.

Can the result replace a RADIUS load test?

No. The result is useful for sizing conversations and scenario screening, but final capacity depends on policy complexity, identity-store latency, certificate work, logging, accounting writes, hardware, and client retry behavior.

Glossary:

NAS: Network access server, the RADIUS client that sends requests for users, devices, or sessions.
Access-Request: A RADIUS packet asking a server to authenticate or authorize access.
Access-Challenge: A response that asks for another authentication step and often creates another Access-Request.
Accounting-Request: A packet that records session start, stop, or usage information.
Interim update: A periodic accounting message sent while a session remains active.
Retransmission factor: A multiplier for duplicate requests caused by timeout, loss, slow responses, or synchronized retries.
N-1 capacity: The server-pool condition after one configured server is unavailable.

References:

RFC 2865: Remote Authentication Dial In User Service (RADIUS), RFC Editor, June 2000.
RFC 2866: RADIUS Accounting, RFC Editor, June 2000.
RFC 2869: RADIUS Extensions, RFC Editor, June 2000.
RFC 5080: Common Remote Authentication Dial In User Service (RADIUS) Issues and Suggested Fixes, RFC Editor, December 2007.