> RADIUS Server State Behavior
> This appendix provides an explanation of RADIUS server states and the commands that affect them. It also provides a list of triggers that change servers in a “Down” state to “Active”.
> Understanding RADIUS Server States and Commands
> Server States
> The system defines three server states for connected RADIUS servers:

> • | Active: The server is believed to be operational.

> • | Not Responding: The server has failed to respond to a message from the system a configured number of times (retries).

> • | Down: The system is no longer sending requests to the server.

> RADIUS Server Commands
> RADIUS server states are controlled by parameters set in the RADIUS Server Group Configuration Mode. The commands are:

> • | detect-dead-server: Configures how the system determines that a RADIUS server is not functioning. One or both of the following parameters should be set:

> • | consecutive-failures: Configures the consecutive number of times the RADIUS server is unreachable by any single aaamgr on the system based on the max-retries command. If this command is enabled, each time the maximum number of retries is exceeded, this counter increments by one for the particular aaamgr and server. When any aaamgr exceeds this counter for a specific RADIUS server, the server’s state is changed to “Down” and the deadtime timer is started. The default is enabled and 4.

> • | response-timeout: Configures a specific delay, in seconds, in receiving a response from the RADIUS server before the server’s state is changed to “Down” and the deadtime timer is started. The default is disabled.

> Important: If response-timeout is configured and consecutive-failures is not, the system will only wait for the specified period of time before changing the server’s state to “Down”, ignoring other settings such as radius timeout, and max-retries.
> If response-timeout is configured and consecutive-failures is not, consecutive-failures is removed entirely from the system, including default configuration. If both parameters are configured, then both conditions must be met to change a RADIUS server’s state to “Down”.

> • | deadtime: Configure the maximum amount of time, in minutes, that must elapse after a context has exceeded one or both of the detect-dead-server parameters, depending on which parameter is configured. Once this timer has elapsed, the system reclassifies the RADIUS server as “Active” and subsequent requests to it can be made. If radius deadtime is not explicitly configured, the default value of 10 minutes is used.

> • | max-retries: Configures maximum number of times the system attempts to retry communication with a RADIUS server. Once exceeded, the system changes the state of the server to “Not Responding”, increments the detect-dead-server consecutive-failures counter (if configured), and attempts to communicate with another RADIUS server. The default value for this parameter is 5.

> • | max-transmissions: Configures the maximum number of times the system transmits authentication requests to a server before it fails the authentication due to lack of response. The absolute maximum number of transmissions is equal to NS * (N + 1), where NS is the number of configured authentication servers, and N is the setting for radius max-retries. The default for this command is disabled.

> • | timeout: Specifies how many seconds the system waits for a response from a RADIUS server before re-transmitting the request.

> More information regarding each command can be found in the Command Line Interface Reference.
> The following figure shows a simple flow of events and how the system reacts based on configured parameters.
> Sample RADIUS Communication Flow
> Server State Triggers
> A number of triggers, events, and conditions can occur that change the state of a RADIUS server from “Down” to “Active” as defined by the system. They are:

> • | When the timer, based on the RADIUS Server Group Configuration Mode command: deadtime has expired, the server’s state on the system is returned to “Active”.

> Important: This parameter should be set to allow enough time to solve the issue that originally caused the server’s state to be changed to “Down”. After the deadtime timer expires, the system returns the server’s state to “Active” regardless of whether or not the issue has been fixed.

> • | When a RADIUS authentication server is configured, the server state is initialized as “Active”.

> • | When a RADIUS accounting server is configured and after receiving response for Acct-On message, the server state is made “Active”.

> • | When a RADIUS accounting server is configured and after the Acct-On message exceeds the max retries setting and times-out, the server state is made “Active”.

> • | When a RADIUS accounting server is configured with Acct-On disabled, the server state is made “Active”.

> • | When a response from a RADIUS server is received, the server state is made “Active”.

> • | When a RADIUS server responds to the Exec Mode command radius test, the server state is made “Active”.

> • | When a RADIUS probe is enabled and the probe response is received, the server state is made “Active”.

> • | When a RADIUS probe request times-out after max retries, the server state is made “Active”.

> • | If only one RADIUS authentication server is “Active” and goes down, all RADIUS authentication servers are made “Active”.

> • | If only one RADIUS accounting server is “Active” and goes down, all RADIUS accounting servers are made “Active”.

> Important: The system uses the above triggers to mark RADIUS servers as “Active”, however, this does not necessarily mean that the actual server is functional. When the system changes a server state, a trap is automatically sent to the management station. Action should be taken to identify the cause of the failure.

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883