Log InNot all RADIUS systems are the same, and the system architecture can vary wildly. For example, a network design which works well for 10,000 users will likely not work well for 10,000,000 users. It can be difficult to just “scale up” a RADIUS system. In most situations, the entire system architecture has to change.
Basic RADIUS configuration
The most simple and straightforward RADIUS system consists of a single RADIUS server and a single database.
This one-to-one configuration is appropriate for networks that need to support relatively small numbers of users. As a rule-of-thumb, a single RADIUS server and database is a reasonable implementation for up to 100,000 users.
However, this one-to-one setup doesn’t work very well for more than 100,000 users and is vulnerable to failure. If either the RADIUS system or the database are down, the entire system is down. Moreover, upgrading anything requires you to take the entire system offline, which is often not acceptable.
RADIUS crossbar configuration
For networks serving roughly between 100,000 and 1 million users, we usually recommend a “crossbar configuration” to improve performance and introduce redundancy into the system
In this architecture, RADIUS server 1 normally uses Database 1, and RADIUS server 2 normally uses Database 2. The two databases are synchronized with each other so that they contain the same information.
In the event that Database 1 fails or needs maintenance, RADIUS 1 can then easily switch over to using Database 2. Similarly, if Database 2 goes down, RADIUS 2 can seamlessly transition to using Database 1. If one of the RADIUS servers goes down or needs upgrading, the other RADIUS server takes over, and users experience no disruption in service.
The crossbar configuration is generally suitable for up to about 1 million users. Some more scalability can be gained by deploying multiples of the same configuration in multiple geographic locations.
Load balanced configuration
For networks that must support over 1 million users, we recommend a load balanced or “sharded” configuration.
In a sharded architecture, there are multiple pairs of RADIUS servers and databases, and a load balancer distributes the traffic between them. The number of shards can scale up depending on the number of users. The databases are synchronized so that they all contain the same information.
The benefit of a sharded configuration are that it can scale very easily. As the number of users grows, more RADIUS/Database pairs can be added. There is no need to change the client configuration, or create complex fail-over scenarios. Simply add more back-end systems, and the load accepted by the RADIUS servers will scale nearly without limit.
Sharded configurations also provide many levels of redundancy. If any component of any of the “shards” are compromised or is taken down for maintenance, the load balancer detects that situation, and stops sending packets to that particular shard temporarily. When the shard comes back online, the load balancer will automatically start using it again.
All of these configurations can be used in conjunction with any of the other RADIUS database architectures for specific characteristics. For example, it is possible to separate accounting from authentication functionality, or split historical data from “live data”. There is no need to use the same architecture for authentication and accounting. There is no need to use the same architecture in different locations.
For more details on RADIUS system architecture, see our article on RADIUS database architecture considerations.
The costs of implementing the wrong design
There are many costs to using the wrong design for your network. The simplest of course is increased expense, time, and effort for complex systems which are not needed. Similarly, a system which is too small will not be able to handle the traffic, which will result in users being unable to access the network.
It may be tempting to use cloud services which automatically scale, and are billed only for services used. However, using cloud services is not always recommended, as they have their own costs and benefits. We will cover those services in another article.
As with all summary articles, this one provides a high level summary of the technical issues. The numbers given above are only a guideline, and are not intended to be a “written in stone” set of recommendations. Your individual architecture may differ from the ones described here, depending on your local requirements.
Need more help?
Network RADIUS has been helping clients around the world design and deploy their RADIUS infrastructure for 20 years. We specialize in complex systems and have seen pretty much every variation and problem out there. If you want help from the people who wrote FreeRADIUS, visit our quote page to contact us for a consultation.
