Relazione Laboratorio di reti telematiche

Transcript

Relazione
Laboratorio di reti telematiche
Djatsa Yota Eric
Matricola n. 140360
Fiandrino Claudio
Matricola n. 138436
Giacchè Diego
Matricola n. 125292
Nfonte Mandje Fouapon Abdou Cassimou
Matricola n. 151351
Ricci Marco
Matricola n. 140653
Indice
1 Configurazione
3
2 Protocollo ARP
2.1 Tabella di arp . . . . . . . . . . . . . .
2.2 Aggiornamento della tabella di arp . .
2.3 Host Inesistente ma nella stessa subnet
2.4 Host inesistente e in subnet diversa . .
2.5 Durata delle entry nella tabella . . . .
3
3
4
5
5
5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Consegna diretta e risoluzione di indirizzi: il protocollo
ARP
6
3.1 Diagramma temporale . . . . . . . . . . . . . . . . . . . . . .
6
3.2 Round Trip Time . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.3 Commando ping con dimensione applicativa piccola . . . . .
7
3.4 Comportamenti in caso di perdità di connetività . . . . . . .
8
3.5 Perdità temporanea di connetività . . . . . . . . . . . . . . .
8
3.6 Velocità di collegamento . . . . . . . . . . . . . . . . . . . . .
8
3.7 Grafici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
4 Cattura e analisi di protocollo di livello trasporto/applicazione
4.1 Analisi sequence number, receiver window e lunghezza segmenti trasmessi . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Sequence number . . . . . . . . . . . . . . . . . . . . .
4.1.2 Receiver window . . . . . . . . . . . . . . . . . . . . .
4.1.3 Lunghezza segmenti trasmessi . . . . . . . . . . . . . .
5 Misure di prestazioni
6 Operazioni verso internet
6.1 Comando Ping . . . . . . .
6.2 Comando Traceroute . . . .
6.2.1 Output comando . .
6.2.2 Cattura con ethereal
6.3 Prova con il browser . . . .
14
14
14
16
18
20
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
23
23
26
28
7 Protocollo RIP
31
7.1 Comportamenti in caso di guasti . . . . . . . . . . . . . . . . 33
2
1
Configurazione
Abbiamo configurato la nostra rete con indirizzi privati di classe B nel
seguente modo:
. indirizzo di rete 172.16.0.0;
. netmask 255.255.255.128;
. indirizzo di broadcast IP 172.16.0.127;
. indirizzo host A 172.16.0.1;
. indirizzo host B 172.16.0.2;
. indirizzo host C 172.16.0.3.
2
2.1
Protocollo ARP
Tabella di arp
L’output del comando arp, permette di visualizzare la tabella di arp (tabella delle associazioni fra indirizzi IP e indirizzi MAC) dell’host sul quale si
esegue il comando.
Riportiamo di seguito un esempio:
Address
172.16.0.1
172.16.0.2
HWtype
ether
ether
HWaddress
Flags Mask
00:E0:4C:A0:1B:F2
C
00:50:FC:09:6C:28
C
la composizione dei campi è:
. Address: indirizzo IP destinatario;
. HWType: collegamento di livello 2 (Ethernet nel nostro caso);
. Hwaddress: indirizzo MAC destinatario;
. Flag mask;
. Iface: l’interfaccia di rete verso il destinatario.
3
Iface
eth1
eth1
2.2
Aggiornamento della tabella di arp
Nel caso in cui ci sia uno scambio di pacchetti ICMP tra un host sorgente
(A) e un destinatario (B) e vi siano presenti nella subnet altri host, solo A
e B aggiornano le proprie tabelle di ARP.
Quando l’host sorgente ha dati da inviare controlla, innanzitutto, se è presente nella propria tabella di ARP l’entry del destinatario; se esiste, i pacchetti
vengono inoltrati nella rete mentre in caso contrario A inoltra a livello 3 una
ARP request in broadcast per conoscere la corrispondenza IP-MAC di B.
B, se è connesso alla subnet e operativo, riconosce il suo IP e risponde in
unicast ad A con una ARP-reply con il proprio indirizzo MAC quindi A
completa nella ARP table l’entry relativa a B.
Inoltre, poichè si suppone che vi sia uno scambio di pacchetti tra i due host,
anche B aggiorna la propria ARP-table con l’entry relativa ad A.
Nel caso in cui in una tabella di arp ci sia un’entry incompleta o obsoleta
relativa ad un host e arrivi da quello stesso host un’ARP-request il destinatario provvede ad aggiornare la propria tabella di arp.
Un’altra possibilità nella gestione delle arp tables è la seguente: tutti gli
host che ricevono un’arp request, anche se non indirizzata a loro a livello
IP, la processano e inseriscono o aggiornano l’entry relativa all’host sorgente
nella propria tabella di arp.
Vantaggio
. Le tabelle di arp di tutti gli host della subnet contengono un maggior
numero di informazioni questo permette di avere un minor numero di
richieste di arp sulla rete.
Svantaggi:
. questo metodo non è scalabile in quanto all’aumentare delle dimesioni
della subnet aumenterà il numero di arp request che ogni host dovrà
elaborare e di conseguenza il tempo di elaborazione;
. sarà necessaria più memoria visto che il numero di entry sarà maggiore;
. la tabella di arp contiene informazioni che potrebbero non essere utilizzate.
Per i punti seguenti 3, 4 e 5 ipotizziamo che la tabella di arp del mittente
sia vuota.
4
2.3
Host Inesistente ma nella stessa subnet
Se si prova a contattare un host ipoteticamente appartenente alla sottorete,
ma inesistente, il risultato che si ha a video all’esecuzione del comando ping
è il messaggio di errore host unreachable.
Nella tabella di arp si ha il campo indirizzo IP con l’IP corretto dell’ipotetico host destinatario mentre il campo indirizzo MAC destinatario avrà la
dicitura incomplete che indica che l’host mittente non ha ricevuto risposta.
2.4
Host inesistente e in subnet diversa
Se si prova a contattare un host ipoteticamente non appartenente alla sottorete e inesistente, il risultato che si ha all’esecuzione del comando ping è
il seguente: A controllando nella routing table vede che il destinatario è al
di fuori della subnet e invia l’ARP-request al default gateway, non riceve
nessuna risposta neanche host unreachable perchè i pacchetti non vengono
elaborati da nessun host.
Nella tabella di arp sarà presente l’entry con il campo indirizzo MAC destinatario incomplete.
Riportiamo un output del comando ping per questo esempio:
PING 172.16.0.4 (172.16.0.4): 56 data bytes
— 172.16.0.4 ping statistics —
2 packets transmitted, 0 packets received, 100% packet loss
e la relativa tabella di arp:
Address
172.16.0.4
2.5
HWtype
HWaddress
(incomplete)
Flags Mask
Iface
eth1
Durata delle entry nella tabella
Dalle misure effettuate sull’host A risulta che la durata delle entry nella
tabella di arp è:
. host raggiungibile: 3 minuti e 31 secondi (ven mag 8 15:35:46 CEST
2009 / ven mag 8 15:39:17 CEST 2009);
. host non raggiungibile: 2 minuti e 21 secondi (ven mag 8 16:19:11
CEST 2009 / ven mag 8 16:21:32 CEST 2009).
5
3
3.1
Consegna diretta e risoluzione di indirizzi: il
protocollo ARP
Diagramma temporale
Figura 1: diagramma temporale
6
Indirizzi MAC di destinazione:
. ARP-REQUEST
. ARP-REPLY
3.2
−→
−→
broadcast (FF:FF:FF:FF:FF:FF);
unicast, verso il mittente dell’ARP-REQUEST.
Round Trip Time
Il round trip time (RTT) è dato da:
RT T = TelabA + TpropA + TT X + TelabB + TpropB + TT X + TelabA ∼
= 2TT x (1)
Telab : tempo
Tprop : tempo
della luce e d
TT X : tempo
di elaborazione (ipotizziamo trascurabile);
di propagazione (trascurabile in quanto è pari a dc , c velocità
distanza dell’ordine dei metri);
di trasmissione legato alla capacità del canale TT X = P ayload
VT X .
Il motivo per cui il primo pacchetto ICMP inviato ha un RTT chiaramente
superiore rispetto a quello calcolato per i successivi pacchetti è dovuto alla
necessità di ottenere il MAC del destinatario con ARP.
Esempio di output:
64
64
64
64
PING 172.16.0.2 (172.16.0.2): 56 data bytes
bytes from 172.16.0.2: icmp seq=0 ttl=64 time=1.4 ms
— 172.16.0.2 ping statistics —
4 packets transmitted, 4 packets received, 0% packet loss
3.3
Commando ping con dimensione applicativa piccola
Nel caso in cui si esegua il comando ping utilizzando l’opzione -s e si setti la
grandezza del pacchetto a 1 Byte, nella risposta non verranno visualizzate
tutte le informazioni.
Il dato che non viene visualizzato a causa della dimensione esigua del pacchetto è il Round Trip Time (RTT); questo accade perchè tra le informazioni
contenute nel pacchetto questa è quella meno rilevante.
7
3.4
Comportamenti in caso di perdità di connetività
Se si perde connettività durante un’operazione di ping esistono 2 possibilità:
1. nel caso in cui un certo numero di pachetti siano già arrivati all’host destinatario e che quest’ultimo abbia mandato le risposte corrispondenti
prima della perdita di connettività la tabella di arp viene comunque
aggiornata con l’entry corretta dell’ultimo pacchetto andata a buon
fine;
2. Nel caso, invece, che si perda la connettività prima dello scambio di
pacchetti gli host non sono in grado di aggiornare le proprie tabelle di
arp e l’entry risulterà incomplete nel caso di host interni alla subnet e
sarà vuota in caso di host esterni.
3.5
Perdità temporanea di connetività
Se si perde connettività tra 2 host a causa del cambiamento temporaneo di
un’indirizzo o di un guasto sulla rete durante un ping si hanno le seguenti
possibilità:
. meno di 5 secondi: la sorgente continua a mandare ICMP echo request,
che non avranno risposta, finchè non si recupera la connettività;
. più di 5 secondi: dopo aver inviato un certo numero di ICMP echo
request che non avranno risposta la sorgente invia ARP-REQUEST
in unicast all’indirizzo del destinatario per accertarsi che sia operativo. Quando la connettività è ripristinata il destinatario risponderà
all’ARP request e alle successive echo request;
. più di 60 secondi: come nel caso precedente la sorgente invia ARP
request, per un certo periodo, in unicast che non ricevendo risposta
vengono successivamente mandate in broadcast.
3.6
Velocità di collegamento
È possibile calcolare la velocità del collegamento di 2 host appartenenti alla
stessa subnet tramite il comando ping con l’utilizzo della seguente formula:
VT X =
S
TT X
con S dimensione Payload applicativo e TT X tempo di trasmissione.
Poichè sappiamo dalla (1) che RT T ∼
= 2 · TT X deduciamo:
VT X ∼
=
S
RT T
2
8
=
2·S
RT T
Per quanto riguarda i tempi di trasmissione della PDU l’unico legato alla
capacità del canale è il tempo è il tempo di trasmissione, come abbiamo già
evidenziato nel punto 3.2.
3.7
Grafici
grafico RTT(Payloadapp)
120
100
RTT[ms]
80
60
40
20
0
0
1
2
D
3
[Byte]
4
5
app
Figura 2: grafico RTT in funzione del Payload applicativo
Come si evince dalle formule:
Dapp
RT T ∼
= 2 · TT X =
VT X
le due grandezze sono direttamente proporzionali tra loro linearmente.
9
6
4
x 10
grafico RTT(Payload
)
app
3
2.8
RTT[ms]
2.6
2.4
2.2
2
1200
1300
1400
D
1500
[Byte]
1600
1700
1800
app
Figura 3: zoom sul punto critico di frammentazione del pacchetto
Dal grafico possiamo notare che quando il payload supera i 1472 byte
(1500 Maximum Transmission Unit - 20 intestazione ip - 8 ICMP) il livello
IP frammenta i pacchetti.
Se i dati utili nel secondo pacchetto sono pochi in rapporto all’ header c’è
un’inefficienza nel tempo di trasmissione e dunque nel RTT.
In generale la frammentazione avviene quando al livello 3 arrivano segmenti
(payload + intestazione ICMP) di dimensione superiore a 1472 byte.
Nel caso in cui siano inferiori a 2952 (1472 + 1480) il segmento viene diviso
in due pacchetti, altrimenti i frammenti saranno di più ogni volta che si
superano:
1472 + κ · 1480
con κ = 2, 3, 4...
10
grafico Ttx(Payload
)
app
60
50
Ttx[ms]
40
30
20
10
0
0
1
2
3
Dapp[Byte]
4
5
6
Figura 4: grafico TT X in funzione del Payload applicativo
Questo grafico è analogo al precedente a meno di un fattore 2 dovuto a:
RT T ∼
= 2 · TT X
11
4
x 10
grafico v (Payload
tx
)
app
10
9
8
7
vtx[Mb/s]
6
5
4
3
2
1
0
0
1
2
3
Dapp[Byte]
4
5
6
4
x 10
Figura 5: grafico Vtx in funzione del Payload applicativo
La velocità è anche calcolabile in
VT X =
byte
secondo
come:
8
2 · Dapp
·
RT T
1000
Si può osservare che inizialmente con valori di Dapp piccoli la crescita è
molto alta in quanto la dimensione del payload è confrontabile con quella
degli header. È possibile notare una serie di discontinuità in corrispondenza
delle frammentazioni, in particolar modo la prima avviene con dimensione
del payload pari a 1472 bytes.
Per valori di Dapp grandi la velocità tende al goodput massimo, inferiore al
limite teorico di 10 Mbit/s.
12
grafico v (Payload )
tx
fis
10
9
8
7
vtx[Mb/s]
6
5
4
3
2
1
0
0
1
2
3
4
5
Dfis[Byte]
6
7
4
x 10
Figura 6: grafico Vtx in funzione del Payload fisico
Questo grafico è analogo al precedente ad eccezione del limite a cui la curva
tende per valori di Df is alti, ovvero al throughput, che risulta essere maggiore del goodput in quanto il Df is a differenza del Dapp tiene conto degli
header.
13
4
Cattura e analisi di protocollo di livello trasporto/applicazione
Lo scopo di questa esercitazione è l’analisi delle caratteristiche del protocollo
TCP mediante l’applicativo chargen.
Questo servizio ha lo scopo di trasmettere una sequenza infinita di caratteri
finchè la sorgente non chiude la connessione.
4.1
4.1.1
Analisi sequence number, receiver window e lunghezza
segmenti trasmessi
Sequence number
Figura 7: numero sequenza client
Poichè il client non deve inviare dati al server, il sequence number resta
costante per tutta la durata della connessione.
In realtà si possono notare 2 salti sul grafico, essi sono relativi ai pacchetti
di apertura e chiusura della connessione TCP (SYN e FIN).
14
Figura 8: numero sequenza server
Quando la connessione è stata instaurata, il server comincia a inviare pacchetti in slow start raddoppiando sempre la finestra di trasmissione finché
non si riempie la receiver window del client. A questo punto il client limita
la finestra di invio; ciò spiega la non linearità presente all’inizio del grafico;
durante il resto della connessione il sequence number cresce linearmente.
Quando si digita il comando CT RL+] il client blocca il server dunque il
sequence number si mantiene costante, come si può notare nella parte finale
del grafico.
15
4.1.2
Receiver window
Figura 9: receiver window del client
La receiver window del client inizialmente è massima quindi il server può
mandare un numero elevato di pacchetti.
Quando il client inizia ad elaborare le informazioni ricevute attiva il controllo
di flusso per limitare il server nell’invio dei pacchetti in funzione dello spazio
disponibile nella sua receiver window.
Si può chiaramente vedere che, dopo gli istanti iniziali, essa presenta un
comportamento altalenante dovuto al fatto che il server invia una mole di
dati superiore a quella che il client riesce ad elaborare. Il client è dunque
obbligato a fermare ad intervalli costanti il server dichiarando una receiver
window pari a zero.
Quando l’utente digita il comando CTRL+] si interrompe il flusso di dati in
ricezione imponendo la finestra a 0.
Il picco finale è dovuto al fatto che, una volta ripresa la comunicazione, il
client può annunciare alla sorgente receiver window con valore massimo.
16
Figura 10: receiver window del server
Il server inizialmente dichiara una receiver window di una determinata
dimensione, anche grande; poichè però non riceve nessun pacchetto di dati
dal client annuncia un valore costante per tutta la durata della connessione.
17
4.1.3
Lunghezza segmenti trasmessi
Figura 11: lunghezza pacchetti trasmessi dal client
Poichè il client non invia dati alla sorgente la lunghezza dei segmenti
trasmessi sarà sempre pari a 0.
18
Figura 12: lunghezza pacchetti trasmessi dal server
Per quanto riguarda il server inizialmente osserviamo un transitorio in
cui la dimensione dei segmenti inviati e piccola e successivamente si manterrà
costante ad un valore pari alla MTU privata della lunghezza degli header.
Digitando CTRL+] si interrompe il flusso dei dati quindi la lunghezza risulta nulla.
19
5
Misure di prestazioni
Prova
Tipo
A
A
B
B
C
C
C
C
D
D
D
E
E
E
F
F
F
G
G
G
H
H
H
I
I
L
L
TCP
UDP
TCP
UDP
TCP→TCP 1
UDP→UDP
UDP→TCP
TCP→UDP
TCP-TCP
UDP-UDP
TCP-UDP
TCP-TCP
UDP-UDP
TCP-UDP
TCP-TCP
UDP-UDP
TCP-UDP
TCP-TCP
UDP-UDP
TCP-UDP
TCP-TCP
UDP-UDP
TCP-UDP
TCP-TCP
UDP-UDP
TCP-TCP
UDP-UDP
Goodput
Prev.
Oss.
9.03
7,2736
9.57
9.6824
94.9 94.9082
95.7 96.7632
4.52
3.6378
4.79
5.5448
4.52
4.1732
4.67
8.6175
90.3 78.0428
95.7 90.2728
91.1 77.2788
4.52
4.8355
4.79
5.4663
4.67
4.9324
47.5 59.6868
47.9 18.2753
47.5 84.8056
4.52
5.2322
4.79
4.9145
4.63
6.3942
47.5 40.1441
47.7 42.2910
47.5 47.5325
1.5
4.0806
1.6
3.7190
45.2 75.6799
47.9 84.0814
Collisioni
Prev. Oss.
SI
2004
NO
0
NO
0
NO
0
SI
3259
SI
470
SI
2389
SI
2116
NO
0
NO
0
NO
0
SI
3551
NO
3
SI
2008
NO
0
NO
0
NO
0
SI
4497
SI
470
SI
2416
NO
0
NO
0
NO
0
SI
3861
SI
418
NO
0
NO
0
Perdite
Prev. Oss.
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
SI
SI
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
SI
SI
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
NO
SI
NO
NO
NO
SI
SI
Tabella 1: riassunto prestazioni, valori espressi in Mbit/s
1
L’host A della configurazione è il trasmettitore.
Come si può notare nei casi A,B e C dove sono presenti solo 2 hosts, il
goodput ottenuto con UDP è leggermente superiore a quello che si ha con
TCP; questo è dovuto al fatto che TCP è un protocollo orientato alla connessione perciò prevede un traffico aggiuntivo di segnalazione e quindi degli
overhead piu grandi che diminuiscono il goodput.
Si può notare che con UDP il goodput peggiora significativamente nel caso
20
in cui si imposti, come parametro L (lunghezza del paccheto), un valore di
poco superiore a 1472 byte o in generale una dimensione che generà un frammento di dimensioni paragonabili a quella degli header Ethernet+IP+TCP
come spiegato nel punto 3.6.1 in figura 3.
Con TCP non c’è questo problema in quanto TCP offre a IP uno stream
di byte, ed è TCP stesso che fa la segmentazione in base alla MSS(Maximu
Segment Size).
Nel caso D, con l’uso di TCP, si ha un goodput elevato perché lo switch
permette di avere due canali in paralello, uno usato per i paccheti da trasmettere e l’altro usato per gli ACK.
Nelle configurazioni con 2 trasmettitori ed un ricevitore, con uso di switch,
come il caso F, si nota che il goodput di UDP è elevato mentre quello di TCP
è piutosto basso (vicino al 50%); questo è dovuto al fatto che non c’è un’utilizzo equo delle risorse,infatti appena un pacchetto viene perso a causa dello
riempimento della coda dello switch,TCP attiva il controllo congestione che
riduce il goodput,mentre UDP continua a trasmettere senza interuzioni.
Avevamo previsto perdite nel caso I con UDP poichè nella tipologia ad anello l’hub, che può essere considerato come un unico canale, non è in grado di
supportare tre flussi di informazione contemporanei. Tuttavia in una rete
come quella creata da noi CSMA risulta molto affidabile quindi risolve questa possibilità.
È stato verificato che, con UDP, si inviano come minimo 5 pacchetti. Infatti
il goodput tende ad annullarsi al diminuire della dimensione dei pacchetti
fino a diventare pari a zero con num. pacchetti < 5.
21
6
Operazioni verso internet
Connettendo le diverse isole a internet esterna abbiamo provato ad eseguire alcune operazioni verso i siti internet www.polito.it , www.google.it,
www.gazzetta.it e www.sun.com.
6.1
Comando Ping
Riportiamo la cattura dei primi pacchetti sniffati con l’analizzatore di protocolli ethereal verso www.google.it:
No. Time
Source
Destination
Protocol
1
0.000000 192.168.200.11 192.168.200.250 DNS
Info
Standard query A www.google.it
Frame 1 (73 bytes on wire, 73 bytes captured)
Ethernet II, Src: 00:0b:6a:d1:0c:10, Dst: 00:07:95:d9:2d:f7
Internet Protocol, Src Addr: 192.168.200.11 (192.168.200.11), Dst Addr: 192.168.200.250
(192.168.200.250)
User Datagram Protocol, Src Port: 32792 (32792), Dst Port: 53 (53)
Domain Name System (query)
No. Time
Source
Destination
2
0.004263 192.168.200.250 192.168.200.11
Protocol
DNS
Info
*
* Standard query response CNAME www.google.com CNAME www.l.google.com A
74.125.87.103 A 74.125.87.104 A 74.125.87.147 A 74.125.87.99
Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:d1:0c:10
(192.168.200.11)
Domain Name System (response)
No. Time
Source
Destination
3
0.004558 192.168.200.11 74.125.87.103
22
Protocol
ICMP
Info
Echo (ping) request
Ethernet II, Src: 00:0b:6a:d1:0c:10, Dst: 00:07:95:d9:2d:f7
(74.125.87.103)
Internet Control Message Protocol
No. Time
Source
4
0.034693 74.125.87.103
Destination
192.168.200.11
Protocol
ICMP
Info
Echo (ping) reply
Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:d1:0c:10
(192.168.200.11)
6.2
Comando Traceroute
6.2.1
Output comando
. Verso www.polito.it:
- 192.168.3.1 (192.168.3.1) 0.236 ms 0.202 ms 0.200 ms
- 10.0.0.6 (10.0.0.6) 0.825 ms 0.789 ms 0.770 ms
- 192.168.200.250 (192.168.200.250) 2.033 ms 1.921 ms 1.806 ms
- 130.192.77.65 (130.192.77.65) 2.649 ms 2.695 ms 2.651 ms
- 192.168.255.162 (192.168.255.162) 2.615 ms 2.812 ms 2.592 ms
- 192.168.255.21 (192.168.255.21) 2.877 ms 2.883 ms 2.876 ms
- 192.168.255.17 (192.168.255.17) 3.052 ms 3.096 ms 3.023 ms
- 192.168.255.1 (192.168.255.1) 2.607 ms 2.700 ms 2.563 ms
- 130.192.232.2 (130.192.232.2) 2.713 ms 2.588 ms 2.570 ms
23
. Verso www.gazzetta.it:
- 192.168.3.1 (192.168.3.1) 0.280 ms 0.203 ms 0.201 ms
- 10.0.0.6 (10.0.0.6) 0.872 ms 0.793 ms 0.768 ms
- 192.168.200.250 (192.168.200.250) 2.268 ms 2.120 ms 2.051 ms
- 130.192.77.65 (130.192.77.65) 2.969 ms 3.007 ms 2.933 ms
- 192.168.255.162 (192.168.255.162) 9.037 ms 3.070 ms 4.096 ms
- 192.168.255.21 (192.168.255.21) 3.279 ms 3.329 ms 3.041 ms
- 192.168.255.17 (192.168.255.17) 3.231 ms 3.353 ms 3.247 ms
- 192.168.255.1 (192.168.255.1) 2.809 ms 3.014 ms 2.672 ms
- 130.192.232.60 (130.192.232.60) 3.092 ms 3.130 ms 2.897 ms
- 130.192.232.254 (130.192.232.254) 3.794 ms 3.162 ms 3.151 ms
- ru-polito-rt-to1.to1.garr.net (193.206.132.33) 3.560 ms 3.732 ms 4.435 ms
- rt-to1-rt-mi2.mi2.garr.net (193.206.134.41) 6.610 ms 6.407 ms 6.340 ms
- infracomna.mix-it.net (217.29.66.11) 6.824 ms 6.301 ms 6.405 ms
- Milano-1-tge-3-1.ita.tip.net (62.196.4.250) 7.303 ms 6.710 ms 6.600 ms
24
. Verso www.sun.com:
- 192.168.3.1 (192.168.3.1) 0.260 ms 0.202 ms 0.200 ms
- 10.0.0.6 (10.0.0.6) 0.833 ms 0.793 ms 0.771 ms
- 192.168.200.250 (192.168.200.250) 3.012 ms 3.042 ms 2.998 ms
- 130.192.77.65 (130.192.77.65) 16.067 ms 3.645 ms 3.660 ms
- 192.168.255.162 (192.168.255.162) 3.562 ms 3.563 ms 4.623 ms
- 192.168.255.21 (192.168.255.21) 27.576 ms 3.734 ms 3.687 ms
- 192.168.255.17 (192.168.255.17) 10.965 ms 5.127 ms 3.900 ms
- 192.168.255.1 (192.168.255.1) 3.767 ms 3.802 ms 3.865 ms
- 130.192.232.60 (130.192.232.60) 3.927 ms 3.810 ms 3.798 ms
- 130.192.232.254 (130.192.232.254) 4.027 ms 18.509 ms 3.792 ms
- ru-polito-rt-to1.to1.garr.net (193.206.132.33) 4.664 ms 4.555 ms 4.443 ms
- rt-to1-rt-mi2.mi2.garr.net (193.206.134.41) 7.368 ms 7.093 ms 7.389 ms
- 213.248.71.161 (213.248.71.161) 7.556 ms 7.106 ms 7.032 ms
- prs-bb1-link.telia.net (80.91.249.38) 19.906 ms 20.021 ms 19.822 ms
- ash-bb1-link.telia.net (80.91.252.36) 101.194 ms 101.381 ms 102.180 ms
- sl-st22-ash-2-0.sprintlink.net (144.232.19.113) 102.401 ms 101.346 ms 101.515 ms
- sl-bb20-dc-8-0-0.sprintlink.net (144.232.9.120) 103.104 ms 102.879 ms 102.881 ms
- sl-crs1-rly-0-1-5-0.sprintlink.net (144.232.20.15) 110.448 ms 104.730 ms 103.595 ms
- sl-crs2-sj-0-5-0-0.sprintlink.net (144.232.20.186) 164.080 ms 163.078 ms 164.780 ms
- sl-gw19-sj-15-0-0.sprintlink.net (144.232.0.250) 173.301 ms 173.078 ms 178.985 ms
- 144.232.191.202 (144.232.191.202) 173.160 ms 178.413 ms 172.330 ms
- border2.te8-1-bbnet2.sfo002.pnap.net (63.251.63.82) 174.757 ms 174.705 ms 180.140
ms
25
6.2.2
Cattura con ethereal
Riportiamo la cattura dei pacchetti effettuati con l’analizzatore di protocolli
ethereal per l’operazione compiuta verso www.sun.com:
No. Time
Source
Destination
Protocol Info
6
11.010752 192.168.200.12 192.168.200.250 DNS
*
*Standard query A www.sun.com
Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 00:07:95:d9:2d:f7
(192.168.200.250)
No. Time
Source
Destination
Protocol Info
7
11.184463 192.168.200.250 192.168.200.12 DNS
*
* Standard query response A 72.5.124.61
Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:cf:04:c6
(192.168.200.12)
No. Time
Source
Destination Protocol Info
8
11.185605 192.168.200.12 72.5.124.61 UDP
*
*Source port: 38090 Destination port: 33435
(72.5.124.61)
Data (10 bytes)
26
No Time
Source
Destination
Protocol
9 11.186743 192.168.200.250 192.168.200.12 ICMP
Info
*
* Time-to-live exceeded (Time to live exceeded in transit)
(192.168.200.12)
No. Time
Source
Destination
Protocol
10 11.187036 192.168.200.12 192.168.200.250 DNS
Info
*
* Standard query PTR 250.200.168.192.in-addr.arpa
(192.168.200.250)
No. Time
Source
Destination
Protocol
11 11.188034 192.168.200.250 192.168.200.12 DNS
Info
*
* Standard query response PTR AZIMUT2K
(192.168.200.12)
Commenti:
inizialmente l’host richiede al DNS (192.168.200.250) la traduzione del nome
logico nel relativo indirizzo ip; la prima volta questa operazione è di tipo A
mentre successivamente le traduzione sono di tipo PTR (pointer).
Osserviamo che vengono ricevuti pacchetti Time-to-live exceeded per determinare i router intermedi attraversati, inoltre come implementato dal
27
sistema operativo (Knoppix) di default il comando traceroute utilizza pacchetti UDP con porte di destinazione comprese tra 33434 e 33534.
6.3
Prova con il browser
In questa sezione riportiamo la cattura di pacchetti effettuata connettendoci
al sito www.polito.it tramite browser:
No. Time
Source
Destination
3
11.290911 00:0b:6a:cf:04:c6 ff:ff:ff:ff:ff:ff
Protocol
ARP
Info
*
* Who has 192.168.200.250? Tell 192.168.200.12
Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: ff:ff:ff:ff:ff:ff
Address Resolution Protocol (request)
No. Time
Source
Destination
Protocol
4
11.291374 00:07:95:d9:2d:f7 00:0b:6a:cf:04:c6 ARP
*192.168.200.250 is at 00:07:95:d9:2d:f7
Address Resolution Protocol (reply)
28
Info
*
I pacchetti 3 e 4 rappresentano la richiesta ARP dell’indirizzo ip del dns e la
risposta. I pacchetti successivi (5, 6, 7 e 8) invece contengono la richiesta di
traduzione del nome logico www.polito.it nell’indirizzo ip e la risposta del dns.
No. Time
Source
Destination
Protocol
5 11.291399 192.168.200.12 192.168.200.250 DNS
Info
*
* Standard query A www.polito.it
(192.168.200.250)
No. Time
Source
Destination
Protocol
6 11.291405 192.168.200.12 192.168.200.250 DNS
Info
*
* Standard query AAAA www.polito.it
(192.168.200.250)
Il segmento catturato num. 6 è un pacchetto ipv6.
No. Time
Source
Destination
Protocol
7 11.294271 192.168.200.250 192.168.200.12 DNS
Info
*
* Standard query response A 130.192.73.1
(192.168.200.12)
29
No. Time
Source
Destination
Protocol
8 11.295864 192.168.200.250 192.168.200.12 DNS
Info
*
* Standard query response CNAME web01.polito.it
(192.168.200.12)
I tre pacchetti successivi (9, 10 e 11) rappresentano la three-way handshake.
No. Time
Source
Destination
9 11.296119 192.168.200.12 130.192.73.1
Protocol
TCP
Info
*
* 35614 > 80 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=4294893864
TSER=0 WS=2
(130.192.73.1)
Transmission Control Protocol, Src Port: 35614 (35614), Dst Port: 80 (80), Seq: 0, Ack:
0, Len: 0
No. Time
Source
10 11.297401 130.192.73.1
Destination
Protocol
192.168.200.12 TCP
Info
*
* 80 > 35614 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0
TSER=0
(192.168.200.12)
1, Len: 0
30
No. Time
Source
Destination
11 11.297430 192.168.200.12 130.192.73.1
Protocol
TCP
Info
*
* 35614 > 80 [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV=4294893866 TSER=0
(130.192.73.1)
1, Len: 0
Il pacchetto num. 12 contiene la richiesta (GET) HTTP di connessione
al sito www.polito.it; dalle INFO possiamo dedurre che la connessione è di
tipo persistente (1.1) mentre se fosse stata non persistente avremmo letto 1.0.
No. Time
Source
Destination
12 11.297678 192.168.200.12 130.192.73.1
Protocol
HTTP
Info
GET / HTTP/1.1
(130.192.73.1)
1, Len: 351
Hypertext Transfer Protocol
7
Protocollo RIP
Per visualizzare mediante ethereal solo i pacchetti di interesse si è provveduto
a inserire come filtro ′′ rip′′ .
La versione utilizzata è stata esclusivamente RIP v2 in cui l’annuncio delle
tabelle di routing viene effettuato con i seguenti indirizzi di destinazione:
. livello mac: 01:00:5E:00:00:09 che è un’indirizzo multicast in quanto
compreso nel range di indirizzi [01:00:5E:00:00:00 ÷ 01:00:5E:7F:FF:FF];
. livello ip: verso 224.0.0.9 che è un indirizzo di multicast, conosciuto solo dai router che implementano RIP v2 , anzichè inviare le informazioni
in broadcast al fine di non far elaborare traffico inutile agli host.
L’aggiornamento delle informazioni avviene ad intervalli regolari di circa 30
secondi.
Riportiamo i campi di un pacchetto RIP catturato:
31
No. Time
Source
Destination
14 9.495861 192.168.200.12 224.0.0.9
Protocol
RIPv2
Info
Response
.
Arrival Time: Jun 12, 2009 16:52:27.362838000
.
Time delta from previous packet: 0.487824000 seconds
.
Time since reference or first frame: 9.495861000 seconds
.
Frame Number: 14
.
Packet Length: 106 bytes
.
Capture Length: 106 bytes
.
Protocols in frame: eth:ip:udp:rip
Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 01:00:5e:00:00:09
.
Destination: 01:00:5e:00:00:09 (01:00:5e:00:00:09)
.
Source: 00:0b:6a:cf:04:c6 (00:0b:6a:cf:04:c6)
.
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.200.12 (192.168.200.12), Dst Addr:
(224.0.0.9)
.
Version: 4
.
Header length: 20 bytes
.
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
.
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.
.... ..0. = ECN-Capable Transport (ECT): 0
.
.... ...0 = ECN-CE: 0
.
Total Length: 92
.
Identification: 0x0000 (0)
.
Flags: 0x04 (Don’t Fragment)
.
0... = Reserved bit: Not set
.
.1.. = Don’t fragment: Set
.
..0. = More fragments: Not set
.
Fragment offset: 0
.
Time to live: 1
.
Protocol: UDP (0x11)
.
Header checksum: 0x10d3 (correct)
.
Source: 192.168.200.12 (192.168.200.12)
.
Destination: 224.0.0.9 (224.0.0.9)
.
Source port: 520 (520)
.
Destination port: 520 (520)
.
Length: 72
.
Checksum: 0xcc8e (correct)
32
224.0.0.9
Routing Information Protocol
.
Command: Response (2)
.
Version: RIPv2 (2)
.
Routing Domain: 0
.
Authentication: Simple Password
.
Authentication type: Simple Password (2)
.
Password: g3
.
IP Address: 172.16.2.0, Metric: 1
.
Address Family: IP (2)
.
Route Tag: 0
.
IP Address: 172.16.2.0 (172.16.2.0)
.
Netmask: 255.255.255.192 (255.255.255.192)
.
Next Hop: 0.0.0.0 (0.0.0.0)
.
Metric: 1
.
IP Address: 172.16.3.0, Metric: 1
.
Address Family: IP (2)
.
Route Tag: 0
.
IP Address: 172.16.3.0 (172.16.3.0)
.
Netmask: 255.255.255.224 (255.255.255.224)
.
Next Hop: 0.0.0.0 (0.0.0.0)
.
Metric: 1
Commenti:
a differenza di RIP v1 , in questa versione si può notare nel payload del
pacchetto un campo riservato all’autenticazione; essa avviene mediante password che deve essere univoca per tutti i router della subnet.
7.1
Comportamenti in caso di guasti
Una volta scollegato un cavo in modo tale da spezzare l’anello della rete
come si vede in figura 14 e interrompere il ping verso un’interfaccia abbiamo
notato che RIP è in grado di ripristinare la connettività della rete in un
intervallo di tempo superiore a 180 secondi dopo che le tabelle di routing
sono scadute.
33
Quando nel ping compare il messaggio Network unreachable come riportato in figura 13 l’informazione relativa a quella destinazione non è ancora
scaduta tuttavia risulta inutilizzabile; nell’istante in cui la connettività viene ripristinata le informazioni presenti nella routing table sono relative al
nuovo stato della rete.
Riportiamo un esempio di output delle tabelle di routing:
34
Figura 13: output comando ping durante un guasto
35
Figura 14: configurazione rete
36

Relazione Laboratorio di reti telematiche

Transcript

Documenti analoghi

Wireless Network Esercitazioni

8E4510, FW41IP5-U01 8E4511, FW42IP16-U01

la scelta “essenziale” per il comfort geldof b0186 s3 src

CATEGORIE - COURSE JEUN ES

promozione solari

Corso di Reti II Materiale del corso

Scheda pdf

Internet e i suoi servizi

Reti di computer ed Internet - Università degli Studi di Milano