RADIUS Failover and Retry Details
MRにおける RADIUS フェイルオーバーおよびリトライ日本語版はこちら
Dashboard provides the ability to host a sign-on splash page that can use one or more external RADIUS servers for authenticating users. This document describes the details of how and when those RADIUS servers will be contacted for authentication, and how the Dashboard will behave if it is unable to contact any of the configured servers.
For the purposes of this document, let's assume that you have configured three RADIUS servers for authentication and that they have the hostnames radius1.example.com, radius2.example.com, and radius3.example.com, in that order. We will refer to them as servers 1, 2 and 3 respectively in the following examples.
Load Balancing Policy
The "Load balancing policy" setting in Dashboard determines which RADIUS server will be contacted first in an authentication attempt, and thus the ordering of any necessary retry attempts.
This can be found via Wireless > Configure > Access Control > RADIUS when Sign-on with my RADIUS server is selected under the Splash page section. There are two options, Strict priority order (default) and Round robin:
Strict Priority Order
The servers will always be contacted in the order listed in Dashboard. In the example given, that ordering is 1,2,3. That means that server 1 is always contacted first and server 2 will only be contacted if server 1 cannot be reached. Similarly, server 3 will only be contacted if neither server 1 nor server 2 can be reached.
Round Robin
The server chosen first will be rotated based on which was used last. So on the first auth request from a client, the order for contacting servers will be 1,2,3 (i.e. same as the "strict priority" setting). On the next auth request however, the ordering will be 2,3,1, then 3,1,2, and then 1,2,3 again. The purpose of this setting is to have all of the configured servers receive roughly the same number of requests on average so that no single server has to handle all of the request traffic.
Retry Attempts
In the event that a RADIUS server is not reachable, the Dashboard will attempt to contact each server up to three times (one initial request plus two retries).
In the example above, behavior will differ based on the load balancing policy:
- If load balancing is set to "strict priority" and all three servers are unavailable, then a total of nine (9) RADIUS packets will be sent by the Dashboard, in this order: 1,2,3,1,2,3,1,2,3
- If load balancing is set to "round robin", then the first server tried may be different, e.g. the ordering might be: 2,3,1,2,3,1,2,3,1
If no valid reply is received from any of the servers after all the retries, then the request will be handled according to the Failover policy setting (see below).
Retry Timing
The Dashboard uses a packet timeout of two (2) seconds. This means that after sending a RADIUS request packet, the Dashboard will wait for a reply for up to two seconds before giving up and trying the next server on the retry list.
The Dashboard will try the next server on the list if EITHER:
- The timeout period is exceeded for the packet that was sent, OR
- An error packet is received.
Error packets are generally ICMP "Destination Unreachable" packets that indicate either the connection was refused (e.g. no program is listening on the specified UDP port on the destination machine) or the host itself is unreachable (e.g. invalid IP address). If such a packet is received then the next server on the list is tried immediately since the Dashboard knows that it will not receive a reply packet from that server.
The packet timeout is needed because RADIUS servers that are overloaded, or that are behind a firewall that drops incoming request packets, may not send any error packets in response to authentication requests.
In the event that all configured RADIUS servers are unreachable, the maximum amount of time that an end user may have to wait for a reply after trying to log in via sign-on splash is 3*N*T, where N is the number of configured RADIUS servers and T is the per-packet timeout. In the normal case where T=2 seconds, this means that the users may have to wait up to 6 seconds per server, which is a maximum of 18 seconds if three RADIUS servers are configured.
Failover Policy
The Failover policy setting in Dashboard determines how authentication requests should be handled in the event that all of the configured RADIUS servers are unreachable.
If the policy is "deny", then no new users will be allowed on to the network until one or more RADIUS servers is available again. (Users with existing sessions can still use the network until their session ends.) This is the default setting.
If the policy is "allow", then users will be granted a special 1 hour session on the network if no RADIUS servers can be reached.
Failover policy is only available on configurations using Splash Page with RADIUS.
RADIUS Accounting
If you have RADIUS accounting servers configured, the same behavior described above for retrying RADIUS auth requests will also apply to retrying RADIUS accounting messages. The only difference is that the Failover policy setting does not apply to RADIUS accounting (availability of the accounting servers never affects whether clients are allowed on the network).