This article explains how the authentication moves to the next server in multiple-radius server environment.

In a multiple radius server environment, the logic to move to the next server for authentication will occur only when the current server is not reachable.

But in the particular case with the radius config "timeout 1 retry 1", it is still observed the authentication "Moving to next UDP server:" even if the server is reachable.
 

set system authentication-order radius
set system radius-server 192.168.0.2 port 1812
set system radius-server 192.168.0.2 secret "$9$ChOXA0IEhrKvLIRNdbwg4"
set system radius-server 192.168.0.2 timeout 1
set system radius-server 192.168.0.2 retry 1
set system radius-server 192.168.0.2 source-address 192.168.0.1
set system radius-server 192.168.1.2 port 1812
set system radius-server 192.168.1.2 secret "$9$.mT36/t0ORn6reMWx7"
set system radius-server 192.168.1.2 source-address 192.168.1.1
 

Jun 27 23:46:50 R1_re sshd[25571]: Added radius server 192.168.0.2 (192.168.0.2)
Jun 27 23:46:50 R1_re sshd[25571]: Added radius server 192.168.1.2 (192.168.1.2)
Jun 27 23:46:50 R1_re sshd[25571]: sendmsg to 192.168.0.2(192.168.0.2).1812: h->try:0 serv->num_tries:0, serv->max_tries:1 tries_per_addr:1, nleft:1, cur_addr:0
Jun 27 23:46:51 R1_re sshd[25571]: Moving to next UDP server: 192.168.1.2(192.168.1.2).1812
Jun 27 23:46:51 R1_re sshd[25571]: sendmsg to 192.168.1.2(192.168.1.2).1812: h->try:1 serv->num_tries:0, serv->max_tries:1 tries_per_addr:1, nleft:1, cur_addr:0
Jun 27 23:46:51 R1_re sshd[25569]: Accepted keyboard-interactive/pam for jtac3 from 10.32.35.22 port 52330 ssh2


 

In a multiple radius servers environment, the logic to move to next server for authentication will occur only when the current server is not reachable.
If the server is reachable login should fail if wrong username or password is used for login.

It is shown "Moving to next UDP server:" only with "retry 1 timeout 1" parameters because the response time taken to receive "Access-Reject" from server1(192.168.0.2) is > 1 second (i.e. > timeout) hence the client considers the server is unreachable and it is moving to next radius server. 
However, the same phenomenon is unlikely to occur with "retry 2 timeout 1" because the server would respond/reject within 2 seconds in most cases.
Upon receiving "Access-Reject", the client will turn to try next authentication method if configured.

It is recommended to set the timeout value > 1 second (or use the default timeout, which is 3 seconds) to get the expected behavior.