|
|
Uno degli scopi del protocollo di routing è la convergenza, cioè tutte le volte che si verificano dei cambiamenti nella topologia di rete, passerà un certo intervallo di tempo, prima che tutti i router si aggiornino sui nuovi percorsi in maniera corretta. Quello che si desidera è che tale convergenza sia la più rapida possibile. Proprio perché non sempre ciò è possibile, si possono verificare una serie di problemi: uno di questi è il routing loop, ossia quando un pacchetto rimane vincolato a muoversi fra 2 o più router senza trovare una via d'uscita.
Ammettiamo che la connessione fra Router C e Router D non sia più attiva, per cui Router C nella propria routing table elimina questo percorso. Al successivo update, il Router C invia la sua tabella a Router B, il quale rimuove la entry corrispondente alla RETE1. Il Router B, osservando che Router A ha un percorso verso la RETE2 (appreso da updates precedenti) con una Metrica di 2, modifica la route verso la RETE1 passando attraverso il Router A ed incrementando la metrica a 3. A questo punto, Router A pensa che la RETE1 sia raggiungibile attraverso Router B, il quale in maniera analoga pensa lo stesso del Router A. Come risultato i pacchetti non raggiungeranno mai la destinazione, ma continueranno a rimbalzare fra nodo A e nodo B. Una possibile soluzione è rappresentata dallo stabilire un numero massimo di Hop count (salti) che il pacchetto può fare. Infatti tutte le volte che un pacchetto passa attraverso un router, viene incrementato di 1 l'hop count e se siamo in presenza di un loop, questo numero si incrementerà sempre più tendendo all'infinito. Fissare quindi a priori un soglia massima per l'hop count, significa che superato tale valore il pacchetto verrà scartato. Tuttavia con questa soluzione non si riesce ad evitare del tutto il problema del loop, poiché pacchetti rimangono nel loop fino a quando non vengono scartati. Come conseguenza , si verifica uno spreco inutile di banda e di risorse. Un altra soluzione che cerca di limitare i loops prende il nome di algoritmo di Split Horizon, mediante il quale un router che riceve certe informazioni pertinenti una certa destinazione da un router adiacente, non può rispedire indietro altre informazioni sulla medesima destinazione. Altro procedimento è Poison Riverse, che può essere interpretato come uno split horizon leggermente modificato, infatti talvolta è chiamato split horizon con updates poison reverse. Con questa tecnica, invece di non spedire informazioni su certe routes a chi li ha inviati, le invia ugualmente ma gli attribuisce una metrica infinita, per cui la destinazione viene considerata come irraggiungibile. Il metodo di split horizon sia con poison reverse che senza, elimina però i loops solo fra router adiacenti. Per risolvere tale problema occorre utilizzare altri metodi diversi da quelli visti fino ad ora. Si parla di Hold downs e Triggered updates. Hold downs permette, tutte le volte che una route è rimossa dalla routing table, di non accettare alcun update sulla route stessa, se non prima di aver aspettato un certo periodo di tempo. Tale intervallo sarà quello necessario affinché tutta la rete sia aggiornata. Triggered updates permette di rendere più veloce la convergenza. Normalmente i protocolli di tipo Distance vector inviano gli updates ad intervalli regolari di tempo. La tecnica Triggered updates permette di inviare tali messaggi nel momento in cui si verificano dei cambiamenti nella topologia della rete, piuttosto che aspettare prefissati istanti di tempo. Un altro problema relativo ai protocolli di tipo Distance vector è il seguente:
Tutto quanto riportato in questa pagina è a puro scopo informativo personale. Se non ti trovi in accordo con quanto riportato nella pagina, vuoi fare delle precisazioni, vuoi fare delle aggiunte o hai delle proposte e dei consigli da dare, puoi farlo mandando un email. Ogni indicazione è fondamentale per la continua crescita del sito.