Algoritmi di routing in reti magliate wireless

  • Published on
    25-Jul-2015

  • View
    41

  • Download
    1

Embed Size (px)

Transcript

<p>POLITECNICO DI TORINO</p> <p>III Facolt di IngegneriaCorso di Laurea in Ingegneria delle Telecomunicazioni</p> <p>Monograa di Laurea</p> <p>Algoritmi di routing in reti magliate wireless</p> <p>Marco Fanti</p> <p>Supervisore Aziendale Ing. Andrea Ghittino</p> <p>Luglio 2011</p> <p>SommarioQuesto documento descrive il lavoro compiuto durante il tirocinio svolto presso il laboratorio di ricerca InLab del CSP. Il documento costituito da due parti, nella prima si spiega nel dettaglio il protocollo di routing OSPF e brevemente il protocollo OLSR, nella seconda si mostra unimplementazione pratica di un demone OSPF e di uno OLSR su una rete magliata simulata e si analizzano le prestazioni dei due protocolli. Il protocollo OLSR non stato trattato molto nel dettaglio in quanto gi stato provato a dovere in passato in questa azienda, in questo documento si proceder ad analizzarlo essenzialmente evidenziando i pregi e i difetti rispetto a OSPF.</p> <p>ii</p> <p>IndiceSommario 1 Introduzione teorica a OSPF 1.1 Protocolli Link State . . . . . . . . . . . . . . . . . . . . 1.2 Introduzione a OSPF . . . . . . . . . . . . . . . . . . . . 1.2.1 Concetto di Area . . . . . . . . . . . . . . . . . . 1.2.2 RFC di riferimento . . . . . . . . . . . . . . . . . 1.2.3 Tipi di area . . . . . . . . . . . . . . . . . . . . . 1.2.4 Tipi di nodo . . . . . . . . . . . . . . . . . . . . . 1.2.5 Contiguit dellarea Backbone . . . . . . . . . . . 1.2.6 Virtual Link . . . . . . . . . . . . . . . . . . . . . 1.2.7 Esempio di Automous System gestito con OSPF . 1.3 I pacchetti OSPF . . . . . . . . . . . . . . . . . . . . . . 1.3.1 OSPF Header . . . . . . . . . . . . . . . . . . . . 1.3.2 Pacchetto Hello . . . . . . . . . . . . . . . . . . . 1.3.3 Protocollo Hello . . . . . . . . . . . . . . . . . . . 1.3.4 Cosa sono le adiacenze . . . . . . . . . . . . . . . 1.3.5 Elezione del Designated Router e del suo Backup 1.3.6 Il database Link State . . . . . . . . . . . . . . . 1.3.7 LSA Header . . . . . . . . . . . . . . . . . . . . . 1.3.8 Router LSA . . . . . . . . . . . . . . . . . . . . . 1.3.9 Network LSA . . . . . . . . . . . . . . . . . . . . 1.3.10 Summary LSA . . . . . . . . . . . . . . . . . . . 1.3.11 AS-external LSA . . . . . . . . . . . . . . . . . . 1.3.12 LSA speciali per le aree NSSA . . . . . . . . . . . 1.3.13 Pacchetti OSPF non Hello . . . . . . . . . . . . . 1.3.14 Creazione delle adiacenze . . . . . . . . . . . . . . 1.3.15 Procedura di ooding . . . . . . . . . . . . . . . . 1.3.16 Procedura di Aging . . . . . . . . . . . . . . . . . 1.3.17 Confrontare due LSA . . . . . . . . . . . . . . . . 1.3.18 Impostazione del costo di un collegamento . . . . iii ii 1 1 1 2 2 3 4 4 5 5 5 7 7 8 8 9 9 9 10 10 11 12 12 13 13 14 16 16 16</p> <p>. . . . . . . . . . . . . . . . . . . . . . . . . . . .</p> <p>. . . . . . . . . . . . . . . . . . . . . . . . . . . .</p> <p>. . . . . . . . . . . . . . . . . . . . . . . . . . . .</p> <p>. . . . . . . . . . . . . . . . . . . . . . . . . . . .</p> <p>. . . . . . . . . . . . . . . . . . . . . . . . . . . .</p> <p>. . . . . . . . . . . . . . . . . . . . . . . . . . . .</p> <p>. . . . . . . . . . . . . . . . . . . . . . . . . . . .</p> <p>1.4</p> <p>1.3.19 Creazione delle tabelle di routing . 1.3.20 Bilanciamento del carico con OSPF 1.3.21 Considerazioni sui link virtuali . . . Considerazioni nali su OSPF . . . . . . . 1.4.1 OSPF su reti wireless . . . . . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>17 17 18 18 18 19 19 19 20 20 20 22 22 22 23 23 23 24 28 28 29 30 30 31 31 32 32 32 33 44 44 44 45 45</p> <p>2 Il protocollo di routing OLSR 2.1 Metriche ETX . . . . . . . . . . . . . . . . 2.1.1 Calcolo delle metriche ETX . . . . 2.2 Traco di rete . . . . . . . . . . . . . . . 2.3 Demone OLSR . . . . . . . . . . . . . . . 2.4 Congurazione di base del demone OLSRd 3 Implementazioni di OSPF 3.1 OpenOSPFd . . . . . . . . . . . . 3.2 BIRD . . . . . . . . . . . . . . . 3.3 XORP . . . . . . . . . . . . . . . 3.4 Quagga . . . . . . . . . . . . . . 3.4.1 Congurazione del demone 3.4.2 Congurazione del demone</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . . . . . . . . . . . . . Zebra ospfd</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>. . . . . .</p> <p>4 Realizzazione dei test 4.1 Simulatore di reti NetKit . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Installazione di Quagga e OLSRd su NetKit . . . . . . . . . . 4.2 Congurazione di OSPF per la rete del CSP . . . . . . . . . . . . . . 4.2.1 Divisione in aree . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Hello Interval e Router Dead Interval . . . . . . . . . . . . . . 4.2.3 Hello Interval e Router Dead Interval sui link virtuali . . . . . 4.3 Test su OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Traco di gestione della rete . . . . . . . . . . . . . . . . . . . 4.3.2 Tempi di reazione della rete con perdita totale dei pacchetti . 4.3.3 Tempi di reazione della rete con perdita parziale dei pacchetti 4.3.4 Tempo di formazione delle adiacenze . . . . . . . . . . . . . . 4.4 Test su OLSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.5 Congurazione del demone . . . . . . . . . . . . . . . . . . . . . . . . 4.5.1 Traco di gestione della rete . . . . . . . . . . . . . . . . . . . 4.5.2 Tempi di reazione della rete . . . . . . . . . . . . . . . . . . .</p> <p>5 Conclusioni 46 5.1 Soluzioni proposte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 iv</p> <p>A Pacchetti OSPF A.1 Pacchetti . . . . . . . . . . . . . . . . . . A.1.1 Pacchetto Hello . . . . . . . . . . A.1.2 Pacchetto Database Description . A.1.3 Pacchetto LS-Request . . . . . . A.1.4 Pacchetto LS-Update . . . . . . . A.1.5 Pacchetto LS- Acknowledgement A.2 LSA . . . . . . . . . . . . . . . . . . . . A.2.1 LSA Header . . . . . . . . . . . . A.2.2 Router LSA . . . . . . . . . . . . A.2.3 Network LSA . . . . . . . . . . . A.2.4 Summary LSA . . . . . . . . . . A.2.5 AS-External LSA . . . . . . . . . B NetKit B.1 Requisiti . . . . . . . . . . . . . . . . . . B.2 Installazione . . . . . . . . . . . . . . . . B.2.1 Congurazione post-installazione B.3 Comandi . . . . . . . . . . . . . . . . . . B.4 Creare un laboratorio . . . . . . . . . . . B.4.1 File lab.conf . . . . . . . . . . . . B.4.2 Esempio di le lab.conf . . . . . . B.4.3 Esempio di le .startup . . . . . . B.5 Trasferimento le tra macchina virtuale e</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>. . . . . . . . . . . .</p> <p>48 48 48 49 50 50 51 51 51 52 53 53 54 55 55 55 56 56 56 57 57 58 59 60 60 61 61 62 63 65</p> <p>. . . . . . . . . . . . . . . . . . . . . . . . host</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>. . . . . . . . .</p> <p>C Esempi le di congurazione Quagga C.1 File zebra.conf . . . . . . . . . . . . . . . . . . C.2 File ospfd.conf . . . . . . . . . . . . . . . . . . C.2.1 Router interno . . . . . . . . . . . . . C.2.2 Area Border Router con Link Virtuale C.2.3 AS Boundary Router interno a un area Bibliograa</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>. . . . .</p> <p>v</p> <p>Capitolo 1 Introduzione teorica a OSPFOSPF (Open Shortest Path First) un Interior Gateway Protocol in grado di garantire bassi tempi di convergenza. usato in tutto il mondo anche per reti molto grandi, come ad esempio le backbone degli ISP.</p> <p>1.1</p> <p>Protocolli Link State</p> <p>OSPF fondamentalmente un protocollo di routing dinamico di tipo Link State. Con questo nome si indicano tutti quei protocolli di routing dove ogni nodo conosce esattamente la topologia dellintero dominio di routing, ogni nodo quindi ha un database che descrive la topologia e che deve mantenersi uguale in tutto lAutonomous System. Lalgoritmo di base molto semplice e si divide in due passi eseguiti ciclicamente da ciascun nodo della rete. Prima ogni nodo raccoglie informazioni sui collegamenti a lui direttamente adiacenti, poi inoltra questi dati a tutti i nodi della rete tramite la cosiddetta procedura di ooding. Inne ogni nodo esegue lalgoritmo di Dijkstra per calcolare il percorso pi breve verso ogni destinazione, questo algoritmo considerato abbastanza pesante, ma per il momento lunico a garantire che non si formino dei loop nei percorsi di instradamento.</p> <p>1.2</p> <p>Introduzione a OSPF</p> <p>Lo svantaggio dei protocolli Link State che al cambiamento dello stato di un singolo collegamento tutti i nodi si devono rifare tutto il calcolo, e questo pu essere veramente un problema per le reti molto grandi. 1</p> <p>1 Introduzione teorica a OSPF</p> <p>1.2.1</p> <p>Concetto di Area</p> <p>OSPF si dierenzia dalla maggior parte degli algoritmi di routing Link State perch introduce un livello di gerarchizzazione nella rete permettendone la divisione in diverse aree. Ogni area composta da un insieme di collegamenti tra i nodi, non da un insieme di nodi. Questo signica che ogni nodo pu avere alcuni collegamenti appartenenti ad unarea e altri ad unaltra area. Esistono quindi nodi interni alle aree, cio con tutti i collegamenti appartenenti ad una sola area, ed altri nodi cosiddetti di bordo area. Le aree vengono identicate tramite numeri di unsigned int da 32 bit (a partire da 0), e per convenzione si usa la stessa notazione degli indirizzi IPv4. Larea 0 quindi diventa 0.0.0.0, la 1 invece 0.0.0.1 e cos via. Questa divisione del dominio di routing, se ben fatta, porta a una riduzione del carico di lavoro su ogni nodo, perch lalgoritmo di Dijkstra viene eseguito solamente allinterno delle aree. I router interni ad unarea infatti non conoscono la tipologia esterna, ma conoscono solo i costi con cui i router di bordo area possono raggiungere le varie destinazioni. In pratica il cambiamento di un costo su un collegamento causa il ricalcolo del cammino minimo con lalgoritmo di Dijkstra solo allinterno dellarea dov avvenuto. I nodi esterni allarea invece in tal caso verranno a sapere dai nodi di bordo area che cambiato il costo con cui loro raggiungono una certa destinazione, ma il carico di lavoro da fare sar molto minore. Unaltro vantaggio potenziale della divisione in aree la minore occupazione di banda causata dal traco di gestione del protocollo, per ottenere ci per bisogna sfruttare bene le tipologie di area esistenti.</p> <p>1.2.2</p> <p>RFC di riferimento</p> <p>OSPF un protocollo denito dallIETF, quindi ci sono varie RFC che descrivono lo standard le sue estensioni aggiunte negli anni. Le pi importanti sono: RFC 2328 denisce lo standard OSPFv2, nato per le reti IPv4 e largamente usato ancora oggi nella sua forma originaria[1]; RFC 2370 denisce gli Opaque LSA, per poter estendere in futuro le funzionalit di OSPF; RFC 3101 denisce il tipo di area Not-So-Stubby-Area (NSSA)[2]; RFC 5340 denisce OSPFv3, nato esplicitamente per le reti IPv6 e quindi poco utilizzato; 2</p> <p>1 Introduzione teorica a OSPF</p> <p>RFC 5614 denisce unestensione a OSPFv3 in modo che il protocollo possa supportare le reti Ad-Hoc radiomobili, un documento ancora in stato sperimentale, e non descrive tutti gli aspetti che sarebbero necessari per la sua implementazione; RFC 5838 denisce unestensione ad OSPFv3 in modo che possa essere usato anche sulle reti IPv4. Questo molto importante perch cos, quando questo RFC sar implementato, da una parte gli sviluppatori potranno concentrarsi solo su OSPFv3, dallaltra i gestori delle reti potranno usare le estensioni di OSPFv3 anche sulle loro reti IPv4. In questo documento ci concentreremo su OSPFv2 per le reti IPv4[1] che la versione maggiormente usata ai giorni nostri..</p> <p>1.2.3</p> <p>Tipi di area</p> <p>Vediamo di seguito le varie tipologie di area che si possono incontrare in un Autonomus System(AS) gestito con OSPF: Backbone anche chiamata area 0 perch ha sempre questo numero. larea che collega letteralmente tutte le altre, le quali obbligatoriamente devono avere almeno un nodo collegato a questarea. lunica area che ha lobbligo di essere sempre contigua. Tutto il traco inter-area passa almeno da un nodo che conna con la backbone. Aree normali conoscono tutte le reti raggiungibili esterne allarea, ma anche quelle esterne allAS annunciate dai nodi connanti con altri AS. I nodi interni alle aree normali possono connare con altri AS e annunciare le reti che vedono agli altri nodi OSPF. Stub in queste aree non vengono inoltrate informazioni sui costi per raggiungere destinazioni esterne allAS, ma viene pubblicizzata al posto una default route. Dentro queste aree non possono trovarsi nodi connanti con zone non gestite con OSPF. Totally Stub la tipologia consigliata quando larea ha solo un nodo di conne con la backbone, questo perch i nodi interni allarea non sanno nulla sullesterno. Ai nodi interni viene comunicata solo una default-route che deve servire per tutte le destinazioni esterne allarea. Questo pu ridurre di molto il traco. Not-So-Stubby-Area (NSSA) utilizzata quando allarea collegata una zona non gestita con OSPF, accessibile solo tramite larea in questione. Queste aree quindi possono connare con zone non gestite da OSPF, a dierenza delle stub. [2] 3</p> <p>1 Introduzione teorica a OSPF</p> <p>1.2.4</p> <p>Tipi di nodo</p> <p>Ogni nodo (o router) pu essere di vari tipi a seconda delle aree a cui appartengono i suoi collegamenti. In particolare si possono distinguere 4 tipi di router: Area-Border-Router (ABR) sono quei router che fanno parte di pi aree, quindi sono loro ad annunciare in unarea le metriche con cui raggiungono le altre aree. Devono sempre essere connessi alla backbone, sicamente o tramite link virtuali, e gestiscono un database Link State per ogni area. Router interni sono i router che hanno tutti i collegamenti appartenenti alla stessa area, quindi gestiscono un solo database Link State. Autonomous-System Boundary-Router (ASBR) sono quei router che connano con zone non gestite con OSPF, e hanno il compito di informare il proprio AS su quali reti possono raggiungere e con quale costo. Possono essere sia rou...</p>

Recommended

View more >