Feature Description
Remote Authentication Dial-In User Service (RADIUS) is a client and server protocol. The RADIUS client is typically a Network Access Server (NAS) and the RADIUS server is usually a daemon process running on a UNIX or Windows NT machine. The client passes user information to designated RADIUS servers and acts on the response that is returned. RADIUS servers receive user connection requests, authenticate the user, and then return the configuration information necessary for the client to deliver service to the user.
RADIUS provides Authentication and Accounting services to the users. The SMF supports the following configurations:
-
Add RADIUS server details.
-
Enable RADIUS accounting and authentication.
-
Add RADIUS interface as an option for virtual APN configuration within DNN profile.
-
Enable CC trigger reporting.
-
Define volume and time limits.
The RADIUS client supports the following functions:
-
Server Selection
RADIUS servers are configured with IP: Port as the key. The algorithm CLI specifies the failover or load-balancing algorithm to select the RADIUS server to which the authentication or accounting request must be sent. Servers that are marked "dead" aren’t considered for selection until they are marked "alive". The supported algorithms are first-server and round-robin.
-
First-server—Specifies that the request must be sent to the RADIUS server with the highest priority. If the server becomes unreachable, the request is sent to the server with the next highest configured priority. This is the default algorithm.
-
Round-robin—Specifies that the request must be sent based on load balancing in a circular queue manner. The server that is last used is stored to maintain the round-robin selection. The order of the list is purely based on the configuration sequence.
-
-
Monitor Server and Dead Server Detection
The Dead-Server Detection feature allows you to configure the criteria to be used to mark a RADIUS server as dead. The two different parameters that you can set up to identify a dead server are as follows.
-
Response-timeout: Monitor Server revisits the server database and marks the server which hasn’t received response beyond the configured "response-timeout" value after the first request is sent. The server is marked "dead" and remains in dead-state for minutes configured as "deadtime". After the "deadtime" elapses, the server's dead-variable is reset again to mark it as ready to process requests. If the server is still not reachable, it’s marked "dead" as part of the next request response timeout.
-
Consecutive failures: Consecutive failure helps to configure the number of consecutive timeouts that must occur on the server before the RADIUS server is marked as dead. Whether a request is a retry request or a regular request, the failure count increments when server doesn’t return any response (i.e request timeout). When the failure count of the server reaches the threshold for consecutive failures, the server is declared as dead server.
-
-
Timeout and Retry
After a server is selected and a request is sent to the server, an entry is maintained in the request queue until response is received from the RADIUS server or until timeout occurs. Monitor Requests is called to check on the requests queue for response timeouts and retry. It walks through all the entries and checks if any request timeout value configured as "timeout" is hit. For such requests, if the number of retries is less than the configured "max-retries" value, the request is resent to the RADIUS server. Else, if the "max-retries" count is reached, the request is deleted from the request queue. After a request is deleted, even if response comes for such requests, the response is discarded and not sent to the user.
-
Max transmission
Max transmission helps to configure the transmission parameters for all the available servers. This feature helps to cross-check if the number of transmissions exceeds the number of retries once the retry cycle for a request is finished, and if so, it begins the subsequent retry cycle on a different server if one is available. If no server is available, or if the maxtransimissions limit is reached, then the timeout response is sent.
Example: If max-transmissions value is set to 5, max retry value is 2, and there are two servers available. So there are three attempts (one actual attempt and two retries) on the first server, and the remaining 2 (1 actual and one retry) on the second server.