¶ Radius failover
¶ Overview
The RADIUS protocol is one of the methods to authorize internet services in Splynx.
Radius failover increases the reliability and resilience of the RADIUS protocol and its interactions with NAS devices.
This module allows the creation of an additional server(-s) that will function as a backup one for the main Splynx RADIUS server. This is useful if the Splynx server is under maintenance or there is a loss of connection with the main server.
In such a case, a router will automatically switch to the failover server, and the customer’s services will be less susceptible to outages.
The data synchronization between the main server and the radius failover occurs every 4 hours.
The solution is an active-active configuration.
¶ Getting started
![]()
Minimum requirements to run the backup server
Ubuntu 20.04 server with SSH root access allowed via RSA key.
- CPU: 4 cores
- CPU Core speed: 2.4 GHz
- Memory: 4 GB
- SSD: 64 GB
Your Ubuntu 20.04 server needs to be clear and updated without pre-installed Splynx or any other software.
Additionally, please add 4GB SWAP for the system.
Use this command to create SWAP:
sudo sh -c "fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile && swapon --show"
The Splynx system will add/install everything automatically for the next step described in the documentation below.
First, the Radius server should be configured on your Splynx server. The following article explains this process: Radius.
The next step is the radius failover configuration. For this, navigate to Config → Networking → Radius failover:
Click the Add button to add a new backup RADIUS server (Radius failover) to the list:
- SSH host (IPv4) - indicates the IP address that will be reserved for the RADIUS server;
- Commands... - execute the commands from this window on your backup (failover) server to create the connection;
- Enabled - enable this to make the failover server available for initialization;
- SSH username (for viewing only) - root SSH username;
- SSH port - specify the SSH port.
Click the Add button at the bottom of the add server window to start the initialization of the failover server.
The newly added failover server will now show in the list:
Here you can view the IPv4 address of the backup server, its initialization status, when it was last updated and the date and time of its last successful sync.
There are several stages of the radius failover initialization - each stage can be viewed under the Status column:
![]()
Initialization stages
a newly added server for the radius failover (if it is enabled in the config, the status will be immediately changed to Init).
the server initialization process when the required packets are added and the data is synced for the backup server to work correctly. The initialization duration may vary depending on the number of services on the main server.
the synchronization of data to ensure proper operation of the new services and after any changes to existing services.
in this stage, all data is synced and the radius failover server is ready to work via the RADIUS protocol to ensure the AAA (authentication, authorization, accounting) process functions correctly. Now you can specify it as one more radius server on the router:
If an error occurs at any stage, the following statuses could be shown: Init error, Connection error, Remote error or Sync error (on red backgrounds). The Disabled status on a dark background means that the server is disabled in the config.
After finishing all the stages of initialization, you should wait till the process is completed on the remote server. When it is completed, the status for MySQL, Free Radius and Splynx Radius will be changed to Active:
¶ Actions
- you can edit the information about the radius failover server:
- by clicking on Services status, you can view the status of services on the current radius failover. Use the Force sync button should you wish to synchronize the radius failover:
- the View log button allows you to view radius failover logs, search necessary information that will be displayed in the field below after clicking on Load:
The Scroll On/Off button, when enabled, can automatically scroll the log window when new log entries are added.
- click the Delete button to delete the selected radius failover.
¶ Examples
![]()
An example network topology with a failover server
Radius auth request to the main server:
Radius auth request to the failover server (when the main server is not available):
![]()
MikroTik router configuration
Example of two RADIUS servers added - primary + failover:
The second RADIUS server entry is reached only if the first RADIUS server doesn't respond.
Src. IP address of the MikroTik Radius client and the NAS IP address attribute value sent to the server in Radius UDP packets should be the same for the primary and failover servers.
![]()
Radius debug on MikroTik
To view detailed Radius client information and determine which Radius server your router is using - you can Radius debug on MikroTik can be enabled via System -> Logging:
CLI command:
/system logging/add topics=radius
![]()
Radius accounting on failover server
The failover server is accepting Radius accounting packets, but it is not writing or syncing them to the failover server itself.
The primary purpose of the failover server is to provide authorization to existing customers and it is primarily designed for this purpose in Splynx. It is not intended for load-balancing.
Example:
- Customer logins and accounting starts on the main server.
- When main servers goes offline, MikroTik starts sending interim accounting requests to the failover server (we believe this is done automatically when MikroTik registers that there is no connection to the main one according to the priority).
- Failover simply accepts accounting packets to ensure the accounting process for each session continues; it does not process them. Inside each accounting packet, whether it's an Accounting-Start or Interim-Update, there are incremental counters within RADIUS attribute values that only increase with time, such as the session duration and traffic counters.
- When your primary Splynx server is operational, the router should redirect authentication and accounting processes to it. Upon receiving an accounting packet at the main Splynx server, it will record the accounting data and establish the customer's online status using information extracted from the accounting packet for the current client session.
The sole issue arises when a customer session terminates before your primary Splynx instance is operational. In such cases, the historical session accounting data becomes susceptible to loss, as there is currently no mechanism in place to store and synchronize it with the main server.
Regarding customer online status: You will never see a customer who is online during failover on the main server simply due to the aforementioned logic of our failover feature. Its main purpose is to serve as a backup for authorization, allowing your customers to log in whenever the main instance is down. In such a case, when the main instance is down, there is no point in even attempting to sync the customer's online status there.