The RADIUS protocol is one of the methods to authorize internet services in Splynx.
Since v4.1 of Splynx, Radius failover was implemented to increase the reliability and resilience of the RADIUS protocol and its interactions with NAS devices.
Radius failover is a module that 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.
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.
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:
Add button to add a new backup RADIUS server (Radius failover) to the list:
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:
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:
- 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:
View log button allows you to view radius failover logs, search necessary information that will be displayed in the field below after clicking on
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.
Radius auth request to the main server:
Radius auth request to the failover server (when the main server is not available):
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.
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:
/system logging/add topics=radius
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.
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.