CATTURA #1
CONFIGURAZIONE E COMANDI
Macchina e interfaccia di cattura: Goomer pvc0 (IP address 10.0.0.66)
Comando Tcpdump: Tcpdump -i pvc0 -w goompvc0.acp -s 1518 ip proto
89
Configurazione gateD Goomer:
ospf yes {
backbone {
interface xl1 le0 pvc0 pvc1 {priority 1;};
interface xl0 {disable;};
};
};
In generale, la configurazione di GateD su ciascuna macchina era comunque
tale da abilitare la trasmissione e la ricezione di pacchetti OSPF 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).
Inoltre, ciacuna macchina GateD, oltre che Goomer stessa, era configurata per l'area di
backbone.
ANALISI
La cattura in esame si riferisce ad un singolo pacchetto
relativo al protocollo
Hello. Questo protocollo, congiuntamente ai protocolli Exchange
e Flooding, e'
imbustato in un header comune, che
caratterizza tutti i pacchetti OSPF. Il pacchetto faceva inizialmente parte di
una cattura caratterizzata da molteplici pacchetti ma e' stato volutamente
isolato in un file, in quanto questa cattura e' unicamente orientata alla
descrizione del pacchetto Hello.
La prima cosa che e' possibile osservare, e' il campo "Protocol Type" del pacchetto IP. Il valore
di tale campo, corrispondente al byte 17 (attenzione che il primo byte ha
identificativo 0), assume il valore 59h (89), che corrisponde all'identificativo del protocollo OSPF. Infine,
possiamo osservare che si tratta di un pacchetto multicast, in quanto
l'indirizzo IP di destinazione e' 224.0.0.5. Ma vediamo in dettaglio i valori assunti dai
vari campi, sia per l'header comune che per il pacchetto Hello:
L'HEADER COMUNE
Byte
28 :
02h -> Versione del protocollo OSPF (versione 2)
Byte 29 :
01h -> Tipo di protocollo trasportato (1 = Hello)
Bytes
30 ÷ 31 :
00h 30h -> Numero di bytes del pacchetto (Header + Hello = 48)
Bytes
32 ÷ 35 :
82h C0h 1Ch 8Eh -> Indirizzo IP del source router (130.192.28.142)
Bytes 36 ÷ 39 :
00h 00h 00h 00h-> Identificativo dell'area all'interno
del dominio OSPF (0); corrisponde all'area di backbone
Bytes
40 ÷ 41 :
D3h E5h -> Checksum
Bytes 42 ÷ 43 : 00h 00h -> Authentication Type (0 = nessuna
autenticazione)
Bytes
44 ÷ 51 :
Tutti 00h -> Riservati per l'eventuale autenticazione e quindi
ignorati
IL PACCHETTO HELLO
Bytes
52 ÷ 55 : FFh FFh FFh FCh-> Netmask associata
all'interfaccia da cui viene emesso il pacchetto (255.255.255.252)
Bytes
56 ÷ 57 :
00h 1Eh -> Intervallo tra i pacchetti Hello (30 secondi)
Byte
58 :
02h (00000010 bin) -> Il penultimo bit vale 1, che significa che
l'interfaccia non e' connessa ad una stub area, mentre l'ultimo bit vale 0, che
sta a significare che il router non gestisce il TOS routing
Bytes
59 :
00h -> Indica la priorita' assegnata al router al fine di poter
diventare Designed Router (0)
Bytes
60 ÷ 63 :
00h 00h 00h 78h-> Intervallo di validita' dei pacchetti
Hello (120 sec.)
Bytes
64 ÷ 67 :
00h 00h 00h 00h-> Indirizzo IP del Designed Router (0.0.0.0);
significa che l'elezione del DR non e' ancora avvenuta
Bytes
68 ÷ 71 :
00h 00h 00h 00h -> Indirizzo IP del Backup Designed Router (0.0.0.0);
significa che l'elezione del BDR non e' ancora avvenuta
Bytes 72 ÷ 75 : 82h C0h 05h 47h-> Indirizzo IP del router
da cui e' stato ricevuto il pacchetto di Hello negli ultimi 120 secondi
(130.192.5.71); questo campo avrebbe potuto essere replicato se i router fossero
stati piu' di uno
Torna all'inizio
CATTURA #2
CONFIGURAZIONE E COMANDI
Macchina e interfaccia di cattura: Goomer pvc0 (IP address 10.0.0.66)
Comando Tcpdump: Tcpdump -i pvc0 -w goompvc0.acp -s 1518 ip proto
89
Configurazione gateD Goomer:
ospf yes {
backbone {
interface xl1 le0 pvc0 pvc1 {priority 1;};
interface xl0 {disable;};
};
};
In generale, la configurazione di GateD su ciascuna macchina era comunque
tale da abilitare la trasmissione e la ricezione di pacchetti OSPF 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).
Inoltre, ciacuna macchina GateD, oltre che Goomer stessa, era configurata per l'area di
backbone.
ANALISI
La cattura in esame e' relativa al protocollo Flooding e si riferisce
ai pacchetti:
- Link State Update, utilizzato per diffondere a tutta la rete,
attraverso il Link State Advertisment, lo stato delle rete. Con questo
pacchetto, il campo Type dell'header comune assume il valore 4. Un pacchetto
LSU e' composto da un campo che identifica il numero di Advertisment
trasportate e, di seguito, dalle LSA, nel numero definito dal campo
precedente.
- Link State Acknowledgment, e' la risposta di riconoscimento
a fronte della ricezione di un pacchetto LSU. Con questo pacchetto, il campo
Type dell'header comune assume il valore 5.
Come nel caso precedente e per la stessa ragione, anche in questo caso, i 2
pacchetti sono stati volutamente isolati in un file. Il pacchetto LSU e' stato
inviato in multicast (osservabile dall'indirizzo IP di destinazione 224.0.0.5)
da Goomer sull'interfaccia pvc0 , mentre il pacchetto LSA e' la risposta,
proveniente da Gedeone, relativa al riconoscimento della precedente LSU. Ma
vediamo in dettaglio i 2 pacchetti:
PACCHETTO #1 - LSU: L'HEADER COMUNE
Byte
28 :
02h -> Versione del protocollo OSPF (versione 2)
Byte 29 :
04h -> Tipo di protocollo trasportato (4 = Link State Update)
Bytes
30 ÷ 31 :
00h 4Ch -> Numero di bytes del pacchetto (Header + LSU = 76)
Bytes
32 ÷ 35 :
82h C0h 1Ch 8Eh -> Indirizzo IP del source router (130.192.28.142)
Bytes
36 ÷ 39 :
00h 00h 00h 00h-> Identificativo dell'area all'interno
del dominio OSPF (0); corrisponde all'area di backbone
Bytes
40 ÷ 41 :
95h 27h -> Checksum
Bytes 42 ÷ 43 : 00h 00h -> Authentication Type (0 = nessuna
autenticazione)
Bytes
44 ÷ 51 :
Tutti 00h -> Riservati per l'eventuale autenticazione e quindi
ignorati
IL PACCHETTO LSU
Bytes
52 ÷ 55 :
00h 00h 00h 01h-> Numero di LSA inclusi nel pacchetto di
Update (1)
I dati che seguono, identificati nella cartella dell'albero come "OSPF
Link State Header", fanno a tutti gli effetti parte del pacchetto Link
State Update e rappresentano l'header del Link State Advertisment:
Bytes
56 ÷ 57 :
00h 02h -> Anzianita' dell' LSA corrente (2 sec.)
Byte 58 :
00h -> Solo gli ultimi 2 bit hanno significato, il penultimo viene
utilizzato dal protocollo Hello, mentre l'ultimo
sta a significare che il router non gestisce il TOS routing.
Byte 59 :
01h -> Definisce il tipo di LSA trasportato (1 = Router
Link)
Bytes
60 ÷ 63 :
82h C0h 03h 2Eh -> Identificativo dell'LSA (130.192.3.46)
Bytes
64 ÷ 67 :
82h C0h 03h 2Eh-> Indirizzo IP dell'Advertising Router
(130.192.3.46)
Bytes
68 ÷ 71 :
80h 00h 00h 0Ah-> Numero di sequenza dell'LSA (2147483658)
Bytes
72 ÷ 73 :
23h 28h -> Checksum
Bytes
74 ÷ 75 :
00h 30h -> Lunghezza totale del pacchetto, incluso l'header (48)
I campi che seguono rappresentano infine la LSA (Advertisment) vera e
propria, di tipo Router Link, che annuncia le 2 subnet 10.0.0.0 e 10.0.0.16
PACCHETTO #2 - LSA: L'HEADER COMUNE
Byte
28 :
02h -> Versione del protocollo OSPF (versione 2)
Byte 29 :
05h -> Tipo di protocollo trasportato (5 = Link State Acknowledge)
Bytes
30 ÷ 31 :
00h 2Ch -> Numero di bytes del pacchetto (Header + LSU = 44)
Bytes
32 ÷ 35 :
82h C0h 05h 47h -> Indirizzo IP del source router (130.192.5.71)
Bytes
36 ÷ 39 :
00h 00h 00h 00h-> Identificativo dell'area all'interno
del dominio OSPF (0); corrisponde all'area di backbone
Bytes
40 ÷ 41 :
C6h 84h -> Checksum
Bytes 42 ÷ 43 : 00h 00h -> Authentication Type (0 = nessuna
autenticazione)
Bytes
44 ÷ 51 :
Tutti 00h -> Riservati per l'eventuale autenticazione e quindi
ignorati
IL PACCHETTO LSA (Acknowledge)
Bytes
52 ÷ 53 :
00h 02h -> Anzianita' dell' LSA corrente (2 sec.)
Byte 54 :
00h -> Solo gli ultimi 2 bit hanno significato, il penultimo viene
utilizzato dal protocollo Hello, mentre l'ultimo
sta a significare che il router non gestisce il TOS routing.
Byte 55 :
01h -> Definisce il tipo di LSA trasportato (1 = Router
Link)
Bytes 56 ÷ 59 :
82h C0h 03h 2Eh -> Identificativo dell'LSA (130.192.3.46)
Bytes 60 ÷ 63 :
82h C0h 03h 2Eh-> Indirizzo IP dell'Advertising Router
(130.192.3.46)
Bytes 64 ÷ 67 :
80h 00h 00h 0Ah-> Numero di sequenza dell'LSA (2147483658)
Bytes 68 ÷ 69 :
23h 28h -> Checksum
Bytes 70 ÷ 71 :
00h 30h -> Lunghezza totale del pacchetto, incluso l'header (48)
In pratica, questo pacchetto di Acknowledge e' la replica effettiva della LSU
precedente alla quale e', in effetti, riferita (uguale numero di sequenza). Da
notare, infine, che il pacchetto Acknowledge e', in effetti, una replica
dell'header comune della LSA (Advertisment).
Torna all'inizio
CATTURA #3
CONFIGURAZIONE E COMANDI
Macchina e interfaccia di cattura: Goomer pvc0 (IP address 10.0.0.66)
Comando Tcpdump: Tcpdump -i pvc0 -w goompvc0.acp -s 1518 ip proto
89
Configurazione gateD Goomer:
ospf yes {
backbone {
interface xl1 le0 pvc0 pvc1 {priority 1;};
interface xl0 {disable;};
};
};
In generale, la configurazione di GateD su ciascuna macchina era comunque
tale da abilitare la trasmissione e la ricezione di pacchetti OSPF 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).
Inoltre, ciacuna macchina GateD, oltre che Goomer stessa, era configurata per l'area di
backbone.
ANALISI
La cattura in esame e' relativa a 16 pacchetti OSPF 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.
Come vedremo successivamente, questa cattura e' direttamente associata alla
cattura #4, effettuata contemporaneamente sull'interfaccia pvc1 di Goomer; il
confronto tra le 2 catture ci permettera' di osservare degli aspetti
interessanti.
Ma effettuiamo, in dettaglio, un'analisi dei 16 pacchetti,
focalizzandoci sull'aspetto funzionale e tralasciando invece l'aspetto
descrittivo, per il quale si puo' fare riferimento alle catture precedenti (cattura #1 per il pacchetto Hello,
cattura #2 per i pacchetti LSU e LSA):
Pacchetti #1 ÷
#4: Pacchetti Hello, provenienti da Goomer:pvc0 (pacchetti 1 e 3) e da
Gedeone:pvc1 (pacchetti 2 e 4). Si ribadisce che questo evento e' possibile in
quanto si tratta di pacchetti multicast (IP address 224.0.0.5) e l'interfaccia
di ascolto e' abilitata anche alla ricezione dei pacchetti
Pacchetto #5:
Questo pacchetto e' stato emesso in concomitanza con l'abbattimento del
link. Si tratta di un pacchetto LSU, emesso da Goomer:pvc0 che
trasporta un LSA contenente 5 Link State di tipo Router
Link, ossia:
3
router link di tipo 3 (connessione ad una rete stub) che annunciano le sottoreti/interfacce
10.0.032, 10.0.065, 10.0.0.81
2
router link di tipo 1 (connessione punto-punto con un altro router) che
annunciano le interfacce 130.192.5.71 e 130.192.28.96 attraverso i link con
interfacce 10.0.0.66 e 10.0.0.81
Come si puo' osservare, non appaiono link state relativi alle interfacce
10.0.0.1 e 10.0.0.2 o alla subnet che li identifica 10.0.0.0, in quanto
rappresentano il link abbattuto. In pratica la LSU ha presentato il nuovo
stato dei link relativi al router che l'ha emessa
Pacchetto
#6: Pacchetto LSA (Acknowledge), emesso da Gedeone:pvc1 in risposta alla
ricezione della LSU precedente (e' identificabile, tra l'altro, dallo stesso
numero di sequenza)
Pacchetti #7 ÷
#8: Pacchetti Hello
Pacchetto #9:
Questo pacchetto e' stato emesso in concomitanza con il ripristino del link
abbattuto. Si tratta di un pacchetto LSU, emesso da Goomer:pvc0 che
trasporta un LSA contenente 6 Link State di tipo Router Link, ossia:
gli
stessi 5 router link state, visti per l'analisi del pacchetto #5
un
ulteriore link state di tipo 3 relativo alla subnet 10.0.0.0, che annuncia il
link ripristinato.
Pacchetto #10:
Pacchetto LSA (Acknowledge), emesso da Gedeone:pvc1 in risposta alla ricezione
della LSU precedente
Pacchetto #11:
Si tratta di un pacchetto LSU, emesso da Goomer:pvc0 che trasporta un LSA
contenente 2 Link State di tipo Router Link tipo 3, che annunciano le subnet
10.0.0.0 e 10.0.0.16
Pacchetto #12:
Pacchetto LSA (Acknowledge), emesso da Gedeone:pvc1 in risposta alla ricezione
della LSU precedente
Pacchetto #13:
Si tratta di un pacchetto LSU, emesso da Goomer:pvc0 che trasporta un LSA
contenente 6 Link State di tipo Router Link, ossia:
gli
stessi 5 router link state, visti per l'analisi del pacchetto #5
un
ulteriore link state di tipo 2 (transit network) relativo alla subnet 10.0.0.0,
che annuncia le 2 interfacce 10.0.0.1 e 10.0.0.2
Pacchetto #14:
Pacchetto LSA (Acknowledge), emesso da Gedeone:pvc1 in risposta alla ricezione
della LSU precedente
Pacchetto #15:
Si tratta di un pacchetto LSU, emesso da Goomer:pvc0 che trasporta un LSA
contenente 2 Link State di tipo Router Link, che annunciano l'interfaccia
10.0.0.2 e la subnet 10.0.0.16
Pacchetto #16:
Pacchetto LSA (Acknowledge), emesso da Gedeone:pvc1 in risposta alla ricezione
della LSU precedente
Torna all'inizio
CATTURA #4
CONFIGURAZIONE E COMANDI
Macchina e interfaccia di cattura: Goomer pvc1 (IP address 10.0.0.81)
Comando Tcpdump: Tcpdump -i pvc1 -w goompvc1.acp -s 1518 ip proto
89
Configurazione gateD Goomer:
ospf yes {
backbone {
interface xl1 le0 pvc0 pvc1 {priority 1;};
interface xl0 {disable;};
};
};
In generale, la configurazione di GateD su ciascuna macchina era comunque
tale da abilitare la trasmissione e la ricezione di pacchetti OSPF 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).
Inoltre, ciacuna macchina GateD, oltre che Goomer stessa, era configurata per l'area di
backbone.
ANALISI
La cattura in esame e' relativa a 13 pacchetti OSPF 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.
Come anticipato nell'analisi della cattura #3, questa cattura e' direttamente
associata a quella, in quanto e' stata effettuata contemporaneamente,
avvalendosi di 2 comandi tcpdump, dati su 2 finestre diverse in tempi
simili; il confronto tra le 2 catture ci permette di osservare degli aspetti
interessanti, di seguito descritti:
-
Le LSU catturate sull'interfaccia pvc1, alla quale si
riferisce la cattura, sono praticamente identiche a quelle effettuate
sull'interfaccia pvc0, alla quale si riferisce la cattura 3. La sola
differenza, rispetto a quella cattura, e' che, ovviamente, le LSU viaggiano
da Goomer verso Dante e in senso opposto le LSA.
-
I tempi di emissione delle LSU su entrambe le interfacce
coincidono
Il fatto che la cattura sia limitata a 13 pacchetti anziche' a 16, come nel
caso della cattura #3, e' semplicemente dovuto al fatto che e' stata interrotta
prima di quest'ultima.
Torna all'inizio
