[ Home ] [ RIP - CATTURE DI ESEMPIO ] [ IL PACCHETTO ] [ RIP 2 ]

CATTURA #1

CONFIGURAZIONE E COMANDI

  Macchina e interfaccia di cattura: Goomer xl1 (IP address 10.0.0.1)

  Comando Tcpdump: Tcpdump -i xl1 -w rip2_01.acp -s 1518 udp port 520

  Configurazione gateD Goomer:

rip yes {
interface xl1 le0 pvc0 pvc1 ripin ripout version 2;
interface xl0 noripin noripout version 2;
traceoptions packets;
};

In generale, la configurazione di gateD su ciascuna macchina era comunque tale da abilitare la trasmissione e la ricezione di pacchetti RIP sulle sole interfacce "interne" (indirizzi IP 10.x.x.x), escludendo le interfacce direttamente connesse alla LAN del Politecnico (indirizzi IP 130.192.x.x). Rispetto alla cattura di esempio relativa al pacchetto RIP versione 1, si puo' osservare che e' stato inserito il parametro "version 2", indispensabile per la cattura dei pacchetti RIPv2.

ANALISI

La cattura in esame, e' relativa a 9  pacchetti di aggiornamento RIP versione 2. Attraverso l'analisi di questi ultimi, e' possibile rilevare che l'imbustamento del protocollo e' invariato rispetto a quanto osservato durante l'analisi del pacchetto RIP versione 1. Anche la porta utilizzata dal protocollo di trasporto UDP resta invariata (520). E' invece interessante osservare che l'indirizzo IP di destinazione (del pacchetto IP) equivale a 224.0.0.9 che e' l'indirizzo IP utilizzato per il multicast periodico. Ma vediamo in dettaglio il contenuto del primo pacchetto; a questo preciso scopo si ricorda che per osservare il dettaglio di un pacchetto e' necessario espandere la cartella del protocollo desiderato, cliccando sul "+" a sinistra della cartella e che il primo byte nella tabella dei dati grezzi ha identificativo 0. 

  Byte 42 : 02h -> Indica che e' un messaggio di aggiornamento

  Byte 43 : 02h -> Indica che il pacchetto si riferisce al protocollo RIP versione 2

  Bytes 44 ÷ 45 : 00h 00h -> Must be zero

  Bytes 46 ÷ 47 : 00h 02h -> E' il campo AFI, e vale 2 con il protocollo IP

  Bytes 48 ÷ 49 : 00h 00h -> Route Tag; e' utilizzato per segnalare routes esterne al dominio. 

  Bytes 50 ÷ 53 : 82h C0h 00h 00h -> Rappresenta l'indirizzo IP di destinazione (130.192.0.0)

  Bytes 54 ÷ 57 : FFh FFh 00h 00h -> Rappresenta la subnet mask (255.255.0.0)

  Bytes 58 ÷ 61 : 0Ah 00h 00h 02h -> Rappresenta l'indirizzo del next hop router (10.0.0.2) 

  Bytes 62 ÷ 65 : 00h 00h 00h 01h -> Rappresenta il valore del next hop (1)

I successivi pacchetti sono tra loro coerenti, poiche' tutti quanti annunciano la stessa subnet 130.192.0.0; come gia' e' avvenuto per l'analisi della cattura RIP versione 1, anche in questo caso si possono trarre le seguenti considerazioni:

1. I pacchetti con source IP address 10.0.0.1 sono pacchetti trasmessi dall'interfaccia di cattura, mentre i pacchetti con source IP address 10.0.0.2 sono pacchetti ricevuti da Carlo, attraverso l'interfaccia xl1. Questo si spiega attraverso l'utilizzo, quale indirizzo IP di destinazione, dell'indirizzo di multicast 224.0.0.9
   
   

2. La frequenza di trasmissione dei pacchetti e' pari a 30 secondi che corrisponde al valore predefinito del "routing update timer", ossia del timer che controlla l'intervallo di tempo per l’invio degli annunci.  

Torna all'inizio

CATTURA #2

CONFIGURAZIONE E COMANDI

  Macchina e interfaccia di cattura: Goomer pvc1 (IP address 10.0.0.81)

  Comando Tcpdump: Tcpdump -i pvc1 -w rip2_02.acp -s 1518 udp port 520

  Configurazione gateD Goomer:

rip yes {
interface xl1 le0 pvc0 pvc1 ripin ripout version 2;
interface xl0 noripin noripout version 2;
traceoptions packets;
};

In generale, la configurazione di gateD su ciascuna macchina era comunque tale da abilitare la trasmissione e la ricezione di pacchetti RIP sulle sole interfacce "interne" (indirizzi IP 10.x.x.x), escludendo le interfacce direttamente connesse alla LAN del Politecnico (indirizzi IP 130.192.x.x). Rispetto alla cattura di esempio relativa al pacchetto RIP versione 1, si puo' osservare che e' stato inserito il parametro "version 2", indispensabile per la cattura dei pacchetti RIPv2.

ANALISI

La cattura in esame e' relativa a 7 pacchetti RIP versione 2 ed illustra la risposta del protocollo, nel caso si verifichi la caduta di un link. Questo evento e' stato effettuato attraverso l'abbattimento dell'interfaccia xl1 di Goomer ( e di conseguenza del link tra Goomer e Carlo), tramite il comando ifconfig xl1 down. Piu' in generale, ifconfig permette di tenere sotto controllo e quindi di modificare, la configurazione della rete. Successivamente, con la cattura ancora in corso, il link e' stato ripristinato, tramite il comando ifconfig xl1 up. 

Ma effettuiamo, in dettaglio, un'analisi dei 7 pacchetti, focalizzandoci sull'aspetto funzionale e tralasciando invece l'aspetto descrittivo, per il quale si puo' fare riferimento all'analisi del pacchetto precedente. Tutti i pacchetti sotto descritti sono trasmessi da Goomer verso Dante:

  Pacchetto #1: Si tratta di un pacchetto multicast di aggiornamento che annuncia le subnet 130.192.0.0 e 10.0.0.0

  Pacchetto #2: E' un pacchetto emesso dopo 30 secondi dal precedente (coerentemente con il routing update timer) ed e' del tutto simile a questo. 

  Pacchetto #3: Questo pacchetto e' stato emesso in seguito all'abbattimento del link ed annuncia la sottorete 10.0.0.0 (quella relativa al link caduto) irraggiungibile, con il campo metrica uguale a 16

  Pacchetto #4: Dopo 30 secondi dal precedente, viene emesso questo pacchetto che annuncia la sottorete 130.192.0.0 con metrica 1 e la sottorete 10.0.0.0 irraggiungibile

  Pacchetto #5: E' un pacchetto emesso dopo 30 secondi dal precedente ed e' del tutto simile a questo. 

  Pacchetto #6: Questo pacchetto e' stato emesso in seguito al ripristino del link precedentemente abbattuto e si puo' osservare come la subnet 10.0.0.0 venga nuovamente annunciata con metrica 1, cosi' come la subnet 130.192.0.0

  Pacchetto #7: Entrambe le subnet 130.192.0.0 e 10.0.0.0 vengono annunciate con metrica 1 

Torna all'inizio