H3C Technologies H3C SecPath F1000-E - Manual (Page 196)

186
NOTE:
Changing the RADIUS server type restores the unit for data flows and that for the packets sent to the
RADIUS server to the defaults.
Setting the maximum number of RADIUS request transmission attempts
Because RADIUS uses UDP packets to transfer data, the communication process is not reliable. RADIUS
uses a retransmission mechanism to improve the reliability. If a NAS sends a RADIUS request to a
RADIUS server but receives no response after the response timeout timer (defined by the timer
response-timeout command) expires, it retransmits the request. If the number of transmission attempts
exceeds the specified limit but it still receives no response, it tries to communicate with other RADIUS
servers in active state. If no other servers are in active state at the time, it considers the authentication or
accounting attempt a failure. For more information about RADIUS server states, see "
Setting the status of
RADIUS servers ."
The maximum number of transmission attempts of RADIUS packets multiplied by the RADIUS server
response timeout period cannot be greater than 75 seconds. For more information about the RADIUS
server response timeout period, see "
Setting timers for controlling communication with RADIUS servers ."
To set the maximum number of RADIUS request transmission attempts for a scheme:
Step Command Remarks
1. Enter system view. system-view N/A
2. Enter RADIUS scheme view. radius scheme radius-scheme-name N/A
3. Set the maximum number of
RADIUS request transmission
attempts.
retry retry-times
Optional.
The default setting is 3.
Setting the status of RADIUS servers
By setting the status of RADIUS servers to blocked or active, you can control which servers the firewall will
communicate with for authentication, authorization, and accounting or turn to when the current servers
are no longer available. In practice, you can specify one primary RADIUS server and multiple secondary
RADIUS servers, with the secondary servers functioning as the backup of the primary servers. Generally,
the firewall chooses servers based on these rules:
• When the primary server is in active state, the firewall communicates with the primary server. If the
primary server fails, the firewall changes the server's status to blocked and starts a quiet timer for
the server, and then turns to a secondary server in active state (a secondary server configured
earlier has a higher priority). If the secondary server is unreachable, the firewall changes the
server's status to blocked, starts a quiet timer for the server, and continues to check the next
secondary server in active state. This search process continues until the firewall finds an available
secondary server or has checked all secondary servers in active state. If the quiet timer of a server
expires or an authentication or accounting response is received from the server, the status of the
server changes back to active automatically, but the firewall does not check the server again during
the authentication or accounting process. If no server is found reachable during one search process,
the firewall considers the authentication or accounting attempt a failure.
• Once the accounting process of a user starts, the firewall keeps sending the user's real-time
accounting requests and stop-accounting requests to the same accounting server. If you remove the
accounting server, real-time accounting requests and stop-accounting requests for the user are no
longer delivered to the server.