{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }}{{ badge.value }}
Visual unavailable
Use the concurrent busy-minute client population, not the estate inventory.
clients
Enter observed busy-minute access events before retransmits.
events/min
Use a capture-derived average when authentication conversations vary.
req/event
Use the observed request rate before retransmits; do not double-count interval updates from Advanced.
req/min
1.00 means no extra retry traffic; 1.20 adds 20 percent.
x
Use the servers that actually share requests, not standby nodes that receive none.
servers
This is an operator-supplied planning ceiling, not a vendor maximum.
req/s
{{ workflowFeedback }}
Zero leaves the normal busy-minute request rate unchanged.
%
Zero keeps all configured servers active; the value must remain below the configured count.
servers
Leave zero if the per-NAS accounting rate already includes interval updates.
sessions
Zero disables the derived interim-update load.
min
Zero disables this side of the wire estimate.
bytes
Zero disables this side of the wire estimate.
bytes
MeasureValueCapacity meaningCopy
{{ row.label }}{{ row.value }}{{ row.note }}
CheckpointSignalActionOperator noteCopy
{{ row.label }}{{ row.signal }}{{ row.action }}{{ row.note }}
VPN Tunnel Capacity Calculator Estimate practical VPN concurrent-user capacity from tunnel rate and packet overhead with gateway limits, busy-hour demand, and MTU risk checks.
ECMP Path Capacity Calculator Estimate ECMP route capacity from healthy paths and hash efficiency, then test reserve headroom plus member-failure and single-flow limits.
LACP Bundle Capacity Calculator Calculate usable LACP bundle capacity after failed links, reserve, and hash-efficiency discounts while checking aggregate and single-flow headroom.
QoS Bandwidth Allocation Calculator Allocate a QoS parent rate across traffic classes and check reserved bandwidth, best-effort headroom, burst ceilings and priority pressure.

Network access can create several back-end requests for one visible login. A switch, wireless controller, virtual private network gateway, or other network access server sends RADIUS packets to authenticate users and devices, enforce policy, and record session activity. Capacity planning therefore starts with request-producing clients and protocol exchanges, not simply the number of connected people.

An access event may need one Access-Request, or several when challenge-response, Extensible Authentication Protocol (EAP), or multi-factor steps continue the conversation. Accounting creates a separate stream for session starts, stops, and usage updates. A quiet login period can still carry heavy accounting traffic when many active sessions report at short interim intervals.

NAS
Network access server, meaning the RADIUS client that sends requests to the server pool.
Retransmission
A duplicate request sent when a response is late or appears lost.
N-1 capacity
Per-server load after one more active RADIUS server is removed for failure or maintenance.

Retries matter because they rise when the service or network is already under pressure. Slow directory lookups, packet loss, overloaded logging, or synchronized client timeouts can multiply requests at the worst moment. A burst reserve covers additional busy-period demand, while the retransmission factor represents duplicate request pressure across access and accounting traffic.

The per-server budget should come from a representative test that includes the real identity source, policy rules, certificate work, accounting writes, and logging path. A vendor maximum or packet-forwarding benchmark may ignore the slowest dependency. A low calculated utilization also does not prove acceptable login latency when load is distributed unevenly.

This model is intended for sizing and failure scenarios. It does not send RADIUS packets, test shared secrets, measure response time, or inspect a live deployment. Use its request-rate result to choose test cases, then confirm those cases with counters, captures, and load tests.

How to Use This Tool:

Describe one busy minute, then divide its adjusted traffic across only the servers that actively share requests.

  1. Enter the concurrent busy-minute NAS devices, access events per NAS, and Access-Requests created by each event. Count RADIUS clients as the server pool sees them.
  2. Add observed accounting requests per NAS. If that rate excludes interim updates, enter active sessions and the interim interval in Advanced.
    Leave interim inputs at zero when periodic updates are already included in the observed accounting rate; otherwise the same traffic is counted twice.
  3. Set the retransmission factor and peak burst reserve from counters or a deliberately conservative scenario. A factor of 1.20 adds 20% duplicate-request load.
  4. Enter the configured RADIUS servers, unavailable servers, and tested per-server request budget. Unavailable servers must remain below the configured count.
  5. Review active-pool load, minimum active servers, and the N-1 result. Use packet-size averages only when an approximate request-plus-response wire rate is also useful.

Interpreting Results:

Planned request rate combines access, accounting, optional interim updates, retransmissions, and burst reserve. Per-server load divides that total across the active pool. The status compares this value with the operator-supplied per-server budget.

  • Check the N-1 utilization even when the active pool is clear. Maintenance or a node failure may move the surviving servers into a tight or over-budget state.
  • Minimum active servers is rounded upward from planned load divided by the tested per-server budget.
  • Retry sensitivity shows how duplicate traffic changes both the active and N-1 cases; a steep crossing points to timeout, loss, or slow-dependency work as well as server count.
  • Wire rate covers average request and response bytes only. It excludes lower-layer overhead and does not predict CPU, directory, or database cost.

A clear arithmetic result can still fail operationally through uneven NAS server ordering, slow identity stores, certificate validation, or accounting storage. Verify request latency and error behavior under the same policy mix used to set the budget.

Technical Details:

RADIUS access and accounting are modeled as request streams per minute. Access traffic is the number of NAS clients multiplied by access events and Access-Requests per event. Interim accounting traffic is active sessions divided by the update interval, but only when both values are positive.

Formula Core:

The base rate is converted to requests per second before retry and burst multipliers are applied. Capacity is then evaluated per active server and for one fewer server.

Raccess=NEQ Raccount=NA+SI Rbase=Raccess+Raccount60 Rplan=RbaseF(1+b100) Rserver=RplanC-U u=RserverB Crequired=max(1,⌈RplanB⌉)

N is NAS count, E is access events per NAS per minute, Q is requests per event, A is accounting requests per NAS per minute, S is active sessions, and I is interim interval in minutes. F is the retransmission factor, b is burst reserve percent, C is configured servers, U is unavailable servers, and B is the tested per-server budget in requests per second.

Rule Core:

StatusBudget useMeaning
ClearAt or below 60%Arithmetic headroom remains for the modeled active pool.
WatchAbove 60% through 80%Test with the intended policy and accounting mix.
TightAbove 80% through 100%Retries or failover can consume the remaining budget.
Over budgetAbove 100%Modeled per-server requests exceed the selected ceiling.

N-1 load uses one fewer active server, never fewer than one. Extra retry load is the base rate multiplied by the retransmission factor above 1 and the burst multiplier. Approximate wire rate multiplies planned requests per second by average request plus response bytes and then by eight bits per byte.

With the default inputs, access traffic is 2,160 requests per minute and accounting is 4,200, giving 106 base requests per second. A 1.20 retransmission factor produces 127.2 planned requests per second. Three active servers receive 42.4 requests per second each, or about 28.3% of a 150 request-per-second budget.

Limitations and Privacy Notes:

The model cannot test a shared secret, certificate chain, directory response, database write path, or client retry timer. Its budget is only as credible as the representative test behind the entered ceiling.

  • Model sites or NAS groups separately when routes, timeouts, server ordering, or accounting policy differ.
  • Use busy-minute counters rather than daily or estate-wide averages.
  • Confirm that interim updates are not already included in the observed accounting rate.
  • Planning values are evaluated in the browser. Avoid sharing results that reveal sensitive site scale or failover posture.

Worked Examples:

Active pool passes and N-1 stays clear

The default 127.2 request-per-second plan spreads to 42.4 per server across three active servers. Losing one server raises the remaining pair to 63.6 each, still only 42.4% of the 150 request-per-second budget.

Interim updates dominate a quiet access period

Twenty-four thousand sessions reporting every 10 minutes add 2,400 accounting requests per minute before retries. This is 40 requests per second even with no access event, showing why active-session accounting must be included when the observed NAS rate omits it.

References: