2.5 Retransmission Hints (Suggerimenti per la Ritrasmissione)
2.5. Retransmission Hints (Suggerimenti per la Ritrasmissione)
Se la richiesta all'host primario del server RADIUS fallisce o si verifica un timeout, la richiesta può essere ritrasmessa a un server alternativo. Ci sono diversi modi per implementare la logica di fallback.
Se i client RADIUS utilizzano un singolo server RADIUS, non è necessario implementare una logica di fallback. Tuttavia, se ci sono più server RADIUS nella rete, è consigliabile utilizzare una qualche forma di algoritmo di fallback.
Un metodo possibile consiste nell'inviare la richiesta prima al server primario. Se non viene ricevuta alcuna risposta entro un certo periodo di tempo, inviare la richiesta al server secondario. Un altro metodo consiste nell'inviare la richiesta sia al server primario che al server secondario contemporaneamente e accettare la prima risposta. Un terzo metodo consiste nell'inviare la richiesta prima al server primario e, se non viene ricevuta alcuna risposta entro un certo periodo di tempo, inviare una nuova richiesta al server primario e al server secondario contemporaneamente.
La scelta del timeout per decidere quando ritrasmettere dipende da diversi fattori, inclusi il tipo di servizio, la velocità della rete e il carico del server di autenticazione. Come linea guida, i timeout nell'ordine di pochi secondi sono appropriati per la maggior parte degli ambienti.
Un approccio suggerito consiste nell'utilizzare un timeout iniziale di 3-5 secondi, con un massimo di 3 ritrasmissioni. Se tutte le ritrasmissioni falliscono, il client può provare un server alternativo, se configurato per farlo.
Quando si utilizzano più server, il client può utilizzare un algoritmo round-robin per distribuire il carico tra i server. Tuttavia, il client DOVREBBE tenere traccia di quali server sono attualmente raggiungibili e dare priorità ai server che hanno risposto di recente.
I client NON DOVREBBERO implementare algoritmi di retry che possano causare congestione della rete o sovraccarico del server. Particolare attenzione dovrebbe essere prestata per evitare il fenomeno noto come "retry storm" (tempesta di retry), in cui molti client tentano di ritrasmettere le richieste simultaneamente, causando ulteriore congestione.