How to speed up RADIUS authentication processing during peak hours with Radiator

From time to time, our customers reach out to us and ask guidance on how to speed up RADIUS authentication processing during peak hours. Performance of this core functionality of Radiator is stable and predictable, and with increasing traffic load, most of the bottlenecks often emerge from the performance of the backend services that Radiator is utilising. In this blog, we give some helpful information to make improvements.

What causes bottlenecks?

In many cases,  authentication backends that Radiator is configured to use may be too slow to process the number of requests that are arriving. For example SQL databases may be slow to respond, LDAP lookups can take time, or HTTP requests be delayed. Writing accounting data or logging to a slow database can slow down Radiator.

When this happens, the host system's UDP traffic buffer on the listening port fills up to the point that it overflows and new RADIUS request packets arriving at the server get dropped. Because the requests are dropped by the host operating system, they cannot even be logged as failed requests by Radiator.

To get a better understanding of what is happening during peak hours, set `Trace 4` debug log level with `LogMicroseconds` in the configuration file (see [How to enable debug logging?]. The debug log will show how long each processing step is taking, and from there you can determine how many requests per second the configuration can handle.

How to tune Radiator to speed up authentication processing?

There are several ways to tune Radiator to speed up processing:

• Split configuration into two separate files, one for authentication and one for accounting, and run Radiator as two separate running instances. This way there are two processes handling traffic with their own UDP buffers and backend dependencies that may even out the congestion. On Linux systems with systemd there are mechanisms readily available to help with that. More information: [How do I manage Radiator instances on a single host?].
• Use a proxy instance to forward authentication and/or accounting requests to multiple worker instances (see first bullet). The requests can be spread out to worker instances so that request state is preserved (see [methods for load distribution and balancing] in documentation).
• Within instances, use [FarmSize] to create a farm of server processes to add parallel processing of requests. Note: This is not compatible with many EAP protocols, such as EAP-TLS, EAP-TTLS, PEAP etc. This is because such protocols rely on authentication state being held within each server process, and it is necessary for all the requests for such protocols to go to the same Radiator process.
• Incoming requests can be distributed from one or two proxying or load-balancing hosts to multiple hosts for processing.
• Depending on use case, any combination of FarmSize, multiple instances per host and multiple hosts can be used together to enable more throughput. Separating processing on the Radiator side will create more separate connections to backends that may help even out backend load.

Additionally, the bottleneck might be the available resources

• If the host is running other processes, make sure it has enough resources available for Radiator. The best would be to use dedicated hosts for each function.
• If a virtualisation platform is used, make sure that it can provide the configured resources to Radiator virtual machines even during the peak hours when other vm's are running their peak loads.
• Logging to external servers may cause some unneeded delays for Radiator. This can be mitigated by configuring Radiator to log locally, and then process and ship logs with a separate agent.
• Outside of Radiator, performance of backends may be tuned depending on the backend itself. For example a database can be scaled up or replicated to multiple-server cluster. On the other hand, speeding up the database might be possible even without adding more hardware if queries can be optimised or suitable indexes created. For optimising backends, please refer to their respective documentation.
• Running configuration or Radiator may contain some parts that can be optimised. At the end of this blog post, we tell a bit about our consultation services. 

How can we help?

 

In case you would like our assistance when tuning your Radiator and related infrastructure, please contact sales@radiatorsoftware.com. Our team of experts have a long experience on configuring Radiator, and also assisting with the best practices when integrating Radiator with existing or new infrastructure. 

Radiator as a CISCO CPAR replacement

Recently we have received a lot of queries on whether Radiator AAA would be a good solution for replacing Cisco CPAR (Cisco Prime Access Registrar). As it is known, Cisco CPAR has a released end of support date in October 2024, after which it will not receive software maintenance updates. Therefore many operators are looking to replace their existing CPAR setups with alternative established robust AAA solutions. If you are among these companies, Radiator AAA is the solution for you.

Why choose Radiator AAA as a Cisco CPAR replacement?

 

Known for its reliability and flexibility, Radiator AAA has been in the market for decades. Radiator is an actively developed and supported AAA server with RADIUS and TACACS+ functionalities. With modules focused on carriers, Radiator AAA can also be complemented with Diameter functionalities, SIM-based authentication with IMSI Privacy and other mobile network functionalities.

At the same time, Radiator AAA Server offers support for both Linux and Windows installations - and Radiator AAA has multi-vendor support and can be installed flexibly on different platforms on physical or virtual machines. Radiator has extensive support for different databases and authentication backends (SQL-based, LDAP, AD etc.) as well as support for MFA solutions with TOTP capable authenticators and tokens (Google and MS authenticator, Yubikey, DIGIPASS etc.)

The Radiator technical team consists of experts with vast experience in migration from other AAA solutions. We offer migration support and configuration assistance so you do not need to worry about meeting project schedules before the end of support for CPAR - we have already done these kinds of transitions. Radiator can integrate with existing databases and in most cases no changes to schema are needed.

With Radiator, you can compile your AAA use cases under one product: RADIUS, Diameter, TACACS+, SIGTRAN, you name it, we have it!

Want to know more?

For any questions or other inquiries about Radiator as Cisco CPAR replacement, please contact sales@radiatorsoftware.com. We always provide also simple, transparent and cost-effective licensing models, so there will be no surprises in the cost of ownership during the whole time your company is using Radiator.