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.

Meet Radiator team at WGC Americas in Dallas!

We are delighted to announce that Radiator Software will be attending the top connectivity event of the summer: WGC Americas in Dallas on 10 – 13 June 2024. We are looking forward to meeting our current and prospective partners and customers in Texas.

Wireless Global Congress Americas

WGC is hosted by the Wireless Broadband Alliance and gathers together Wi-Fi industry leaders and experts from all around the world. As usual, the event is divided into two parts: WBA Members-Only Sessions and plugfest on 10 and 11 June hosted by AT&T, and WGC Americas Open Congress on 12 and 13 June held in Dallas Marriott Downtown.

Meet with Radiator team

We extend an invitation to all WGC Americas attendees to meet with Radiator managing director Karri Huhtanen, who is part of our conference delegation. You can find the Radiator team at the WBA Members-Only Sessions and in the Open Congress throughout the event.

To schedule a meeting or simply ask a question, please leave a message and we will get back to you. See you in Texas!

Radiator Simple WiFi Authentication – Introduction to Radiator Cloud

We are pleased to announce an expansion to the Radiator product offering – Radiator Cloud for Azure. We have ever so often been approached by companies and organisations that require a fast to set up, easy to use hosted WiFi authentication solution.

Often the trouble with Software-as-a-Service type WiFi solutions is the concern for privacy, who has access to customer data and how it is handled. To address the demand for a hosted solution with complete privacy to customer data, we’ve developed an Azure-native cloud solution – Radiator Cloud for Azure

Radiator Cloud for Azure is a managed application that is deployed, hosted, operated and monitored all in Azure. User data and logs stay within your Azure tenant with no external access. User and NAS client provisioning is done with enhanced Azure UI and the solution can be monitored with premade Azure Monitoring queries.

Radiator Simple WiFi authentication, powered by Radiator Cloud

The first application that is now live in Azure Marketplace is Radiator Simple WiFi authentication. It is a simple username-password authentication solution that allows organisations to take control of their wireless network with minimum requirements. The only prerequisites to deploying the solution are an active Azure subscription and access to one’s network device configuration.

Deployment is done within minutes from the Azure Marketplace. A user with at least Contributor permissions for their tenant can deploy the application. Provisioning and monitoring is made straightforward with Azure UI and billing is done together with the organisation's other Azure applications.

Radiator Simple WiFi authentication – Easy, Fast and Affordable

The main customer groups that benefit from the application are organisations who do not yet have any WiFi authentication solution in use, as well as organisations with multiple locations who want to centralise their WiFi authentication operations. Radiator Simple WiFi authentication provides an easy way for centralised user and device management with minimum prerequisites.

Radiator Simple WiFi authentication is easy, fast and affordable. The simple structure of the application, backed with comprehensive deployment guide and user manual, make the application easy to deploy and operate. Deployment process is automated and does not need any vendor approval. Provisioning is very straightforward. In a typical deployment, you have a working system within the same day.

The costs of the application consists of two parts: fixed monthly software cost and Azure running costs for hosting the application. All costs are transparent and easy to estimate. You are only billed by Azure, along with your other Azure applications.

The future of Radiator Cloud

While Radiator Simple WiFi authentication is already available for purchase in Azure Marketplace, we are also actively looking to expand the Radiator Cloud product family both horizontally with other use cases and vertically to other platforms.

Our two big roadmap items for Radiator Cloud are enterprise-grade WiFi authentication application and an application for WiFi authentication utilising Microsoft Entra IDs. Both of these address a direct need not only from new but also existing customers who are looking to move from their existing Active Directory on to Azure.

While these development news are all about Radiator Cloud, this is by no means a sign that we would have shifted focus from our on-site products. Radiator is committed to active development and latest standards and these efforts are made to make Radiator products more accessible to all organisations across different platforms and deployment models.

Want to know more?

If you have any questions about Radiator Simple WiFi Authentication or Radiator Cloud roadmap items, please do not hesitate to contact us at sales(a)radiatorsoftware.com

WiFi offloading vs VoWiFi

In recent years we have encountered a lot of customers wanting to utilize their networks more efficiently, and provide premium service for their subscribers. WiFi offloading and VoWiFi are popular ways to to extend the mobile operator’s network coverage into wifi, free bandwidth from congested cellular networks and improve user experience with better connectivity. The technologies share many similarities and both use a 3GPP AAA server for SIM based authentication.

WiFi offloading offers some flexibility in the supported authentication backends and the SIM authentication can be done through various HSS and HLR interfaces depending on what the mobile operator has available. This is especially important in roaming scenarios where the WiFi provider has agreements with multiple MNOs to offload their subscribers.

WiFi calling is more strictly standardised to support high QoS for the voice call, and also the handover between VoWiFi and VoLTE. This allows users to move outside the range of the WiFi hotspot and seamlessly continue the call over VoLTE, and vice versa.

Let’s take a look at the key differences between the two related technologies:

Comparison	WiFi offloading	VoWiFi
Purpose	Ease network congestion, Network CAPEX savings, Roaming cost savings, Secure authentication to private wireless networks: carrier, industrial, in-flight, underground, IoT	Ease network congestion, Indoor coverage extension, Combat OTT apps, Roaming cost savings
Relationship between MNO and access network provider	Agreement required between MNO and wifi provider	No relationship between MNO and wifi provider
Access network	Carrier or partner wifi	Any public or private wifi
Traffic	Data only	Voice and video calls
SIM authentication protocol	EAP-SIM, EAP-AKA, or EAP-AKA’	EAP-AKA
Supported HSS interfaces	SWx, Wx, Cx, S6a	SWx required
Supported HLR interfaces	MAP, SIGTRAN	Not supported
ePDG	Not applicable	ePDG mandatory
Security	WPA Enterprise	IPSec tunnel between UE and ePDG
IMSI Privacy	Yes, supported by Radiator	Yes, supported by Radiator

What is different?

The main difference between WiFi offloading and VoWiFi is the relationship between the mobile operator and the wifi provider: operator controlled data offloading always requires a prior agreement between the MNO and the WISP. WiFi offloading is often done in high traffic areas such as airports, sports stadiums and concert venues, since offloading users to WiFi is cheaper than adding microcells to boost the mobile signal. MNOs can invest in carrier wifi hotspots themselves, or make offloading agreements with wireless ISPs.

VoWiFi requires the mobile device to be connected to a wifi before attempting a VoWiFi call, but any type of wifi can be used for WiFi calling, including consumer home wifi. Therefore no relationship between the mobile operator and WiFi provider is required. However VoWiFi has specific technical requirements for the MNO: a HSS with SWx interface and ePDG are required.

Private network authentication

WiFi offloading technology is also applicable to private network offerings, such as industrial and IoT networks. SIM authentication provides a secure method to authenticate users into a private network using their SIM credentials and eliminates the human element of reusing and sharing passwords. In high security deployments the SIM authentication can be further combined with device IMEI check, to make sure that only authorised users and devices are able to access the private wifi network. VoWiFi is also possible in private networks, and can enable voice calls in challenging environments such as underground.

Interested in WiFi offloading or VoWiFi?

Radiator SIM Pack provides a fully featured 3GPP AAA server solution, with superb flexibility to connect with your environment. Please contact the Radiator team at sales (at) radiatorsoftware.com to get a quote.