R3166-R3206-HP High-End Firewalls Access Control Configuration Guide-6PW101

141
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 the active state. If no other servers are in the 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.“
Follow these steps to set the maximum number of RADIUS request transmission attempts for a scheme:
To do… Use the command…
Remarks
Enter system view system-view —
Enter RADIUS scheme view
radius scheme
radius-scheme-name
—
Set the maximum number of
RADIUS request transmission
attempts
retry retry-times
Optional
3 by default
NOTE:
• 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
co
ntrolling communication with RADIUS servers.“
Setting the status of RADIUS servers
By setting the status of RADIUS servers to blocked or active, you can control which servers the device will
communicate with for authentication, authorization, and accounting or turn to when the current servers
are not available anymore. 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 device chooses servers based on these rules:
• When the primary server is in the active state, the device communicates with the primary server. If
the primary server fails, the device changes the server’s status to blocked and starts a quiet timer for
the server, and then turns to a secondary server in the active state (a secondary server configured
earlier has a higher priority). If the secondary server is unreachable, the device changes the
server’s status to blocked, starts a quiet timer for the server, and continues to check the next
secondary server in the active state. This search process continues until the device finds an
available secondary server or has checked all secondary servers in the 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 device does not check the server
again during the authentication or accounting process. If no server is found reachable during one
search process, the device considers the authentication or accounting attempt a failure.
• Once the accounting process of a user starts, the device 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 cannot
be delivered to the server anymore.
• If you remove an authentication or accounting server in use, the communication of the device with
the server will soon time out, and the device will look for a server in the active state from scratch: it