25
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
RADIU
S servers."
To set the maximum number of RADIUS request transmission attempts for a scheme:
To do… Use the command… Remarks
1. Enter system view.
system-view —
2. Enter RADIUS scheme view.
radius scheme radius-scheme-
name
—
3. Set the maximum number of
RADIUS request transmission
attempts.
retry retry-times
Optional
3 by default
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 "
7Setting timers for
controlling 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 switch
communicates with for authentication, authorization, and accounting or turns 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 switch chooses servers based on these rules:
• When the primary server is in the active state, the switch communicates with the primary server. If
the primary server fails, the switch changes the server’s status to blocked and starts a quiet timer for
the server, and then it 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 switch 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 switch 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 switch does not check the server again during the
authentication or accounting process. If no server is found reachable during one search process,
the switch considers the authentication or accounting attempt a failure.
• Once the accounting process of a user starts, the switch 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 switch with
the server soon times out, and the switch looks for a server in the active state from scratch. It checks
the primary server (if there is one) first and then the secondary servers in the order they are
configured.
• When the primary server and secondary servers are all in the blocked state, the switch
communicates with the primary server. If the primary server is available, its status changes to active;
otherwise, its status remains as blocked.
• If one server is in the active state and all others are in the blocked state, the switch only tries to
communicate with the server in the active state, even if the server is unavailable.