{{ result.summaryTitle }}
{{ result.primaryDisplay }}
{{ result.secondaryText }}
{{ result.statusText }} {{ result.clusterBadge }} {{ result.retryBadge }} {{ result.failoverBadge }} {{ result.mixBadge }}
Count the RADIUS clients that can send requests during the same busy minute.
clients
Use observed busy-minute access events per NAS, before retransmits.
events/min
Use 1.0 for single-request flows; raise it for EAP challenge conversations.
Access-Req/event
Include normal accounting starts/stops here; optional interval updates can be modeled in Advanced.
req/min
Use 1.0 for clean traffic; 1.2 means 20% extra request pressure.
x
Enter the active servers receiving traffic after load balancer or NAS server-order behavior.
servers
Use tested safe throughput, not a vendor maximum. The result compares modeled load against this ceiling.
req/s
Leave 1.0 for steady-state math; raise it only for a known busy-minute burst.
x
Leave 0 for normal active-active sharing; set 1 for an N-1 pool check.
servers
Leave 0 when the accounting requests per NAS already include interval updates.
sessions
Example: 15 means each active session contributes one accounting request every 15 minutes.
min
Leave the default unless you have packet captures for your attributes and EAP method.
bytes
Use a capture-derived value if Access-Accept attributes are large.
bytes
Load componentValueDetailCopy
{{ row.component }}{{ row.value }}{{ row.detail }}
Pool stateServersPer-server loadBudget useActionCopy
{{ row.state }}{{ row.servers }}{{ row.perServer }}{{ row.budgetUse }}{{ row.action }}
Retry factorTotal loadActive-pool loadN-1 loadBudget signalCopy
{{ row.factor }}{{ row.totalLoad }}{{ row.activePool }}{{ row.nMinusOne }}{{ row.signal }}
CheckpointSignalActionDetailCopy
{{ row.checkpoint }}{{ row.signal }}{{ row.action }}{{ row.detail }}
 

          

        

      

    

  

                

                

                    

                        

                            Tags: Networking, Security, Sysadmin
                        

                        

                            Export to PDF
                            Fullscreen
                        

                    

                

            

        

    


                    
        

        

        

            

            
        

        


                                                                                                                                                                                                                                                        
        

        

            
            

                Customize

                

                    

                        

                            
                            
                        


                        

                            
                            
                        


                        

                            
                            
                        

                    


                    

                        Advanced

                        

                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                
                                

                                    
                                    :
                                    
                                

                            


                            

                                
                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                

                                    
                                    
                                

                            


                            

                                
                                
                            


                            

                                
                                
                            

                        

                    

                

            

            
        


        

            
            
            
        


        
        

    

    

        

  
  
RADIUS request load is the rate at which network access servers send authentication and accounting packets to a RADIUS server pool. It matters most during busy minutes, when Wi-Fi reauthentication, virtual private network reconnects, switch port checks, and accounting updates arrive close together instead of spreading evenly through the day.

  
A useful capacity estimate starts with requests per second, not only with user count. One access event can produce one Access-Request in a simple exchange, or several Access-Requests when challenge-based authentication is involved. Accounting Start, Stop, and Interim-Update packets add another request stream, and packet loss or slow responses can make clients resend the same request.

  

    RADIUS request flow from NAS clients through retry pressure into an active server pool and policy path
  

  
Bandwidth is rarely the only limit. Authentication policy checks, directory lookups, multifactor handoff, logging, and accounting writes can make two servers with the same network path behave very differently. A safe request budget should therefore come from a measured server limit under production-like policy and monitoring, not from a vendor maximum or an empty-lab benchmark.

  
The estimate is a planning check. It can show when a pool has spare request capacity, when an N-1 failure would be tight, and when retransmission pressure deserves investigation. It does not prove that a RADIUS design is ready by itself, because real capacity still depends on policy complexity, identity-store latency, accounting storage, CPU, and how duplicates are handled.






  
Technical Details:

  
RADIUS uses request and response exchanges between a network access server, often shortened to NAS, and one or more RADIUS servers. Access-Request packets carry authentication material and can lead to Access-Accept, Access-Reject, or Access-Challenge responses. Challenge flows can require more than one Access-Request for a single user access event.

  
Accounting traffic is separate from authentication decision traffic. Start, Stop, and Interim-Update records can continue even when authentication rates are calm, so accounting requests must be counted with authentication requests when sizing server and database capacity. Retransmission adds another multiplier: when responses are late or packets are lost, clients can resend requests, and duplicate detection prevents the server from treating a repeated Access-Request as a new login.

  
The calculation is a busy-minute model. It converts per-minute authentication and accounting activity into requests per second, then applies retransmission and burst multipliers before dividing the resulting load across the active server pool.


  
Formula Core

  
The main request-rate equation combines authentication, accounting, optional interim updates, retransmission pressure, and burst demand.

  

    
      
        Rtotal
        =
        
          
            (N×E×A)
            +
            (N×C)
            +
            I
          
          60
        
        ×
        T
        ×
        P
      
    
  

  

    

      
      
        

          Symbol
          Meaning
          Unit
        

      
      
        

          N
          NAS devices that can send requests during the same busy minute
          clients
        

        

          E
          Access events started by each NAS in one minute
          events/min
        

        

          A
          Access-Request packets produced by one access event
          requests/event
        

        

          C
          Accounting requests started by each NAS in one minute
          requests/min
        

        

          I
          Interim-Update rate, equal to active accounting sessions divided by the interim interval when both are set
          requests/min
        

        

          T
          Retransmission factor for duplicate or timeout-driven request pressure
          multiplier
        

        

          P
          Peak burst multiplier for synchronized reauthentication or reconnect events
          multiplier
        

      
    

  

  
Server capacity is checked after total request rate is known. Reserved or failed servers are removed from the active pool, with at least one server always left in the modeled pool. The N-1 check uses the configured server count minus one, also with a minimum of one server.

  

    
      
        Uactive
        =
        
          
            Rtotal
            /
            S
          
          B
        
        ×
        100
      
    
  

  
Here, S is the active server count and B is the safe per-server request budget in requests per second. The same division is repeated for the N-1 pool, and required server count is the total request rate divided by the per-server budget, rounded up.

  

    

      
      
        

          Signal
          Per-server utilization
          Meaning
        

      
      
        

          Capacity clear
          0% to 60%
          Per-server load is well below the entered budget.
        

        

          Capacity watch
          > 60% to 80%
          There is usable headroom, but busy-minute monitoring should match the model.
        

        

          Capacity tight
          > 80% to 100%
          The active pool is near its entered budget and needs load-test evidence.
        

        

          Over budget
          > 100%
          The modeled load exceeds the entered per-server budget.
        

      
    

  

  
The wire-rate estimate is intentionally rough. It multiplies total requests per second by average request plus response packet bytes and by eight bits per byte. That number helps catch unusually large RADIUS attributes or EAP messages, but it does not replace packet capture, server latency, or identity-store measurements.






  
Everyday Use & Decision Guide:

  
Start with the busiest minute you expect to defend. Use the NAS device count for clients that can send traffic at the same time, then enter observed access events per NAS and accounting requests per NAS. If accounting interval updates are already included in that observed accounting rate, leave active accounting sessions and interim interval at zero to avoid counting them twice.

  
Use one Access-Request per event for simple exchanges. Raise it when EAP or challenge flows create several Access-Requests for one access attempt. A value of 1.2 for retransmission factor means 20% extra request pressure; values above 1.5 should usually trigger timeout, packet loss, duplicate, or backoff review before you add more users.

  
    
    
  • Use the calculator for Wi-Fi, VPN, switch authentication, MAC authentication bypass, and accounting growth checks.
    • 
    
  • Use a measured per-server budget from production-like policy, directory, logging, and accounting tests.
    • 
    
  • Use peak burst multiplier for shift changes, site recovery, synchronized reauthentication, or VPN reconnect storms.
    • 
    
  • Avoid using the result as proof of end-to-end login success; it estimates request pressure, not policy correctness.
    • 
  

  
Stop and verify when the summary badge moves from capacity clear to capacity watch or capacity tight, or when the N-1 badge crosses 80%. If the Server Ledger says N-1 is over budget, the active pool may still look acceptable while a single failed server would overload the remaining servers.

  
After the first pass, use the Retry Sensitivity Curve and Retry Sensitivity table to see how quickly duplicates consume headroom. The Capacity Guidance rows point to the most likely follow-up: add active servers, lower retry pressure, test the accounting write path, or confirm that multi-round authentication is represented by the Access-Request count.






  
Step-by-Step Guide:

  
Use one consistent busy-minute scenario for the whole pass so the server and retry results stay comparable.

  
    
    
  1. Enter NAS devices and Access events per NAS. The summary should immediately update the total and per-server request rate.
    2. 
    
  2. Set Access requests per event. Keep it at 1.0 for a single Access-Request flow, or raise it for EAP and challenge conversations that produce several Access-Requests.
    3. 
    
  3. Enter Accounting requests per NAS. If you want derived interval updates, open Advanced, set Active accounting sessions, and set a nonzero Interim update interval.
    4. 
    
  4. Set Retransmission factor and, when needed, Peak burst multiplier. Watch the Retransmit pressure row in Load Breakdown and the retry badge in the summary.
    5. 
    
  5. Enter RADIUS servers, Reserved or failed servers, and Per-server budget. Review Active-pool per server, Budget use, and the N-1 row in Server Ledger.
    6. 
    
  6. Check Capacity Guidance before sharing the result. If a field was blank or below its valid range, re-enter it rather than relying on the normalized minimum, such as one NAS, one server, a 1.0 retry factor, or 20-byte packet sizes.
    7. 
  

  
When the result looks stable, keep the Load Breakdown and Server Ledger with the test notes that produced the per-server budget.






  
Interpreting Results:

  
The main number is the summary request rate per active server. Read it next to the entered per-server budget and the summary status badge. Capacity clear means the modeled active pool is at or below 60% of budget; capacity tight means it is above 80% and no higher than the budget; over budget means the active pool exceeds the entered safe limit.

  
The N-1 badge deserves separate attention. A design can pass the active-pool check and still fail the N-1 check because one missing server concentrates the same request rate onto fewer servers. Treat N-1 over budget as a capacity risk even when the current active pool still has headroom.

  
    
    
  • Load Breakdown shows which input creates the request rate: authentication, accounting, interim updates, retransmissions, or burst multiplier.
    • 
    
  • Server Ledger turns the same total rate into configured pool, active pool, N-1, and minimum-server views.
    • 
    
  • Retry Sensitivity shows whether a small increase in duplicates would cross the budget line.
    • 
    
  • Capacity Guidance flags retry pressure, accounting-heavy traffic, multi-round authentication, and validation needs.
    • 
  

  
A low utilization value does not mean logins will be fast. Compare the result with real latency, duplicate Access-Request counters, accounting database write time, and identity-store response time before trusting the design for production growth.






  
Worked Examples:

  
Campus steady state

  
With 120 NAS devices, 18 access events per NAS per minute, one Access-Request per event, 35 accounting requests per NAS per minute, a 1.20 retransmission factor, three servers, and a 150 req/s per-server budget, the base rate is 106.00 req/s. The summary shows 42.40 req/s per active server and 127.20 req/s total across three active servers. Server Ledger reads 28.3% budget use for the active pool and 42.4% for N-1, so the status remains capacity clear.


  
Active pool passes, N-1 fails

  
A denser authentication period with 150 NAS devices, 30 access events per NAS per minute, two Access-Requests per event, 20 accounting requests per NAS per minute, a 1.35 retransmission factor, three servers, and a 100 req/s budget produces 270.00 req/s total. The active pool carries 90.00 req/s per server, which appears as capacity tight. The N-1 row rises to 135.00 req/s per server and the failover badge changes to N-1 over budget, so one failed server would require more capacity or less retry pressure.


  
Reconnect storm with one server reserved

  
Keep the campus steady-state inputs, then model a 2.00 retransmission factor, a 1.40 peak burst multiplier, and one reserved or failed server. Total load jumps to 296.80 req/s, with two active servers carrying 148.40 req/s each against a 150 req/s budget. Retry Sensitivity marks the 2.00x case as an N-1 watch state, and Capacity Guidance points to high retry load before the pool fully crosses the budget line.






  
FAQ:

  

    What should I use for the per-server budget?
    
Use the request rate one RADIUS server can safely handle with real policy, directory lookup, accounting writes, logging, and monitoring enabled. A vendor maximum without that workload can make the budget look safer than it is.

  

  

    When should Access requests per event be higher than 1?
    
Raise it when one login can create several Access-Requests, such as challenge-based authentication or EAP conversations. Leave it at 1.0 for a simple single-request flow.

  

  

    Why does accounting change the capacity result?
    
Accounting requests share the same planning budget in this model. Start, Stop, and Interim-Update traffic can become a large share of base requests, especially when many active sessions report at a short interval.

  

  

    What does a high retransmission factor mean?
    
A factor above 1.15 is treated as a retry watch signal, and 1.50 or higher is treated as high retry load. Review timeout settings, packet loss, jitter, duplicate request handling, and overloaded response paths before scaling the design.

  

  

    Why did my blank or tiny input still produce a result?
    
Numeric fields are normalized to safe minimums where needed, such as one NAS, one server, a retransmission factor of 1.0, and packet sizes of at least 20 bytes. Re-enter the intended values if the output does not match your scenario.

  






  
Glossary:

  

    
NAS

    
Network access server, such as a wireless controller, VPN gateway, switch, or access point that sends RADIUS requests.

    
Access-Request

    
The RADIUS request packet used to ask for an authentication or authorization decision.

    
Accounting request

    
A RADIUS request used to record session activity, including Start, Stop, and Interim-Update records.

    
Interim-Update

    
A periodic accounting update for an active session.

    
Retransmission factor

    
A multiplier for duplicate or timeout-driven requests above the base request rate.

    
N-1 check

    
A capacity check that removes one configured server and divides the same total request rate across the remaining servers.

    
Per-server budget

    
The measured safe request rate for one RADIUS server under the policy and accounting workload being planned.

  






  
References: