This KB describes a scenario when one of Radius servers was periodically declared dead and then alive, and suggests steps that need to be taken.

Usually there are two symptoms:

1. Number of subscribers in init state is higher than usual
2. Periodic logs about Radius server being declared dead and alive

user@device> show log messages | match radius | last 5
Jan 6 09:04:45 device authd[16516]: %DAEMON-4-AUTHD_RADIUS_SERVER_STATUS_CHANGE: Status of radius server 10.16.4.163 set to ALIVE (profile vlan-auth-access)
Jan 6 09:05:38 device authd[16516]: %DAEMON-4-AUTHD_RADIUS_SERVER_STATUS_CHANGE: Status of radius server 10.16.4.163 set to DEAD (profile vlan-auth-access)
Jan 6 09:06:08 device authd[16516]: %DAEMON-4-AUTHD_RADIUS_SERVER_STATUS_CHANGE: Status of radius server 10.16.4.163 set to ALIVE (profile vlan-auth-access)
Jan 6 09:07:01 device authd[16516]: %DAEMON-4-AUTHD_RADIUS_SERVER_STATUS_CHANGE: Status of radius server 10.16.4.163 set to DEAD (profile vlan-auth-access)
Jan 6 09:07:31 device authd[16516]: %DAEMON-4-AUTHD_RADIUS_SERVER_STATUS_CHANGE: Status of radius server 10.16.4.163 set to ALIVE (profile vlan-auth-access)

This log message is generated when reachability to the Radius server changes:

user@device> help syslog RADIUS_SERVER_STATUS_CHANGE
Name:          AUTHD_RADIUS_SERVER_STATUS_CHANGE
Message:       Status of radius server <destination-address> set to <new-state> (profile <profile-name>)
Help:          RADIUS server status changed
Description:   Radius server status is changed to DOWN if it is unavailable, and it is again set to UP after revert interval timer expires
Type:          Event: This message reports an event, not an error
Severity:      warning
Facility:      LOG_AUTH

The following steps could help to resolve the issue:

1. This configuration is usually used in a subscriber-management environment, and the same Radius server is usually used by more than one BNG device. If the same errors are reported for the same Radius server on multiple BNG devices, it's highly likely that, for some reasons, Radius server fails to respond to requests from BNG devices.
2. Reachability should be verified by using ping with various parameters (DF bit, packet size, etc.).
3. Packet capture could be taken to check whether responses from the Radius server arrive on MX.
4. Packet capture on the Radius server could be collected to confirm whether requests from BNG devices are responded.

If packet capture confirms that Radius server doesn't respond in time, most likely, there is a problem with Radius process on the Radius server.

There is no Radius keepalive mechanism in JUNOS, and an unreachable Radius server will be periodically marked as alive when revert-interval timer expires. If the Radius server is still unreachable, it will be marked as dead and revert-interval timer will be started again.

RADIUS Servers and Parameters for Subscriber Access