Comportamento di RIPv1 in alcuni casi di indirizzamento (ita)

Il protocollo di Routing Rip versione 1 è del tipo appartenete alla famiglia IGP, è originario di Xerox nella suite XNS. Nel 1982 passa a formare parte del Unix BSD (Berkeley Software Distribution). E’ definito nel RCF 1058 nell’anno 1988. LA metrica utilizzata è del tipo numero di salti (distance vector di 4 bits); un numero di salti non superiore a 15 e lavora a livello UDP con il numero di porta 520. Il pacchetto Rip contiene le seguenti informazioni

Command 1 Byte	Identifica se si tratta di una richiesta o una risposta e sollecita l’invio della route table e se risponde con parte o tutta della stessa table
Version 1 Byte	Identifica la versione del protocollo
Reserved 2	Bytes non utilizzati
Address 2 Bytes	indica il tipo di indirizzo di rete utilizzato, vale 2 per IP
Reserved2 Bytes	Bytes non utilizzati
Address 4 Bytes	Indirizzo ip di destinazione che corrisponde alla metrica più bassa. Nel messaggio Rip di risposta possono essere riportati un massimo di 25 destinazioni per pacchetto. La routing table più grande richiede pacchetti multipli
Reserved 8 Bytes	Bytes non utilizzati
Metric 4 Bytes	Indica il numero di salti necessari

La grandezza massima del messaggio è di 512 Bytes. I messaggi sono di REQUEST, dove è richiesta la connessione e RESPONSE, come risposta. Normalmente il request è un messaggio con direzione broadcast. Il protocollo Rip non utilizza indirizzi con subnet mask variabile.

Il pacchetto del protocollo RIP permette di aggiornare la Routing Table nei routers, il contenuto dell’indirizzo IP e il valore della metrica. La Routing Table formata dal RIP contiene le seguenti informazioni: indirizzo di destinazione, prossimo salto, distanza, timer, flag. Viene mantenuta solo la Route Table migliore, e quando ne viene identificata un’ulteriore, questa rimpiazza la precedente. Ciascun router aggiorna il cambio e lo propaga agli altri. Il tempo di convergenza è alto.

RIP richiede dati delle rotte per aggiornare la tabella di instradamento, e periodicamente annuncia la presenza e trasmette i cambi identificati nella rete. Utilizza l’algoritmo “distance vector", originario di Bellmann-Ford.

I pacchetti RIP sono scambiati circa ogni 30 secondi (update), questo meccanismo di trasmissione carica la rete di informazioni di routing, se il tempo di update supera i 90 secondi, la rotta di uscita è considerata non valida e se supera i 270 secondi (flash timer) è eliminata dalla routing table.

Per ricapitolare possiamo prendere in considerazione i tre vincoli che C. Hedrick ha descritto a pagina 3 dell'RFC 1058:

• Il protocollo consente di non più di quindici salti, vale a dire che i due router non possono essere più distanti di ulteriori 15 salti, altrimenti non si può utilizzare il RIP

• problema di "conteggio all'infinito”. Questo problema può verificarsi in situazioni in cui possono produrre cicli, dato che questi anelli possono causare ritardi e persino la congestione sulle reti con una la larghezza di banda limitata. L'autore dell' RFC 1058 dice anche che in realtà questo può essere solo un problema su reti lente, ma il problema esiste.

Oltre ai problemi citati dall'autore del protocollo, dobbiamo tenere conto del fatto che il protocollo RIPv1 è un protocollo classful, con il quale esiste il problema della discontinuità delle reti. Il problema della discontinuità di rete si verifica nel momento in cui abbiamo una rete suddivisa in più sottoreti e può essere summarizzata in una via, perché fisicamente ciascuna delle sottoreti si trova in una invece dipendente da una interfaccia diversa da quella di altre subnet.

Formato del messaggio RIPv1

Si analizzano nel seguito il comportamento di RIPv1 in tre diversi scenari.

Scenario 1 – FLSM

Nel presente scenario si analizza il comportamento di RIPv1, protocollo classful, in un ambiente composto da tre router 1841 connessi tra loro ed associati ognuno ad una diversa LAN secondo lo schema in figura:

Le sottoreti sono indirizzate in questo modo:

• LAN1 : 10.10.0.0/16
• LAN2 : 10.20.0.0/16
• LAN3 : 10.30.0.0/16
• LAN4 : 10.40.0.0/16
• LAN5 : 10.50.0.0/16

Nelle connessioni PC - Router, il primo indirizzo della sottorete disponibile è associato all’interfaccia (FastEthernet 0/0) del Router, il secondo all’interfaccia del PC

Nei collegamenti seriali tra i Router:

• Interfaccia Serial 0/0/0 di R1 su LAN4 : 10.40.0.1/16
• Interfaccia Serial 0/0/0 di R2 su LAN4 : 10.40.0.2/16
• Interfaccia Serial 0/0/1 di R2 su LAN5 : 10.50.0.2/16
• Interfaccia Serial 0/0/1 di R3 su LAN5 : 10.50.0.1/16

PROVE EFFETTUATE

Dopo avere impostato gli indirizzi delle interfacce ed avere effettuato varie prove di connettività tra i routers e tra pc e default gateways per assicurare il corretto funzionamento della rete, come prima prova abbiamo eseguito un Ping tra Pc1 e Pc2, e tra Pc1 e Pc3. Il ping in entrambi casi va a buon fine, contrariamente a quanto ci si aspettasse.

Ping Pc1 ---> Pc2

Ping Pc1 ---> Pc3

Questo è dovuto al fatto che nonostante non ci sia modo per i router di capire la maschera di sottorete degli indirizzi annunciati da RIP (in RIPv1 il campo subnet mask è composto da soli 0), essi tentano di interpretare la subnet mask riferendosi a quella presente sulle loro interfacce. In questo caso, essendo in FLSM, la subnet mask è sempre la stessa per tutte le sottoreti, di conseguenza questo “tentativo” dei router va sempre a buon fine, e gli indirizzi di rete vengono sempre interpretati in maniera corretta. Da queste prove effettuate quindi ci si aspetta che nello scenario con VLSM la connettività non ci siano, e di conseguenza i ping non vadano a buon fine. Vediamo.

Scenario 2 – VLSM

Nel presente scenario si analizza il comportamento di RIPv1, protocollo classful, in un ambiente composto da tre router 1841 connessi tra loro ed associati ognuno ad una diversa LAN secondo lo schema identico al precedente ma con indirizzamento VLSM:

• LAN1 : 10.10.128.0/17
• LAN2 : 10.10.64.0/18
• LAN3 : 10.10.32.0/19
• LAN4 : 10.0.0.0/20
• LAN5 : 10.10.16.0/20

Le varie connessioni alle interfacce sono eseguite seguendo la stessa logica dello scenario precedente.

In questo scenario, come ci si aspettava e per lo stesso motivo esposto precedentemente, il ping non va a buon fine. R2 ad esempio, riceve RIP updates dalle sottoreti 4 e 5, ma avendo maschere di sottorete di lunghezza differente, non riesce a processare i messaggi che gli arrivano correttamente al contrario di come faceva in precedenza con FLSM, di conseguenza li scarta. Nella sua routing table infatti non compaiono le reti che dovrebbero essere annunciate tramite il protocollo di routing, ma solo quelle direttamente connesse.

ROUTING TABLE DI R2

Come nota finale a questo scenario, R3 riceve le notifiche della LAN4 in quanto il router R2 che gliele invia è connesso ad R3 attraverso la LAN5, che ha come la LAN4 una maschera di sottorete uguale (/20).

Scenario 3 – Indirizzamento discontiguo

Nell’ultimo scenario invece si analizza il comportamento di RIPv1, protocollo classful, in un ambiente composto da tre router 1841 connessi tra loro ed associati ognuno ad una diversa LAN, in modo che le sottoreti tra pc e router siano contigue, ma tutte classful:

• LAN1 : 192.168.0.0
• LAN2 : 192.168.1.0
• LAN3 : 192.168.2.0
• LAN4 : 172.16.0.0
• LAN5 : 10.0.0.0

In questo scenario le sottoreti alle quali i pc sono connessi sono contigue. In questo caso tutte e 5 la LAN sono classful quindi i router riescono ad indirizzare correttamente tutti i messaggi usando le maschere di sottorete adeguate. I ping vanno tutti a buon fine.