Algoritmi Di Routing in Reti Magliate Wireless

POLITECNICO DI TORINO
III Facolt di Ingegneria

Corso di Laurea in Ingegneria delle Telecomunicazioni
Monograa di Laurea
Algoritmi di routing in reti magliate wireless
Marco Fanti
Supervisore Aziendale Ing. Andrea Ghittino
Luglio 2011
Sommario
Questo 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.
ii
Indice
Sommario 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
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
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 . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
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
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
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . . . . . . . . . . . . . Zebra ospfd
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
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 . . . . . . . . . . . . . . . . . . .
5 Conclusioni 46 5.1 Soluzioni proposte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 iv
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
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
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
. . . . . . . . . . . . . . . . . . . . . . . . host
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
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
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
Capitolo 1 Introduzione teorica a OSPF

OSPF (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.
1.1
Protocolli Link State
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.
1.2
Introduzione a OSPF
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
1 Introduzione teorica a OSPF
1.2.1
Concetto di Area
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.
1.2.2
RFC di riferimento
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
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..
1.2.3
Tipi di area
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
1.2.4
Tipi di nodo
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 router interni che di bordo area. Ogni nodo/router identicabile allinterno del dominio di routing tramite il suo Router ID, un numero di 32 bit che, come per le aree, viene sempre espresso con la tipica notazione degli indirizzi IPv4. Il Router ID si pu anche lasciare non congurato, in tal caso viene usato al posto lindirizzo IP pi alto tra tutte le interfacce del router.
1.2.5
Contiguit dellarea Backbone
Com noto lalgoritmo di Dijkstra per il calcolo dei cammini minimi viene eseguito solamente allinterno delle aree. quindi possibile che si vadano a formare dei loop nellinstradamento tra aree che vanicherebbero i vantaggi dati dalluso di un protocollo link state. Per evitare questo problema lo standard impone che tutti i router di bordo area facciano parte della backbone, si impone poi anche che tutto il traco transitante tra due aree (chiamato traco inter-area) passi obbligatoriamente per larea backbone. Ad esempio il traco tra due ipotetiche aree A e B dovr sempre fare il percorso A backbone B. Questultimo esempio fa anche capire che larea backbone deve per forza essere contigua, se no sarebbe impossibile instradare verso alcune destinazioni. Se un router facesse eettivamente parte di pi aree senza essere collegato anche alla backbone, per lui sarebbe impossibile trasferire dati direttamente da unarea allaltra senza violare lOSPF standard. 4
1.2.6
Virtual Link
Essendoci spesso la necessit di fare aree che non potranno essere sicamente collegate alla backbone, stato inventato uno stratagemma che consente di creare link virtuali tra diversi ABR. Questi link vengono deniti tra due router di bordo area e sono idealmente visti dal demone OSPF come uninterfaccia di rete virtuale collegata direttamente alla backbone. Il protocollo poi tratter questi link come se fossero dei collegamenti punto-punto. Si possono vedere due esempi di link virtuali in gura 1.1 nella pagina seguente In realt un link virtuale non crea strane connessioni come si potrebbe pensare in un primo momento. Semplicemente tutti i pacchetti OSPF appartenenti alla backbone, quando dovranno essere trasmessi su uno di questi link, verranno spediti da un ABR verso lindirizzo IP sico dellaltro capo del link. I pacchetti seguiranno automaticamente il cammino minimo in quanto il percorso sar tutto interno allarea, e verranno identicati dal ricevente come appartenenti alla backbone. Un ABR considera attivo un link virtuale quando le informazioni in suo possesso relative allarea in cui passa il link gli permettono di raggiungere lABR allaltro capo. I link virtuali non possono passare attraverso le aree stub.
1.2.7
Esempio di Automous System gestito con OSPF
Si prenda ad esempio lAS in gura 1.1 nella pagina successiva, si pu notare larea 0.0.0.4 congurata come stub, ma sarebbe ancora meglio congurarla come totally stub in quanto ha solo un punto duscita verso lesterno. Si evidenzia anche la presenza di due link virtuali necessari a mantenere gli ABR delle aree 4 e 5 contigui alla backbone. Inne si noti che gli AS BR possono essere presenti allinterno di tutte le aree (escluse le stub), ma quelli interni alle aree NSSA sono usati solo per collegamenti verso piccoli AS.
1.3
I pacchetti OSPF
OSPF lavora direttamente su IP e usa cinque dierenti tipi di pacchetti: 1. Hello: utilizzati per scoprire e mantenere le adiacenze, sulle reti di transito (con pi di due router) vengono anche utilizzati per eleggere un router designato e un suo backup (vedi 1.3.5 a pagina 9); 2. Database Description: utilizzati quando due router si vedono per la prima volta per confrontarsi i rispettivi database link state; 5
Figura 1.1. Esempio di divisione in aree di un AS gestito con OSPF. Si possono notare gli Area Border Router e gli ASBR
3. LS-Request: utilizzati per richiedere ad un router vicino delle informazioni che nel router richiedente sono assenti od obsolete; 4. LS-Update: utilizzati per trasferire ad un vicino le voci del proprio database link state; 5. LS-Acknowledgment: utilizzati solo per confermare la ricezione delle informazioni contenute nei pacchetti LS-Update. Si precisa n da ora che questi pacchetti viaggiano sempre da un router no al suo vicino, non vengono mai inoltrati ulteriormente. Al massimo saranno le informazioni 6
ivi contenute ad essere spacchettate e reintrodotte in altri pacchetti simili destinati ad altri router.
1.3.1
OSPF Header
Tutti i pacchetti hanno un header comune contenente i seguenti campi: Version: indica la versione di OSPF (2 o 3); Type: indica il tipo di pacchetto (da 1 a 5); Router ID: indica il router che ha generato il pacchetto; Area ID: indica larea a cui appartiene il pacchetto; Checksum; AuType: specica se usare lautenticazione e, se si, quale tipo usare (password in chiaro oppure crittografata con MD5); Authentication.
1.3.2
Pacchetto Hello
Questo il pacchetto utilizzato dal protocollo Hello (vedi 1.3.3 nella pagina successiva), contiene i seguenti campi: Hello Interval: tempo in secondi che trascorre al massimo tra due emissioni successive di un pacchetto Hello; Router Dead Interval: indica dopo quanti secondi senza ricevere pacchetti Hello si deve considerare morto un router vicino; Designated router (DR) e Backup Designated Router (BDR): indicano il DR e il BDR della rete su cui si aaccia linterfaccia di rete, questri campi si usano solo sulle reti non punto-punto (vedi 1.3.5 a pagina 9); Options: contiene vari bit ma ne sono deniti solo 2, uno indica se larea stub, laltro se NSSA; Elenco dei vicini: indica i router ID di tutti i nodi vicini visti tramite questa interfaccia scoperti grazie ai rispettivi pacchetti Hello. Perch due vicini riescano eettivamente a vedersi necessario che i campi del pacchetto, esclusa la lista dei vicini, siano uguali. Quindi non si possono congurare Hello Interval e Router Dead Interval diversi su pi router che si aacciano sullo stesso link. 7
1.3.3
Protocollo Hello
Questo protocollo serve a scoprire i vicini su una determinata interfaccia, quindi lavora in modo diverso a seconda del tipo di rete a cui essa collegata. Sulle reti broadcast e NBMA viene eletto un router designato (vedi 1.3.5 nella pagina successiva). Nelle broadcast ogni nodo si annuncia periodicamente inviando pacchetti Hello allindirizzo multicast AllSPFRouters 224.0.0.5. Nelle reti NBMA invece serve una congurazione preesistenete che istruisca il protocollo Hello su quali sono i router potenzialmente contattabili tramite linterfaccia corrente, quindi non esistono metodi per scoprire automaticamente i nodi vicini. Sulle reti punto-punto non c nessuna procedura di elezione del router designato quindi il protocollo Hello si limita a cercare il singolo vicino. Le reti punto-multipunto vengono gestite dal demone OSPF come se fossero tante reti punto-punto quante sono le destinazioni raggiunte. In ogni caso, a prescindere dal tipo di rete a cui collegata linterfaccia, ogni volta che viene visto un Hello proveniente da un vicino viene aggiunto il corrispondente router ID allelenco dei vicini del prossimo pacchetto Hello generato.
1.3.4
Cosa sono le adiacenze
Un adiacenza un collegamento tra due router vicini che viene usato per lo scambio dei pacchetti non Hello. Mentre gli Hello infatti vengono sempre spediti verso tutti i vicini, se no perderebbero di senso, non sempre preferibile che anche gli altri tipi di pacchetti viaggino con indirizzi broadcast. Nelle reti di transito con pi di due router, i router che non sono (B)DR non si scambiano mai pacchetti al di fuori di quelli Hello.
Figura 1.2. Formazione delle adiacenze in una rete di transito broadcast con 5 nodi. A sinistra si pu notare la topologia della rete, mentre a destra c il graco delle adiacenze che si vengono a formare.
Come si pu notare in gura 1.2 le adiacenze si formano solo tra il Designated Router e gli altri router del dominio di broadcast. I pacchetti non Hello verranno scambiati solo ed esclusivamente lungo questi collegamenti. In una rete punto-punto 8
o in una punto-multipunto invece due router vicini sono sempre automaticamente adiacenti.
1.3.5
Elezione del Designated Router e del suo Backup
Vista lassenza di reti di transito broadcast nella rete del CSP, non si spiegher nel dettaglio lelezione del Designated Router per non appesantire troppo la trattazione. Per completezza comunque meglio accennare alcuni aspetti. Non possibile stabilire a priori quale sar il DR di una rete, lunica possibilit assegnare in fase di congurazione una certa priorit allinterfaccia del router che si preferisce come DR. Generalmente il router con la priorit pi alta riesce ad essere eletto, ma non detto che in ogni momento il DR della rete sia lui. Si pu anche impostare la priorit a zero, in questo caso il router non si candider mai al ruolo di (B)DR. La procedura di elezione parte ogniqualvolta il pacchetto Hello di un router indica che il DR (o il BDR) 0.0.0.0, questo signica che il nodo in questione non vede pi il DR e quindi va rifatta lelezione. Nel caso il BDR sia ancora visibile a tutti, nel senso che presente in tutti i pacchetti Hello, esso comincia semplicemente ad annunciare se stesso come DR, mentre la procedura di elezione andr a selezionare un nuovo BDR tra i router rimanenti.
1.3.6
Il database Link State
Prima di cominciare a spiegare nel dettaglio i pacchetti di tipo Database Description e gli altri tipi di pacchetti usati da OSPF (vedi 1.3.13 a pagina 13) essenziale sapere com composto il database Link State dei router e come viene compilato. Questo perch essenzialmente i pacchetti OSPF diversi dagli Hello non contengono altro che record completi o parziali presi dai database dei router che li creano. I record del database si chiamano Link State Announcement (abbreviato LSA), questo perch dopo essere stati creati vengono annunciati agli altri router tramite la procedura di ooding (vedi 1.3.15 a pagina 14). Esistono vari tipi di LSA, con diverse funzioni in base a cosa descrivono e al router che li ha generati.
1.3.7
LSA Header
Ogni LSA ha 6 campi ssi, dei quali i primi 3 servono a distinguerlo dagli altri LSA presenti nel database, cio si potrebbe dire che fungono da chiave primaria, mentre gli ultimi 3 servono per poter confrontare due LSA che descrivono lo stessa entit e decidere qual il pi recente. Questi ultimi 3 campi entrano in azione nella procedura di oodind (vedi 1.3.15 a pagina 14) per poter distinguere gli LSA da scartare da quelli aggiornati. 9
Questi campi tutti insieme prendono il nome di LSA Header e sono i seguenti: 1. LS Type: il tipo di LSA (vedi 1.3.8 e successive); 2. Advertising Router: il router che ha creato lLSA; 3. Link State ID: cambia a seconda del tipo; 4. LS Age: una stima del tempo passato, in secondi, da quando stato creato lLSA, un numero di 16 bit il cui valore massimo si indica con MaxAge; 5. LS checksum: un semplice checksum dellintero LSA; 6. LS Sequence Number: indica il numero di sequenza dellLSA, viene incrementato periodicamente, ma anche e sopratutto quando cambia il contenuto dellLSA. Nelle sezioni successive si trattano nel dettaglio i vari tipi di Link State Announcement, da chi vengono creati, in quale zone del dominio di routing devono essere diusi e quali informazioni contengono in aggiunta alle 6 gi specicate qui.
1.3.8
Router LSA
I Router LSA vengono creati da ogni router (uno per ogni area di cui il router fa parte) e descrivono tutti i link che il router ha verso larea in cui verranno diusi. Il campo Link State ID in questo caso indica il Router ID del creatore dellLSA, quindi identico al campo Advertising Router. Il resto del contenuto dellLSA costituito da un elenco di link, i quali possono essere di vari tipi, e il loro costo associato. Questo costo sar quello che andr poi a determinare le metriche nelle tabelle di routing. A ogni link, oltre al costo, sono anche assegnati un Link ID e un Link Data entrambi di 32 bit, Se ne pu vedere il signicato nella tabella 1.1 nella pagina seguente.
1.3.9
Network LSA
Un Network LSA creato per ogni rete di transito dal router designato della stessa. Esso elenca semplicemente tutti i nodi che si aacciano sulla rete di transito tramite il loro Router ID. Anche questi LSA verranno diusi dalla procedura di ooding solo nellarea in cui si trova la rete di transito. Il Link State ID di questi LSA corrisponde allindirizzo IP che il router designato ha sulla rete, mentre la network mask della rete specicata nel corpo dellLSA prima della lista dei router. 10
Tabella 1.1. I vari tipi di link elencabili in un Router-LSA con relativa descrizione e signicato dei campi Link ID e Link Data
Type 1 2 3 4
Descrizione Link punto-punto
Link ID Router ID del vicino
Link Data Indirizzo IP dellinterfaccia del router (se c) Indirizzo IP dellinterfaccia
Link a una rete Indirizzo IP del DR di transito della rete
Link a una rete Indirizzo IP della re- Address mask della rete stub te Link virtuale Router ID del vicino Indirizzo IP dellinterfaccia
Non viene denito nessun costo nel raggiungere i vari nodi dalla rete, perch il protocollo assume che il costo per raggiungere un router da una rete sia uguale a zero. Quindi in OSPF i costi sono solo deniti in uscita dalle interfacce dei router.
1.3.10
Summary LSA
I Summary LSA vengono creati dai router di bordo area per poter descrivere ai router interni le destinazioni che loro possono raggiungere. Ne esistono di due tipi, indicati con i valori 3 e 4 del campo LS Type. I primi descrivono il costo con cui lABR pu raggiungere una rete, i secondi descrivono il costo con cui pu raggiungere un AS Boundary-Router. Nei due casi il formato dellLSA identico, cambia solo il signicato del campo Link State ID, che nel tipo 3 un indirizzo qualsiasi della rete di destinazione, mentre nel tipo 4 il Router ID dellAS Boundary-Router a cui fa riferimento. anche presente un campo network mask, utile nel caso il Summary LSA sia di tipo 3, che viene settato a tutti zeri negli LSA di tipo 4. Note sulla creazione dei Summary LSA di tipo 3 Si possono impostare i router di bordo area in modo che nascondino allarea determinati range di indirizzi. Nella stessa maniera si pu fare in modo che pi range vengano raggruppati in un unico Summary LSA, in tal caso il costo pubblicato allinterno dellarea sar uguale a quello della sottorete raggiunta con il costo maggiore. Non necessario che il range sia completamente occupato dalle sottoreti raggruppate, quindi bisogna stare attenti a non pubblicizzare allinterno dellarea delle route che in realt non sono raggiungibili. 11
Note sulla creazione dei Summary LSA di tipo 4 I Summary LSA di tipo 4 non vengono creati allinterno delle aree Stub e NSSA. Al loro posto invece viene sempre creato un Summary LSA di tipo 3 settato come DefaultDestination (route 0.0.0.0/0) e metrica uguale al parametro, congurabile, DefaultCost.
1.3.11
AS-external LSA
Gli AS-external LSA, anche detti di tipo 5, vengono creati dagli AS Boundary-Router e descrivono solo le destinazioni esterne allAutonomous System. Per questo si pu intuire che questo tipo di LSA venga diuso in tutte le aree eccetto quelle Stub e NSSA. Un AS Boundary-Router genera un singolo LSA di tipo 5 per ogni destinazione esterna che ha imparato, ad esempio tramite BGP o una congurazione statica. Le informazioni contenute in questi LSA sono lindirizzo della rete di destinazione, contenuto nel Link State ID, laddress mask e il costo del collegamento. C anche un campo Forwarding Address il quale pu indicare a chi consegnare direttamente i pacchetti destinati al range specicato dallLSA corrente.
Note sulle metriche specicate negli AS-external LSA Oltre alla metrica che indica il costo del link, presente anche un bit che indica se la metrica ti tipo 1 o 2. Nel caso delle metriche di tipo 1 i router dovranno sommare a tale metrica il costo del collegamento tra loro e lAS Boundary-Router, mentre le metriche di tipo 2 vengono usate cos come sono, ignorando il costo del percorso tra il router di partenza e lAS Boundary-Router.
1.3.12
LSA speciali per le aree NSSA
Come spiegato precedentemente gli AS-external LSA non possono essere creati e/o diusi nella aree Stub. Le aree NSSA per sono delle aree Stub speciali che possono contenere router collegati ad altri piccoli AS (vedi area 0.0.0.5 in g. 1.1 a pagina 6), quindi hanno la necessit di creare AS-external LSA. Per questo gli AS BR interni ad unarea NSSA creano degli AS-external LSA di tipo speciale, mettendo il numero 7 al posto del 5 nel campo LS Type. Il router di bordo area poi provveder a convertire lLSA in uno di tipo 5 prima di dionderlo nelle altre aree[2]. 12
1.3.13
Pacchetti OSPF non Hello
Di seguito viene spiegata la struttura dei pacchetti OSPF Database Description (tipo 2), LS-Request (tipo 3), LS-Update (tipo 4) e LS-Acnowledgement (tipo 5). Pachetti Database Description Adesso che sono stati trattati tutti i tipi di LSA, si possono descrivere i pacchetti Database Description. Come il nome stesso suggerisce, vengono utilizzati quando due router vicini si devono descrivere a vicenda il loro database LSA, e ci succede quando vengono create le adiacenze (vedi 1.3.14). Il pacchetto ha una composizione molto semplice, oltre allintestazione OSPF presente un campo opzioni contenete i bit Initialize, Master e More, un campo Sequence Number da 32 bit pi un elenco indenito di LSA Header. Il signicato e lo scopo di questi campi sanno chiariti nella sezione 1.3.14. Pacchetti LS-Request Questi pacchetti hanno una struttura semplicissima, data dal fatto che servono semplicemente a richiedere ad un router vicino uno o pi LSA dal suo database. Il corpo del pacchetto infatti contiene semplicemente una lista di LS Type, Link State ID e Advertising Router. Si ricorda che questi sono i 3 campi di un LSA che consentono di individuarlo univocamente allinterno del database Link State. Pacchetti LS-Update I pacchetti LS-Update sono quelli che materialmente diondono gli LSA allinterno del dominio di routing. Gli unici dati contenuti nel body del pacchetto sono un capo che indica il numero di LSA in esso contenuto e lelenco stesso degli LSA. Pacchetti LS-Acknoledgement I pacchetti LS-Acknoledgement sono quelli che richiedono meno spiegazioni, contengono semplicemente una lista di LSA Header e servono a confermare la ricezione degli LSA ricevuti tramite un pacchetto LS-Update.
1.3.14
Creazione delle adiacenze
Come gi spiegato in precedenza (vedi 1.3.4 a pagina 8) due router sono sempre adiacenti in una rete punto-punto, mentre nelle reti di transito non cos. In ogni caso i vari router, grazie al protocollo hello (1.3.3), sono in grado di determinare con quali router necessario formare le adiacenze. 13
Due router vicini e che si vedono a vicenda tramite i pacchetti Hello si dice che hanno un rapporto di vicinato in stato 2-Way. Nel caso si rendano conto che devono formare unadiacenza, perch la rete punto-punto o perch uno dei due il router designato, lo stato dovr passare da 2-Way a Full, che indica la sincronizzazione completa dei database. Inizialmente entrambi i router si inviano a vicenda un pacchetto Database Description con i bit Initialize e Master settati a 1 e senza alcun LSA Header (questi pacchetti DD si dicono appunto vuoti). A questo punto il router con il Router ID pi alto diventa il master della comunicazione, che avviene in questo modo: il Master imposta il campo Sequence Number del suo pacchetto DD e invia pacchetti contenenti tutti i suoi Header LSA, nch ha pacchetti da inviare il bit More rimane settato ad 1; a ogni pacchetto del Master lo Slave risponde con un suo pacchetto DD, impostando il campo sequence number allo stesso valore del master (in questo modo il pacchetto funge anche da ack), anche lo slave tiene il bit More a 1 nch ha ancora Header LSA da inviare; se il Master ha nito di descrivere il suo database, continua comunque a inviare pacchetti DD vuoti incrementando solo il Sequence Number nch non ha nito anche lo Slave, e viceversa. Una volta che i due router si son descritti a vicenda il proprio database si inviano a vicenda i pacchetti LS Request per richiedere gli LSA mancanti o non aggiornati (vedi 1.3.17 a pagina 16). Fatto ci i router si scambiano ancora i pacchetti LS Update e i relativi LS Ack. Essendo la procedura studiata in modo da essere adabile, durante la formazione delladiacenza ogni pacchetto deve essere ritrasmesso se non si ricevono Acknowledgement entro RxmtInterval secondi (tempo impostabile su ogni interfaccia di ogni router). sottinteso che se per caso i due router smettono di vedersi, entrambi o solo uno dei due, per pi di Router Dead Interval, allora ladiacenza muore ancora prima di nascere. Solo una volta che ladiacenza ha raggiunto lo stato full i due router possomo modicare i propri LSA aggiungendovi ladiacenza.
1.3.15
Procedura di ooding
La procedura di ooding ha lo scopo di diondere gli LSA dal router dove sono stati creati no a tutti i nodi dellarea di appartenenza dellLSA. Gli AS-External LSA invece vengono diusi in tutte le aree escluse quelle Stub e NSSA. Questa procedura pu anche essere variata leggermente in modo da eliminare un LSA dalla rete invece che dionderlo, in questo caso prende il nome di procedura 14
di aging (vedi 1.3.16 nella pagina seguente). In ogni caso entrambe le procedure partono dal router che ha creato lLSA. Primo passo della procedura Quando un router crea un nuovo LSA o ne aggiorna uno esistente (in tal caso incrementa il relativo Sequence Number) usa i pacchetti LS-Update per comunicarli ai vicini adiacenti. I pacchetti vengono sempre spediti verso lindirizzo multicast AllSPFRouters, tranne nelle reti di transito dove non si (B)DR sulle quali vengono spediti a AllDRouters e sui link virtuali dove vengono spediti direttamente allIP dellaltro capo del link. Ogni volta che un LSA viene inoltrato su uninterfaccia bisogna incrementarne il campo Age di un numero di secondi diverso da zero (predenito a 1) impostabile. Inoltre per ogni vicino viene tenuta traccia degli LSA gi inviati e non ancor confermati tramite LS-Ack, e se non si riceve la conferma entro RxmtInterval secondi lLSA viene ritrasmesso solo allindirizzo IP del vicino. Il protocollo considera come Ack impliciti gli LS-Update contenenti listanza dellLSA di cui si stava aspettando la conferma di ricezione; comunque anche in caso di ricezione di un Ack implicito prudente spedire un pacchetto LS-Ack al mittente. Passi successivi della procedura I router che ricevono un LSA da unadiacenza devono confrontarlo con la copia nel database locale (vedi 1.3.17 nella pagina successiva) e nal caso sia pi recente della copia locale devono diondere lLSA lungo le altre adiacenze. In ogni caso bisogna inviare un Acknowledgement al mittente. Casi particolari della procedura di ooding Se si ricevono pi LSA uguali (anche solo i primi 3 campi) in un piccolo intervallo di secondi chiamato MinLSArrivalSeconds, lultimo ricevuto viene scartato senza nemmeno controllare se pi recente dellaltro. Se un router riceve un LSA pi vecchio della sua copia locale invia la copia aggiornata al mittente. Se si riceve un LSA con il campo Age uguale al massimo, allora si manda un Ack al mittente, poi, se lLSA presente nel database locale, si inoltra a tutte le adiacenze e ad ack ricevuto si elimina dal database. Se si riceve un LSA che risulta creato da se stessi, ma la copia locale o ha un numero di sequenza minore o non esiste proprio, allora si crea una nuova 15
istanza dellLSA con numero di sequenza maggiore, oppure si usa la procedura di Aging per eliminarlo dalla rete (vedi 1.3.16).
1.3.16
Procedura di Aging
La procedura di Aging viene usata per eliminare un LSA dal dominio di routing. necessario ricorrere a questa procedura anche nel caso particolare in cui il numero di sequenza di un LSA ha raggiuno il valore massimo e necessita di essere riavvolto, in questo caso si elimina lLSA dal dominio di routing e se ne ricrea uno con numero di sequenza minimo. La procedura si basa sul fatto che gli LSA con et uguale a MaxAge non vengono usati per il calcolo delle tabelle di routing, ma possono essere diusi con la procedura di ooding e vengono eliminati dal database Link State una volta ricevuti tutti gli Ack.
1.3.17
Confrontare due LSA
Poter confrontare due istanze dello stesso LSA per determinarne la pi recente un requisito essenziale per ogni protocollo di routing, sia la formazione delle adiacenze (vedi 1.3.14 a pagina 13), che la procedura di ooding (vedi 1.3.15 a pagina 14) si basano sulla fattibilit di questo confronto. Il primo termine di confronto il campo Sequence Number, lLSA con questo valore maggiore viene considerato pi recente. In caso di uguaglianza ti questo termine si va a vedere il campo Age, che considerato in questo modo: se solo uno dei due LSA ha et MaxAge, quello con questa et viene considerato pi recente se il campo Age dierisce di un valore maggiore di MaxAgeDi 1 , allora pi recente lLSA con Age minore. In ogni altro caso i due LSA vengono considerati uguali.
1.3.18
Impostazione del costo di un collegamento
In OSPF le metriche vengono calcolate basandosi sui costi che ogni router imposta in uscita delle sue interfacce. Questi costi in uscita vengono comunicati nei Router LSA e sono impostati staticamente sulle interfacce Lunica possibilit di modica dinamica dipende dalle funzionalit del demone che implementa il protocollo, ma nello standard (RFC 2328 ) non viene specicato
1
Valore non impostabile nelle implementazioni di OSPF.
16
alcun modo per variare dinamicamente il costo di un link: o il link funzionante e con un certo costo, oppure non funzionante.
1.3.19
Creazione delle tabelle di routing
Una volta che tutti i nodi appartenenti ad unarea hanno il database sincronizzato possono procedere a calcolarsi tutti i percorsi minimi interni allarea con lalgoritmo di Dijkstra. Per fare questo si usano solamente i Router e i Network LSA. Questi percorsi vengono chiamati intra-area e le relative voci della tabella di routing vengono calcolate immediatamente dopo lesecuzione di Dijkstra. Successivamente si procede ad analizzare i Summary LSA, eventualmente ignorando quelli riferiti a destinazioni interne allarea. Sommando il costo del cammino no al router di bordo area al costo pubblicato nel Summary LSA, si ottiene il costo totale che permette di scegliere il percorso pi breve no a destinazione. Queste route vengono chiamate inter-area. Lanalisi degli AS-external LSA a questo punto immediata perch si conoscono gi tutte le route per le destinazioni interne allAutonomus System. Intervalli di tempo nel calcolo delle tabelle di routing Visto il fatto che il cambiamento di una metrica in un Summary LSA non causa la riesecuzione di Dijkstra, si dice che laggiornamento delle route inter-area incrementale, perch vengono aggiornate immediatamente cambiando solo la route a cui si riferiscono. Il cambiamento di una metrica o di un link in un Router o in un Network LSA invece richiede necessariamente la riesecuzione dellalgoritmo di Dijkstra, per questo: dopo la ricezione di un LSA di tipo 1 o 2, si aspetta sempre un certo tempo (chiamato delay), in modo che si permetta larrivo di altri eventuali LSA, prima del ricalcolo della tabella di routing; impostabile un intervallo di tempo (chiamato hold-time) minimo che deve passare tra un calcolo della tabella di routing e il successivo.
1.3.20
Bilanciamento del carico con OSPF
OSPF permette di bilanciare il traco in uscita tra due interfacce, questo possibile grazie alle funzionalit del kernel linux che permettono di impostare pi route per la stessa destinazione. Il bilanciamento non implementato a livello di pacchetto, ma a livello di usso. 17
Tutto questo viene fatto automaticamente quando per una destinazione esistono due percorsi possibili con la stessa metrica, questo non sempre facilmente realizzabile, ma comunque una possibilit da tenere in considerazione.
1.3.21
Considerazioni sui link virtuali
Vista la natura speciale dei link virtuali, opportuno fare alcune precisazioni a loro riguardo. La prima riguarda il fatto che i due capi del link devono sempre avere un indirizzo IP assegnato, cosa non scontata nelle reti punto-punto. Su questi collegamenti bisogna poi stare attenti a congurare il tempo di ritrasmissione, visto che il Round Trip Time pu essere molto pi alto che sugli altri link sici.
1.4
Considerazioni nali su OSPF
OSPF un buon protocollo di routing, considerati il piccolo traco di rete e lalta velocit di convergenza. Presenta tuttavia alcuni difetti e alcuni aspetti a cui bisogna stare attenti quando si decide di usarlo per gestire un Autonomus System. Prima di tutto bisogna stare attenti a creare le aree, perch i percorsi intra-area vengono sempre preferiti sugli inter-area, anche se questi ultimi hanno costo minore tra gli stessi nodi di partenza e destinazione. Potrebbe capitare che non sia possibile dividere le aree in modo che tutti i percorsi siano sempre i pi brevi. Similmente al problema della divisione in aree, sempre durante la progettazione del sistema bisogna stare attenti a fare in modo che larea backbone sia sempre contigua. Questo laspetto da mantenere in maggior considerazione, perch se non soddisfatto semplicemente la rete non funziona. Per fare in modo che sia cos ci si pu aiutare con i link virtuali, tenendo conto del fatto che il traco di controllo di OSPF aumenter inevitabilmente sul percorso del link.
1.4.1
OSPF su reti wireless
OSPFv2 studiato apposta per reti cablate, dove solitamente i link o sono completamente non funzionanti oppure non perdono nessun pacchetto. Su una rete wireless, dove il numero di pacchetti persi dipende da una miriade di fattori, questa visione del link causa principalmente due problematiche: un link pu passare frequentemente dallo stato di funzionante a non fuzionante, per quel che riguarda il punto di vista di OSPF; il costo di un link non pu essere cambiato automaticamente in base al numero di pacchetti persi o altri parametri che indicano la qualit del collegamento.
18
Capitolo 2 Il protocollo di routing OLSR

OLSR (Optimized Link State Routing Protocol) un protocollo di routing link state realizzato presso luniversit di Oslo. Ha la particolarit di essere realizzato apposta per le reti wireless Ad-Hoc radiomobili, quindi supporta alcuni tipi di metriche che servono apposta per tenere conto delle problematiche introdotte da questo tipo di reti.
2.1
Metriche ETX
OLSR stato esteso in modo da supportare le metriche ETX (Expected Transmission Count) le quali tengono conto della percentuale di pacchetti persi su un determinato link wireless, questo con o scopo di massimizzare la probabilit che i pacchetti trasmessi arrivino a destinazione.
2.1.1
Calcolo delle metriche ETX
Per calcolare le metriche ETX bisogna per prima cosa contare la percentuale dei pacchetti Hello che si riescono a ricevere dai vicini. Se lintervallo di Hello lo stesso in tutta la rete allora un calcolo molto semplice, e il valore percentuale ottenuto viene chiamato LinkQuality. molto importante conoscere la percentuale di pacchetti persi anche nellaltra direzione (dal nodo verso i vicini), la quale viene comunicata dai vicini nei loro pacchetti Hello e si chiama NeighborLinkQuality. La moltiplicazione tra NeighborLinkQuality e LinkQuality fornisce unindicazione sulla qualit del link in termini di pacchetti persi, quindi viene usata direttamente per il calcolo della metrica. 19
2 Il protocollo di routing OLSR
OLSR utilizzato con le metriche ETX non seleziona il percorso pi breve per arrivare a destinazione, ma quello su cui si perdono meno pacchetti. La qualit del percorso si ottiene facilmente moltiplicando tra di loro le qualit dei link attraversati.
2.2
Traco di rete
A dierenza di OSPF, il cui traco di gestione molto basso, limitandosi a minuscoli pacchetti Hello quando la situazione tranquilla per poi aumentare quando bisogna comunicare le modiche dei link ai nodi, OLSR si comporta diversamente. In questo protocollo infatti ogni nodo invia di continuo ai vicini informazioni sulle destinazioni da lui direttamente raggiungibili, e il traco in uscita da ogni nodo risulta essere praticamente invariabile qualsiasi cosa succeda.
2.3
Demone OLSR
Il demone uciale di OLSR sviluppato dagli stessi ideatori del protocollo1 e presenta un unico le di congurazione olsrd.conf, inoltre esiste un progetto che mira ad aggiungere a Quagga il supporto ad OLSR2 , ma al momento ha un solo sviluppatore e supporta una vecchia versione di Quagga. Oltre a non supportare ancora le metriche ETX.
2.4
Congurazione di base del demone OLSRd
Congurazione di base di un demone OLSRd (preso da www.olsr.org), su un nodo con due interfacce eth0 e eth1. Interface "eth0" "eth1" { HelloInterval 1.0 HelloValidityTime 600.0 TcInterval 0.5 TcValidityTime 300.0 MidInterval 10.0 HnaInterval 100.0 HnaValidityTime 600.0 } LinkQualityFishEye 0
1 2
vedi il sito http://www.olsr.org vedi il sito http://olsrdq.sourceforge.net/
20
2 Il protocollo di routing OLSR
IpVersion 4 Willingness 7 UseHysteresis no LinkQualityLevel 2 #indica di usare le metriche ETX Pollrate 0.1 TcRedundancy 2 MprCoverage 1
21
Capitolo 3 Implementazioni di OSPF

In questo capitolo verranno descritte velocemente le principali implementazioni open source del protocollo OSPF, per poi concentrarsi sullimplementazione pi diusa e supportata, cio Quagga.
3.1
OpenOSPFd
OpenOSPFd unimplementazione di OSPF molto diusa, ma disponibile soltanto per il mondo BSD. Ha il pregio di essere un progetto molto semplice, in quanto si limita a supportare bene solo un protocollo di routing, a dierenza delle altre implementazioni di OSPF le quali sono delle vere e proprie suite che puntano a supportare tutti i protocolli pi diusi. OpenOSPFd anche ritenuto il migliore, grazie sopratutto al suo numero di linee di codice molto esiguo (circa 12000), in termini di memoria occupata e presenza di bug[3].
3.2
BIRD
BIRD (Bird Internet Routing Daemon) una suite di routing sviluppata dalla Charles University di Praga, implementa vari protocolli tra cui OSPF. Presenta vari difetti, quali i pochi sviluppatori e i molti bug, per il difetto principale quello di non poter cambiare al volo unimpostazione su un nodo senza dover modicare a mano i le di congurazione e riavviare il demone. 22
3 Implementazioni di OSPF
3.3
XORP
XORP (eXtensible Open Router Platform) una suite di routing che punta a essere facilmente estendibile per poter supportare quanti pi protocolli possibile. Nonostante a detta degli sviluppatori sia ritenuto un progetto molto ambizioso, anchesso sore di molti bug. Tuttavia limplementazione di OSPF abbastanza valida, mentre i molti bug pi che altro aiggono implementazioni di altri protocolli. Unaltra caratteristica da sottolineare che XORP scritto in C++ ed ha centinaia di migliaia di righe di codice (oltre 600 000), quindi sembrerebbe poco adatto a girare sui router rispetto ad altre suite pi leggere.
3.4
Quagga
Quagga una suite di routing nata da un fork dallomai defunta suite Zebra. Tra i suoi punti di forza si sottolineano i fatti che ha molti sviluppatori e che in assoluto la suite di routing open source pi diusa al mondo. Quagga presenta un demone principale, chiamato zebra, che ha il compito di mettere in comunicazione tra loro i vari demoni supportati, oltre a dover modicare la tabella di routing del kernel in base alle informazioni ricevute dai vari demoni. Zebra pu anche essere usato per impostare route statiche. Il le di congurazione di zebra molto semplice, contiene solo alcune informazioni, pi che altro descrittive, delle interfacce, pi eventualmente le route statiche. Il demone OSPF si chiama semplicemente ospfd e anchesso presenta un suo le di congurazione, il metodo di congurazione preferibile per usare il terminale accessibile tramite telnet. Questo metodo di congurazione Cisco-like (anche nella somiglianza dei comandi) permette di congurare ospfd al volo e senza commettere banali errori di sintassi. Inoltre la presenza di un help in linea molto pi pratica del dover leggersi un manuale mentre si compila un le di congurazione. Con il comando write poi si possono salvare le modiche fatte al volo nel le di congurazione. Quagga scritto in linguaggio C. Il progetto composto da circa 40 000 righe di codice per il demone Ospfd, pi 15 000 righe per il demone Zebra e 35 000 per le librerie comuni[3].
3.4.1
Congurazione del demone Zebra
Per congurare il demone zebra si pu agire sul le /etc/quagga/zebra.conf oppure si accede tramite telnet alla porta 2601 (predenita) e si entra in modalit di congurazione tramite i comandi enable e configure terminal. I commenti nei le di congurazione di Quagga si introducono con il carattere !. 23
Figura 3.1. La shell Cysco-like in ascolto su localhost:2604, in questo caso usato per modicare il costo di uninterfaccia.
Di seguito un tipico le zebra.conf, si nota subito che, a parte le route statiche, la congurazione questo le non contiene niente di cos fondamentale: hostname Router password zebra interface eth0 link-detect description link verso Torino interface eth1 link-detect description link verso Milano !Esempio di route statica (in questo caso default route) ip route 0.0.0.0/0 203.181.89.241 La denizione delle route statiche molto scarna, infatti gli unici dati specicabili sono la route di destinazione e il gateway.
3.4.2
Congurazione del demone ospfd
La congurazione del demone ospfd pu avvenire nelle stesse modalit del demone zebra, con la dierenza che il le da editare si chiama ospfd.conf mentre la porta predenita su cui in ascolto la shell Cysco-like la 2604. 24
Nella prima parte del le bisogna specicare le opzioni relative alle singole interfacce (ad esempio HelloInterval), invece nella seconda si specicano tutte le impostazioni globali del router (Router ID, link virtuali, ecc. . . ). Congurare le interfacce OSPF interface ethX ip ospf network point-to-point !forza ad usare lautenticazione sicura MD5 su eth0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 password123 ip ospf hello-interval 5 ip ospf dead-interval 20 ip ospf retransmit-interval 5 !secondi da sommare al campo Age durante la spedizione dellLSA: ip ospf transmit-delay 1 I tempi Hello Interval e Dead Interval sono gi stati citati nelle speciche, mentre lopzione retransmit-interval si riferisce allintervallo di tempo che nelle speciche chiamato RxmtInterval (vedi 1.3.15 a pagina 15). In questo caso si congurato un collegamento punto-punto, ma allo stesso modo il collegamento si pu impostare come point-to-multipoint, non-broadcast (cio NBMA) oppure broadcast. Nonostante lo standard non sembrerebbe dare la possibilit di impostare HelloInterval sotto il secondo, esiste lopzione ip ospf dead-interval minimal hello-multiplier <2-20> la quale imposta lHello Interval nel pacchetto Hello a 0 secondi, il Router Dead Interval a 1 secondo e invia il numero specicato di pacchetti Hello al secondo. Questo anche uno stratagemma che consente a nodi diversi aacciati sullo stesso link di vedersi nonostante Hello Interval non sia uguale tra tutti. Oltre alle interfacce che si impostano in questo modo, che sono le interfacce del router collegate agli altri router, ci sono anche le interfacce collegate alle reti stub, quelle che nei Router LSA vengono chiamate per lappunto Link a una rete Stub (vedi tab. 1.1 a pagina 11). Queste interfacce si specicano in OSPF dopo la direttiva router ospf in questo modo: router ospf passive-interface ethX Gli altri parametri da impostare dipendono dalla natura del router, se semplicemente interno allarea, oppure se un ABR e/o un AS BR 25
Parametri presenti in tutti i router router ospf ospf router-id 0.0.0.1 log-adjacency-changes detail !si specifica a che aree appartengono le interfacce !specificando la rete a cui collegata linterfaccia network 10.0.0.4/30 area 0.0.0.1 network 10.0.0.16/30 area 0.0.0.1 !forza ad usare lautenticazione message-digest MD5 sullarea 1 area 0.0.0.1 authentication message-digest !da aggiungere se larea Stub area 0.0.0.1 stub !da aggiungere se larea NSSA area 0.0.0.1 nssa Si noti che se larea Stub oppure Totally-Stub allora bisogna specicare lopzione area 0.0.0.1 stub anche se tale opzione interviene solo sul comportamento degli ABR, mentre qui si potrebbe benissimo essere su un router interno allarea. Questo necessario perch il campo Options del pacchetto Hello deve indicare che la rete Stub. Lo stesso discorso vale se larea NSSA. Parametri esclusivi per gli Area Border Routers router ospf ospf abr-type standard !se nellarea 1 sono presenti una o pi route nel range !specificato, nella backbone viene annunciato un solo LSA !con questo range: area 0.0.0.1 range 10.0.0.0/8 !virtual-link attraverso larea 1 fino al router 5 area 0.0.0.1 virtual-link 0.0.0.5 area 0.0.0.1 virtual-link 0.0.0.5 message-digest-key 2 md5 PWD !altri parametri del virtual link area 0.0.0.1 virtual-link 0.0.0.5 hello-interval 1 area 0.0.0.1 virtual-link 0.0.0.5 dead-interval 5 area 0.0.0.1 virtual-link 0.0.0.5 retransmit-interval 5 !imposta unarea come totally-stub (dentro larea viene !pubblicizzata solo una route di default) area 0.0.0.1 stub no-summary !costo della route di default pubblicizzata nellarea stub area 0.0.0.1 default-cost 100 26
!area NSSA !istruisce lABR per convertire tutti gli LSA di tipo 7 !in LSA di tipo 5 da pubblicare nella backbone area 0.0.0.1 nssa translate-always Il settaggio ospf abr-type standard obbliga lABR a comportarsi in modo standard, cio non permette lutilizzo di percorsi inter-area che non passino per la backbone (vedi 1.2.5 a pagina 4). possibile settare il comportamento del router come cisco (settaggio predenito in Quagga), in tal caso se un ABR si ritrovasse senza collegamenti con la backbone potrebbe utilizzare percorsi che passino attraverso altre aree prima di arrivare alla backbone. Lo standard risolve questo problema con i link virtuali. La direttiva translate-always nellistruzione che imposta una certa area come NSSA impone al router di convertire sempre gli LSA di tipo 7 in LSA di tipo 5 da comunicare nella backbone (vedi 1.3.12 a pagina 12). Parametri esclusivi per gli AS Boundary-Routers router ospf !redistribuisce le route specificate in zebra.conf !esclusa quella di default! redistribute static metric 100 metric-type 1 !se presente in zebra.conf, redistribuisce la !default route (0.0.0.0/0) default-information originate metric 100 metric-type 1 Al posto della direttiva static si pu mettere il nome di un altro demone gestito da Quagga, kernel oppure connected, anche se questultimo caso generalmente sconsigliato perch potrebbe portare a pubblicare pi route di quelle necessarie.
27
Capitolo 4 Realizzazione dei test

I protocolli di rete sono stati testati su una topologia di rete il pi possibile simile alla futura rete wireless del CSP. La rete attuale non magliata, quindi la caduta di un link non pu essere aggirata in nessun modo che non sia il ripristino del link stesso. Il progetto per lammodernamento della rete prevede lintroduzione di due anelli, come si pu vedere in gura 4.1 nella pagina successiva. Lo schema volutamente una semplicazione, nel senso che in realt i nodi rappresentano gruppi di router, inoltre non comprende la parte della rete che rimarrebbe non magliata dopo lammodernamento.
4.1
Simulatore di reti NetKit
Per emulare facilmente un grande numero di router ci si serviti del programma NetKit 1 , sviluppato dalluniversit di Roma3. Questo simulatore utilizza UML (User Mode Linux), che una variante del kernel Linux in grado di girare in user space. Questo fa in modo che Netkit sia estremamente leggero, requisito ideale quando si devono emulare molti nodi. Allo stesso tempo ci sono dei limiti derivanti dal fatto di non avere a disposizione una vera e propria macchina virtuale. Possono essere avviate molteplici istanze di UML, ognuna con un numero di schede di rete arbitrario e congurabile dallutente tramite un semplice le di congurazione. Nello stesso modo ogni scheda si pu collegare a un diverso dominio di collisione, che si potrebbe denire come un hub virtuale. I limiti di NetKit non permettono di modicare dallesterno i collegamenti tra una macchina virtuale e laltra, ad esempio eliminando il collegamento o facendo perdere una certa quantit di pacchetti, quindi per fare ci si ricorrer ad alcuni stratagemmi che si vedranno in seguito.
1
http://wiki.netkit.org
28
4 Realizzazione dei test
Figura 4.1. La rete che si andr a simulare nellambiente di test. I numeri di anco ai nodi indicano il Router ID
Non si tratter la congurazione di NetKit, perch abbastanza semplice, ma soprattutto perch allungherebbe inutilmente la trattazione oltre ad uscire dallo scopo del presente documento.
4.1.1
Installazione di Quagga e OLSRd su NetKit
Quagga gi installato di default nellultima release di NetKit fornita, peccato che non sia una versione molto recente. Questo comunque rappresenta solo un piccolo problema, in quanto limplementazione di OSPFv2 ormai consolidata. C solo un piccolo bug che non permette agli AS Boundary-Router di redistribuire le route del kernel o delle reti a loro direttamente connesse, quindi si sar costretti a congurare tali router impostando le route statiche allinterno del demone Zebra. OLSRd per contro non installato su NetKit, quindi stato necessario prelevare i relativi pacchetti deb dal sito della distribuzione GNU/Linux Debian e installarli a mano sulle macchine virtuali sfruttando lutility dpkg. 29
4.2
Congurazione di OSPF per la rete del CSP
Prima di cominciare a congurare Quagga sui router, necessario fermarsi un attimo a pensare come eettuare la divisione in aree del dominio di routing.
4.2.1
Divisione in aree
Essendoci essenzialmente due anelli, la tentazione sarebbe di creare unarea per anello oppure ununica area comprendente i due anelli. La questione della divisione in aree va studiata bene, in quanto in molti siti di supporto, compresa la mailing list di Quagga, viene suggerito che in OSPF sempre meglio non superare i 50 router per area. Questa aermazione per non ha nessuna fonte, in realt un limite euristico nato con tutta probabilit in anni in cui i router avevano capacit di elaborazione molto pi limitate di adesso. Una fonte molto autorevole che ci pu dare molte informazioni in proposito il sito internet di Cisco [4], dove si pu leggere che il numero massimo di router per area dipende soprattutto dalla potenza del processore dei router. Il traco OSPF infatti non varia signicativamente allaumentare della grandezza dellarea, mentre il lavoro richiesto dallalgoritmo di Dijkstra aumenta esponenzialmente. Sempre riguardo alla capacit di calcolo del router, viene detto di stare attenti al numero di aree collegate a un ABR in quanto tali router devono gestire un database per ogni area di cui fanno parte, ma questo un problema che riguarda solo reti decisamente grandi. Per ridurre il carico di lavoro interno ad unarea si consiglia di usare molto le aree totally stub dove possibile, ad esempio per quei rami della rete che si aacceranno sugli anelli2 . Allo stesso tempo sarebbe meglio cercare di raggruppare i range di indirizzi ip interni a queste aree, in modo che nella backbone venga comunicata una sola route, questo ridurrebbe il lavoro al di fuori dellarea. In ogni caso molto probabile che i router del CSP siano in grado di reggere ben pi di 50 router per area. Scelta fatta nella simulazione Per la simulazione stato scelto di dividere il sistema in due aree, vale a dire una per anello. Si sarebbe potuto scegliere un anello come area backbone e uno come area normale, ma questo avrebbe creato un sistema in un certo senso asimmetrico. Quindi si sono impostati entrambi gli anelli come aree normali distinte, poi i due router di bordo area sono stati collegati tramite un link virtuale passante allinterno di una delle due aree. Sarebbe stato pi corretto creare due link virtuali tra i due
2
qui si parla di rami della rete non presenti nella simulazione, in quanto fuori dagli anelli
30
router, uno passante su unarea e uno sullaltra, ma questo cambia poco ai ni della simulazione.
4.2.2
Hello Interval e Router Dead Interval
I tempi Hello Interval e Router Dead Interval sono particolarmente dicili da scegliere su una rete wireless. Visto che il protocollo OSPF nato per reti cablate (vedi 1.4 a pagina 18), se questi parametri vengono impostati in un certo modo si rischia di contare come non funzionante un link che tutto sommato ha una perdita di pacchetti accettabile, mentre un altro settaggio potrebbe portare a contare come validi dei link totalmente inutilizzabili. Per fare qualche esempio, impostando un Hello Interval di un secondo e un Router Dead Interval di 2 secondi si avrebbe che la perdita di un solo pacchetto Hello decreterebbe la caduta del link, quindi tutta la rete si ricongurerebbe in modo da utilizzare un altro percorso. Se per il link fosse di buona qualit, allora i due router recupererebbero in pochi secondi ladiacenza e il collegamento verrebbe di nuovo contato come utilizzabile dal protocollo. In questa situazione quindi si avrebbe una forte vulnerabilit dei link ai pacchetti persi, che probabilmente garantirebbe al sistema di utilizzare solo percorsi ottimi, ma allo stesso tempo genererebbe molto traco di controllo se molti link si mettessero a cadere e rialzarsi con molta frequenza. Per contro, se si aumenta il Router Dead Interval a 3 secondi devono essere persi 2 pacchetti Hello di seguito per decretare che un link sia down, quindi aumenta la probabilit che un link inadatto venga considerato valido, ma non c il rischio che una perdita isolata di un pacchetto Hello causi il dirottamento di tutto il traco su un altro percorso.
4.2.3
Hello Interval e Router Dead Interval sui link virtuali
Sui link virtuali si devono anche impostare i due intervalli Hello e Dead. Il valore di default molto alto, ed consigliato lasciarli cos. Questo perch quando un ABR viene a sapere dagli altri router che non pu pi raggiungere lABR che sta allaltro capo del link elimina direttamente ladiacenza, senza aspettare il Dead Interval sul link virtuale. Avere un Hello Interval molto basso quindi non serve a niente su un link virtuale, perch lesistenza o meno del percorso allinterno dellarea si conosce gi. 31
4.3
Test su OSPF
In questa sezione si vedranno i test fatti sulla rete simulata con il protocollo OSPF. Quando si parler di percentuale di pacchetti persi su un link, questo dato sar riferito ai pacchetti persi in entrambe le direzioni, quindi per perdita del 50% dei pacchetti si intende che viene perso il 50% dei pacchetti in una direzione e il 50% nellaltra. Nella pratica possibile che questa percentuale non coincida nelle due direzioni (infatti OLSR considera questa possibilit), ma facendo questa assunzione si evita di andare a complicare di molto le simulazioni. Per introdurre una perdita di pacchetti nelle macchine emulate con NetKit stato usato il comando tc, che in NetKit per stato rinominato in orig-tc, il quale permette di eliminare una certa percentuale dei pacchetti in uscita da uninterfaccia, con il comando orig-tc qdisc replace dev ethX root netem loss X%.
4.3.1
Traco di gestione della rete
Il traco di gestione di OSPF generalmente molto piccolo e si limita ai pacchetti Hello, che nel caso di reti punto-punto hanno una dimensione di 98 byte. Ci possono anche essere eventualmente alcuni pacchetti LS-Update che portano rispettivamente aggiornamenti sul cambiamento di stato di una route, se il cambiamento avvenuto fuori dallarea, oppure sul cambiamento di due Router LSA, in quanto per ogni variazione di un link allinterno dellarea vengono aggiornati i 2 Router LSA dei router che si aacciano sul link. Questi pacchetti hanno dimensioni di circa 150 byte. Il traco OSPF invece maggiore sulle adiacenze in fase di formazione, cio su quei link dove due router si vedono per la prima volta, in quanto sta avvenendo una sincronizzazione tra i due rispettivi database Link State (vedi 1.3.14 a pagina 13). Questi link per non sono usati per linstradamento del traco no alla ne della procedura di sincronizzazione, quindi lunico traco che devono poter supportare quello di OSPF che tutto sommato molto piccolo.
4.3.2
Tempi di reazione della rete con perdita totale dei pacchetti
I tempi di reazione ai guasti in una rete gestita con OSPF sono esattamente uguali al Router Dead Interval, in quanto dopo tale intervallo di tempo che il link in questione viene segnalato come non funzionante. La velocit ancora maggiore in caso di guasto di uninterfaccia del router, in quanto, a seconda del fatto se il driver in grado o no di rilevare il guasto, il nodo potrebbe aggiornare subito il suo Router LSA senza aspettare il Dead Interval. 32
4.3.3
Tempi di reazione della rete con perdita parziale dei pacchetti
Il discorso cambia se un link non completamente down ma perde solo una certa percentuale di pacchetti (vedi 4.2.2 a pagina 31). In questo caso sono stati eettuati vari test per vericare come viene trattato un link al cambiare della percentuale di pacchetti persi. In particolare sono state testate le congurazioni con Hello Interval di 1 secondo e Router Dead Interval di 2 secondi, e successivamente la congurazione stata cambiata aumentando Router Dead Interval a 3 secondi. Per il test stato generato traco costante di circa 20 000 Byte/s (10 KByte/s per direzione) tra il nodi PinoT e An (vedi gura 4.1 a pagina 29), poi stata impostata con orig-tc una certa perdita di pacchetti sul link tra i nodi CSP e ITG. Successivamente si catturato parallelamente il traco in transito sul link malato e quello sul link sano34 . Si pu cos notare che il link che perde pacchetti passa continuamente dallo stato di pienamente adiacente a non adiacente5 , quindi mentre il usso passa su questo link perde una quantit anche considerevole di pacchetti, invece se riesce a passare sul link sano non viene perso nemmeno un pacchetto.
Test con Router Dead Interval di 2 secondi Da questo test emerso che percentuali di pacchetti persi anche abbastanza basse, come il 5%, fanno passare il link molto frequentemente da utilizzabile a non utilizzabile. C per il pregio che gi con percentuali di pacchetti persi sul 20% il link viene usato molto poco per trasportare il traco. Nelle gure 4.2 e 4.3 si pu vedere il traco rispettivamente sul link sano e sul link con perdite nel caso di una percentuale di pacchetti persi del 50%. Nelle gure 4.4 e 4.5 vengono mostrati gli stessi graci con perdite del 40%, si pu notare che la situazione non cambia molto da quella con perdite del 50%, in quanto il link con perdite non viene praticamente mai utilizzato per portare traco. Si pu notare poi che nei graci successivi la situazione cambia radicalmente, no ad arrivare al punto (gure 4.14 e 4.15) che il traco passa per quasi tutto il tempo sul link dove ci sono perdite del 3% dei pacchetti.
Link sano: PinoT - Chiaves - Turu - An; Link con perdite: PinoT - ITG - CSP - An. 4 Notare che il nodo PinoT non utilizza mai il percorso tramite T3 per andare verso An, perch nel farlo uscirebbe e poi rientrerebbe nellarea 2. 5 Nella documentazione di OSPF i due stati vengono chiamati 1-Way e Full.
3
33
Figura 4.2. Traco sul link sano mentre sul link con perdite si perdono il 50% dei pacchetti (Router Dead Interval di 2 secondi).
Figura 4.3. Traco sul link dove vengono persi il 50% dei pacchetti (Router Dead Interval di 2 secondi).
34
35
36
37
38
Test con Router Dead Interval di 3 secondi Nei test con Router Dead Interval di 3 secondi6 si pu notare come la situazione cambi abbastanza radicalmente, infatti con basse percentuali di pacchetti persi molto pi dicile che ladiacenza cada, visto che bisogna perdere due pacchetti Hello di seguito. Anche in questo caso le rilevazioni di traco sono state fatte per percentuali di pacchetti persi del 50%, 40%, 30%, 20%, 10% e 5%. Non si riportano le rilevazioni con perdite di pacchetti del 3% in quanto tutte le volte che stata provata questa simulazione il traco sempre passato sul link con perdite, ed eettivamente la probabilit di pedere due pacchetti Hello di seguito in questo caso del 0,09%.
Hello Interval rimasto ad 1 secondo
39
40
41
42
43
4.3.4
Tempo di formazione delle adiacenze
Come spiegato nella sez. 1.3.14 a pagina 13, il procedimento di formazione delladiacenza prevede lo scambio di parecchi pacchetti, a seconda della dimensione dei database dei router. Solo alla ne di questa procedura il link su cui si formata ladiacenza pu essere usato per inoltrare il traco della rete. Le adiacenze si formano in tempi molto rapidi, nella rete di test di g. 4.1 a pagina 29 ad esempio in meno di un secondo. Al crescere della dimensione della rete comunque questo tempo dovrebbe rimanere basso perch il tempo che intercorre tra la ricezione di un pacchetto e la trasmissione della risposta molto basso. Se per questa procedura, studiata apposta in modo che ogni pacchetto sia lacknowledgement del precedente, si interrompe a causa di un pacchetto perso, ladiacenza impiegher pi tempo a formarsi in misura dellimpostazione di RxmtInterval 7 . Perch questo il tempo che viene aspettato da chi ha trasmesso un pacchetto per ricevere lAck. Se inoltre durante questo procedimento vengono persi alcuni pacchetti Hello, nel caso venga sforato il limite Router Dead Interval ladiacenza ritorna nello stato 1-Way e il processo deve ricominciare da capo. Per questo allaumentare dei pacchetti persi su un link aumenta anche il tempo necessario perch si riformi un adiacenza.
4.4
Test su OLSR
OLSR dovrebbe comportarsi meglio di OSPF sulle reti senza li, questo perch grazie alle metriche ETX dovrebbe essere di volta in volta essere selezionato il percorso con meno perdite di pacchetti.
4.5
Congurazione del demone
La congurazione di ogni nodo quella di default, visibile nella sez. 2.4 a pagina 20. Hello Interval impostato ad 1 secondo, TC Interval a mezzo secondo e MPR Coverage a 1. Questultimo parametro va impostato a un intero maggiore di 0 tanto pi grande quanto i nodi sono in movimento8 , in questo caso i nodi sono ssi quindi 1 va bene. In passato bisognava anche specicare la grandezza di una nestra di ricezione, in quanto la qualit dei link veniva calcolata sulla base degli ultimi n pacchetti Hello ricevuti e non. Dalla versione 0.5.6-rc7 del demone olsrd (attualmente siamo alla 6.0) questa funzionalit sembra essere deprecata, anche se la notizia non si trova
7 8
In Quagga questo intervallo chiamato retransmit-interval. Si ricorda che OLSR un protocollo per reti radiomobili
44
sul changelog uciale del progetto ma su siti di progetti che al loro interno usano olsrd[5].
4.5.1
Traco di gestione della rete
Come si gi detto nella sez. 2.2 a pagina 20 OLSR ha per sua natura un traco di gestione maggiore di OSPF. Con la congurazione scelta ogni nodo OLSR emette da ogni sua interfaccia 2 pacchetti grandi circa 500-600 byte al secondo, quindi il traco molto maggiore rispetto al traco medio di OSPF (1000 Byte/s contro 100 Byte/s).
4.5.2
Tempi di reazione della rete
OLSR, almeno nelle congurazioni provate, risultato essere molto lento nel reagire al cambio di qualit dei link. Sia in caso di caduta totale del collegamento, sia con qualsiasi percentuale di perdita dei pacchetti, OLSR ha impiegato sempre almeno 25 secondi a selezionare il percorso migliore. In alcuni casi, sopratutto con percentuali di pacchetti persi sotto il 50%, i tempi sono stati molto pi alti, e in qualche occasione si continuato ad usare il percorso peggiore senza che il protocollo riuscisse a selezionare il percorso dove non cerano perdite di pacchetti. Per completezza stata provata anche una vecchia versione di olsrd (la 0.5.6rc7), la quale permetteva ancora di impostare la nestra di ricezione su cui calcolare la qualit del link. Tale nestra stata impostata a 20 pacchetti Hello, cio 20 secondi, ma la situazione non cambiata.
45
Capitolo 5 Conclusioni
Il protocollo OSPF si rivelato abbastanza inadeguato alle reti wireless, in quanto non in grado di rilevare la qualit dei link e di cambiare le metriche di conseguenza.
5.1
Soluzioni proposte
Per risolvere questo problema si potrebbero realizzare delle soluzioni tampone, nel senso che non intervengono sul protocollo, ma che potrebbero essere abbastanza semplici da realizzare. Ad esempio si potrebbe realizzazione uno script che testi periodicamente il numero di pacchetti persi sul link e nel caso sia necessario modichi i costi delle interfacce sfruttando il fatto che Quagga pu essere congurato al volo. Una soluzione pi semplice, ma peggiore, potrebbe essere quella di disattivare OSPF sulle interfacce dove il numero di pacchetti persi supera una certa soglia, e riattivarlo quando la situazione rientra nella normalit. Un altro tipo di soluzione estendere il protocollo in modo che supporti le metriche ETX, o comunque un altro tipo di metriche pensate per le reti wireless, questa la soluzione adottata attualmente dai router Cisco[6].
5.2
Sviluppi futuri
Mentre i costruttori di router come Cisco hanno gi trovato soluzioni al problema, anche lo standard si sta evolvendo, proprio per inseguire le soluzioni di Cisco. Le estensioni future al protocollo OSPF verranno sviluppate solo per OSPFv3, inizialmente nato solo per reti IPv6, in quanto stato recentemente proposto uno standard (RFC 5838) che permetter a OSPFv3 di supportare anche reti IPv4[7]. Inoltre in fase di denizione unestensione di OSPFv3 pensata per le reti AdHoc radiomobili (RFC 5614)[8]. Gli autori di questa estensione, tra i quali c 46
5 Conclusioni
la Boeing, stanno sviluppando insieme alla marina militare degli Stati Uniti una variante di Quagga in grado di supportare questa estensione[9]. Anche se questa variante di Quagga stata rilasciata molto recentemente (maggio 2011), lo stato dello sviluppo sembra essere abbastanza avanzato in quanto le release note indicano che vengono implementate entrambe le RFC 5614 e 5838. Inoltre limplementazione va leggermente oltre lRFC perch implementa anche formule per il calcolo delle metriche che tengono conto di pi fattori oltre al numero di pacchetti persi, come la banda totale teorica del link e la banda eettiva del link. Potrebbe essere interessante testare a dovere questa variante di Quagga.
47
Appendice A Pacchetti OSPF

In questa appendice verranno presentati gli schemi dei pacchetti OSPFv2 cos come compaiono nella reference RFC 2328[1]. Il signicato dei campi dei pacchetti gi stato spiegato nella sez. 1.3 a pagina 5.
A.1
A.1.1
Pacchetti
Pacchetto Hello
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 1 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | Options | Rtr Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 48
A Pacchetti OSPF
| RouterDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Designated Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
A.1.2
Pacchetto Database Description
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 2 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface MTU | Options |0|0|0|0|0|I|M|MS +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DD sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+ | | +An LSA Header -+ | | +-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 49
A Pacchetti OSPF
A.1.3
Pacchetto LS-Request
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 3 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
A.1.4
Pacchetto LS-Update
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 4 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | 50
A Pacchetti OSPF
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # LSAs | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSAs | +-+ ... +-+ | |
A.1.5
Pacchetto LS- Acknowledgement
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | 5 | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | AuType | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +An LSA Header -+ | ... |
A.2
A.2.1
LSA
LSA Header
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | LS type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 51
A Pacchetti OSPF
| Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A.2.2
Router LSA
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |V|E|B| 0 | # links | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | # TOS | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | 0 | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | 52
A Pacchetti OSPF
A.2.3
Network LSA
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attached Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
A.2.4
Summary LSA
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 3 or 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TOS | TOS metric | 53
A Pacchetti OSPF
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |
A.2.5
AS-External LSA
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS age | Options | 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link State ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Advertising Router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Mask | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| 0 | metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E| TOS | TOS metric | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Forwarding address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | External Route Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | External Route Tag non stato spiegato perch non viene usato dal protocollo OSPF
54
Appendice B NetKit
NetKit (http://wiki.netkit.org) il simulatore di reti usato per eettuare i test. Le macchine virtuali possono essere collegate in rete tra loro oppure anche alla macchina reale attraverso uninterfaccia tap.
B.1
Requisiti
NetKit funziona anche su computer molto poco potenti e con relativamente poca ram, anche solo 256 MB. Lunico requisito riguarda lutilizzo su sistemi operativi a 64 bit, essendo NetKit compilato a 32 bit, bisogna installare le librerie per poter eseguire software a 32 bit (libc6-i386 e ia32-libs sono nominate nella documentazione).
B.2
Installazione
Per linstallazione bisogna procurasi da http://wiki.netkit.org/index.php/Download_ Official i componenti: Core: contiene i comandi e un po di documentazione; File System: contiene il le system delle macchine virtuali; Kernel: contiene il kernel che verr eseguito in user space per far funzionare le macchine virtuali. Nei test sono state utilizzate rispettivamente le versioni 2.8 per il Core e il Kernel e la versione 5.2 del File System. Ognuno dei 3 componenti pu avere un numero di versione dierente. I le vanno scompattati nella stessa directory, verr creata una directory netkit. molto impostante usare un le system che supporti i le sparsi (EXT3/4 vanno 55
B NetKit
bene, ma ad esempio JFS e XFS no), e mentre si scompattano i le passare al comando tar anche il parametro S che attiva il supporto ai le sparsi. Se non si fa questo, ogni macchina virtuale occuper 10 GB di disco. Si ricorda che NetKit usa UML (User Mode Linux), un kernel eseguito in user space che assomiglia a una macchina virtuale, ma di fatto non si pu decidere lhardware da emulare quindi non un vero emulatore.
B.2.1
Congurazione post-installazione
Bisogna aggiornare la variabile di sistema PATH, pi crearne un paio di nuove, per questo si possono usare i comandi: export NETKIT_HOME=/home/foo/netkit export MANPATH=:$NETKIT_HOME/man export PATH=$NETKIT_HOME/bin:$PATH Aggiungere eventualmente questo comando al proprio le di congurazione della shell (.bashrc nel caso di shell bash). Si pu controllare la correttezza di questa congurazione entrando nella cartella di netkit ed eseguendo lo script: ./check_configuration.sh
B.3
vstart vhalt lstart lhalt
Comandi
fa partire una singola macchina virtuale; arresta una singola macchina virtuale; avvia un intero laboratorio o singole macchine che ne fanno parte; arresta un intero laboratorio o singole macchine che ne fanno parte;
B.4
Creare un laboratorio
Le reti simulate in NetKit si chiamano laboratori. Per crearne uno bisogna creare una directory vuota per ogni macchina virtuale da far partire con il nome della macchina virtuale. Bisogna anche creare un le di congurazione del laboratorio lab.conf che contiene la descrizione della topologia della rete e i parametri da passare alle macchine virtuali. Per ogni macchina virtuale poi si pu creare un le nome_macchina.startup che contiene le istruzioni da eseguire sulla macchina virtuale al suo avvio. Tutti questi le, e le cartelle vuote con i nomi delle macchine virtuali, devono essere messe in una cartella che sar la cartella del laboratorio. 56
B NetKit
B.4.1
File lab.conf
Nel le ogni riga ha una sintassi del tipo nome_macchina[parametro] = valore Se come parametro viene scritto un numero, quel numero indicher una scheda di rete ethX (dove X il numero) e il valore indicher il nome di uno switch virtuale a cui la scheda collegata. Se il parametro non un numero, allora un parametro della macchina virtuale (vedere man vstart), ad esempio la memoria ram della macchina emulata. Per le periferiche tap vedere la pagina di manuale di vstart.
B.4.2
Esempio di le lab.conf
Si prende il le lab.conf usato per la rete in g. 4.1 a pagina 29. an[0]=n7 an[1]=n6 anonimo[mem]=256 csp[0]=n6 csp[1]=n4 csp[2]=n10 csp[3]=n3 csp[4]=tap,192.168.0.1,192.168.0.3 csp[mem]=256 vg[0]=n10 vg[1]=n15 vg[2]=tap,192.168.0.1,192.168.0.2 vg[mem]=256 itg[0]=n3 itg[1]=n2 itg[mem]=256
pinot[0]=n2 pinot[1]=n1 pinot[2]=n9 pinot[mem]=256 t3[0]=n4 t3[1]=n1 57
B NetKit
t3[2]=n5 t3[mem]=256 chiaves[0]=n9 chiaves[1]=n8 chiaves[mem]=256 turu[0]=n7 turu[1]=n8 turu[mem]=256 calvo[0]=n5 calvo[1]=n11 calvo[mem]=256 morra[1]=n11 morra[0]=n12 morra[mem]=256 alb[0]=n12 alb[1]=n13 alb[mem]=256 sup[0]=n13 sup[1]=n14 sup[mem]=256 tb1[0]=n14 tb1[1]=n15 tb1[mem]=256
B.4.3
Esempio di le .startup
Nella simulazione della rete HPWNet i le nome_macchina.startup sono stati usati per congurare allavvio gli indirizzi delle macchine virtuali ed avviare il demone Quagga. Di seguito il sile csp.startup del laboratorio che riproduce la rete in g. 4.1 a pagina 29. #file startup della macchina CSP ip addr add 10.0.0.6/30 dev eth0 brd + 58
B NetKit
ip link set eth0 up ip addr add 10.0.0.9/30 dev eth1 brd + ip link set eth1 up ip addr add 10.0.0.13/30 dev eth2 brd + ip link set eth2 up ip addr add 10.0.0.17/30 dev eth3 brd + ip link set eth3 up ip addr add 192.168.1.2/24 dev eth4 brd + ip link set eth4 up /etc/init.d/quagga start
B.5
Trasferimento le tra macchina virtuale e host
Per trasferire i le tra macchine virtuali e macchina host si possono sfruttare le cartelle /hosthome e /hostlab in ogni macchina virtuale. La prima punta alla cartella home dellutente che ha in esecuzione la macchina virtuale, la seconda alla cartella che contiene il laboratorio virtuale.
59
Appendice C Esempi le di congurazione Quagga

Alcuni le di congurazione presi dalla rete emulata di g. 4.1 a pagina 29. Dove le linee niscono con il segno %, signica che la linea era troppo lunga e continua sulla successiva.
C.1
File zebra.conf
File zebra.conf della macchina CSP ( 4.1 a pagina 29). hostname Router password zebra log file /var/log/quagga/zebra.log ! interface eth0 description link verso anonimo link-detect ! interface eth1 description link verso T3 link-detect ! interface eth2 description link verso VG link-detect ! interface eth3 description link verso ITG 60
C Esempi le di congurazione Quagga
link-detect ! interface eth4 ! interface lo ! interface teql0 ipv6 nd suppress-ra ! ip forwarding ! ip route 0.0.0.0/0 192.168.0.1 ! line vty
C.2
C.2.1
File ospfd.conf
Router interno
File ospfd.conf del router interno Morra ( 4.1 a pagina 29). hostname ospfd password zebra log file /var/log/quagga/ospfd.log ! interface eth0 ip ospf network point-to-point ip ospf authentication message-digest ip ospf message-digest-key 1 md5 area1 ip ospf hello-interval 1 ip ospf dead-interval 3 ip ospf retransmit-interval 3 ! interface eth1 ip ospf network point-to-point ip ospf authentication message-digest ip ospf message-digest-key 1 md5 area1 ip ospf hello-interval 1 ip ospf dead-interval 3 ip ospf retransmit-interval 3 61
! interface lo ! interface teql0 ! router ospf ospf router-id 0.0.0.10 log-adjacency-changes detail network 10.0.0.40/30 area 0.0.0.1 network 10.0.0.44/30 area 0.0.0.1 area 0.0.0.1 authentication message-digest ! line vty
C.2.2
Area Border Router con Link Virtuale
File ospfd.conf del router ABR T3( 4.1 a pagina 29). hostname ospfd password zebra log file /var/log/quagga/ospfd.log ! ! ! interface eth0 ip ospf network point-to-point ip ospf authentication message-digest ip ospf message-digest-key 1 md5 area1 ip ospf cost 10 ip ospf hello-interval 1 ip ospf dead-interval 3 ip ospf retransmit-interval 3 ! interface eth1 ip ospf network point-to-point ip ospf authentication message-digest ip ospf message-digest-key 2 md5 area2 ip ospf hello-interval 1 ip ospf dead-interval 3 ip ospf retransmit-interval 3 ! 62
interface eth2 ip ospf network point-to-point ip ospf authentication message-digest ip ospf message-digest-key 1 md5 area1 ip ospf hello-interval 1 ip ospf dead-interval 3 ip ospf retransmit-interval 3 ! interface lo ! router ospf ospf router-id 0.0.0.2 ospf abr-type standard log-adjacency-changes detail network 10.0.0.8/30 area 0.0.0.1 network 10.0.0.36/30 area 0.0.0.1 network 10.0.0.24/30 area 0.0.0.2 area 0.0.0.0 authentication message-digest area 0.0.0.1 authentication message-digest area 0.0.0.2 authentication message-digest area 0.0.0.1 virtual-link 0.0.0.1 hello-interval 10 retransmit-interval 5 % transmit-delay 1 dead-interval 40 area 0.0.0.1 virtual-link 0.0.0.1 message-digest-key 1 md5 area1virtual ! line vty
C.2.3
AS Boundary Router interno a un area
File ospfd.conf del router AS Boundary Router VG( 4.1 a pagina 29). hostname ospfd password zebra log file /var/log/quagga/ospfd.log ! interface eth0 ip ospf network point-to-point ip ospf authentication message-digest ip ospf message-digest-key 1 md5 area1 ip ospf hello-interval 1 ip ospf dead-interval 3 ! 63
interface eth1 ip ospf network point-to-point ip ospf authentication message-digest ip ospf message-digest-key 1 md5 area1 ip ospf hello-interval 1 ip ospf dead-interval 3 ! interface eth2 ! interface lo ! interface teql0 ! router ospf ospf router-id 0.0.0.3 log-adjacency-changes detail redistribute static network 10.0.0.12/30 area 0.0.0.1 network 10.0.0.56/30 area 0.0.0.1 area 0.0.0.1 authentication message-digest default-information originate metric 100 metric-type 1 ! line vty
64
Bibliograa
[1] J. Moy - Ascend Communications Inc., RFC 2328: OSPF Version 2, http: //tools.ietf.org/html/rfc2328, April 1998. [2] P. Murphy, RFC 3101: The OSPF Not-So-Stubby Area (NSSA) Option, http: //tools.ietf.org/html/rfc3101, January 2003. [3] Claudio Jeker, Internet Business Solutions AG, Design and Implementation of OpenOSPFD, www.networx.ch/OpenOSPFD-Paper.pdf [4] Cysco Systems, OSPF Design Guide, http://www.cisco.com/en/US/tech/ tk365/technologies_white_paper09186a0080094e9e.shtml, August 2005 [5] Freifunk Firmware Changelog, http://ipkg.berlin.freifunk.net/ChangeLog, August 2008. [6] Cysco Systems, OSPFv3 Dynamic Interface Cost Support, http://www.cisco. com/en/US/docs/ios/12_4t/12_4t15/odics_ST.html, 2007 [7] A. Lindem - Ericsson, S. Mirtorabi, A. Roy, M. Barnes - Cisco Systems, R. Aggarwal - Juniper Networks, RFC 5838: Support of Address Families in OSPFv3, http://tools.ietf.org/html/rfc5838, April 2010. [8] R. Ogier - SRI International, P. Spagnolo - Boeing, RFC 5614: Mobile Ad Hoc Network (MANET) Extension of OSPF Using Connected Dominating Set (CDS) Flooding, http://tools.ietf.org/html/rfc5614, August 2009. [9] P. Spagnolo, Release Notes for the Mobile Routing variant of Quagga, http://downloads.pf.itd.nrl.navy.mil/ospf-manet/quagga-0.99.17mr2. 0/RELEASE_NOTES.MobileRouting, May 2011
65

Algoritmi Di Routing in Reti Magliate Wireless

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Algoritmi Di Routing in Reti Magliate Wireless

Transféré par

Droits d'auteur :

Formats disponibles

POLITECNICO DI TORINO

III Facolt di Ingegneria

Algoritmi di routing in reti magliate wireless

Supervisore Aziendale Ing. Andrea Ghittino

5 Conclusioni 46 5.1 Soluzioni proposte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 5.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 iv

Capitolo 1 Introduzione teorica a OSPF

Protocolli Link State

1 Introduzione teorica a OSPF

1 Introduzione teorica a OSPF

1 Introduzione teorica a OSPF

Contiguit dellarea Backbone

1 Introduzione teorica a OSPF

Esempio di Automous System gestito con OSPF

1 Introduzione teorica a OSPF

1 Introduzione teorica a OSPF

1 Introduzione teorica a OSPF

Cosa sono le adiacenze

1 Introduzione teorica a OSPF

Elezione del Designated Router e del suo Backup

Il database Link State

1 Introduzione teorica a OSPF

1 Introduzione teorica a OSPF

Descrizione Link punto-punto

Link ID Router ID del vicino

Link Data Indirizzo IP dellinterfaccia del router (se c) Indirizzo IP dellinterfaccia

Link a una rete Indirizzo IP del DR di transito della rete

1 Introduzione teorica a OSPF

LSA speciali per le aree NSSA

1 Introduzione teorica a OSPF

Pacchetti OSPF non Hello

Creazione delle adiacenze

1 Introduzione teorica a OSPF

1 Introduzione teorica a OSPF

1 Introduzione teorica a OSPF

Confrontare due LSA

Impostazione del costo di un collegamento

Valore non impostabile nelle implementazioni di OSPF.

1 Introduzione teorica a OSPF

Creazione delle tabelle di routing

Bilanciamento del carico con OSPF

1 Introduzione teorica a OSPF

Considerazioni sui link virtuali

Considerazioni nali su OSPF

OSPF su reti wireless

Capitolo 2 Il protocollo di routing OLSR

Calcolo delle metriche ETX

2 Il protocollo di routing OLSR

Congurazione di base del demone OLSRd

vedi il sito http://www.olsr.org vedi il sito http://olsrdq.sourceforge.net/

2 Il protocollo di routing OLSR

Capitolo 3 Implementazioni di OSPF

Congurazione del demone Zebra

Congurazione del demone ospfd

Capitolo 4 Realizzazione dei test

Simulatore di reti NetKit

4 Realizzazione dei test

Installazione di Quagga e OLSRd su NetKit

4 Realizzazione dei test

Congurazione di OSPF per la rete del CSP

4 Realizzazione dei test

Hello Interval e Router Dead Interval

Hello Interval e Router Dead Interval sui link virtuali

4 Realizzazione dei test