Information About AAA Dead-Server Detection
The AAA Dead-Server Detection feature allows you to configure the criteria to be used to mark a RADIUS server as dead.
If you have more than one RADIUS server, the following concepts come into picture:
Deadtime—Defines the time in minutes a server marked as DEAD is held in that state. Once the deadtime expires, the controller marks the server as UP (ALIVE) and notifies the registered clients about the state change. If the server is still unreachable after the state is marked as UP and if the DEAD criteria is met, then server is marked as DEAD again for the deadtime interval.
You can configure deadtime for each server group or on a global level.
Dead-criteria—To declare a server as DEAD, you need to configure dead-criteria and configure the conditions that determine when a RADIUS server is considered unavailable or dead.
Using this feature will result in less deadtime and quicker packet processing.
Criteria for Marking a RADIUS Server As Dead
The AAA Dead-Server Detection feature allows you to determine the criteria that are used to mark a RADIUS server as dead. That is, you can configure the minimum amount of time, in seconds, that must elapse from the time that the controller last received a valid packet from the RADIUS server to the time the server is marked as dead. If a packet has not been received since the controller booted, and there is a timeout, the time criterion will be treated as though it has been met.
In addition, you can configure the number of consecutive timeouts that must occur on the controller before the RADIUS server is marked as dead. If the server performs both authentication and accounting, both types of packets are included in the number. Improperly constructed packets are counted as though they are timeouts. Both initial packet transmission and retransmissions are counted. (Each timeout causes one retransmission to be sent.)
Both the time criterion and tries criterion must be met for the server to be marked as dead.
The RADIUS dead-server detection configuration will result in the prompt detection of RADIUS servers that have stopped responding. This configuration will also result in the avoidance of servers being improperly marked as dead when they are “swamped” (responding slowly) and the avoidance of the state of servers being rapidly changed from dead to live to dead again. This prompt detection of non-responding RADIUS servers and the avoidance of swamped and dead-to-live-to-dead-again servers will result in less deadtime and quicker packet processing.