[ Home ]

INTRODUZIONE

Il protocollo IGP (Interior Gateway Protocol) maggiormente utilizzato oggi su Internet e' senza dubbio il protocollo RIP. 

RIP e' l'acronimo di Routing Information Protocol ed e' un protocollo relativamente semplice appartenente alla famiglia di protocolli di tipo "distance vector".

E' il protocollo di routing IP più vecchio ancora in uso : la versione IP esiste in due versioni, la seconda versione aggiunge nuove funzionalità a questo protocollo. RIPv1 è di tipo classfull mentre RIPv2 è classless. L' algoritmo distance vector è stato sviluppato da Bellman, Ford e Fulkerson nel lontano 1969 : poi è stato integrato dalla Xerox Network System nei suoi protocolli come XNS RIP. Tale protocollo è stato precursore di comuni protocolli di routing come Novell IPX RIP, AppleTalk Routing Table Maintenance Protocol (RTMP) e naturalmente IP RIP. Nella versione 4.2 del Berkley UNIX rilasciata nel 1982 il RIP è implementato come un processo demone chiamato routed : ancora molte versioni di UNIX implementano il RIP.

Torna all'inizio

CARATTERISTICHE DEL PROTOCOLLO

Gli indirizzi presenti nelle tabelle RIP sono indirizzi Internet a 32 bit. Una voce (entry) nella tabella di routing puo' rappresentare un host, una rete o una sottorete. Non sono presenti specifiche sul tipo di indirizzo nei pacchetti RIP; e' compito dei router analizzare l'indirizzo per capire di cosa si tratta. Questi prima separano la parte di rete dalla parte "sottorete + host" in funzione della classe dell' indirizzo (A, B o C).  Se la parte "sottorete+host" e' nulla, l'indirizzo rappresenta una rete, viceversa puo' rappresentare sia una sottorete che un host. Al fine di discriminare tra queste 2 possibilita', e' necessario conoscere la subnet mask; se la parte host e' nulla, si tratta dell'indirizzo di una sottorete, di un host viceversa.

Di default, RIP utilizza una metrica molto semplice: la distanza (hop count) e' il numero di links che vengono attraversati per raggiungere la destinazione. Questa distanza e' espressa come un numero intero variabile tra 1 e 15; 16 rappresenta una distanza infinita.

RIP supporta sia i links punto a punto che le reti di tipo broadcast come Ethernet. I pacchetti RIP vengono impacchettati nei pacchetti UDP e IP; i processi RIP utilizzano la porta 520 sia per la trasmissione che per la ricezione. Utilizzando una porta specifica, minore di 1024, si e' in linea con le protezioni di sistema di BSD-Unix. I pacchetti normalmente sono inviati in modalita' broadcast, questo significa che saranno ricevuti da tutti i routers connessi alla rete. Normalmente i pacchetti vengono inviati ogni 30 secondi, o meno, nel caso di aggiornamenti alle tabelle. Se una route non viene aggiornata entro 3 minuti, la distanza viene fissata ad infinito e l'entry verra' successivamente rimossa dalle tabelle. Allo scopo di evitare aggiornamenti troppo frequenti , questi vengono regolati da un timer casuale, che puo' variare tra 1 e 5 secondi.  

Come osservabile dal pacchetto, il protocollo RIP prevede un comando di richiesta e uno di risposta o aggiornamento. Normalmente RIP opera in risposta, a intervalli regolari di 30 secondi, o in seguito a richieste di aggiornamento delle tabelle di routing. Il processo RIP, in seguito alla ricezione di un messaggio di risposta, aggiorna la propria tabella. Ogni voce della tabella sara' al limite composta da :

  Indirizzo di destinazione

  Metrica associata con la destinazione

  Indirizzo del "next router"

  Un "recently updated" flag

  Numerosi timers

Processando le risposte in arrivo, il router esaminera' le voci una ad una ed eseguira' una serie di checks, ad esempio verifichera' che l'indirizzo sia valido ed appartenente ad una delle classi A, B o C, che il numero identificante la rete non sia 127 (loop-back) o zero (ad eccezione dell'indirizzo di default 0.0.0.0), che la parte host non sia un indirizzo broadcast e che la metrica non sia maggiore di infinito. In ogni caso voci non corrette vengono ignorate.

Se la metrica in arrivo risulta diversa da infinito, viene incrementata di 1 per il successivo hop, quindi la tabella di routing viene scandita per una voce corrispondente alla destinazione e viene quindi eseguito il generico processo "distance vector", di seguito illustrato:

  Se la voce non e' presente e la sua metrica nel messaggio ricevuto non e' infinito, la aggiunge alla tabella, inizializzando la metrica al valore ricevuto ed il next router al mittente del messaggio, prima di avviare un timer per quella voce.

  Se la voce e' presente con una metrica piu' grande, aggiorna i campi della metrica e del next router e riavvia il timer per quella voce.

  Se la voce e' presente ed il next router e' il mittente del messaggio di risposta, aggiorna la metrica se questa differisce dal valore memorizzato e, in tutti i casi, riavvia il timer.

In tutti gli altri casi, il messaggio ricevuto e' ignorato.

Se la metrica o il next router cambiano, l'entry viene marcata come "aggiornata". Un messaggio di risposta viene inviato ad intervalli regolari di 30 secondi o puo' essere attivato in seguito ad un aggiornamento alle tabelle di routing. Questo puo' essere causa di eccesso di traffico sulla rete e l' RFC-1058 specifica una serie di precauzioni da adottare a questo preciso scopo. La risposta non dovrebbe essere inviata immediatamente in seguito alla ricezione dell' aggiornamento ma, piuttosto, dopo un piccolo intervallo random, variabile tra 1 e 5 secondi. Questo permette ai relativi aggiornamenti provenienti dai nodi vicini di venire riassunti nel successivo messaggio, limitando cosi' il carico di rete. 

Un messaggio di risposta separato viene preparato per tutte interfacce connesse. L'informazione puo' variare in seguito al processo di split horizon. Il messaggio normalmente include le coppie indirizzo e metrica per tutte le voci della tabella ma, se il messaggio e' inviato come un aggiornamento, non deve necessariamente includere tutte le voci, ma solo quelle che sono state aggiornate rispetto all'ultima trasmissione. Il massimo formato del pacchetto e' 512 bytes, che permette di avere sino a 25 voci per messaggio. Nel caso di un maggiore numero di voci, RIP inviera' piu' pacchetti. L'indirizzo sorgente del messaggio dovrebbe sempre coincidere con l'indirizzo IP associato con l'interfaccia alla quale il messaggio e' inviato.

I processi RIP possono anche ricevere messaggi di richiesta. Una richiesta viene normalmente inviata quando un router inizia le operazioni allo scopo di ottenere dai suoi vicini il valore iniziale delle tabelle di routing. Esistono 2 possibili forme di richiesta, quella per una lista completa delle tabelle di routing o quella per sole specifiche routes.

Una delle richieste di lista completa delle tabelle di routing si ha specificando solo le coppia indirizzo + metrica per l'indirizzo di default 0.0.0.0 con una metrica pari ad infinito. In questo caso, il router replichera' con una tipica risposta, simile a quelle inviate periodicamente nelle normali operazioni del protocollo, incluso il processo di split horizon.

Qualsiasi altra forma di richiesta prevede la lista delle sole voci specificate. La risposta verra' inviata in modalita' point to point al richiedente e conterra' una copia esatta dell'informazione di distanza nelle tabelle di routing, senza eseguire il processo di split horizon. Questa forma di richiesta ha poco significato per le normali operazioni, mentre ne assume molto per scopi di debugging.

Torna all'inizio

TIMERS

Il protocollo RIP gestisce i seguenti timers:

  Routing update timer (default 30 s): intervallo di tempo per l’invio degli annunci

  Route invalid timer (default 90 s): intervallo di tempo dopo il quale una route è dichiarata irraggiungibile (distanza posta ad infinito)

  Route flush timer (default 270 s): intervallo di tempo dopo il quale la route è cancellata dalla routing table

  Triggered updates: sono inviate con un ritardo casuale compreso tra 1 e 5 secondi, per evitare intasamenti della rete e per far si' di poter eventualmente comunicare piu' cambi di route con un messaggio solo.

Torna all'inizio

STABILITA'

Al fine di assicurare una buona stabilita' e, quindi, di evitare situazioni di loop e, di conseguenza, possibili congestioni della rete, RIP utilizza una serie di tecniche, di seguito descritte:

  Triggered updates:  si tratta di messaggi di routing update fatti anzitempo, causati da variazioni di connettività. Nel caso vengono inviate solo le informazioni relative alle route che sono cambiate (non viene trasferito il distance vector completo). Evitano alla rete di trovarsi in uno stato incoerente, fino allo scadere del Routing Update Timer, quando i distance vector sarebbero inviati comunque.

  Hop Count Limit:  fa si che le destinazioni più distanti di 15 siano considerate irraggiungibili e permette quindi di evitare il "count to infinity problem".

  Hold Downs: Il router mette in quarantena le route che utilizzavano il link guasto. Inoltre, il router che ha rilevato il guasto non può partecipare ad alcun loop fino almeno alla scadenza dell’Hold Down timer.

  Split Horizon: "Se A raggiunge la destinazione X attraverso B, non ha senso per B cercare di raggiungere X attraverso A". Previene il loop tra 2 nodi ma non elimina i loop con 3 nodi

  Split Horizon with Poisonous Reverse: Migliora lo Split Horizon puro. Nel momento in cui si verifica una variazione di route, lo Split Horizon semplice non comunica piu' la route (che continua pero' a valere sino alla scadenza del timer). Viceversa, con il Poisonous Reverse la route viene comunicata con costo infinito, quindi gli altri router apprendono immediatamente che non possono usare la route (non devono aspettare lo scadere del route invalid timer). Le route non più valide non vengono rimosse dagli annunci ma sono annunciate con metrica 15 (infinity)

Torna all'inizio