Relazione Laboratorio di reti telematiche

Transcript

1 Relazione Laboratorio di reti telematiche Djatsa Yota Eric Matricola n Fiandrino Claudio Matricola n Giacchè Diego Matricola n Nfonte Mandje Fouapon Abdou Cassimou Matricola n Ricci Marco Matricola n

2 Indice 1 Configurazione 3 2 Protocollo ARP Tabella di arp Aggiornamento della tabella di arp Host Inesistente ma nella stessa subnet Host inesistente e in subnet diversa Durata delle entry nella tabella Consegna diretta e risoluzione di indirizzi: il protocollo ARP Diagramma temporale Round Trip Time Commando ping con dimensione applicativa piccola Comportamenti in caso di perdità di connetività Perdità temporanea di connetività Velocità di collegamento Grafici Cattura e analisi di protocollo di livello trasporto/applicazione Analisi sequence number, receiver window e lunghezza segmenti trasmessi Sequence number Receiver window Lunghezza segmenti trasmessi Misure di prestazioni 20 6 Operazioni verso internet Comando Ping Comando Traceroute Output comando Cattura con ethereal Prova con il browser Protocollo RIP Comportamenti in caso di guasti

3 1 Configurazione Abbiamo configurato la nostra rete con indirizzi privati di classe B nel seguente modo:. indirizzo di rete ;. netmask ;. indirizzo di broadcast IP ;. indirizzo host A ;. indirizzo host B ;. indirizzo host C Protocollo ARP 2.1 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 HWtype HWaddress Flags Mask Iface ether 00:E0:4C:A0:1B:F2 C eth ether 00:50:FC:09:6C:28 C eth1 la composizione dei campi è:. 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

4 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 è 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 è 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, poichè 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 possibilità nella gestione delle arp tables è 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 è scalabile in quanto all aumentare delle dimesioni della subnet aumenterà il numero di arp request che ogni host dovrà elaborare e di conseguenza il tempo di elaborazione;. sarà necessaria più memoria visto che il numero di entry sarà 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

5 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 è 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 avrà 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 è il seguente: A controllando nella routing table vede che il destinatario è al di fuori della subnet e invia l ARP-request al default gateway, non riceve nessuna risposta neanche host unreachable perchè i pacchetti non vengono elaborati da nessun host. Nella tabella di arp sarà presente l entry con il campo indirizzo MAC destinatario incomplete. Riportiamo un output del comando ping per questo esempio: PING ( ): 56 data bytes ping statistics 2 packets transmitted, 0 packets received, 100% packet loss e la relativa tabella di arp: Address HWtype HWaddress Flags Mask Iface (incomplete) eth1 2.5 Durata delle entry nella tabella Dalle misure effettuate sull host A risulta che la durata delle entry nella tabella di arp è:. 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

6 3 Consegna diretta e risoluzione di indirizzi: il protocollo ARP 3.1 Diagramma temporale Figura 1: diagramma temporale 6

7 Indirizzi MAC di destinazione:. ARP-REQUEST broadcast (FF:FF:FF:FF:FF:FF);. ARP-REPLY unicast, verso il mittente dell ARP-REQUEST. 3.2 Round Trip Time Il round trip time (RTT) è dato da: RTT = T elaba + T propa + T TX + T elabb + T propb + T TX + T elaba = 2TTx (1) T elab : tempo di elaborazione (ipotizziamo trascurabile); T prop : tempo di propagazione (trascurabile in quanto è pari a ( d c), c velocità della luce e d distanza dell ordine dei metri); T TX : tempo di trasmissione legato alla capacità del canale T TX = Payload V TX. Il motivo per cui il primo pacchetto ICMP inviato ha un RTT chiaramente superiore rispetto a quello calcolato per i successivi pacchetti è dovuto alla necessità di ottenere il MAC del destinatario con ARP. Esempio di output: PING ( ): 56 data bytes 64 bytes from : icmp seq=0 ttl=64 time=1.4 ms 64 bytes from : icmp seq=1 ttl=64 time=0.3 ms 64 bytes from : icmp seq=2 ttl=64 time=0.3 ms 64 bytes from : icmp seq=3 ttl=64 time=0.3 ms 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 è il Round Trip Time (RTT); questo accade perchè tra le informazioni contenute nel pacchetto questa è quella meno rilevante. 7

8 3.4 Comportamenti in caso di perdità di connetività Se si perde connettività durante un operazione di ping esistono 2 possibilità: 1. nel caso in cui un certo numero di pachetti siano già arrivati all host destinatario e che quest ultimo abbia mandato le risposte corrispondenti prima della perdita di connettività 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 connettività prima dello scambio di pacchetti gli host non sono in grado di aggiornare le proprie tabelle di arp e l entry risulterà incomplete nel caso di host interni alla subnet e sarà vuota in caso di host esterni. 3.5 Perdità temporanea di connetività Se si perde connettività tra 2 host a causa del cambiamento temporaneo di un indirizzo o di un guasto sulla rete durante un ping si hanno le seguenti possibilità:. meno di 5 secondi: la sorgente continua a mandare ICMP echo request, che non avranno risposta, finchè non si recupera la connettività;. più 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 connettività è ripristinata il destinatario risponderà all ARP request e alle successive echo request;. più 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 Velocità di collegamento È possibile calcolare la velocità del collegamento di 2 host appartenenti alla stessa subnet tramite il comando ping con l utilizzo della seguente formula: V TX = S T TX con S dimensione Payload applicativo e T TX tempo di trasmissione. Poichè sappiamo dalla (1) che RTT = 2 T TX deduciamo: V TX = S RTT 2 = 2 S RTT 8

9 Per quanto riguarda i tempi di trasmissione della PDU l unico legato alla capacità del canale è il tempo è il tempo di trasmissione, come abbiamo già evidenziato nel punto Grafici 120 grafico RTT(Payload app ) RTT[ms] D [Byte] app x 10 4 Figura 2: grafico RTT in funzione del Payload applicativo Come si evince dalle formule: RTT = 2 T TX = D app V TX le due grandezze sono direttamente proporzionali tra loro linearmente. 9

10 grafico RTT(Payload app ) RTT[ms] D [Byte] 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 è 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 ( ) il segmento viene diviso in due pacchetti, altrimenti i frammenti saranno di più ogni volta che si superano: κ 1480 con κ = 2,3,

11 60 grafico Ttx(Payload app ) T tx [ms] D app [Byte] x 10 4 Figura 4: grafico T TX in funzione del Payload applicativo Questo grafico è analogo al precedente a meno di un fattore 2 dovuto a: RTT = 2 T TX 11

12 10 grafico v tx (Payload app ) v tx [Mb/s] D app [Byte] x 10 4 Figura 5: grafico V tx in funzione del Payload applicativo La velocità è anche calcolabile in ( ) byte secondo come: V TX = 2 D app RTT Si può osservare che inizialmente con valori di D app piccoli la crescita è molto alta in quanto la dimensione del payload è confrontabile con quella degli header. È possibile notare una serie di discontinuità in corrispondenza delle frammentazioni, in particolar modo la prima avviene con dimensione del payload pari a 1472 bytes. Per valori di D app grandi la velocità tende al goodput massimo, inferiore al limite teorico di 10 Mbit/s. 12

13 10 grafico v tx (Payload fis ) v tx [Mb/s] D x 10 4 fis [Byte] Figura 6: grafico V tx in funzione del Payload fisico Questo grafico è analogo al precedente ad eccezione del limite a cui la curva tende per valori di D fis alti, ovvero al throughput, che risulta essere maggiore del goodput in quanto il D fis a differenza del D app tiene conto degli header. 13

14 4 Cattura e analisi di protocollo di livello trasporto/applicazione Lo scopo di questa esercitazione è l analisi delle caratteristiche del protocollo TCP mediante l applicativo chargen. Questo servizio ha lo scopo di trasmettere una sequenza infinita di caratteri finchè la sorgente non chiude la connessione. 4.1 Analisi sequence number, receiver window e lunghezza segmenti trasmessi Sequence number Figura 7: numero sequenza client Poichè il client non deve inviare dati al server, il sequence number resta costante per tutta la durata della connessione. In realtà si possono notare 2 salti sul grafico, essi sono relativi ai pacchetti di apertura e chiusura della connessione TCP (SYN e FIN). 14

15 Figura 8: numero sequenza server Quando la connessione è stata instaurata, il server comincia a inviare pacchetti in slow start raddoppiando sempre la finestra di trasmissione finché non si riempie la receiver window del client. A questo punto il client limita la finestra di invio; ciò spiega la non linearità presente all inizio del grafico; durante il resto della connessione il sequence number cresce linearmente. Quando si digita il comando CTRL+] il client blocca il server dunque il sequence number si mantiene costante, come si può notare nella parte finale del grafico. 15

16 4.1.2 Receiver window Figura 9: receiver window del client La receiver window del client inizialmente è massima quindi il server può 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 può 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 è 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 è dovuto al fatto che, una volta ripresa la comunicazione, il client può annunciare alla sorgente receiver window con valore massimo. 16

17 Figura 10: receiver window del server Il server inizialmente dichiara una receiver window di una determinata dimensione, anche grande; poichè però non riceve nessun pacchetto di dati dal client annuncia un valore costante per tutta la durata della connessione. 17

18 4.1.3 Lunghezza segmenti trasmessi Figura 11: lunghezza pacchetti trasmessi dal client Poichè il client non invia dati alla sorgente la lunghezza dei segmenti trasmessi sarà sempre pari a 0. 18

19 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 manterrà 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

20 5 Misure di prestazioni Prova Tipo Goodput Collisioni Perdite Prev. Oss. Prev. Oss. Prev. Oss. A TCP ,2736 SI 2004 NO NO A UDP NO 0 NO NO B TCP NO 0 NO NO B UDP NO 0 NO NO C TCP TCP SI 3259 NO NO C UDP UDP SI 470 NO NO C UDP TCP SI 2389 NO NO C TCP UDP SI 2116 NO NO D TCP-TCP NO 0 NO NO D UDP-UDP NO 0 SI SI D TCP-UDP NO 0 NO NO E TCP-TCP SI 3551 NO NO E UDP-UDP NO 3 NO NO E TCP-UDP SI 2008 NO NO F TCP-TCP NO 0 NO NO F UDP-UDP NO 0 SI SI F TCP-UDP NO 0 NO NO G TCP-TCP SI 4497 NO NO G UDP-UDP SI 470 NO NO G TCP-UDP SI 2416 NO NO H TCP-TCP NO 0 NO NO H UDP-UDP NO 0 NO NO H TCP-UDP NO 0 NO NO I TCP-TCP SI 3861 NO NO I UDP-UDP SI 418 SI NO L TCP-TCP NO 0 NO NO L UDP-UDP NO 0 SI SI Tabella 1: riassunto prestazioni, valori espressi in Mbit/s 1 L host A della configurazione è il trasmettitore. Come si può notare nei casi A,B e C dove sono presenti solo 2 hosts, il goodput ottenuto con UDP è leggermente superiore a quello che si ha con TCP; questo è dovuto al fatto che TCP è un protocollo orientato alla connessione perciò prevede un traffico aggiuntivo di segnalazione e quindi degli overhead piu grandi che diminuiscono il goodput. Si può notare che con UDP il goodput peggiora significativamente nel caso 20

21 in cui si imposti, come parametro L (lunghezza del paccheto), un valore di poco superiore a 1472 byte o in generale una dimensione che generà un frammento di dimensioni paragonabili a quella degli header Ethernet+IP+TCP come spiegato nel punto in figura 3. Con TCP non c è questo problema in quanto TCP offre a IP uno stream di byte, ed è 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 perché 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 è elevato mentre quello di TCP è piutosto basso (vicino al 50%); questo è dovuto al fatto che non c è 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 poichè nella tipologia ad anello l hub, che può essere considerato come un unico canale, non è 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 possibilità. È 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

22 6 Operazioni verso internet Connettendo le diverse isole a internet esterna abbiamo provato ad eseguire alcune operazioni verso i siti internet e Comando Ping Riportiamo la cattura dei primi pacchetti sniffati con l analizzatore di protocolli ethereal verso No. Time Source Destination Protocol Info DNS Standard query A 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: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: (32792), Dst Port: 53 (53) Domain Name System (query) No. Time Source Destination Protocol Info DNS * * Standard query response CNAME CNAME A A A A Frame 2 (409 bytes on wire, 409 bytes captured) Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:d1:0c:10 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 53 (53), Dst Port: (32792) Domain Name System (response) No. Time Source Destination Protocol Info ICMP Echo (ping) request 22

23 Frame 3 (98 bytes on wire, 98 bytes captured) Ethernet II, Src: 00:0b:6a:d1:0c:10, Dst: 00:07:95:d9:2d:f7 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Internet Control Message Protocol No. Time Source Destination Protocol Info ICMP Echo (ping) reply Frame 4 (98 bytes on wire, 98 bytes captured) Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:d1:0c:10 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Internet Control Message Protocol 6.2 Comando Traceroute Output comando. Verso ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms 23

24 . Verso ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms - ru-polito-rt-to1.to1.garr.net ( ) ms ms ms - rt-to1-rt-mi2.mi2.garr.net ( ) ms ms ms - infracomna.mix-it.net ( ) ms ms ms - Milano-1-tge-3-1.ita.tip.net ( ) ms ms ms 24

25 . Verso ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms - ru-polito-rt-to1.to1.garr.net ( ) ms ms ms - rt-to1-rt-mi2.mi2.garr.net ( ) ms ms ms ( ) ms ms ms - prs-bb1-link.telia.net ( ) ms ms ms - ash-bb1-link.telia.net ( ) ms ms ms - sl-st22-ash-2-0.sprintlink.net ( ) ms ms ms - sl-bb20-dc sprintlink.net ( ) ms ms ms - sl-crs1-rly sprintlink.net ( ) ms ms ms - sl-crs2-sj sprintlink.net ( ) ms ms ms - sl-gw19-sj sprintlink.net ( ) ms ms ms ( ) ms ms ms - border2.te8-1-bbnet2.sfo002.pnap.net ( ) ms ms ms 25

26 6.2.2 Cattura con ethereal Riportiamo la cattura dei pacchetti effettuati con l analizzatore di protocolli ethereal per l operazione compiuta verso No. Time Source Destination Protocol Info DNS * *Standard query A Frame 6 (71 bytes on wire, 71 bytes captured) Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 00:07:95:d9:2d:f7 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: (32840), Dst Port: 53 (53) Domain Name System (query) No. Time Source Destination Protocol Info DNS * * Standard query response A Frame 7 (223 bytes on wire, 223 bytes captured) Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:cf:04:c6 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 53 (53), Dst Port: (32840) Domain Name System (response) No. Time Source Destination Protocol Info UDP * *Source port: Destination port: Frame 8 (52 bytes on wire, 52 bytes captured) Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 00:07:95:d9:2d:f7 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: (38090), Dst Port: (33435) Data (10 bytes) 26

27 No Time Source Destination Protocol Info ICMP * * Time-to-live exceeded (Time to live exceeded in transit) Frame 9 (70 bytes on wire, 70 bytes captured) Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:cf:04:c6 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Internet Control Message Protocol No. Time Source Destination Protocol Info DNS * * Standard query PTR in-addr.arpa Frame 10 (88 bytes on wire, 88 bytes captured) Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 00:07:95:d9:2d:f7 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: (32840), Dst Port: 53 (53) Domain Name System (query) No. Time Source Destination Protocol Info DNS * * Standard query response PTR AZIMUT2K Frame 11 (138 bytes on wire, 138 bytes captured) Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:cf:04:c6 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 53 (53), Dst Port: (32840) Domain Name System (response) Commenti: inizialmente l host richiede al DNS ( ) la traduzione del nome logico nel relativo indirizzo ip; la prima volta questa operazione è 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

28 sistema operativo (Knoppix) di default il comando traceroute utilizza pacchetti UDP con porte di destinazione comprese tra e Prova con il browser In questa sezione riportiamo la cattura di pacchetti effettuata connettendoci al sito tramite browser: No. Time Source Destination Protocol Info :0b:6a:cf:04:c6 ff:ff:ff:ff:ff:ff ARP * * Who has ? Tell Frame 3 (42 bytes on wire, 42 bytes captured) 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 Info :07:95:d9:2d:f7 00:0b:6a:cf:04:c6 ARP * * is at 00:07:95:d9:2d:f7 Frame 4 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:cf:04:c6 Address Resolution Protocol (reply) 28

29 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 nell indirizzo ip e la risposta del dns. No. Time Source Destination Protocol Info DNS * * Standard query A Frame 5 (73 bytes on wire, 73 bytes captured) Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 00:07:95:d9:2d:f7 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: (32768), Dst Port: 53 (53) Domain Name System (query) No. Time Source Destination Protocol Info DNS * * Standard query AAAA Frame 6 (73 bytes on wire, 73 bytes captured) Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 00:07:95:d9:2d:f7 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: (32769), Dst Port: 53 (53) Domain Name System (query) Il segmento catturato num. 6 è un pacchetto ipv6. No. Time Source Destination Protocol Info DNS * * Standard query response A Frame 7 (102 bytes on wire, 102 bytes captured) Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:cf:04:c6 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 53 (53), Dst Port: (32768) Domain Name System (response) 29

30 No. Time Source Destination Protocol Info DNS * * Standard query response CNAME web01.polito.it Frame 8 (143 bytes on wire, 143 bytes captured) Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:cf:04:c6 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) User Datagram Protocol, Src Port: 53 (53), Dst Port: (32769) Domain Name System (response) I tre pacchetti successivi (9, 10 e 11) rappresentano la three-way handshake. No. Time Source Destination Protocol Info TCP * * > 80 [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV= TSER=0 WS=2 Frame 9 (74 bytes on wire, 74 bytes captured) Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 00:07:95:d9:2d:f7 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Transmission Control Protocol, Src Port: (35614), Dst Port: 80 (80), Seq: 0, Ack: 0, Len: 0 No. Time Source Destination Protocol Info TCP * * 80 > [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0 TSER=0 Frame 10 (78 bytes on wire, 78 bytes captured) Ethernet II, Src: 00:07:95:d9:2d:f7, Dst: 00:0b:6a:cf:04:c6 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Transmission Control Protocol, Src Port: 80 (80), Dst Port: (35614), Seq: 0, Ack: 1, Len: 0 30

31 No. Time Source Destination Protocol Info TCP * * > 80 [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSV= TSER=0 Frame 11 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 00:07:95:d9:2d:f7 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Transmission Control Protocol, Src Port: (35614), Dst Port: 80 (80), Seq: 1, Ack: 1, Len: 0 Il pacchetto num. 12 contiene la richiesta (GET) HTTP di connessione al sito dalle INFO possiamo dedurre che la connessione è di tipo persistente (1.1) mentre se fosse stata non persistente avremmo letto 1.0. No. Time Source Destination Protocol Info HTTP GET / HTTP/1.1 Frame 12 (417 bytes on wire, 417 bytes captured) Ethernet II, Src: 00:0b:6a:cf:04:c6, Dst: 00:07:95:d9:2d:f7 Internet Protocol, Src Addr: ( ), Dst Addr: ( ) Transmission Control Protocol, Src Port: (35614), Dst Port: 80 (80), Seq: 1, Ack: 1, Len: 351 Hypertext Transfer Protocol 7 Protocollo RIP Per visualizzare mediante ethereal solo i pacchetti di interesse si è provveduto a inserire come filtro rip. La versione utilizzata è stata esclusivamente RIP v 2 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 è 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 che è un indirizzo di multicast, conosciuto solo dai router che implementano RIP v 2, anzichè 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

32 No. Time Source Destination Protocol Info RIPv2 Response Frame 14 (106 bytes on wire, 106 bytes captured). Arrival Time: Jun 12, :52: Time delta from previous packet: seconds. Time since reference or first frame: 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: ( ), Dst Addr: ( ). Version: 4. Header length: 20 bytes. Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) = Differentiated Services Codepoint: Default (0x00) = ECN-Capable Transport (ECT): = ECN-CE: 0. Total Length: 92. Identification: 0x0000 (0). Flags: 0x04 (Don t Fragment) = 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: ( ). Destination: ( ) User Datagram Protocol, Src Port: 520 (520), Dst Port: 520 (520). Source port: 520 (520). Destination port: 520 (520). Length: 72. Checksum: 0xcc8e (correct) 32

33 Routing Information Protocol. Command: Response (2). Version: RIPv2 (2). Routing Domain: 0. Authentication: Simple Password. Authentication type: Simple Password (2). Password: g3. IP Address: , Metric: 1. Address Family: IP (2). Route Tag: 0. IP Address: ( ). Netmask: ( ). Next Hop: ( ). Metric: 1. IP Address: , Metric: 1. Address Family: IP (2). Route Tag: 0. IP Address: ( ). Netmask: ( ). Next Hop: ( ). Metric: 1 Commenti: a differenza di RIP v 1, in questa versione si può 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 è in grado di ripristinare la connettività della rete in un intervallo di tempo superiore a 180 secondi dopo che le tabelle di routing sono scadute. 33

34 Quando nel ping compare il messaggio Network unreachable come riportato in figura 13 l informazione relativa a quella destinazione non è ancora scaduta tuttavia risulta inutilizzabile; nell istante in cui la connettività 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

35 Figura 13: output comando ping durante un guasto 35

36 Figura 14: configurazione rete 36