Tecniche Di Detection e Avoidance Dei Loop Di Rete e Possibili Evoluzioni

Universit degli studi dellAquila
Facolt di Scienze Matematiche, Fisiche e Naturali

Corso di laurea in Informatica I Livello
TESI DI LAUREA
TECNICHE DI DETECTION ED AVOIDANCE DEI LOOP DI RETE E POSSIBILI EVOLUZIONI
Candidato Massimiliano FERMO
Relatore Prof.ssa Dajana CASSIOLI
Anno Accademico 2009-2010
Quante peripezie e quante fatiche mi hai aiutato ad affrontare. Questo lavoro modesto a confronto, ma quanto posso dedicarti, cara Antonella.
Sommario
Introduzione ..................................................................................................................................1 Capitolo 1: Dal canale condiviso al canale dedicato ........................................................................3 La nascita di Ethernet.................................................................................................. 3 Lo Spanning Tree Protocol .......................................................................................... 9 Alternative allo Spanning Tree Protocol .................................................................... 11 Capitolo 2: Il loop di rete.............................................................................................................. 12 Sistema con due switch ed assenza di loop................................................................ 14 Sistema con due switch e presenza di loop................................................................ 19 Caso di studio di una rete con hub ............................................................................ 27 Capitolo 3: il sistema di unlooping................................................................................................ 28 La sticky forwarding table ......................................................................................... 28 Laumento di prestazioni........................................................................................... 31 Implementazione...................................................................................................... 32 Ipotesi di procedure di test ....................................................................................... 41 Conclusioni ............................................................................................................... 46 Bibliografia .................................................................................................................................. 47 Indice analitico ............................................................................................................................ 48 Indice delle figure ........................................................................................................................ 49 Indice dei listati ........................................................................................................................... 49
Introduzione
Introduzione
I sistemi informativi sono presenti in ogni ambito della nostra vita, privata e lavorativa. La loro utilit trae origine dalla quantit dinformazioni contenuta, dalla velocit di estrazione e dalla fruibilit nel tempo e nel luogo. I sistemi di telecomunicazioni hanno permesso, nella loro evoluzione da veicolo di voce a trasporto di dati, una diffusione enorme dei sistemi informativi, consentendo di utilizzarli in luoghi diversi dalla loro ubicazione fisica. Nel 1967 il ricercatore Lowrence Roberts pubblic il progetto complessivo dellARPAnet, un sistema di calcolatori interconnessi impiegato da un organo militare statunitense. Son state queste le basi per la nascita di Internet ed in generale di tutti i sistemi di telecomunicazione, oggi definiti reti di computer, tra calcolatori. In quei tempi le reti erano pensate per la loro estensione geografica soltanto, data la scarsissima diffusione di calcolatori. Ma labbassamento dei costi di produzione dei calcolatori, quindi la loro maggiore diffusione, ha spinto la richiesta di loro interconnessione anche in ambiti locali. Di tutti i sistemi di telecomunicazione oggi disponibili alla collettivit, questo studio valuta quello delle reti Ethernet, in particolare degli apparati posti tra calcolatori, quelli che rendono possibile la costituzione di una rete detta locale. Tali reti sono caratterizzate da apparati attivi, detti genericamente concentratori, che, tramite cablaggi (detti apparati passivi) o segnali radio, raggiungono ogni calcolatore per farli comunicare reciprocamente. La disponibilit, intesa come rapporto tra la quantit di tempo che i calcolatori hanno erogato i servizi ed il tempo totale trascorso, una quantit numerica che dipende molto dalla medesima misura operata sui concentratori ed i cablaggi che li interessano. possibile aumentare la disponibilit degli apparati attivi inserendo elementi ridondati, in modo tale da surrogarsi reciprocamente in caso di fallimento di una componente. Diventa per necessario, a tal punto, stabilire metodi di arbitrazione del lavoro prodotto dagli apparati e della eventuale commutazione tra gli elementi in produzione e quelli in resilienza.
1
Introduzione
Nel seguito, approfondiremo una proposta di variazione tecnologica di ridondanza di cablaggio tra apparati attivi, studiando il comportamento che questi ultimi possono avere quando fallisca una linea che li connette e si debba commutare verso una via alternativa esistente.
Capitolo 1: Dal canale condiviso al canale dedicato

I sistemi di rete Ethernet sembrano, ad oggi, essersi affermati come la pi diffusa tecnologia impiegata per la costituzione delle reti locali di computer. Sino a una quindicina di anni fa, difatti, i tentativi di diversificazione e lutilit per i produttori di tecnologie di far fruttare gli investimenti in ricerca hanno sostenuto lofferta di suoi concorrenti, quali Token Ring, FDDI, ATM ed altre minori. Ma la fortissima semplicit di Ethernet, rispetto alle tecnologie concorrenti, ed unaccorta sostituzione delle porzioni critiche della stessa, lhanno reso vincente commercialmente. La forza commerciale ha ridotto quasi totalmente la ricerca di evoluzioni prestazionali delle altre forme di rete locale, sancendone lobsolescenza gi con lofferta dei 100 Mbps, oggi diventati 10 Gbps, velocit questultima disponibile sul mercato ordinario al prezzo di alcune centinaia di euro per porta. La comprensione di questa proposta tecnica beneficia di una sintetica descrizione di quanto avvenuto in quasi quarantanni di storia dellEthernet, permettendo anche di capirne alcuni limiti ed in particolare quello in cui si innester questa proposta di miglioria.
La nascita di Ethernet
Le reti Ethernet hanno avuto origine evolvendo il protocollo ALOHAnet veicolato su cavo coassiale grazie ai perfezionamenti di Metcalfe, sin dal 1973. Le parti pi interessanti ed innovative di ALOHA sono: 1. il media condiviso (nella fattispecie letere, poi il cavo coassiale); 2. la libert di spedire quando le stazioni ne necessitano (multiplexing statistico), eventualmente ritrasmettendo le porzioni di non confermata ricezione; 3. la lunghezza dellinformazione scambiata, fissa perch il messaggio scisso in entit atomiche di trasmissione; 4. lassegnazione di un indirizzo diverso ad ogni stazione.
3
Lefficienza pari a modesto.
18% della banda nominale (KUROSE, et al., 2002), valore senzaltro
La principale causa va rintracciata nella libert di trasmissione (ALOHAnet puro non controlla se il canale libero prima di spedire dati), che porta a troppo frequenti conflitti nelloccupazione del media. La legge osservata dai tentativi di spedizione segue una distribuzione poissoniana, caratterizzata con lassunto di un numero infinito di stazioni ed un processo di arrivo dei pacchetti nelle stazioni quantitativamente piccolo. (PATTAVINA, 2007) Ricordiamo che la distribuzione poissoniana la legge di quantit casuali X che rappresentano il numero di successi su un numero molto grande di prove ripetute indipendenti, in ciascuna delle quali la probabilit di successo molto piccola. (BALDI, 1992) In altre parole, la distribuzione di Poisson esprime le probabilit per il numero di eventi che si verificano successivamente ed indipendentemente in un dato intervallo di tempo, sapendo che mediamente se ne verifica un numero (Dis10). Successivamente Metcalfe fond lazienda 3Com e fece consorziare Digital Equipment Corporation (DEC), Intel e Xerox per la costituzione delle specifiche della Ethernet a 10 Mbps su canale condiviso vincolato (cavo coassiale), poi standardizzate dallistituto IEEE con il nome IEEE 802.3. Essa era, come ancora oggi , caratterizzata da: 1. le stazioni in rete sono univocamente identificate, secondo la specifica IEEE MAC-48, da un indirizzo imposto in fabbrica sulladattatore di rete (EthIANA), cio lindirizzo MAC (Medium Access Control), normalmente composto da 6 byte, di cui i tre pi significativi (OUI Organisationally Unique Identifier) rappresentano lidentificativo del costruttore del dispositivo ed i tre meno significativi (NIC Network Interface Controller specific) sono un valore diverso per ogni pezzo costruito;
MSB LSB
I/G Indirizzo di destinazione U/L Origine dellindirizzo della scheda
Figura 1: Importanza di alcuni bit nellindirizzamento 802.3 a livello MAC-SAP. Sul cavo viaggia prima il LSB. (GAI, et al.)
2. laccesso al media casuale ma con una politica di rilevamento delleventuale conflitto trasmissivo nel canale ad opera di stazioni concorrenti, chiamata Carrier Sense Multiple Access with Collision Detection (CSMA/CD). Il conflitto trasmissivo, cio la situazione in cui due o pi stazioni cercano di trasmettere in uno stesso intervallo di tempo su un media condiviso, per cui gli impulsi elettromagnetici od ottici interferiscono fra loro, viene definito collisione (GAI, et al.), ed questa una situazione idealmente da eliminare. Grazie a tale metodo, le stazioni raggiungono unefficienza raddoppiata a quella di ALOHAnet puro, quindi pari a ROSS).

37% della banda nominale (KOUROSE &
La schedulazione della ritrasmissione in base ad un tempo di attesa pseudocasuale evita che, dopo una collisione, le stesse stazioni che l'hanno generata ritrasmettano contemporaneamente; il tempo di attesa determinato da un algoritmo di back-off detto truncated binary exponential backoff (pi semplicemente backoff esponenziale). Il ritardo un multiplo intero dello slot time (512 bit, cio 51,2 ms per 10 Mbps) preso come tempo base, e all'n-esimo tentativo di ritrasmissione il numero di tempi base r da attendere scelto casualmente nell'intervallo 0 r < 2k, dove k = min (n,10). (GAI, et al.) Tale conflitto tanto pi frequente quanto pi sono le stazioni presenti sullo stesso segmento di rete (per questo motivo esiste un limite massimo di host e/o di mutue minime distanze per ogni tipologia di media). Losservazione del comportamento statistico delle stazioni, con la non esaltante efficienza prima descritta, e la forte probabilit di guasti causata dalle componenti meccaniche che pongono in rete le stazioni (un unico cavo per tutto il segmento, la presenza dei tappi terminatori agli estremi, gli adattatori a T per la derivazione di una nuova stazione, etc.), ha spinto la ricerca verso la soddisfazione dellesigenza di creare partizioni di una rete condivisa per isolare il traffico, quindi le collisioni, ed i guasti. Il pi semplice partizionamento rappresentato dalla creazione di due tronchi di rete connessi da un dispositivo definito bridge trasparente, il quale opera adattamenti elettrici ed effettua calcoli sullintestazione di livello II del pacchetto (il MAC SAP Service Address Protocol), quindi sullindirizzo della stazione (o delle stazioni) destinataria.
5
La logica di un bridge valuta se la stazione mittente e quella destinataria (nel caso di unicast, cio quelli destinati soltanto ad un nodo) giacciono entrambe sullo stesso tronco (grazie ad una tabella in memoria definita forwarding table, anche detta CAM Content Addressable Memory table: in tal caso il bridge non svolge lavoro, altrimenti questi copia il pacchetto dal ramo mittente al ramo destinatario, cio quello su cui giace la stazione destinataria. Nel caso di broadcast o di assenza nella tabella di avanzamento del MAC destinatario avviene sempre la copia del pacchetto al segmento non mittente. Con questo approccio si ottiene, come effetto collaterale positivo, che in caso di guasto elettrico di uno dei due tronconi, laltro continui a lavorare indisturbato, poich il bridge non propaga i disturbi elettrici bens soltanto i pacchetti di cui riesca a calcolarne correttamente la destinazione. Un ulteriore importantissimo passo avanti stato compiuto dalla valutazione che il cavo binato telefonico , per ampiezza di banda, sufficientemente surdimensionato alle esigenze della banda base (Lez10) a codifica Manchester di Ethernet (PATTAVINA, 2007) a 10 Mbps, anche grazie a connettorizzazione pi affidabile. Di conseguenza, levoluzione tecnologica (Net10) ha portato alla modifica topologica delle reti da bus (su cavo coassiale sbilanciato Thick RG-50 o Thin RG-58) a stella (su cavo multicoppia a segnale bilanciato), rendendo possibile lisolamento per guasto addirittura della singola stazione, oltre a permettere lintroduzione di fibre ottiche al posto di cavi in rame. La topologia a stella stata permessa dallincremento del numero di porte dei bridge, affinch raggiungessero il rapporto 1:1 con le stazioni, queste ultime poste, di conseguenza, su domini di collisione distinti. Si noti che, con tale tecnica, il broadcast passa definitivamente da condizione elettrica a condizione logica. Quindi, un bridge con tante porte quante siano le stazioni e distinti collegamenti per ogni coppia (nodo, porta) incrementa lefficienza, consentendo il parallelismo delle conversazioni tra i nodi posti su porte diverse, ed isola soltanto le stazioni guaste, senza propagare i problemi elettrici, ed anche alcuni logici, ad altri nodi. Tale tipo di bridge trasparente prende il nome di switch.
anche possibile estendere il raggio (cio la distanza fisica tra due nodi) connettendo in cascata due o pi switch (con alcuni limiti qui non discussi), creando un grafo anzich una stella (un albero nella teoria dei grafi). Uno switch effettua flooding (Flo10), cio inondazione con uno o pi pacchetti su tutte le porte tranne la mittente, quando (Cisco): 1) ritrasmette un broadcast di livello 2 ricevuto; 2) ritrasmette un pacchetto di cui non conosce la porta del MAC di destinazione, nel caso di destinazione unicast; 3) trasmette un pacchetto multicast. Inoltre, occorre notare che esiste un ulteriore caso (MAC10): 4) lo switch ha la forwarding table piena (MIRZA AHMAD, et al., 2004). Questo comportamento, conservativo ai fini degli indirizzi MAC, per la principale causa di problemi quando interconnettiamo apparati attivi generando cicli (sequenza di archi adiacenti in cui il nodo di partenza coincide con il nodo di arrivo) su cui tali pacchetti proseguono la strada a tempo indeterminato.
La figura seguente mostra una corretta applicazione dei cavi dinterconnessione degli apparati attivi:
Figura 2: situazione corretta di collegamento tra apparati e sua rappresentazione matematica
Invece, nel seguito, mostriamo una scorretta applicazione dei cavi dinterconnessione, che porta la rete ad essere assimilabile ad un grafo generico anzich ad un albero:
Figura 3: situazione negativa di collegamento tra apparati e sua rappresentazione matematica
Con la situazione della Figura 3, allarrivo di un broadcast negli apparati attivi Sa o Sb si raggiunge velocemente una saturazione del loro backplane. Si supponga che Ha4 generi un broadcast. Allora Sa deve consegnare tale pacchetto su tutte le porte tranne la mittente. Tramite una di tali porte, ad esempio il Link 2, il pacchetto in questione raggiunge Sb, il quale ha lo stesso obbligo di consegnare a tutti tranne alla porta mittente. Quindi Sb, oltre a consegnare agli host Hb1, Hb2 ed Hb3, rispedir il pacchetto (il broadcast di Ha4 ancora in vita!) anche sul Link 1, poich connesso ad una porta come le altre stazioni. Sa, dal canto suo, deve compiere il suo dovere: consegnare un broadcast a tutte le porte tranne a quella mittente. Ripetendo il processo dallinizio, Sa ed Sb si rimpalleranno allinfinito (poich non c metodica che faccia convergere) lo stesso pacchetto di broadcast, sino a riempire il backplane e a non lasciare spazio ai pacchetti che gli host Ha[14] e Hb[13] vogliano spedire; infatti questi troveranno sempre una collisione, come vedremo nel seguito. La situazione di collasso rappresentata dalla figura seguente, dove le frecce rosse rappresentano uno dei tragitti possibili dei broadcast:
8
Figura 4: saturazione degli apparati a causa dei broadcast e sua rappresentazione matematica
Giova evidenziare che se gli apparati attivi, oppure i link, fossero in numero maggiore di due, la situazione sarebbe identica: semplicemente si andrebbe ancor prima al collasso della rete.
Lo Spanning Tree Protocol

Nel 1985 la ricercatrice americana Radia Joy Perlman, al tempo in servizio presso la Digital Equipment Corporation (DEC), formul un software basato sugli algoritmi del Minimo Albero Ricoprente di Dijkstra e di Kruskal che, con modifiche, divenne standard IEEE allinterno del documento IEEE 802.1D; nel 1998 fu evoluto dallalgoritmo Rapid Spanning Tree Protocol (RSTP) ratificato col nome IEEE 802.1w. Lo STP provvede a risolvere il problema del flooding, in quanto elide le linee ridondanti disattivandole, permettendo quindi al traffico di avere sempre ununica strada su cui fluire. Lo stesso protocollo, per, rimane vigile sulla situazione dei link garantendo che il fallimento dellunico canale attivo tra gli apparati attivi sia recuperato con la riattivazione di qualcuno dei canali precedentemente posti in fermo amministrativo.
Figura 5: Lo Spanning Tree seleziona i percorsi dalla periferia alla radice ed i loro supplenti (HUCABY, 2005)
Lo STP, spegnendo i collegamenti che generano i cicli, garantisce lassenza di ritorno di pacchetti legati al flooding, perch la consegna a tutte le porte tranne la mittente avverr sempre sullunico link attivo del momento. per possibile ipotizzare uno scenario diverso, in cui gli switch siano oculati nella scelta delle porte di ascolto dei flooding.
10
Alternative allo Spanning Tree Protocol

Qualche produttore ha tentato di affrontare il problema del flooding misurando la quantit di broadcast per porta e confrontandola con un valore massimo di soglia: al raggiungimento di tale soglia la porta viene bloccata amministrativamente. Di fatto questo metodo, dai pi definito broadcast storm control, sembra risolvere il problema poich disabilita la porta su cui transitano pi broadcast, quindi quella che partecipa al loop. Ma, al fattore positivo di risoluzione del problema, questo metodo accomuna alcuni aspetti negativi: 1. la porta bloccata non viene riattivata mai. Occorre spegnere lapparato anche nel caso in cui il loop sia stato rimosso; 2. la politica non standard, quindi non pubblica e ben documentata; 3. la politica non si basa sul colloquio tra i dispositivi, quindi c il rischio che due apparati adiacenti, soprattutto se dotati di identico algoritmo, possano, nello stesso istante, porre in blocco le porte fra loro complementari, isolando la rete e generando due tronconi autonomi.
11
Capitolo 2: Il loop di rete

Lanalisi di un sistema di rete Ethernet che entri in stallo per la vulnerabilit del loop pu essere compiuta mediante sonde poste in rete presso qualunque nodo della rete stessa. Difatti, dato che gli apparati attivi operano flooding, si avr che ogni dominio di broadcast verr inondato di tutti i pacchetti di broadcast stessi. Per volont progettuale, uno switch genera un solo dominio di broadcast e tanti domini di collisione quante sono le porte. Questo comportamento porta allimpossibilit di catturare il traffico quando non sia diretto alla sonda. Pertanto, salvo il caso in cui la sonda stessa non sia esplicitamente mittente o destinataria, essa potr ascoltare solo i broadcast. Nel seguito, vedremo comunque delle tecniche per catturare anche il traffico unicast. La metodica seguita in questo studio impiega una coppia di sonde costituite dalle due stazioni, connesse agli switch, in cui stato montato un software di sniffing, cio capace di copiare tutto il traffico che arriva sul segmento di connessione alla rete. stato impiegato il prodotto Wireshark (Wir10), gi in passato noto con il nome Ethereal. Una delle due sonde stata anche impiegata per generare il traffico, il quale stato rilevato da entrambi gli sniffer. Per la generazione del traffico sono stati valutati i seguenti prodotti di categoria Packet forging tool, tutti opensource: 1) Scapy (http://www.secdev.org/projects/scapy/); 2) Packeth (http://packeth.sourceforge.net/); 3) Packit (http://www.intrusense.com/software/packit, prima http://packit.sourceforge.net/); 4) Nemesis (http://nemesis.sourceforge.net/). La scelta caduta su Nemesis in quanto un prodotto molto semplice, nella struttura come anche nellutilizzo, che non ha avuto difficolt nel generare pacchetti anche difettati contenenti esclusivamente PDU di livello 2.
12
Difatti, i software di questa categoria normalmente si rapportano alle system call del kernel che, non di rado, prevede che un pacchetto abbia delle qualit almeno sintattiche. Il kernel di Linux offre due modalit di generazione: layer 2 , tramite le syscall PF PACKET, PF RAW, pfopen(), libdnet, etc.; layer 3, le cui syscall sono sostanzialmente PF INET/SOCK RAW.
Molti prodotti non riescono a spedire pacchetti che difettino di una delle due sezioni, per cui li forgiano andando a completare alcuni campi lasciati vuoti dallutente ed effettuando sostituzione di valori illegali da questi forniti. Tale comportamento, per, conduce ad un incremento della complessit ed alla dipendenza potenziale dal sistema operativo, inquinando lanalisi che mira allo studio dei soli switch. Il sistema operativo a supporto dei predetti software Linux kernel 2.6.30.9 i686 nella distribuzione backtrack 4, eseguito su due computer portatili identici dotati di interfaccia Ethernet in rame Intel(R) PRO/1000, pilotata da driver v. 0.3.3.4-k4. Con la situazione topologia mostrata nella figura seguente, sono state eseguite le generazioni e le catture del traffico.
Figura 6: Ambiente di misura
Salvo diversa indicazione, le catture qui riportate sono state compiute dalla sonda soltanto ricevente e non dalla stazione iniettante.
13
Occorre anche evidenziare che gli apparati attivi impiegati sono layer 2 soltanto.
Sistema con due switch ed assenza di loop

La necessit di valutare con rigore scientifico ha generato lesigenza di analizzare il comportamento delle due stazioni in assenza di loop, ad evitare che elementi insiti nei sistemi operativi o protocolli negli apparati attivi fossero presenti nelle rilevazioni. Prima delliniezione dei pacchetti stata compiuta losservazione per almeno trenta minuti delleventuale rumore di fondo rappresentato da pacchetti non da noi sintetizzati, ma non stata rilevata alcuna voce catturata in entrambe le sonde. Questo implica che i sistemi operativi delle sonde e gli switch stessi non generano traffico non sollecitato. Per verificare che i sistemi lavorino come atteso, stato creato un traffico di quattro broadcast, come fosse un segnale rosa, regolarmente rilevati senza duplicazioni da entrambe le sonde. Il comando di generazione, lanciato quattro volte, stato: nemesis ethernet d eth0 M ff:ff:ff:ff:ff:ff T 2048 P dummy.txt Esso genera un pacchetto di broadcast con indirizzo destinatario MAC FF:FF:FF:FF:FF:FF (M ff:ff:ff:ff:ff:ff), un tipo IP di pacchetto Ethernet (-T 2048) ed un payload. Il primo file posto in payload (P dummy.txt) contiene 48 spazi, uno NewLine, uno EoF e serve a completare il pacchetto per raggiungere i 64 byte. I successivi payload son stati volutamente accorciati di un byte per osservare se gli apparati lavorassero anche con dimensioni inferiori al limite minimo ammesso dallo standard. La cattura la seguente:
14
MAC
MAC
Tabella multipla 1: cattura di broadcast senza loop No. 1 Time 0.000000 Source Toshiba_7c:1d:4d
mittente
Destination Broadcast
destinatario
Protocol Info IP Bogus IP header length
(0, must be at least 20)
Frame 1
(64 bytes on wire, 64 bytes captured)
Arrival Time: Nov 27, 2010 15:29:38.727696000

[Time delta from previous captured frame: 0.000000000 seconds] [Time delta from previous displayed frame: 0.000000000 seconds] [Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1 Frame Length: 64 bytes Capture Length: 64 bytes

[Frame is marked: False] [Protocols in frame: eth:ip]
[Coloring Rule Name: Broadcast] [Coloring Rule String: eth[0] & 1] Ethernet II, Src: Toshiba_7c:1d:4d (00:23:18:7c:1d:4d), Dst: Broadcast
(ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ...1 .... .... .... .... = IG bit: Group address
(multicast/broadcast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: Toshiba_7c:1d:4d (00:23:18:7c:1d:4d) Address: Toshiba_7c:1d:4d (00:23:18:7c:1d:4d) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version: 2 Header length: 0 bytes (bogus, must be at least 20) payload 0000 0010 0020 0030 ff ff ff ff ff ff 00 23 18 7c 1d 4d 08 00 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a .......#.|.M.. .
15
MAC
MAC
mittente
No. 2 Time 7.111731 Source Toshiba_7c:1d:4d Destination Broadcast
destinatario
Protocol Info IP Bogus IP header length
(0, must be at least 20)
Frame 2
Arrival Time: Nov 27, 2010 15:29:45.839427000 [Time delta from previous captured frame: 7.111731000 seconds] [Time delta from previous displayed frame: 7.111731000 seconds] [Time since reference or first frame: 7.111731000 seconds] Frame Number: 2 Frame Length: 64 bytes Capture Length: 64 bytes [Frame is marked: False] [Protocols in frame: eth:ip] [Coloring Rule Name: Broadcast] [Coloring Rule String: eth[0] & 1] Ethernet II, Src: Toshiba_7c:1d:4d (00:23:18:7c:1d:4d), Dst: Broadcast
(multicast/broadcast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: Toshiba_7c:1d:4d (00:23:18:7c:1d:4d) Address: Toshiba_7c:1d:4d (00:23:18:7c:1d:4d) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version: 2 Header length: 0 bytes (bogus, must be at least 20)
payload
.......#.|.M.. .
0000 0010 0020 0030
ff ff ff ff ff ff 00 23 18 7c 1d 4d 08 00
20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a
16
MAC
MAC
mittente
destinatario
Protocol Info IP Bogus IP header length (0, must be at least 20)
Frame 3
payload
0000 0010 0020 0030 ff ff ff ff ff ff 00 23 18 7c 1d 4d 08 00
20 20
.......#.|.M.. .
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a
17
MAC
MAC
mittente
destinatario
Frame 4
payload
.......#.|.M.. .
0000 0010 0020 0030
20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a
18
Sistema con due switch e presenza di loop

Allattivazione del secondo link ed in assenza di pacchetti iniettati da una delle stazioni, non stato catturato alcun pacchetto. Successivamente, si proceduto con la generazione di tre pacchetti col medesimo comando visto prima, ma per distinguere i broadcast duplicati stato anche scelto un pattern di riempimento diverso. Il primo pacchetto stato duplicato 6344 volte in 0.070315000 secondi, il secondo 4351 volte in 0,048275 secondi ed il terzo 5580 volte in 0,061979 secondi. La cattura, riportante soltanto i tre capostipiti e gli ultimi di ognuno dei pacchetti duplicati, la seguente:
19
MAC
MAC
Tabella multipla 2: cattura di broadcast con loop No. 1 Time

0.000000
mittente
destinatario
Source Toshiba_7c:1d:4d
Frame 1
(ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast) .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default) Source: Toshiba_7c:1d:4d (00:23:18:7c:1d:4d) Address: Toshiba_7c:1d:4d (00:23:18:7c:1d:4d) .... ...0 .... .... .... .... = IG bit: Individual address (unicast) .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol Version: 2 Header length: 0 bytes (bogus, must be at least 20)
payload
.......#.|.M.. .
0000 0010 0020 0030
20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a
20

MAC MAC
mittente
destinatario
n-mo PACCHETTO NON GENERATO DA NOI, IDENTICO AL N 1

No. 6344 Time 0.070315 Source Toshiba_7c:1d:4d Destination Broadcast Protocol Info IP Bogus IP header length (0, must be at least 20)
Frame 6344
payload
.......#.|.M.. .
0000 0010 0020 0030
20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 0a
21

MAC MAC
mittente
destinatario
No. 6345
Time
158.357562
Frame 6345
payload
.......#.|.M.. dummy1
0000 0010 0020 0030
20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 64 75 6d 6d 79 31
22
MAC
MAC
mittente
destinatario
n-mo PACCHETTO NON GENERATO DA NOI, IDENTICO AL N 6345

No. 10695 Time
158.405837000
Frame 10695
payload
.......#.|.M.. dummy1
0000 0010 0020 0030
20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 64 75 6d 6d 79 31
23

MAC MAC
mittente
destinatario
No. 10696
Time
222.312268
Frame 10696
payload
.......#.|.M.. dummy1
0000 0010 0020 0030
20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 64 75 6d 6d 79 31
24
MAC
MAC
mittente
destinatario
n-mo PACCHETTO NON GENERATO DA NOI IDENTICO AL N 10696

No.
16275
Time
222.374247
Frame 16275
payload
.......#.|.M.. dummy1
0000 0010 0020 0030
20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 64 75 6d 6d 79 31
La rete, in condizioni normali di lavoro ed in presenza di loop, cessa di erogare servizi, poich gli apparati attivi rifiutano in tutto o parte laccettazione, di conseguenza linoltro, di pacchetti costituenti traffico utile per lutente e provenienti dalle stazioni di lavoro.
25
Spieghiamo ora le prove eseguite per dimostrarlo. Ogni stazione di lavoro, a causa dei servizi software che esegue, genera fisiologiche quantit di broadcast (client DHCP, network node discovery, etc.) che si sommano ai broadcast che il loop amplifica quantitativamente. La prima attivit stata quella di porre gli switch Sa1 ed Sb1 in loop mediante doppio collegamento: in un qualunque intervallo di 5 secondi sono stati catturati circa 500'000 pacchetti. Sulla macchina Ha1, che esegue MS Windows 7 Professional, stata impostata una voce statica di ARP table per lo host Hb1, ad evitare che la risoluzione IP/MAC fosse alla base della mancanza del servizio: arp -s 192.168.127.30 00-23-18-6d-1d-4d Poi, nella medesima macchina, stato comandato un ping (reiterato illimitatamente) verso lo host di destinazione Hb1, che esegue BackTrack4: ping -t 192.168.127.30 Nel contempo, nella macchina destinazione Hb1 stato comandato un ping (reiterato illimitatamente) verso lo host Ha1, dopo laccreditamento ARP: arp -s 192.168.127.10 00-23-26-8C-7F-69 ping 192.168.127.10 La cattura dei pacchetti stata compiuta su un terzo host Ha2, posto in ascolto sullo switch Sa1, ed stata bloccata dopo 7'655'486 pacchetti. Vediamo in dettaglio.
26
Ping da Ha1 a Hb1 Dei 67 pacchetti ICMP che Ha1 riuscito a spedire, 61 sono scaduti e solo 6 hanno avuto la Risposta da 192.168.127.10: Host di destinazione non raggiungibile.. Si precisa che tale risposta significa che non ci sono rotte locali o remote per lo host di destinazione secondo il mittente od il router di pertinenza. Occorre quindi risolvere il problema nella tavola di routing dello host o del router. (How10) Altro tipo di risposta riscontrata tre volte lErrore generale, che ha origine nel firewall di Windows (ICM10). Ping da Hb1 a Ha1 Dei 313 pacchetti ICMP trasmessi in 5 minuti c.ca, solo 9 hanno ricevuto risposta, seppur quasi sempre disordinata temporalmente. Il tempo medio occorso ad una risposta stato di 66,2 secondi.
Caso di studio di una rete con hub

Occorre segnalare che, nel caso in cui sia presente un hub al posto di uno switch, anche i pacchetti di tipo unicast vanno in loop infinito. Ci dovuto al fatto che il comportamento di un hub , per sua definizione, quello di effettuare flooding. Questa topologia, se corretta eliminando il doppio collegamento tra gli apparati, rappresenta una modalit per compiere sniffing di unicast non indirizzati alla stazione ricevente. Ripetendo le prove svolte con due switch, si ottiene analogo risultato ma con loop infinito, cio gli apparati non riescono mai a convergere eliminando le ripetizioni del pacchetto originale. Lo hub, inoltre, attiva in modo continuo il led di segnalazione di collisione.
27
Capitolo 3: il sistema di unlooping

possibile incrementare lintelligenza dellapparato attivo, senza per dover necessariamente invocare una logica microprogrammata come nello STP, affinch capisca che un pacchetto proviene dallunione di un flooding e di un loop di rete. Altro obiettivo di questa proposta di evitare che gli apparati attivi scambino tra loro informazioni di controllo, pur restando il sistema generale autocorrettivo. Lesigenza di evitare comunicazioni inter-switch necessaria per non rientrare nelle strutture tipiche degli apparati a logica microprogrammata, molto pi complessi e costosi da produrre.
La sticky forwarding table

La deducibilit di tale condizione gi insita nella tabella di forwarding dellapparato il quale, in fase di learning, ha appreso che un certo indirizzo MAC fisicamente collocato su una porta; di conseguenza, la presenza del medesimo MAC su porta diversa necessariamente generata da un ritorno di un pacchetto gi inoltrato. Uno switch tradizionale sostituirebbe la porta relativa al MAC da quella originale alla nuova dove viene visto il pacchetto di ritorno. Nella soluzione prospettata, invece, faremo persistere la porta (comportamento che definiremo sticky forwarding table) al fine di evitare che la tabella non riporti unassociazione MAC-porta che rappresenti la realt topologica. Studiamo il comportamento temporale della soluzione, tralasciando al momento che, nella realt, per ogni entry della tabella ci sia unindicazione di vecchiaia dellassociazione MAC-porta (MAC ageing), cio un valore per Tmax calcolato diversamente da come vogliamo proporre con questo studio.
28
Lo switch Sa, appena acceso oppure appena connesso allhost, riceve almeno un pacchetto (di livello 2 indifferentemente unicast o broadcast) sulla porta P1, pertanto arricchisce la propria forwarding table dellindirizzo MAC di Ha1:
Tempo t0 Porta # Sa.1 Sa.21 Sa.22 MAC Ha1 Porta # Sb.1 Sb.21 Sb.22 MAC
Figura 7: Situazione al tempo t0
Tempo t1 Porta # Sa.1 Sa.21 Sa.22

MAC Ha1
Porta # Sb.1 Sb.21 Sb.22
MAC Hb1 Ha1
Allistante t2, troveremo le tabelle di forwarding cos compilate:

MAC Ha1 Hb1
MAC Hb1 Ha1
29
Uno dei punti chiave (lo stickiness) della soluzione proposta valuta il comportamento al tempo t3. Tramite i collegamenti inter-switch, arriveremo al punto di ricevere sullo switch Sa i pacchetti dagli host raggiunti da Sb e viceversa. A quel punto avverr il conflitto di porta per uno stesso MAC:

MAC Ha1 Hb1 Hb1
MAC Hb1 Ha1 Ha1
La proposta progettuale, ribadiamo, di vietare la registrazione di un MAC su una diversa porta, per una quantit Tmax di tempo se tale MAC gi presente in tabella. Nella tabella Tempo t3 mostrato che avremmo dovuto registrare in Sa il MAC di Hb1 sulla porta Sa.22 e, su Sb, il MAC di Ha1 sulla porta Sb.21. Ma tale associazione non dovr avvenire nella nostra soluzione fino allo scadere del tempo Tmax. Proseguendo nellanalisi, arriveremo al tempo t4, che mostra come andremo avanti nelle operazioni ordinarie di switching. Dallistante t4 in poi dovremo, ogni qual volta giunga un broadcast su una porta entrante Px, cercare lindirizzo MAC sorgente di tale broadcast nella tavola di forwarding e verificare se P x = P y. Allora potremo affermare che questo broadcast un nuovo broadcast proveniente da un host e non il precedente che ancora circoli in rete, quindi va inoltrato. La situazione avvelenata, invece, sarebbe con un broadcast entrante sulla porta Px e nella tavola di forwarding lindirizzo MAC mittente compaia come ubicato sulla porta Py, con xy:
30

MAC Ha1 Hb1
MAC Hb1 Ha1
Laumento di prestazioni
I cambiamenti di topologia, dovuti a spegnimento o isolamento intempestivo di link ed apparati, portano il traffico, allo scadere del tempo Tmax, verso i link rimanenti. Inoltre, grazie al multiplexing statistico relativo allaccesso al link, abbiamo che anche gli apparati attivi stessi scambiano i dati consegnati loro da ogni host, sui collegamenti scelti, con distribuzione statistica secondo la porta che risponde prima per il MAC destinatario in fase di learning. Qualora il cambiamento di topologia mostri un recupero dello status quo-ante, nuovamente, allo scadere del tempo Tmax, il MAC riattivato potr giungere sulla porta di uplink che impiegava prima del distacco. Si rileva, quindi, che i canali inter-switch saranno impiegati tutti, seppur senza un algoritmo deterministico che preveda le quantit di traffico da destinarsi ad ognuno, come accade nel protocollo Link Aggregation Protocol, standard IEEE 802.3ad, od in quello proprietario Cisco EtherChannel. Questi protocolli, nuovamente, richiedono la collaborazione tra apparati, in quanto si basano sul protocollo Link Aggregation Control Protocol (LACP) il primo, PAgP il secondo.
31
Implementazione
Il sistema di switching proposto andr realizzato e verificato modificando il comportamento ordinario di un apparato attivo genericamente presente in commercio. In questo modo, interconnettendolo in una rete in produzione, saremmo in grado di compiere valutazioni qualitative e quantitative sul comportamento dello stesso per la validazione del modello. Tutti gli apparati in commercio sono basati su tre tecnologie fondamentali (KUROSE, et al., 2002): 1) Commutazione in memoria, ove il passaggio tra la porta sorgente e quella destinataria fornito dalla copia del pacchetto in memoria RAM dalla locazione che mappa la porta mittente alla locazione relativa alla porta destinataria; 2) Commutazione tramite bus, ove tutte le porte comunicano su un bus condiviso; 3) Commutazione tramite crossbar, basata su una matrice che implementa il prodotto cartesiano tra le porte, ponendo su una dimensione il segnale entrante e sullaltra il segnale uscente.
Figura 12: le tre tecniche di commutazione (KUROSE, et al., 2002)
32
In ognuna di queste tecnologie, i produttori realizzano chip ASIC per aumentare la velocit di commutazione, evitando quindi di specializzare macchine general purpose, oltre che per implementare il processore di controllo, che deve effettuare le ricerche nella tabella di forwarding. Ma la creazione e realizzazione di chip attivit onerosa, ingiustificabile per un elemento sperimentale qual il nostro. In parte lattivit sperimentale potrebbe utilizzare la capacit di alcuni apparati, soprattutto indirizzata a fini di sicurezza, di caricare in modo statico gli indirizzi MAC nelle porte. Questo metodo non per sufficiente a riprodurre un caso di test del comportamento di un apparato Unlooped, poich abbiamo che non gestibile linvecchiamento dellassociazione MAC-porta, necessario nella nostra proposta (por10). Introduciamo alcuni schemi progettuali della soluzione Unlooped. Concentrandosi sul livello II dello stack, occorre lavorare su alcuni membri del seguente flusso:
33
Figura 14: manage (MAC, port) association ageing
Figura 13: viaggio di un pacchetto in un generico switch layer II
34
Si noti che lageing, normalmente valutato 5 minuti (Cisco), trattato dai costruttori in modo predefinito, quando lapparato sia di fascia bassa, o impostabile, ma su valori statici, per apparati programmabili. In uno switch Unlooped, una delle differenze dagli switch tradizionali riguarda proprio la gestione dei tempi dinvecchiamento dellassociazione (MAC, porta). Altra importante differenza che non sono ammessi traboccamenti della tabella di forwarding, in quanto sarebbe impossibile rispettare la propriet sticky della coppia (MAC, porta):
35
Figura 16: manage Unlooped (MAC, port) association ageing
Figura 15: viaggio di un pacchetto in uno switch Unlooped layer II
36
Una proposta progettuale per affrontare tale caso quella di gettar via i pacchetti per cui non esista spazio disponibile nella forwarding table. Oppure andrebbe dotato lo switch Unlooped di una quantit di memoria idonea a contenere tutti i teoricamente possibili 248 indirizzi MAC, quindi 256 Tera-parole da 48 bit ognuna, cosa ovviamente impossibile. A riferimento, si prenda un esempio reale di un apparato commercialmente disponibile quale lo switch di fascia media HP ProCurve 4208vl (J8773A), in cui la dimensione del packet buffer di 36 MB. Lo pseudo-codice necessario ad implementare il precedente algoritmo Unlooped lavora sostanzialmente sulla tabella di forwarding, concettualmente un dizionario che associa allindirizzo MAC (la chiave) la porta ove il MAC raggiungibile (linformazione della chiave). Inoltre, per consentire la rimozione dei MAC scaduti, il dizionario avr unulteriore informazione: il riferimento al nodo della lista che contiene i timestamp, un valore rappresentante il tempo darrivo del MAC nello switch dalla porta registrata. Il dizionario andr realizzato con particolare riguardo alle prestazioni (ad esempio, riprendendo lesempio del modello HP ProCurve 4208vl (J8773A), abbiamo che commuta fino a 48 milioni di pacchetti al secondo e 76,8 Gbps!), quindi potremo scegliere dimplementarlo con un albero binario di ricerca.
Id
1 2 3 n
MAC address
MAC 1 MAC 2 MAC 3 MAC n
Port #
P1 P1 P7 Pm
Timestamp
-> node 3 -> node 2 -> node 4
-> node 1
Tabella 3: tavola di forwarding
37
Il timestamp sar realizzato con una lista doppiamente concatenata, che sar naturalmente ordinata mediante operazioni di append ed agevoler la rimozione di un vecchio timestamp per un MAC gi trattato. La lista avr, in supporto, i riferimenti al primo nodo (quello temporalmente pi anziano), allultimo nodo (quello temporalmente pi giovane) ed allultimo nodo ancora valido rispetto al massimo tempo di vita Tmax di un timestamp, indicato con LAT (Last Alive Timestamp).
Figura 17: lista dei timestamp dei pacchetti
Nella pagina seguente riportato lo pseudo-codice del nucleo di uno switch Unlooped.
38

Listato 1: pseudocodice del nucleo di uno switch Unlooped
INPUT: forwardingTable:BST whose node is composed of fields: MAC (the key), port_id (an attribute), ts_ref (another attribute) ageingList: double chained list whose node is composed of fields: ts, entry_id (the row number in forwardingTable), previous (reference to a node just older next (reference to a node just younger), LAT (reference to oldest alive timestamp node as seen in last evaluation), tail (reference to the youngest timestamp). The ageingList pointer references the oldest filed timestamp. packet: the packet fetched from a physical port of the switch
WHILE true DO { looping = FALSE FOR (portIndex = 0, portIndex++; portIndex < maxAvailablePorts) { packet = fetch_packet (portIndex) drop_packet = FALSE IF ( availableRoom(forwardingTable) { IF ( (portNumber = find(forwardingTable, packet->sourceMAC)) == NULL) { entry_id = insert (forwardingTable, packet->sourceMAC, portNumber) ts_ref = append (ageingList, now(), entry_id) alter (forwardingTable, entry_id, ts_ref) } ELSE { IF (portNumber == portIndex) { current_id = find_entry_id(forwardingTable, packet->sourceMAC) ts_ref = append (ageingList, now(), entry_id) remove_ts ( current_id->ts_ref) alter (forwardingTable, current_id, ts_ref) } ELSE { drop_packet = TRUE looping = TRUE } } } ELSE { drop_packet = TRUE }
//not enough room for new packet's MAC //it's a looped packet! //get the current row in forwardingTable for the MAC //create a new node in ageing list //remove previous timestamp //links the timestamp to the (MAC, port) couple //enough memory in forwarding table and timestamp list? //it's the 1st packet seen from this MAC //create a new (MAC, port) association //create a new node in ageing list
//links the timestamp to the (MAC, port) couple //MAC already registered
39
IF NOT drop_packet { IF (multicast (packet) OR broadcast (packet)) { send_flooding (packet) } ELSE { findDstPort (packet) send (packet) } } } IF looping refreshTmax() }
40
Ipotesi di procedure di test

Il caso di studio pu essere realizzato anche mediante una soluzione software, anzich in logica cablata, ovviamente penalizzando le prestazioni. Unipotesi di lavoro fornita dal codice sorgente delle utilit di bridging presenti nel kernel di Linux a partire dal 2003. In realt esisteva gi una prima implementazione di prova nella versione 2.2, ma la versione effettivamente utilizzabile quella disponibile a partire dal kernel 2.4. Tale sistema consente di accreditare pi schede Ethernet (le porte dello switch) ad un apparato virtuale (il backplane dello switch), il quale avr anche la capacit di implementare lo Spanning Tree Protocol nella versione originale (ad oggi non ancora supportata levoluzione Rapid Spanning Tree Protocol). Ovviamente, tutto possibile a patto che, per la ricezione da host a switch, le interfacce Ethernet accreditate allo switch virtuale lavorino in modalit promiscua e che, per la trasmissione da switch a host, la scheda Ethernet duscita supporti il MAC spoofing. Si noti che il trattamento di un pacchetto compiuto nei vari livelli dello stack TCP/IP, per eseguire demultiplexing al fine della consegna del payload al giusto processo software, ma una porzione non trascurabile di verifiche ed eliminazioni anche compiuta dagli strati relativi alla sicurezza, quindi dai sistemi di filtraggio dei pacchetti di livello II come ebtables, bridge-nf, arptables, etc., e dai firewall per i livelli III e IV, come iptables, etc.. Tutto il lavoro di commutazione dei pacchetti tra la porta sorgente e la/e porta/e destinataria/e viene materialmente realizzato spostando le frame, contenute in istanze della struttura sk_buff, pi comprensibilmente definita socket buffer. Nel seguito riportata la definizione della struttura sk_buff, come presente nel file linux2.6.36/include/linux/skbuff.h (righe 316-418):
41

Listato 2: definizione della struttura sk_buff
/** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * struct sk_buff - socket buffer @next: Next buffer in list @prev: Previous buffer in list @sk: Socket we are owned by @tstamp: Time we arrived @dev: Device we arrived on/are leaving by @transport_header: Transport layer header @network_header: Network layer header @mac_header: Link layer header @_skb_refdst: destination entry (with norefcount bit) @sp: the security path, used for xfrm @cb: Control buffer. Free for use by every layer. Put private vars here @len: Length of actual data @data_len: Data length @mac_len: Length of link layer header @hdr_len: writable header length of cloned skb @csum: Checksum (must include start/offset pair) @csum_start: Offset from skb->head where checksumming should start @csum_offset: Offset from csum_start where checksum should be stored @local_df: allow local fragmentation @cloned: Head may be cloned (check refcnt to be sure) @nohdr: Payload reference only, must not modify header @pkt_type: Packet class @fclone: skbuff clone status @ip_summed: Driver fed us an IP checksum @priority: Packet queueing priority @users: User count - see {datagram,tcp}.c @protocol: Packet protocol from driver @truesize: Buffer size @head: Head of buffer @data: Data head pointer @tail: Tail pointer @end: End pointer @destructor: Destruct function @mark: Generic packet mark @nfct: Associated connection, if any @ipvs_property: skbuff is owned by ipvs @peeked: this packet has been seen already, so stats have been done for it, don't do them again @nf_trace: netfilter packet trace flag @nfctinfo: Relationship of this skb to the connection @nfct_reasm: netfilter conntrack re-assembly pointer union { __wsum struct { __u16 __u16 csum_start; csum_offset; csum; __u16 unsigned int len, data_len; mac_len, hdr_len; #ifdef CONFIG_XFRM struct #endif sec_path *sp; unsigned long _skb_refdst; /* * This is the control buffer. It is free to use for every * layer. Please put your private variables there. If you * want to keep them across layers you have to do a skb_clone() * first. This is owned by whoever has the skb queued ATM. */ char cb[48] __aligned(8); struct sock struct net_device *dev; *sk; ktime_t tstamp; struct sk_buff { struct sk_buff struct sk_buff /* These two members must be first. */ *next; *prev; * * * * * * * * * * * */ @nf_bridge: Saved data about a bridged frame - see br_netfilter.c @skb_iif: ifindex of device we arrived on @rxhash: the packet hash computed on receive @queue_mapping: Queue mapping for multiqueue devices @tc_index: Traffic control index @tc_verd: traffic control verdict @ndisc_nodetype: router type (from link layer) @dma_cookie: a cookie to one of several possible DMA operations done by skb DMA functions @secmark: security marking @vlan_tci: vlan tag control information
42

}; }; #ifdef CONFIG_IPV6_NDISC_NODETYPE __u8 ndisc_nodetype:2, deliver_no_wcard:1; __u32 priority; #else __u8 #endif deliver_no_wcard:1;
kmemcheck_bitfield_begin(flags1); __u8 local_df:1, cloned:1, ip_summed:2, nohdr:1, nfctinfo:3; __u8 pkt_type:3, fclone:2, ipvs_property:1, peeked:1, nf_trace:1; kmemcheck_bitfield_end(flags1); __be16 protocol;
kmemcheck_bitfield_end(flags2);
/* 0/14 bit hole */
#ifdef CONFIG_NET_DMA dma_cookie_t #endif dma_cookie;
#ifdef CONFIG_NETWORK_SECMARK __u32 #endif secmark;
void
(*destructor)(struct sk_buff *skb); union {
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE) struct nf_conntrack *nfct; struct sk_buff #endif __u16 #ifdef CONFIG_BRIDGE_NETFILTER struct nf_bridge_info #endif *nf_bridge; *nfct_reasm; };
__u32 __u32
mark; dropcount;
vlan_tci;
sk_buff_data_t sk_buff_data_t sk_buff_data_t
transport_header; network_header; mac_header; */
int
skb_iif;
/* These elements must be at the end, see alloc_skb() for details. sk_buff_data_t tail; end; *head, *data;
#ifdef CONFIG_NET_SCHED __u16 tc_index; /* traffic control index */
sk_buff_data_t unsigned char
#ifdef CONFIG_NET_CLS_ACT __u16 #endif tc_verd; /* traffic control verdict */ };
unsigned int atomic_t users;
truesize;
#endif
__u32
rxhash;
kmemcheck_bitfield_begin(flags2); __u16 queue_mapping:16;
43
Generalizzando lanalisi sulle strutture utilizzate nellambito Ethernet/switching, abbiamo che la struttura sk_buff viene creata, modificata e distrutta almeno dalle seguenti relazioni:
44
Figura 18: relazioni di un socket buffer sk_buff nel kernel 2.6.20 (ker10)
45
Conclusioni
Questa tesi ha prodotto unipotesi di soluzione al problema dei cicli nelle topologie di rete, oltre a unanalisi comportamentale e prestazionale degli switch commerciali quando trattino broadcast ed unicast. Per lanalisi, stato necessario creare un ambiente di misura hardware e software, con cui stato mostrato che i pacchetti si ripetono anche svariate migliaia di volte. La tecnica risolutrice proposta da questo studio pone laccento sulle semplicit progettuali, realizzative ed implementative, quindi sulleconomicit di produzione e di esercizio, anche alla luce della considerazione che sarebbe sufficiente applicare un numero di dispositivi ridotto rispetto a quelli necessari a generare una rete, in quanto non occorre che tutti gli switch siano dotati di Unlooping. Pi in dettaglio, il caso migliore quello in cui la topologia degli apparati sia una lista concatenata, pertanto, essendo questultima 2-colorabile (T.H. CORMEN, 1994), sar sufficiente porre apparati tradizionali intervallati ad apparati Unlooped. Il caso peggiore, invece, prevede che per qualunque coppia di nodi (cio switch) adiacenti, almeno un apparato sia elemento Unlooped. Ulteriormente, rispetto allo Spanning Tree Protocol, la soluzione gode anche dei vantaggi economici e prestazionali di utilizzare tutti i collegamenti inter-switch esistenti, evitando di disabilitare le linee ridondanti.
46
Bibliografia
802.1D-2004. IEEE. [Online] [Riportato: 24 12 2010.] http://standards.ieee.org/getieee802/download/802.1D-2004.pdf. BALDI, Pietro. 1992. Calcolo delle probabilit e statistica. s.l. : McGraw-Hill Italia, 1992. Cisco. Catalyst 6500/6000 Switches ARP or CAM Table Issues Troubleshooting - Cisco Systems. Cisco Systems. [Online] [Riportato: 14 12 2010.] http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00807347ab.shtml . . Transparent Bridging - DocWiki. DocWiki. [Online] [Riportato: 21 11 2010.] http://docwiki.cisco.com/wiki/Transparent_Bridging. Distribuzione di Poisson. Wikipedia italiano. [Online] [Riportato: 14 11 2010.] it.wikipedia.org/wiki/Distribuzione_di_Poisson.htm. Ether Types. IANA. [Online] [Riportato: 14 12 2010.] http://www.iana.org/assignments/ethernet-numbers. Flooding. en.wikipedia.org. [Online] [Riportato: 19 11 2010.] http://en.wikipedia.org/wiki/Flooding. GAI, Silvano, MONTESSORO, Pier Luca e NICOLETTI, Pietro. Reti locali: dal cablaggio strutturato all'internetworking. L'Aquila : S.S.G.R.R. How to troubleshoot TCP/IP connectivity with Windows XP. Microsoft Product Support Specialist. [Online] [Riportato: 28 11 2010.] http://support.microsoft.com/kb/314067. HUCABY, David. 2005. CCNP BCMSN Exam Certification Guide, 3rd edition. s.l. : Cisco Press, 2005. ICMP_ECHO_REPLY Structure (Windows). MSDN. [Online] [Riportato: 28 11 2010.] http://msdn.microsoft.com/en-us/library/aa366053%28VS.85%29.aspx. kernel_flow. The Linux Foundation. [Online] [Riportato: 03 12 2010.] http://www.linuxfoundation.org/tags/networking/kernel_flow. KUROSE, James F. e ROSS, Keith W. 2002. Reti di calcolatori ed Internet - Un approccio top-down. s.l. : Addison Wesley, 2002. Lezioni di Reti di telecomunicazione 1. Universit di Genova - Dipartimento di Informatica, Sistemistica e Telematica. [Online] [Riportato: 28 11 2010.] http://www.reti.dist.unige.it/reti/Reti1/ParteII/Reti_20.pdf. MAC flooding. en.Wikipedia.org. [Online] [Riportato: 21 11 2010.] http://en.wikipedia.org/wiki/MAC_flooding. MIRZA AHMAD, David R., et al. 2004. Hack proofing - seconda edizione. s.l. : McGraw-Hill, 2004. 47
Network Computing | Feature | Network Computing's 10th Anniversary | Top 10 Products: Number 5 | October 2, 2000 - Network Computing. Network Computing. [Online] [Riportato: 27 11 2010.] http://www.networkcomputing.com/1119/1119f1products_5.html. PATTAVINA, Achille. 2007. Reti di telecomunicazione - Networking e Internet (seconda edizione). Milano : McGraw-Hill, 2007. PERLMAN, Radia. 1999. Interconnections, Second Edition: Bridges, Routers, Switches, and Internetworking Protocols. Boston : Addison Wesley, 1999. port security - The Cisco Learning Network. The Cisco Learning Network. [Online] [Riportato: 14 12 2010.] https://learningnetwork.cisco.com/message/66665. Spanning Tree Protocol. Wikipedia Inglese. [Online] http://en.wikipedia.org/wiki/Spanning_tree_protoco. T.H. CORMEN, C.E. LEISERSON, R.L. RIVEST. 1994. Introduzione agli algoritmi - Vol. III. s.l. : Jackson libri, 1994. Wireshark - Go deep. Wireshark. [Online] [Riportato: 27 11 2010.] http://www.wireshark.org/.
Indice analitico
802.3ad ............................................................31 ageing ..............................................................28 ALOHAnet...........................................................3 apparati attivi.....................................................1 apparati passivi ..................................................1 arptables ..........................................................41 backoff esponenziale ..........................................5 bridge trasparente..............................................5 bridge-nf...........................................................41 broadcast storm control....................................11 CAM Content Addressable Memory table............6 cicli .....................................................................7 collisione.............................................................5 Commutazione in memoria ...............................32 Commutazione tramite bus...............................32 Commutazione tramite crossbar .......................32 concentratori ......................................................1 CSMA/CD............................................................5 distribuzione poissoniana ...................................4 ebtables............................................................41 EtherChannel....................................................31 Ethereal ............................................................12 flooding ............................................................. 7 forwarding table ................................................ 6 IEEE 802.1D ....................................................... 9 IEEE 802.1w ....................................................... 9 IEEE 802.3.......................................................... 4 iptables.............................................................41 LACP .................................................................31 Link Aggregation Control Protocol.....................31 Link Aggregation Protocol .................................31 MAC SAP............................................................ 5 MAC-48 ............................................................. 4 sk_buff..............................................................41 sniffing .............................................................12 sticky forwarding table .....................................28 switch ................................................................ 6 timestamp ........................................................37 unicast............................................................... 6 Wireshark .........................................................12
48
Indice delle figure

Figura 1: Importanza di alcuni bit nellindirizzamento 802.3 a livello MAC-SAP. Sul cavo viaggia prima il LSB. (GAI, et al.) .................................................................................................................................................. 4 Figura 2: situazione corretta di collegamento tra apparati e sua rappresentazione matematica ................... 7 Figura 3: situazione negativa di collegamento tra apparati e sua rappresentazione matematica .................. 8 Figura 4: saturazione degli apparati a causa dei broadcast e sua rappresentazione matematica................... 9 Figura 5: Lo Spanning Tree seleziona i percorsi dalla periferia alla radice ed i loro supplenti (HUCABY, 2005) ...................................................................................................................................................................10 Figura 6: Ambiente di misura ......................................................................................................................13 Figura 7: Situazione al tempo t0..................................................................................................................29 Figura 8: Situazione al tempo t1..................................................................................................................29 Figura 9: Situazione al tempo t2..................................................................................................................29 Figura 10: Situazione al tempo t3 ................................................................................................................30 Figura 11: Situazione al tempo t4 ................................................................................................................31 Figura 12: le tre tecniche di commutazione (KUROSE, et al., 2002)..............................................................32 Figura 13: viaggio di un pacchetto in un generico switch layer II..................................................................34 Figura 14: manage (MAC, port) association ageing......................................................................................34 Figura 15: viaggio di un pacchetto in uno switch Unlooped layer II..............................................................36 Figura 16: manage Unlooped (MAC, port) association ageing......................................................................36 Figura 17: lista dei timestamp dei pacchetti ................................................................................................38 Figura 18: relazioni di un socket buffer sk_buff nel kernel 2.6.20 (ker10) ....................................................45
Indice dei listati

Listato 1: pseudocodice del nucleo di uno switch Unlooped..................................................................... 39 Listato 2: definizione della struttura sk_buff ............................................................................................ 42
49
In tutta sincerit, credo che per qualunque sforzo della vita anche direttamente ascrivibile a noi dai pi, difficilmente si possa ritenere che si sia gli unici a compierlo: avere consigli tecnici da qualcuno che ha competenza per questi uno sforzo, concedere unassenza dal lavoro uno sforzo per chi rimane, ascoltarci in un momento di debolezza uno sforzo, amore, affetto e stima son sentimenti rari, caricarsi delle questioni pratiche della vita quotidiana sforzo fisico e dedizione, aiutare in un impegno finanziario sforzo e fiducia, negare il tempo alla propria famiglia per le attivit grande comprensione e condivisione di obiettivi. Questi bei sentimenti, ed altri, io ho ed avuto la fortuna di viverli tutti. Spero di saperli restituire. Per questo vi debbo ringraziare Antonella, Pierina ed Ugo, Raffaella e Lelio, Massimo e Maura, Stefano ed Egle, Maurizio, Rodolfo e Cinzia, Ildebrando, Wladimiro, Sergio, Fabrizio, Angelo, Luciano, Domenico, Nicola, Gaetano, Stefano, Damian, Loris, Mario, Gaspare, Massimo, Stefano, Fabrizio, Sandra.
Aiutateci da l, Mario, Andrea, Ugo e Roberto.
Max

Tecniche Di Detection e Avoidance Dei Loop Di Rete e Possibili Evoluzioni

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tecniche Di Detection e Avoidance Dei Loop Di Rete e Possibili Evoluzioni

Caricato da

Copyright:

Formati disponibili

Universit degli studi dellAquila

Facolt di Scienze Matematiche, Fisiche e Naturali

TECNICHE DI DETECTION ED AVOIDANCE DEI LOOP DI RETE E POSSIBILI EVOLUZIONI

Candidato Massimiliano FERMO

Relatore Prof.ssa Dajana CASSIOLI

Anno Accademico 2009-2010

Capitolo 1: Dal canale condiviso al canale dedicato

Capitolo 1: Dal canale condiviso al canale dedicato

Capitolo 1: Dal canale condiviso al canale dedicato

Lefficienza pari a modesto.

18% della banda nominale (KUROSE, et al., 2002), valore senzaltro

I/G Indirizzo di destinazione U/L Origine dellindirizzo della scheda

Capitolo 1: Dal canale condiviso al canale dedicato

37% della banda nominale (KOUROSE &

Capitolo 1: Dal canale condiviso al canale dedicato

Capitolo 1: Dal canale condiviso al canale dedicato

Figura 2: situazione corretta di collegamento tra apparati e sua rappresentazione matematica

Capitolo 1: Dal canale condiviso al canale dedicato

Figura 3: situazione negativa di collegamento tra apparati e sua rappresentazione matematica

Capitolo 1: Dal canale condiviso al canale dedicato

Lo Spanning Tree Protocol

Capitolo 1: Dal canale condiviso al canale dedicato

Capitolo 1: Dal canale condiviso al canale dedicato

Alternative allo Spanning Tree Protocol

Capitolo 2: Il loop di rete

Capitolo 2: Il loop di rete

Capitolo 2: Il loop di rete

Figura 6: Ambiente di misura

Capitolo 2: Il loop di rete

Sistema con due switch ed assenza di loop

Capitolo 2: Il loop di rete

(0, must be at least 20)

(64 bytes on wire, 64 bytes captured)

Arrival Time: Nov 27, 2010 15:29:38.727696000

Frame Number: 1 Frame Length: 64 bytes Capture Length: 64 bytes

Capitolo 2: Il loop di rete

(0, must be at least 20)

(64 bytes on wire, 64 bytes captured)

0000 0010 0020 0030

Capitolo 2: Il loop di rete

(64 bytes on wire, 64 bytes captured)

Capitolo 2: Il loop di rete

(64 bytes on wire, 64 bytes captured)

0000 0010 0020 0030

Capitolo 2: Il loop di rete

Sistema con due switch e presenza di loop

Capitolo 2: Il loop di rete

Tabella multipla 2: cattura di broadcast con loop No. 1 Time

(64 bytes on wire, 64 bytes captured)

0000 0010 0020 0030

Capitolo 2: Il loop di rete

n-mo PACCHETTO NON GENERATO DA NOI, IDENTICO AL N 1

(64 bytes on wire, 64 bytes captured)

0000 0010 0020 0030

Capitolo 2: Il loop di rete

Protocol Info IP Bogus IP header length (0, must be at least 20)

(63 bytes on wire, 63 bytes captured)

0000 0010 0020 0030

Capitolo 2: Il loop di rete

n-mo PACCHETTO NON GENERATO DA NOI, IDENTICO AL N 6345

Protocol Info IP Bogus IP header length (0, must be at least 20)

(63 bytes on wire, 63 bytes captured)

0000 0010 0020 0030

(destructor)(struct sk_buff skb); union {