RADIUS is connectionless; retransmission and timeouts are handled by the RADIUS-enabled devices (NADs), not by the transport itself. This means NAD settings can create a retry storm under latency or loss. See Cisco overview and RFC 2865.
EAP over RADIUS adds layers
EAP provides retransmission/duplicate elimination at its layer, but the overall system is still sensitive to timing, especially when EAP is encapsulated over RADIUS and depends on backend responses. See RFC 3748.
1. Where latency hurts the most
1.1 NAD retransmission timer too aggressive
If the NAD times out faster than the true end-to-end time (including ISE↔AD), it retries. Retries increase:
1.3 Backend identity lookup within the same timer budget
Authentication is not “NAD ↔ ISE only”. It includes ISE ↔ AD/LDAP/Kerberos operations, which can dominate latency.
Cisco community guidance explicitly highlights that RADIUS timeout must incorporate NAD↔ISE latency plus ISE↔external store latency and processing time.
2. Practical tuning mindset
2.1 Don’t start with “increase timeout”
Start with:
Measure RTT and jitter on NAD↔ISE and ISE↔AD
Fix DNS site selection and DC proximity
Fix routing/forwarding to the nearest identity store
Ensure PSNs are placed near endpoints
Reduce remote dependencies (CRL/OCSP)
Then tune:
NAD RADIUS timeout and retry
ISE timers and identity store timeouts
Posture reassessment intervals (posture can amplify load)