Load Testing Guide

Overview

Load testing your RADIUS authentication infrastructure helps you understand capacity limits, establish performance baselines, and identify bottlenecks before they affect users. This guide covers how to plan capacity, measure authentication performance, and stress test your IronWiFi deployment.

Why Load Test RADIUS?

Question Load Testing Answers	Why It Matters
How many concurrent users can my deployment handle?	Prevents authentication failures during peak times
What is the average authentication latency?	Sets expectations for user experience
At what point does performance degrade?	Identifies scaling thresholds
Are my APs or IronWiFi the bottleneck?	Directs optimization efforts
How does my deployment handle burst traffic?	Simulates events, shift changes, class transitions

Capacity Planning

Estimating Authentication Load

Before testing, estimate your expected authentication volume:

Factor	How to Estimate
Peak concurrent users	Maximum users connected simultaneously
Authentication rate	Users authenticating per minute during peak (e.g., shift change)
Re-authentication frequency	How often sessions require re-authentication (based on Session-Timeout)
Accounting updates	Interim accounting interval x concurrent users

Example calculation:

IronWiFi Capacity

IronWiFi's cloud RADIUS infrastructure is designed for high availability:

• Authentication processing: Handles thousands of requests per second per region
• Automatic scaling: Backend scales based on demand
• Geographic distribution: Multiple regions reduce latency
• Redundancy: Primary and secondary RADIUS servers per Network

note

For most deployments, the bottleneck is the access point or controller, not IronWiFi's RADIUS servers. APs typically have limits on concurrent RADIUS sessions they can manage simultaneously.

Access Point Capacity Considerations

Each AP vendor has different RADIUS client limits:

Factor	Typical Limit
Concurrent 802.1X sessions per AP	30--200 (varies by model)
RADIUS timeout	3--10 seconds (configurable)
RADIUS retries	1--5 (configurable)
Maximum clients per radio	64--512 (varies by model)

Check your AP vendor's documentation for specific limits.

Setting Up Load Tests

Prerequisites

Before running load tests:

1. Create a test Network in the IronWiFi Console (do not test against production)
2. Create test user accounts with known credentials
3. Ensure network connectivity between your test machine and IronWiFi RADIUS servers
4. Record the RADIUS settings (server IP, port, shared secret)

warning

Run load tests against a dedicated test Network, not your production Network. Load testing against production can trigger rate limiting and affect real users.

Using radperf (Recommended)

radperf

is a purpose-built RADIUS load testing tool:

Users file format (

users.txt

):

Using radclient for Simple Tests

For basic authentication testing (not load testing):

Using eapol_test for EAP Testing

For testing EAP-based authentication (PEAP, EAP-TLS):

For EAP-TLS testing:

Scripted Load Test

For custom load testing scenarios:

Performance Baselines

What to Measure

Metric	Description	Target
Authentication latency	Time from request to Accept/Reject	< 100 ms (simple auth), < 500 ms (EAP)
Success rate	Percentage of valid credentials accepted	100% for valid credentials
Throughput	Authentications per second	Depends on deployment size
Error rate	Percentage of timeouts or errors	< 0.1%
P95 latency	95th percentile response time	< 2x average latency
P99 latency	99th percentile response time	< 3x average latency

Establishing a Baseline

Run a series of tests with increasing load to establish your baseline:

1. Warm-up: 10 requests, 1 concurrent (verify setup works)
2. Light load: 100 requests, 5 concurrent
3. Normal load: 500 requests, 20 concurrent
4. Peak load: 1000 requests, 50 concurrent
5. Stress load: 2000 requests, 100 concurrent

Record the results for each test:

Interpreting Results

• Linear latency increase: Normal behavior as load increases
• Exponential latency increase: Approaching capacity limit
• Success rate drop: Load exceeds capacity; reduce concurrent users or optimize
• Timeout errors: Network issue or RADIUS server overloaded

tip

Your baseline should reflect your expected peak load with at least 50% headroom. If your expected peak is 50 concurrent authentications, ensure the system handles 75 with acceptable latency.

Stress Testing Scenarios

Burst Authentication (Shift Change)

Simulate a large number of users authenticating simultaneously:

Sustained Load (Business Hours)

Simulate steady authentication load over an extended period:

Mixed Authentication Methods

Test with different EAP methods to understand the performance impact of each:

1. Run separate tests for PAP, MSCHAPv2, EAP-PEAP, and EAP-TLS
2. Compare latency and throughput for each method
3. EAP-TLS is typically slower per-authentication due to the TLS handshake but more secure

Failover Scenarios

Test what happens when the primary RADIUS server is unreachable:

1. Configure your AP with both primary and secondary RADIUS servers
2. Run a load test against the AP
3. Block traffic to the primary RADIUS server (firewall rule)
4. Observe failover behavior and measure impact on authentication latency
5. Restore the primary and verify recovery

See Failover Testing for detailed failover test procedures.

Analyzing Results

IronWiFi Console Metrics

After running load tests, review the results in the IronWiFi Console:

1. Navigate to Logs > Authentication Logs
2. Filter by the test time period
3. Review:
   • Total authentication attempts
   • Accept/Reject ratio
   • Average processing time
   • Any error patterns

Common Bottlenecks

Bottleneck	Symptoms	Resolution
AP RADIUS client limit	Timeouts under moderate load	Use multiple APs or upgrade to enterprise-grade
Network latency	High P95 latency, low throughput	Use the closest IronWiFi region; check network path
Shared secret mismatch	All requests rejected	Verify shared secret matches exactly
External IdP slow	High latency for LDAP/SAML auth	Check IdP performance; use local auth for testing
DNS resolution	Intermittent timeouts	Use IP addresses instead of hostnames on APs

Optimization Tips

1. Use the closest IronWiFi region to minimize network round-trip time
2. Configure appropriate RADIUS timeouts on APs (5 seconds recommended)
3. Set RADIUS retries to 3 for resilience without excessive wait
4. Configure both primary and secondary RADIUS servers on every AP
5. Use accounting interim intervals of 300+ seconds to reduce accounting load
6. Consider local auth caching on APs that support it for re-authentications

Ongoing Performance Monitoring

Regular Testing Schedule

Test	Frequency	Purpose
Basic authentication test	Daily (automated)	Verify service is operational
Light load test	Weekly	Detect performance regressions
Full load test	Monthly	Validate capacity for current user count
Stress test	Quarterly	Verify headroom for growth
Failover test	Quarterly	Confirm redundancy works

Alerting

Configure alerts for authentication performance:

1. Set up the IronWiFi Service Monitor to detect RADIUS availability issues
2. Create alerts for authentication failure rate exceeding a threshold
3. Monitor response time trends over time to detect gradual degradation

Related Topics

• Failover Testing -- Testing RADIUS failover procedures
• Networks -- RADIUS server configuration
• Service Monitor -- Automated health checks
• Troubleshooting -- Diagnosing authentication issues
• Attributes -- Session and accounting attributes
• Authentication Testing -- Test local account authentication