Esperimenti di Networking per un uso didattico di una piattaforma di emulazione cluster based

Transcript

1 Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica tesi di laurea Esperimenti di Networking per un uso didattico di una piattaforma di emulazione cluster based Anno Accademico 2009/2010 relatore Ch.mo Prof. Roberto Canonico correlatore Ch.mo Ing. Roberto Bifulco candidato Andrea Rescigno matr. O41/ I

2 Dedicato ad alcuni II

3 Indice Introduzione 5 Capitolo I Importanza degli ambienti di test per le applicazioni distribuite 7 I.1 Simulazione 8 I.1.2 Ns2 ed Ns3 9 I.2 Testbed reali 9 I.3 Network testbed 10 I.3.1 Planet Lab 10 I.4 Emulazione 12 I.5 Emulazione su cluster 13 I.5.1 Emulab 14 I.6 Il multiplexing delle risorse 15 I.7 Conclusioni 16 Capitolo II Neptune 17 Introduzione al capitolo 18 II.1 Organizzazione di Neptune 19 II.2 Il multiplexing delle risorse in Neptune 20 II.3 La gestione degli esperimenti 22 II.4 Utenti e ruoli 23 II.5 L esperimento 25 II.6 La topologia 27 II.7 La rete di controllo 28 II.8 Creare un esperimento con Neptune 29 II.8.1 Operazioni preliminari 29 II.8.2 Creazione di un esperimento 32 II.9 Rete con routing statico 40 II.10 Una prima fase di testing 45 II.10.1 Ping 45 II.10.2 Traceroute 46 Capitolo III Il routing dinamico 48 Introduzione al capitolo 49 III.1 Distance Vector 49 III

4 III.1.1 Costruzione della topologia 50 III.1.2 Indisponibilità di un ramo 56 III.1.3 L algoritmo di Bellman-Ford 63 III.2 Il protocollo RIP 64 III.2.1 Versioni disponibili 64 III.2.2 Problemi del protocollo 65 III.2.3 Ottimizzazioni 65 III.3 Link State 66 III.3.1 L algoritmo di Dijkstra 39 III.4 Il protocollo OSPF 70 III.4.1 Caratteristiche aggiuntive del protocollo 70 III.4.2 Organizzazione di una rete OSPF 71 III.4.3 Tipi di router OSPF 71 III.5 Quagga 73 III.5.1 Installare Quagga 74 III.5.2 Configurare Quagga 75 III.5.3 Vtysh 78 III.5.4 Modifica manuale dei file di configurazione 81 III.5.5 IP Forwarding 82 III.6 Conclusioni 82 Capitolo IV Rete con protocollo RIP 83 Introduzione al capitolo 84 IV.1 Configurazione delle macchine 84 IV.2 Testing 92 IV.2.1 Esame tabella di Routing 92 IV.2.2 Verifica della connettività 92 IV.2.3 Tracciamento dei messaggi sui nodi 94 IV.2.4 Comportamento in caso di Link fail 101 Capitolo IV Rete con protocollo OPSF 104 Introduzione al capitolo 105 V.1 Attivazione del daemon ospf 105 V.2 Configurazione dei router 109 V.3 Testing 110 V.3.1 Esame tabella di Routing 110 IV.3.2 Verifica della connettività 111 IV.3.3 Tracciamento dei messaggi sui nodi 111 IV.3.4 Comportamento in caso di Link fail 113 Conclusioni e sviluppi futuri 115 Bibliografia 116 IV

5 Introduzione Il presente lavoro di tesi si prefigge come scopo la presentazione di una didattica chiara e accessibile per la creazione di alcuni semplici esperimenti di routing utilizzando l ambiente Neptune. Neptune, sviluppato dall Università degli Studi di Napoli Federico II, si presenta come una soluzione per l emulazione di rete basata su cluster di macchine che, mettendo a disposizione su hardware general purpose un ambiente multiutente e accessibile da remoto, permette l esecuzione di diversi scenari di rete. Come tutti gli ambienti di emulazione/simulazione anche Neptune soffre di una certa difficoltà di utilizzo da parte dell utente non specializzato: proprio per questi motivi cercheremo in questa sede di schematizzare i comandi da eseguire e i passaggi da effettuare per creare uno scenario di rete utile all esecuzione di esperimenti di base. Verranno quindi poste le basi per l esecuzione di esperimenti più complessi che hanno reso le piattaforme di test bed per le applicazioni distribuite così diffuse. Sarà possibile controllare la gestione di imponenti traffici di dati, la conseguente gestione della congestione, la reazione della rete a problemi casuali o sistematici, le prestazioni di un determinato protocollo. Nel primo capitolo introdurremo brevemente gli ambienti di test, presenteremo le diverse tipologie sottolineando vantaggi e svantaggi dell una rispetto a un altra e tratteremo brevemente alcuni esempi reali. 5

6 Il secondo capitolo è interamente dedicato a Neptune: ne presenteremo la struttura base, accennando brevemente anche alla sua implementazione, esaminando il ruolo di utente ed amministratore, le azioni che possono essere compiute e il concetto di creazione di un esperimento. Introdurremo quindi l interfaccia Web e illustreremo la creazione di un semplice esperimento. Verrà quindi introdotta una semplice topologia al fine di apprendere le basi per una corretta configurazione delle macchine virtuali per un primo esempio di Routing statico. Il terzo capitolo è dedicato all introduzione del Routing dinamico, alle problematiche ad esso legate e ai protocolli negli anni introdotti. Esamineremo quindi i protocolli Rip e Ospf, esaminandone il funzionamento con una serie di esempi step by step e valutando i loro pregi e difetti. Introdurremo quindi Quagga : un software open source per il Routing dinamico, pienamente compatibile con i protocolli descritti. Forniremo quindi una semplice guida per installare e configurarlo su una macchina virtuale. Il quarto capitolo si prefigge come scopo la creazione di una rete con Routing dinamico utilizzando il protocollo Rip: verranno indicati i passaggi da seguire e la corretta compilazione del file di configurazione del protocollo usato. Verranno quindi introdotti una serie di test atti a sondare la rete per individuare eventuali problemi. Verrà quindi introdotto il concetto di sniffing dei pacchetti e saranno simulati problemi comuni quali ad esempio la caduta di una sottorete per evidenziare il comportamento di Quagga nella fase di aggiornamento nodi e ricerca di una via alternativa. Il quinto capitolo, infine, introdurrà all interno dell ambiente precedentemente creato il protocollo Ospf: vedremo come modificare le impostazioni della rete ed eseguiremo anche in questo caso una sequenza di semplici test. 6

7 Capitolo I Importanza degli ambienti di test per le applicazioni distribuite Al giorno d oggi per testare la robustezza e i diversi aspetti di un nuovo protocollo, o di uno già esistente, c è bisogno di avere a disposizione ambienti reali o simulati che garantiscano tali potenzialità. Per valutare nuovi protocolli è, infatti, necessario condurre una serie di esperimenti che evidenzino le innovazioni che essi comportano. I parametri che uno sperimentatore potrebbe voler misurare sono il throughput offerto dallo specifico protocollo, la sua robustezza a condizioni spinte di traffico, l affidabilità, l equità e così via. Simulazione, emulazione ma anche sperimentazione su testbed reali sono tecniche molto utili nell ambito dell analisi e dello studio di protocolli ed applicazioni di rete; possono inoltre essere utilizzate dai ricercatori per il progetto e lo sviluppo di nuovi sistemi. Essi, dunque, costituiscono strumenti per eseguire sperimentazioni che pongono come obiettivo: il progetto di nuovi protocolli, applicazioni o sistemi la convalida del comportamento di protocolli di rete già esistenti la valutazione dell interazione tra protocolli in un ambiente controllato il confronto tra sistemi già implementati la determinazione del valore ottimale di un dato parametro la predizione delle prestazioni di un sistema nel futuro la determinazione dei punti critici di un sistema 7

8 I.1 Simulazione La simulazione è un processo di imitazione delle operazioni eseguite nel tempo da un sistema reale. Rappresenta infatti la trasposizione, in termini logico-matematicoprocedurali, di un modello concettuale della realtà. Tale modello concettuale può essere definito come l insieme di processi che hanno luogo nel sistema valutato e il cui insieme permette di comprendere le logiche di funzionamento del sistema stesso. La simulazione consente di valutare e prevedere lo svolgersi dinamico di una serie di eventi susseguenti all imposizione di certe condizioni da parte dell analista. Gli scopi della simulazione sono molteplici: analisi delle prestazioni, determinazione delle criticità del sistema (attuali o future), confronto tra sistemi, progettazione di sistemi ipotetici, ottimizzazione. Naturalmente esistono numerose aree di applicazione, che vanno dai sistemi di elaborazione e comunicazione fino ai sistemi militari sociali ed economici. Applicata all ambito delle reti la simulazione fornisce un ambiente ripetibile e controllato per eseguire un esperimento, consentendo l utilizzo di strumenti semplici da configurare per la progettazione e l implementazione di protocolli a diversi livelli di astrazione. Nella simulazione delle reti è molto usata la tempificazione ad eventi discreti dove gli stati del modello cambiano solo in istanti discreti del tempo. L accuratezza della simulazione varia in relazione al livello di astrazione del modello. Quando è utilizzato un alto livello di dettaglio, l efficienza e la scalabilità della simulazione ne risentono. Al contrario, se si desidera una simulazione rapida bisogna tralasciare qualche dettaglio rinunciando alla piena accuratezza del modello da simulare. Lo scopo dei simulatori di reti è quello di modellare le reti del mondo reale: se un sistema può essere modellato, infatti, le caratteristiche del modello possono essere modificate ed i risultati possono essere quindi analizzati. 8

9 Il principale difetto dei Network emulator risiede dunque nella loro natura prettamente simulativa che, pur presentando il vantaggio della notevole semplicità, impedisce una visione completa dell andamento della rete. I.1.2 Ns2 ed Ns3 Ns è un simulatore di reti open source a eventi discreti pensato per uso didattico e di ricerca, nato come una variante del REAL Network Simulator. Nel corso degli anni ha subito un graduale e consistente sviluppo supportato dalla DARPA e da diverse altre società. Permette il supporto di più interfacce di rete sui nodi, l uso dell indirizzamento Ip e un buono anche se parziale supporto ai protocolli diffusi maggiormente su internet. Ns2 usa il C++ come linguaggio principale e OTcl per il controllo della simulazione, pertanto è richiesta una certa conoscenza di entrambi i linguaggi per poterlo usare. Inoltre è poco scalabile e presenta una forte discontinuità nel passaggio da simulazione a sperimentazione I principali pregi di Ns sono la sua ottima diffusione, la conseguente disponibilità di moduli aggiuntivi, il codice stabile e la molta documentazione disponibile. Pur partendo dalla stessa base Ns3 costituisce una versione totalmente nuova del precedente Ns2. Il suo principale difetto è la relativa giovinezza del progetto, testimoniata dalle numerose release che si susseguono a intervalli temporali piuttosto brevi, nell ordine dei 3 mesi. I.2 Testbed reali All opposto della simulazione troviamo la sperimentazione su infrastrutture di rete (testbed) costruite appositamente per la valutazione e la verifica di applicazioni distribuite. La possibilità di disporre di un ambiente dove macchine reali siano effettivamente collegate tra loro ci fornisce il massimo livello di realismo e trasparenza e replicazione nella trattazione di qualsiasi esperimento. 9

10 Tuttavia, bisogna considerare che l utilizzo di un ambiente di testbed per la valutazione di nuove applicazioni pone diverse difficoltà. Un primo problema è dovuto all elevato costo dell hardware necessario alla sua implementazione. Diretta conseguenza può essere quindi la sperimentazione su reti abbastanza limitate sia per il problema economico appena elencato, sia perché è necessario disporre di ambienti adeguati all entità della rete. Altro aspetto negativo può essere il carico di lavoro necessario a mettere a disposizione tutto l ambiente creato per un altra applicazione. I.3 Network Testbed I Network Testbed prendono come punto di partenza il concetto di sperimentazione su un ambiente reale e lo portano all estremo: sono, di fatto, delle reti a grandezza globale, per certi versi pubbliche, messe a disposizione per permettere un livello di realismo impareggiabile. Risentono comunque di una scarsa capacità di replicazione dovuta sia al sovraccarico continuo di diversi nodi sia all estrema variabilità di Internet stessa: è praticamente impossibile ottenere risultati identici in istanti diversi per un singolo esperimento. I.3.1 Planet Lab PlanetLab è un testbed globale di ricerca che supporta lo sviluppo di nuovi servizi di rete. L'uso di PlanetLab da parte di ricercatori o industrie è stato incentrato verso lo sviluppo di nuove tecnologie per l'archiviazione distribuita, network mapping, sistemi peer-to-peer, ecc. PlanetLab, per effettuare il testing di servizi su larga scala, adopera 912 nodi dislocati in 473 siti. In ogni nodo sono istanziate delle macchine virtuali che permettono di eseguire più esperimenti in contemporanea e di ottimizzare le risorse disponibili. Ciascun 10

11 esperimento viene eseguito in una slice, ossia adopera un insieme delle macchine virtuali dislocate in un sottoinsieme dei nodi del testbed. Ciascuna di queste macchine virtuali è connessa alle altre tramite internet. Dislocamento globale dei nodi di PlanetLab Per la realizzazione delle macchine virtuali PlanetLab adopera la LightWeight Virtualization, in cui viene garantito l'isolamento fra le diverse macchine virtuali, ma la virtualizzazione è ottenuta semplicemente modificando in parte il kernel del sistema operativo. Questo approccio costringe l'utilizzo dello stesso sistema operativo per tutte le macchine virtuali, limitando non solo la scelta dell'ambiente operativo ma anche le possibilità di modifica e personalizzazione degli aspetti di basso livello della gestione di rete, come la gestione del protocollo IP. Per queste caratteristiche, PlanetLab è adoperato per lo più per lo sviluppo di applicazioni del livello applicazione dello stack protocollare di rete. 11

12 I.4 Emulazione L emulazione si pone a metà strada tra la simulazione e il test reale. Essa consente l analisi delle dinamiche di un sistema reale attraverso un modello concettuale, permettendo l interfacciamento del sistema con il mondo esterno. L emulazione di una rete rappresenta dunque un approccio ibrido che combina elementi reali (come host e implementazioni di protocolli) con elementi sintetici, astratti o simulati di una rete (come link, nodi intermedi e traffico di background). In sostanza con il termine emulazione ci si riferisce alla capacità di inserire un simulatore all interno di una rete reale. Di conseguenza essa fornisce un ambiente che è più vicino alla realtà ed è un valido strumento per la valutazione delle prestazioni e delle funzioni di componenti reali sotto varie condizioni di funzionamento. Poiché l'obiettivo dell'emulazione è far coesistere e cooperare elementi reali con elementi simulati, è necessario che questi ultimi siano capaci di interagire con i componenti di rete e le applicazioni reali. Questa necessità si presenta a causa della fondamentale differenza che sussiste fra simulazione ed emulazione: nella simulazione l'esperimento è condotto in un tempo fittizio, totalmente slegato dalla realtà e dipendente soltanto dal simulatore, nell'emulazione l'esperimento è condotto nel tempo reale, poiché gli elementi reali sono parte integrante dell'ambiente emulato. 12

13 I.5 Emulazione su cluster Un trend che ha avuto molto successo negli ultimi anni nell'ambito dell'emulazione di rete è la cluster based emulation. Un computer cluster o più semplicemente cluster (dall inglese grappolo) è un sistema hardware modulare costituito da un insieme di computer connessi tramite una rete telematica ad alta velocità. Il cluster è generalmente dotato e di strumenti di amministrazione di base che ne semplificano la gestione di basso livello. Inoltre è scalabile e si adatta alla crescita del business aziendale. I singoli moduli hardware sono inseriti in rack e possono essere gestiti e manutenuti anche da personale non superspecializzato. Lo scopo di un cluster è generalmente quello di distribuire una computazione molto complessa tra i vari computer componenti del cluster stesso. In sostanza un problema che richiede molte elaborazioni viene scomposto in sotto-problemi separati che poi vengono risolti in parallelo. In ambito emulativo i cluster sono molto utilizzati per la realizzazione dell emulazione di reti, poiché questi sistemi comprendono un largo insieme di componenti (link, switch, router, ecc.) organizzati in un'unica infrastruttura, facilmente accessibile anche da remoto (con opportune interfacce). L'esempio più significativo di sistema di emulazione cluster based è certamente Emulab. 13

14 I.5.1 Emulab Uno dei sistemi per l emulazione cluster based più complessi è probabilmente Emulab. Si tratta di una piattaforma fre-for-use sviluppata presso l Università dello Utah. E accessibile via web ed è progettato per essere time e spaceshared. Fornisce l accesso integrato ad un ampia gamma di ambienti sperimentali. Alla base del suo funzionamento vi è un cluster composto da alcune centinaia di server disposti ordinatamente all interno di grossi armadi. I server sono organizzati in modo opportuno dal punto di vista della sicurezza. Un insieme di strumenti web forniscono l accesso alle macchine. Attraverso script ns-compatibili oppure GUI in JAVA è possibile agire sulla configurazione ed il controllo della topologia della rete da emulare. La multiplazione dei nodi avviene attraverso jail. Si tratta di una versione di FreeBSD che consente la creazione di ambienti isolati di esecuzione (vnodes). Ogni vnode è accessibile attraverso il sistema ospite oppure via rete mediante il server sshd. Questa tecnica richiede poche risorse e quindi consente di creare numerose istanze di vnode sulla medesima macchina fisica anche quando quest ultima non è particolarmente performante. Tuttavia questa tecnica non offre un elevato livello di isolamento tra le differenti istanze di vnodes. Per queste ragioni ogni vnode in esecuzione su di una macchina fisica deve appartenere alla stesso esperimento. Anche le risorse di rete non sono completamente virtualizzate in quanto una parte della pila protocollare è condivisa tra i diversi vnode ed il nodo fisico. 14

15 I.6 Il multiplexing delle risorse La dimensione massima di un esperimento verificabile su di un ambiente di testbed è limitata dal numero di PC disponibili e dal numero di interfacce di rete presenti. Tuttavia l approccio basato sull emulazione suggerisce la possibilità di usare degli elementi virtualizzati che condividono le risorse fisiche disponibili. Questa scelta consente una riduzione della dimensione dell hardware necessario per l implementazione dell esperimento ed offre maggiore scalabilità. Ad esempio gruppi di nodi connessi tra loro possono essere emulati su una stessa macchina fisica (node multiplexing). Analogamente più connessioni virtuali possono condividere lo stesso collegamento fisico ad alta velocità (link multiplexing). Le tecniche di virtualizzazione sono uno degli approcci fondamentali (se non l'unico) al node multiplexing. Con il termine virtualizzazione si intende la creazione di una versione virtuale di una risorsa normalmente accessibile direttamente. Qualunque risorsa hardware o software può essere virtualizzata: sistemi operativi, server, memoria, spazio disco. Nel caso specifico del node multiplexing orientato alla network emulation, la virtualizzazione d'interesse assume il nome di virtualizzazione di sistema. In questo caso lo strato software che permette la virtualizzazione viene detto Virtual Machine Monitor (VMM) oppure Hypervisor. Questo layer consente ad una singola macchina fisica di supportare l esecuzione di ambienti multipli contemporaneamente. Tipicamente il sistema operativo delle macchine ospiti (le virtual machine) non è al corrente del fatto che è in funzione in un ambiente emulato ed opera come se stesse girando su di un hardware fisico ad esso completamente dedicato. Il virtual machine monitor (ad esempio Xen) deve operare in maniera trasparente senza pesare con la propria attività sul funzionamento e sulle prestazioni dei sistemi operativi e svolgere attività di 15

16 controllo al di sopra di ogni sistema, permettendone lo il monitoring e debugging delle attività e delle applicazioni in modo da scoprire eventuali malfunzionamenti ed intervenire repentinamente. I.7 Conclusioni Dopo aver esaminato tutti le possibili tecniche di emulazione di un ambiente distribuito, andremo ad esaminare nel prossimo capitolo Neptune: un emulatore cluster based orientato al multiplexing sviluppato presso l Università degli Studi di Napoli Federico II. 16

17 Capitolo II Neptune Neptune (Network Emulation for Protocol TUNing and Evaluation) è un progetto che ha l'obiettivo di realizzare un emulatore di rete flessibile, orientato al multiplexing delle risorse di calcolo e di memorizzazione, sviluppato presso l'università di Napoli Federico II, adoperante l'approccio cluster based. 17

18 I principali obiettivi : Basso costo di implementazione: conseguito attraverso l uso di componenti hardware general purpose e strumenti software open source Utilizzo efficace ed efficiente delle risorse disponibili Completo isolamento tra i diversi nodi Semplicità d uso Elevate performance Sicurezza: conseguita attraverso l uso di tecnologie di comunicazione basate su tunneling SSH Il progetto prende molte delle assunzioni di base da Emulab ma le usa solo come punto di partenza per lo sviluppo di un sistema che si differenzia sostanzialmente da quest'ultimo. Fin dal principio, infatti, Neptune ha assunto la virtualizzazione come tecnologia chiave per la realizzazione di complessi sistemi di rete ma, anziché basarsi su hardware specializzato per riprodurre il funzionamento dei sistemi reali, persegue lo scopo di realizzare un sistema capace di essere integrato in una qualsiasi infrastruttura general purpose. 18

19 II.1 Organizzazione di Neptune Nodo Nodo Nodo Nodo Nodo Nodo Nodo Manager Dhc p Nfs Dns Internet L'organizzazione di Neptune segue un approccio centralizzato alla gestione dell'intero sistema. Uno dei nodi del cluster, che definiremo Neptune Manager (a cui ci riferiremo anche con il solo Manager), fornisce i servizi fondamentali (ad esempio dhcp, dns, nfs, ecc.) ed ospita il software di gestione della configurazione del sistema. Da un punto di vista logico si possono immaginare due livelli all'interno del cluster: un livello su cui risiede il Manager, responsabile della realizzazione dei servizi di gestione del cluster e della comunicazione con l'esterno, ed un livello su cui risiedono tutti gli altri nodi, che rappresenta l'infrastruttura di emulazione vera e propria. Sia il Manager che gli altri nodi risiedono su di una rete comune, che viene definita rete di controllo, adoperata dal Manager per accedere a tutti gli altri nodi del cluster. L'accesso all'esterno da parte dei nodi non è garantito direttamente, ma è necessario adoperare 19

20 sempre il Manager come tramite. Questo assicura la presenza di un filtro configurabile per l'accesso al cluster. Particolarmente interessante è la gestione in Neptune delle macchine virtuali da parte delle macchine fisiche. Queste ultime, infatti, vengono gestite come dei contenitori dove vengono distribuite le macchine virtuali degli esperimenti in esecuzione. Le macchine virtuali sono archiviate in un repository e allocate quindi secondo necessità. In realtà, nel repository non sono effettivamente conservate le macchine virtuali ma dei template, ossia dei modelli che le rappresentano e che sono poi istanziati creando una nuova macchina virtuale in tutto e per tutto uguale al template. II.2 Il multiplexing delle risorse in Neptune Per l emulazione di complesse topologie di reti è stata adottata la tecnica della virtualizzazione attraverso l hypervisor XEN. 20

21 Xen è un monitor di macchine virtuali open source, rilasciato sotto licenza GPL per piattaforma IA-32, x86, x86-64, IA-64 e PowerPC 970, sviluppato presso il Computer Laboratory dell Università di Cambridge. Xen è sostanzialmente un sottile strato software posto sopra l hardware che si interpone tra le macchine virtuali e l hardware schedulando gli accessi alle risorse fisiche della macchina ospite da parte delle varie istanze delle macchine virtuali. Per quanto riguarda invece l emulazione dei collegamenti fra nodi (e quindi il link multiplexing) Neptune può sfruttare due tecniche: IP aliasing: prevede che la definizione del link avvenga interamente al livello IP. Sulla stessa interfaccia vengono gestiti più indirizzi IP, ciascuno rappresentante di un end-point di un link. L'indipendenza del link dagli altri presenti sull'interfaccia è garantita da sistemi di traffic shaping che regolano l'occupazione di risorse. One Link Per Interface: ogni end-point di un link richiede un'interfaccia dedicata. Ogni link, quindi, è modellato come una connessione diretta fra due interfacce di rete. Questo approccio è possibile poiché si opera con nodi realizzati con virtual machine. Anche se questa tecnica di multiplexing prevede di intervenire al livello datalink, la realizzazione del link viene completata ancora una volta al livello IP. Infatti, perché il link risulti correttamente utilizzato, è necessario intervenire sulle tabelle di forwarding, in modo da inoltrare tutto il traffico riguardante il link sull'interfaccia in cui questo è realizzato. 21

22 Allo stato attuale Neptune adopera in prevalenza la seconda tecnica, che risulta di più semplice applicazione dal punto di vista tecnico, in un ambiente composto da macchine virtuali. Il supporto all'ip Aliasing viene comunque contemplato, ma se ne rimanda la realizzazione a fasi successive. II.3 La gestione degli esperimenti Poiché lo scopo di Neptune è fornire un ambiente multiutente per l'emulazione di rete è necessario confrontarsi con le problematiche legate alla definizione, assegnazione e gestione delle risorse di tale ambiente. Il requisito che si vuole soddisfare in questo caso è che ciascun utente possa richiedere ed ottenere le risorse necessarie al suo esperimento (se disponibili) senza che eventuali altri esperimenti in esecuzione ne siano influenzati o viceversa. In altre parole, si vogliono realizzare quelle caratteristiche di isolamento, molteplicità e scalabilità identificate per il node multiplexing, applicate però al contesto più ampio di esperimento in esecuzione sul cluster. L'approccio adoperato da Neptune riprende il concetto di Virtual Workspace, diffuso nei sistemi di Grid computing. Un virtual workspace non e' altro che un ambiente di esecuzione astratto che può essere reso disponibile dinamicamente per gli utenti autorizzati. L'approccio con virtual workspace risolve i problemi di assegnazione delle risorse elaborative agli utenti, permettendo una gestione estremamente flessibile delle risorse del cluster. Nel contesto di Neptune non esistono propriamente dei virtual workspace, ma degli "emulation experiment", che, richiesti dagli utenti, vengono opportunamente allocati sfruttando le risorse del cluster. 22

23 La creazione di un emulation experiment passa dunque attraverso i seguenti passi: L'utente formula una richiesta di risorse Il sistema (seguendo opportune policy) verifica la disponibilità delle risorse richieste e le assegna all'utente L'utente accede alle risorse realizzando il suo esperimento II.4 Utenti e ruoli In Neptune sono identificabili due categorie di utenti: Amministratore del sistema: è colui che gestisce gli aspetti di configurazione del sistema e che regolamenta l'accesso alle risorse del cluster, definendo opportune policy o intervenendo manualmente. Un amministratore di sistema è responsabile per la concessione delle risorse ad un esperimento. Utente: è colui che crea e/o adopera gli esperimenti. L'amministratore di sistema può di fatto eseguire qualsiasi operazione definita in Neptune, operando attraverso l'interfaccia esposta dal Manager. Fra le mansioni dell'amministratore di sistema rientrano la definizione e gestione degli utenti, l'autorizzazione all'utilizzo di determinate risorse sul cluster, la gestione globale degli esperimenti. L'utente, invece, può eseguire le operazioni riguardanti l'esperimento, nel caso ne sia il proprietario (Experiment owner) o semplicemente osservarne lo stato in caso contrario (Experiment user). Nella prossima figura sono sintetizzate le operazioni che comunemente effettuano i due tipi di utente nella creazione di un esperimento. 23

24 L'utente definisce un esperimento indicando un nome univoco per lo stesso. L'esperimento mantiene una duplice informazione: il suo nome identificativo ed il nome-utente del suo creatore, che è anche l'utente che ha il compito di gestire l'esperimento stesso. L'utente definisce una topologia specificando i nodi ed i link che la compongono. La topologia viene quindi associata all'esperimento. All'esperimento così definito è possibile associare ulteriori utenti che avranno la possibilità di intervenire sullo stesso, modificandolo o monitorandolo. 24

25 Quando l'utente si considera soddisfatto della definizione dell'esperimento, lo colloca in una coda di allocazione. Questa operazione corrisponde a dire che l'esperimento è totalmente definito e, quindi, ci si pone in attesa perché venga collocato 6.sui nodi fisici del cluster. L'amministratore esamina la coda di allocazione ed estrae un esperimento dalla stessa per procedere alla sua allocazione sui nodi fisici del cluster. L amministratore definisce quali nodi fisici del cluster ospiteranno i nodi definiti nella topologia dell'esperimento, creandoli e instanziandoli sulle macchine fisiche. Avvierà inoltre la fase di configurazione dei link. L'esperimento definito dall'utente è stato allocato sui nodi del cluster ed è, quindi, possibile accedere ad ogni nodo tramite console remota. II.5 L esperimento L'emulation experiment (a cui ci riferiremo semplicemente col nome di esperimento ) è un concetto fondamentale nella definizione di Neptune. Esso mira infatti a fornire un ambiente separato e gestibile in cui eseguire l'emulazione di rete. Tramite l'esperimento si gestiscono le risorse in relazione agli utenti del sistema, sia in termini di richiesta che di allocazione. Un esperimento contiene quattro informazioni fondamentali: identificativo: un nome univoco che permetta di identificare con certezza l'esperimento proprietario: colui che ha la responsabilità di gestire l'esperimento e che, di fatto, è chi ha l'intenzione di realizzarlo risorse: le risorse del cluster richieste o possedute dall'esperimento stato: lo stato dell'esperimento è un insieme di informazioni che indica la storia del medesimo. 25

26 Adoperando questo approccio, l'esperimento diviene un contenitore concettuale di un sotto-insieme delle risorse del cluster, che punta alla realizzazione di un solo obiettivo di emulazione. Un utente, coerentemente con questa definizione, può essere proprietario di uno o più esperimenti. Per quel che riguarda le risorse del cluster collegate ad un esperimento, osserviamo che la definizione delle risorse richieste da un esperimento è strettamente legata all'attività di emulazione che il medesimo deve compiere: l'emulazione di un sistema composto da due host richiede certamente meno risorse dell'emulazione di un sistema composto da decine. La richiesta in termini di risorse è quindi derivante direttamente dal sistema che l'esperimento vuole emulare. Facendo riferimento all'emulazione di rete, i sistemi da emulare sono identificabili da una topologia, ossia da un insieme di nodi (host, router, ecc.) connessi fra loro da una serie di link. Definendo la topologia da emulare si definisce di fatto la richiesta di risorse. Risulta a questo punto evidente la necessità di un modo per distinguere un esperimento che richiede delle risorse da uno che invece tali risorse le ha acquisite. Sostanzialmente, è necessario definire il ciclo di vita di un esperimento e gli stati che esso assume. Gli stati individuati sono cinque: Undefined: l'esperimento è stato creato e ad esso sono stati associati un nome identificativo ed un amministratore, ma non le informazioni sulle risorse richieste Defined: l'esperimento è stato definito in tutte le sue parti, ossia, contiene anche le informazioni sulle risorse richieste. Quando si è in questo stato la topologia associata è pronta ad essere realizzata sul cluster Waiting: l'esperimento è in attesa di allocazione sul cluster. L'attesa è un momento necessario poiché le risorse del cluster sono finite, ed è quindi inevitabile gestire un meccanismo di allocazione delle stesse Allocated: l'esperimento ha acquisito tutte le risorse necessarie ad essere operativo e sta materialmente occupando le risorse sul cluster. Tuttavia, non è ancora operativo, in quanto deve ancora realizzare la configurazione della topologia. 26

27 Running: l'esperimento è pronto per l'utilizzo. II.6 La topologia Una topologia è un insieme di nodi e di link che connettono tali nodi. Sia i nodi che i link hanno identificativi univoci all'interno di una stessa topologia. Ad ogni topologia è inoltre associato un identificativo univoco a livello globale che la identifica con certezza. I nodi, dati gli scopi di Neptune, sono rappresentati come entità con caratteristiche generali del tutto analoghe a quelle di un computer sia dal punto di vista hardware (memoria centrale, cpu, hard disk, ecc.) che software. Le topologie sono accomunabili, a livello logico, ad un grafo, in cui però vanno tenute in considerazione le seguenti informazioni: I nodi portano informazioni sulla loro configurazione hardware e software I link hanno associate informazioni riguardanti le proprietà che li caratterizzano Gli elementi costitutivi della topologia (nodi, link) sono a loro volta strutture dati complesse, che vanno a realizzare in questo modo un albero descrittivo della topologia. La descrizione della topologia di un esperimento è realizzata mediante un file Xml la cui struttura è descritta nella prossima pagina. 27

28 II.7 La rete di controllo I nodi realizzati da Neptune per supportare gli esperimenti sono macchine virtuali, residenti su macchine fisiche del cluster. E' chiaramente necessario un modo per accedere a queste al fine di controllarle e monitorarle. Abbiamo visto come in un esperimento, le macchine virtuali (i nodi) vadano a realizzare una particolare topologia di rete, che risulta isolata dal mondo esterno. Per accedere a queste macchine è dunque necessario un ulteriore media costituito appunto dalla rete di controllo. Questa rete ha range di indirizzi IP ben definiti, in modo che non possano essere confusi con indirizzi appartenenti a link di topologie degli esperimenti e mette in comunicazione tutte le macchine virtuali con il Neptune manager. Ogni macchina virtuale è quindi dotata di un apposita interfaccia di rete, una sorta di finestra di collegamento tra ambiente simulato e mondo esterno, che ne permette il controllo. La rete di controllo è un punto molto delicato dell'infrastruttura di Neptune, poiché, per quanto dovrebbe risultare trasparente per l'esperimento di emulazione, a conti fatti non lo è in quanto ciascuna macchina virtuale è a conoscenza della sua esistenza. 28

29 Il fatto stesso che Neptune sorga su un infrastruttura condivisa e che tutte le macchine, anche di esperimenti diversi, siano di fatto tutte collegate su una stessa Lan può far sorgere diversi problemi di isolamento che vanno opportunamente considerati. La separazione delle macchine, infatti, avviene al livello di rete (livello 3) e non di datalink (livello 2). Gli esperimenti possono essere condotti senza problemi (l isolamento al livello di rete è sufficiente) ma andranno considerate evenienze (come ad esempio i messaggi inviati da alcuni protocolli a livello datalink) in cui questa separazione può essere di fatto aggirata. L importante è che questi comportamenti eccezionali non vadano di fatto ad influenzare il comportamento della rete virtuale. II.8 Creare un esperimento con Neptune Dopo aver esaminato in maniera teorica la struttura e il funzionamento di Neptune proveremo ad instanziare un semplice esperimento tramite il Neptune Manager. II.8.1 Operazioni preliminari La prima cosa da fare, per connettersi ai Cluster di Neptune, è installare Open Vpn: un software che permette la comunicazione punto punto tra unità di rete e che viene quindi usato per creare un tunnel di comunicazione con cui gestire le macchine virtuali e la loro organizzazione. Per gli utenti Windows il client è disponibile all indirizzo: 29

30 Nota bene : per poterlo installare in Windows 7 è necessario accedere alle proprietà del file impostare le opzioni di compatibilità in modo che il programma venga eseguito in modalità Window Xp sp3. Dopo l installazione è necessario copiare i file dei permessi di accesso nella directory C:\Programmi\OpenVPN\config I permessi sono normalmente concessi e distribuiti dall amministratore di sistema. Per gli utenti Linux possiamo da console usare il comando: apt-get install openvpn copiare con privilegi di amministratore le informazioni utente nella directory /etc/openvpn e digitare il comando: openvpn --config <NomeUtente>.ovpn Per accedere a Neptune è necessario, con OpenVPN attivo, andare al seguente indirizzo: oppure all indirizzo: 30

31 Se tutto è andato per il verso giusto (alcuni browser incontrano allo stato attuale alcune difficoltà di connessione, per questo è preferibile usare Mozilla Firefox) ci troveremo dinanzi a questa schermata: da cui è possibile effettuare il login. Entreremo così nella pagina principale dell interfaccia di Neptune: 31

32 In cui potremo avviare un nuovo esperimento, modificarlo e porlo in richiesta di attivazione. II.8.2 Creazione di un esperimento Dalla schermata principale di Neptune, alla voce experiments, selezioniamo New: Selezioniamo il nome da assegnare all esperimento e attendiamo la sua allocazione. Dalla voce Experiments Summary selezioniamo l esperimento caricato: 32

33 Appare quindi la schermata principale di gestione: da essa possiamo attivare la richiesta di allocazione/deallocazione sui cluster, modificare la topologia della nostra rete virtuale e avere informazione sui nodi attivi. 33

34 Entriamo in Topology: Creiamo un nuovo nodo con cliccando su Topology Nodes Add node : 34

35 Apparirà questo menu: Qui possiamo inserire il nome del nodo, impostare le caratteristiche della macchina virtuale (Ram e Hard disk) e il sistema. Adesso possiamo modificare le impostazioni del nodo e aggiungere interfacce di rete, necessarie per i collegamenti: 35

36 Da questa schermata possiamo selezionare il nome dell interfaccia, il tipo di collegamento e l indirizzo Mac: per il nostro tutorial useremo i parametri che ci vengono dati di default. Dopo aver creato almeno due nodi proviamo a collegarli aggiungendo un Link: 36

37 Potremo dare un nome al link ed assegnare gli Id e le interfacce dei due nodi da collegare. Notiamo che non abbiamo bisogno di assegnare alcun indirizzo Ip alle varie interfacce di rete: sarà effettuato in maniera automatica nel momento in cui l esperimento sarà caricato sul server; questa caratteristica semplifica le operazioni da effettuare in quanto Neptune stesso provvederà a trovare una sequenza di indirizzi Ip in un range tale da non influenzare altri esperimenti. Ultimata la topologia possiamo caricare l esperimento dalla pagina principale di Neptune e attendere la sua allocazione. Per deallocarlo possiamo utilizzare il pulsante terminate. Una volta allocato, potremo avere informazioni sui singoli nodi nella sezione Active nodes : Da questa schermata possiamo conoscere gli indirizzi per collegarsi in remoto alle macchine virtuali e ci è data la possibilità di resettarle in caso ad esempio di malfunzionamento. 37

38 Per accedere alle macchine virtuali possiamo utilizzare in ambiente Windows o Linux il client Putty ( di cui mostriamo la schermata principale: Nella finestra Host Name inseriremo l indirizzo della macchina a cui vogliamo accedere: Useremo sempre Port 22 e connection type SSH. Premendo su Open avremo il terminale del nodo selezionato. 38

39 In alternativa in ambiente Linux possiamo accedere ai nodi direttamente tramite il terminale digitando: ssh ip> Di default le macchine sono inizializzate con amministratore Root e password antoxps. II.9 Rete con routing statico Dopo aver imparato ad usare l interfaccia di Neptune, proviamo a creare un semplice esperimento. La procedura si divide in tre fasi: nella prima dovremo istanziare le macchine (nodes) e le relative interfacce di rete, nella seconda fissare i collegamenti (links) e nella terza compilare tramite terminale le tabelle di routing di ogni macchina per permettere loro di comunicare. Utilizzeremo lo schema qui presentato: una semplicissima rete costituita da 5 macchine virtuali. Pc 3 eth Pc R 1 eth R 2 eth1 eth1 e t h eth2 1 eth eth1 Pc 2 39

40 Per il nostro tutorial dobbiamo dunque instanziare su Neptune 5 macchine collegate tra loro secondo lo schema: sono presenti 4 subnet, 3 endsystem e due macchine che fungono da Router. Gli indirizzi presenti in questo esempio sono puramente indicativi e sono stati assegnati da Neptune. Ogni macchina dispone di un interfaccia eth0 di controllo che la collega con il mondo esterno mediante terminale remoto (Ssh o Putty). Dovremo quindi creare, dall interfaccia di Neptune, un certo numero di interfacce di rete per permettere i collegamenti. Ad esempio la macchina Pc 0 avrà bisogno solo di un ulteriore interfaccia eth1 che andrà opportunamente collegata all interfaccia eth1 di Pc 1, creando la sottorete Elenchiamo quindi il numero di interfacce necessario a ogni macchina: Pc 1: eth0, eth1 R 1: eth0, eth1, eth2 R 2: eth0, eth1, eth2, eth3 Pc 2: eth0, eth1 Pc 3: eth0, eth1 Dopo aver creato la rete dovremo quindi accedere alle singole macchine (tramite ssh o Putty) e, da linea di comando, impostare diversi parametri di configurazione. Per metterle in comunicazione occorrerà su ognuna inizializzare le interfacce di rete assegnando loro un Ip, abilitare l Ip forwarding su quelle che devono smistare i dati (R1 e R2) e compilare opportunamente le tabelle di Routing. Di seguito elencheremo, macchina per macchina e commentandoli brevemente, i comandi da inviare per far funzionare la nostra primissima rete. 40

41 Pc 1 Innanzitutto attiviamo l interfaccia eth1 e assegnamole l indirizzo con il comando ifconfig indicando anche la netmask standard : ifconfig eth1 up ifconfig eth netmask Dovremo adesso indicare alla nostra macchina le strade da seguire per raggiungere le altre macchine, completando a mano la sua tabella di routing. Poiché questa operazione deve essere fatta una tantum dall amministratore di rete, qualsiasi modifica alla topologia della rete comporterà malfunzionamenti e incapacità di raggiungimento dei nodi (a meno di modifiche manuali); proprio per questo si parlerà di Routing statico. Compiliamo la tabella di routing con il commando route : route add net netmask dev eth1 gw route add net netmask dev eth1 gw route add net netmask dev eth1 gw In questo modo abbiamo aggiunto le tre subnet alla tabella di routing indicando alla nostra macchina mediante quale interfaccia raggiungerle. Notiamo inoltre che abbiamo aggiunto l indirizzo di Pc1 su eth1 come gateway: se non prendiamo questa precauzione tutti i dati viaggeranno di default lungo la linea interna (che ha come interfaccia eth0) che collega tutte le macchine virtuali. 41

42 Per visualizzare la tabella di routing possiamo utilizzare il comando route n : # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface U eth U eth U eth U eth U eth UG eth0 R 1 Attiviamo le interfacce eth1 ed eth2 assegnando gli indirizzi e : ifconfig eth1 up ifconfig eth netmask ifconfig eth2 up ifconfig eth netmask Poiché questa macchina funge da router è necessario abilitare l Ip forwarding: per fare questo dobbiamo modificare da 0 a 1 il flag presente nel file /proc/sys/net/ipv4/ip_forward. Allo scopo possiamo utilizzare il comando sysctl seguito dal reset della macchina: sysctl w net.ipv4.ip_forward=1 reset Fatto ciò non ci resta altro da fare che completare la tabella di routing inserendo le subnet che non sono direttamente collegate alle interfacce eth1 ed eth2 della macchina: route add net netmask dev eth2 gw route add net netmask dev eth2 gw

43 R 2 Questa macchina ha ben 3 interfacce da attivare : assegniamo gli indirizzi su eth1, su eth2 e su eth3. ifconfig eth1 up ifconfig eth netmask ifconfig eth2 up ifconfig eth netmask ifconfig eth3 up ifconfig eth netmask Abilitiamo anche qui l Ip forwarding: sysctl w net.ipv4.ip_forward=1 reset Completiamo la tabella di routing inserendo l unica subnet non collegata direttamente alla macchina, la , che potrà essere raggiunta mediante l interfaccia eth1: route add net netmask dev eth1 gw Pc 2 Attiviamo l interfaccia eth1 e assegnamole l indirizzo : ifconfig eth1 up ifconfig eth netmask Compiliamo la tabella di routing : route add net netmask dev eth1 gw route add net netmask dev eth1 gw route add net netmask dev eth1 gw

44 Pc 3 Attiviamo l interfaccia eth1 e assegnamole l indirizzo : ifconfig eth1 up ifconfig eth netmask Compiliamo la tabella di routing : route add net netmask dev eth1 gw route add net netmask dev eth1 gw route add net netmask dev eth1 gw II.10 Una prima fase di testing La nostra rete è completata: potremo testare i collegamenti con il comando ping <indirizzo destinazione> o con il comando traceroute <indirizzo destinazione>. Nei prossimi capitoli questi due comandi saranno molto utili per sondare le nostre reti, limitiamoci per adesso ad introdurli brevemente. II.10.1 Ping Ping è un programma che misura il tempo, espresso in millisecondi, impiegato da uno o più pacchetti ICMP (Internet Control Message Protocol) a raggiungere un altro computer o server di rete e a ritornare all origine. Viene quindi spesso utilizzato per verificare la presenza e la raggiungibilità di un altro computer connesso in rete o per misurare le latenze di trasmissione. Ping invia un pacchetto ICMP di tipo echo request e rimane in attesa di un pacchetto echo reply che viene inviato automaticamente alla ricezione del pacchetto request 44

45 (questa funzione è generalmente presente nella parte del sistema operativo dedicata alla gestione delle reti). Proviamo ad esempio a mandare dei ping da Pc 1 verso R 1: ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_seq=1 ttl=63 time=0.687 ms 64 bytes from : icmp_seq=2 ttl=63 time=0.644 ms 64 bytes from : icmp_seq=3 ttl=63 time=0.630 ms 64 bytes from : icmp_seq=4 ttl=63 time=0.656 ms II.10.2 Traceroute Traceroute è un applicazione che si occupa di ricavare il percorso seguito dai pacchetti, visualizzando l indirizzo IP di ogni router attraversato per raggiungere il destinatario. Traceroute sfrutta, per il suo funzionamento, una particolare caratteristica del protocollo IP, ovvero il campo TTL (time to live) del messaggio. Questo campo specifica il numero degli apparati di rete che il pacchetto potrà attraversare prima di essere dichiarato scaduto e re invitato al mittante. Ogni router che riceve il pacchetto, prima di inviarlo nuovamente, diminuisce il campo di un unità; se si accorge che il campo ha assunto il valore 0, invia al mittente del pacchetto un messaggio di errore ICMP specificando l indirizzo del router che lo ha generato. Traceroute, quindi, invia un pacchetto al destinatario di cui si vuole ricavare il percorso con il campo TTL impostato ad 1. Il primo router che lo riceverà, constatando che il campo TTL ha raggiunto lo 0, invierà un errore al mittente. L applicazione memorizzerà l indirizzo IP del primo router, quindi invierà un nuovo pacchetto con TTL impostato a 2. L operazione continua fin quando non viene raggiunto il destinatario. Proviamo quindi a digitare il comando: traceroute

46 osserviamone l output: traceroute to ( ), 30 hops max, 40 byte packets ( ) ms ms ms ( ) ms ms ms ( ) ms ms ms Ci vengono immediatamente indicati i passi (hops) seguiti dai pacchetti per raggiungere l indirizzo desiderato. 46

47 Capitolo III Il Routing dinamico Dopo aver creato il semplice esperimento del capitolo precedente il nostro pensiero si rivolgerà all aggiramento del suo principale difetto: il routing statico. Le tabelle compilate a mano, infatti, portano sì una certa semplicità ma possono essere utilizzate solo su reti molto piccole e non garantiscono alcuna affidabilità nel caso di modifiche (volontarie o no) alla topologia della rete: un semplice malfunzionamento momentaneo di un nodo può di fatto compromettere tutto. Si sono quindi diffusi diversi protocolli che permettono ai router di collaborare tra loro, inviando informazioni sulla loro posizione e determinando dinamicamente l indirizzamento di una rete. In linea generale ogni router può comunicare a ogni vicino i nodi a lui direttamente connessi e la loro distanza. Queste semplici informazioni andranno condivise fino a creare una mappa della rete e una rete di link ottima per far circolare i dati. Gli algoritmi di instradamento dovranno quindi considerare diversi parametri come distanza, flusso dei dati, percentuale di traffico sulla rete, gestione degli aggiornamenti. Esamineremo due tipi di routing: Distance Vector Link State 47

48 III.1 Distance Vector In un algoritmo distance vector ogni router misura la distanza (secondo una metrica che può seguire diverse politiche) che lo separa dai nodi adiacenti e riceve i dati dai router vicini. Utilizzando l'algoritmo di Bellman-Ford, il router costruisce una tabella che associa ad ogni destinazione conosciuta: la stima della distanza che lo separa dalla destinazione il primo passo del percorso calcolato Periodicamente il router aggiorna le misure di distanza dai router adiacenti e comunica la propria tabella ai vicini. Dopo sufficienti scambi di informazioni, ciascun router potrà avere una riga per ogni altro nodo nella rete. III.1.1 Costruzione della topologia Vediamo come funziona l'algoritmo basandoci su un esempio di rete formata da 5 nodi e 6 rami, come nella figura sotto riportata. 48

49 Ogni nodo è identificato dal proprio indirizzo (nel caso A, B, C, D ed E) e la tabella di routing avrà una voce per ciascuno di essi. Supponiamo di inizializzare la rete alimentando tutti i nodi contemporaneamente: un "cold start". In questo stato ciascuno dei nodi è caratterizzato unicamente da una conoscenza locale, il che significa che ciascun nodo conosce il proprio indirizzo ma ignora totalmente la topologia della rete. La tabella di routing sarà quindi caratterizzata da una singola voce: quella del nodo stesso. Ad esempio, la tabella di A sarà : Da A a: Link Costo A Locale 0 Il nodo A riassume la tabella in un vettore, chiamato "distance vector" che, nel caso, sarà composto dall' unico elemento A = 0. Quest ultimo verrà quindi replicato a tutti i nodi vicini, nel caso B e D, che possono quindi accrescere la loro conoscenza della rete. Dopo aver ricevuto attraverso il link 1 il distance vector A = 0, B aggiorna tutte le distanze aggiungendo loro il costo del link locale, che assumiamo essere uguale a 1, trasforma il messaggio da A = 0 ad A = 1, confronta l'informazione del vettore con le voci presenti nella sua tabella di routing, rileva che il nodo A è ancora sconosciuto e aggiorna la tabella di routing che diventa : Da B a: Link Costo B Locale 0 A 1 1 B può ora preparare il proprio distance vector (B = 0, A = 1) e inviarlo attraverso i suoi link locali, ossia 1, 2 e 4. 49

50 Nel frattempo, anche il nodo D avrà ricevuto il messaggio iniziale da A e avrà aggiornato la propria tabella in : Da D a: Link Costo D Locale 0 A 3 1 Potrà quindi inviare il proprio distance vector (D = 0, A =1) sui link 3 e 6. Il messaggio proveniente da B sarà ricevuto da A, C ed E, mentre quello da D sarà ricevuto da A ed E. Supponiamo che il messaggio da B sia ricevuto prima. Ricevendo il messaggio dal link 1, A aggiornerà le distanze a B = 1 ed A = 2. Poiché quest'ultima è maggiore della voce relativa al link locale, la tabella di A verrà aggiornata con la sola voce relativa al nodo B. Infine, ricevendo il messaggio attraverso il link 3, verrà inserita anche l'informazione relativa al nodo D. La nuova tabella sarà : Da A a: Link Costo A Locale 0 B 1 1 D 3 1 il nodo C riceverà il vettore B = 0, A = 1 attraverso il link 2, e aggiornerà la propria tabella: Da C a: Link Costo C Locale 0 B 2 1 A

51 Il nodo E riceverà il vettore B = 0, A = 1 attraverso il link 4 e aggiornerà la propria tabella: Da E a: Link Costo E Locale 0 B 4 1 A 4 2 Riceverà poi il vettore (D = 0, A = 1) attraverso il link 6 e lo aggiornerà in (D = 1, A = 2) Da E a: Link Costo E Locale 0 B 4 1 A 4 2 D 6 1 Dopo che A, C ed E avranno quindi calcolato le loro nuove tabelle, invieranno sui loro link locali i propri distance vectors Da A : A = 0, B = 1, D = 1, attraverso i link 1 e 3 Da C : C = 0, B = 1, A = 2, attraverso i link 2 e 5 Da E : E = 0, B = 1, A = 2, D = 1 attraverso i link 4, 5 e 6 51

52 Essi causeranno un aggiornamento alle tabelle di B, D ed E in : Da B a: Link Costo B Locale 0 A 1 1 D 1 2 C 2 1 E 4 1 Da D a: Link Costo D Locale 0 A 3 1 B 3 2 E

53 Da E a: Link Costo E Locale 0 B 4 1 A 4 2 D 6 1 C 5 1 B, D ed E possono quindi preparare i nuovi vettori : Da B : B = 0, A = 1, D = 2, C = 1, E = 1, attraverso i link 1, 3 e 4 Da D : D = 0, A = 1, B = 2, E = 1, attraverso i link 3 e 6 Da E : E = 0, B = 1, A = 2, D = 1, C = 1, attraverso i link 4, 5 e 6 che saranno ricevuti da A, C e D che aggiorneranno quindi le loro tabelle (come mostrato nelle pagine seguenti) 53

54 Da A a: Link Costo A Locale 0 B 1 1 D 3 1 C 1 2 E 1 2 Da C a: Link Costo C Locale 0 B 2 1 A 2 2 E 5 1 D

55 Da D a: Link Costo D Locale 0 A 3 1 B 3 2 E 6 1 C 6 2 A questo punto, l'algoritmo converge: i nodi hanno rilevato la topologia della rete III.1.2 Indisponibilità di un ramo Vediamo come reagirà la nostra rete nel momento in cui, per un qualsiasi motivo, il ramo 1 della rete vista in precedenza cada o diventi indisponibile. I due nodi A e B, che sono i terminali del ramo in esame, rilevano il guasto ed aggiornano di conseguenza le loro tabelle di routing, rilevando che il link1 assume ora un costo "infinito" e che tutti i nodi precedentemente raggiungibili attraverso tale link, sono ora collocati ad una distanza infinita. Le nuove tabelle saranno (pagina seguente): 55

56 Da A a: Link Costo A Locale 0 B 1 inf. D 3 1 C 1 inf. E 1 inf. Da B a: Link Costo B Locale 0 A 1 inf. D 1 inf. C 2 1 E 4 1 I nodi A e B prepareranno ed invieranno i nuovi vettori : Da A : A = 0, B = inf, D = 1, C = inf, E = inf, attraverso il link 3 Da B : B = 0, A = inf, D = inf, C = 1, E = 1, attraverso i link 2 e 4 56

57 Il vettore inviato da A sarà ricevuto da D, che aggiornerà le distanze aggiungendo il costo del ramo 3 in : A = 1, B = inf, D = 2, C = inf, E = inf Gli elementi di questo vettore saranno quindi confrontati con le voci presenti nella tabella di D: verrà sì rilevato che tutte le distanze del vettore sono maggiori o al limite uguali a quelle memorizzate, ma che il ramo 3, attraverso il quale è stato ricevuto il vettore, è esattamente quello utilizzato per raggiugere B. La voce per il nodo B dovrebbe essere aggiornata per riflettere il nuovo valore. La tabella di D diventa : Da D a: Link Costo D Locale 0 A 3 1 B 3 inf. E 6 1 C

58 In modo simile, anche C ed E aggiorneranno le proprie tabelle : Da C a: Link Costo C Locale 0 B 2 1 A 2 inf. E 5 1 D 5 2 Da E a: Link Costo E Locale 0 B 4 1 A 4 inf. D 6 1 C

59 Questi 3 nodi, prepareranno ed invieranno quindi i nuovi distance vector : Da D : D = 0, A = 1, B = inf, E = 1, C = 2, attraverso i link 3 e 6 Da C : C = 0, B = 1, A = inf, E = 1, D = 2, attraverso i link 2 e 5 Da E : E = 0, B = 1, A = inf, D = 1, C = 1, attraverso i link 4, 5 e 6 Questi messaggi causeranno un aggiornamento alle tabelle dei nodi A, B, D ed E in : Da A a: Link Costo A Locale 0 B 1 inf. D 3 1 C 3 3 E 3 2 Da B a: Link Costo B Locale 0 A 1 inf. D 4 2 C 2 1 E

60 Da D a: Link Costo D Locale 0 A 3 1 B 6 2 E 6 1 C 6 2 Da E a: Link Costo E Locale 0 B 4 1 A 6 2 D 6 1 C 5 1 e, dopo gli aggiornamenti, i nodi invieranno i nuovi vettori : Da A : A = 0, B = inf, D = 1, C = 3, E = 2, attraverso il link 3 Da B : B = 0, A = inf, D = 2, C = 1, D = 1, attraverso i link 2 e 4 Da D : D = 0, A = 1, B = 2, E = 1, C = 2, attraverso i link 3 e 6 Da E : E = 0, B = 1, A = 2, D = 1, C = 1, attraverso i link 4, 5 e 6 60

61 che causeranno l'aggiornamento delle tabelle dei nodi A, B e C Da A a: Link Costo A Locale 0 B 3 3 D 3 1 C 3 3 E 3 2 Da B a: Link Costo B Locale 0 A 4 3 D 4 2 C 2 1 E

62 Da C a: Link Costo C Locale 0 B 2 1 A 5 3 E 5 1 D 5 2 I nuovi percorsi sono definitivamente stati calcolati e la connettivita' globale e' stata quindi ripristinata. III.1.3 L algoritmo di Bellman-Ford I protocolli distance vector sono basati sull'algoritmo di Bellman-Ford: una versione distribuita di un algoritmo molto semplice per la ricerca del percorso più breve. Formalmente viene definito così: Definizioni: N = numero dei nodi M = numero dei links L = tabella dei links di dimensione M, dove : L[l].m = metrica del link L[l].s = sorgente del link 62

63 L[l].d = destinazione D = matrice di dimensione [N,N], dove D[i,j] è la distanza da i a j H = matrice di dimensione [N,N], dove H[i,j] è il link sul quale i instrada i pacchetti destinati a j Algoritmo: Se i = j allora tutti D[i,j] = 0, altrimenti D[i,j] = infinito. Inizializza tutti gli H[i,j] = -1. Per tutti i links l e per tutte le destinazioni k : i = L[l].s; j = L[l].d; calcola d = L[l].m + D[j,k]. Se d < di D[i,k], aggiorna D[i,k] = d; H[i,k] = 1 Se almeno un D[i,k] e' stato aggiornato, ripeti lo step 2, altrimenti stop. III.2 Il protocollo RIP RIP è un protocollo di routing distance-vector che impiega il conteggio dei numeri di salti (hop count) come metrica di routing. Il massimo numero di hop permessi è 15. Ogni router RIP trasmette di default, ogni 30 secondi, la propria tabella completa di routing a tutti i vicini direttamente collegati. Il Routing Information Protocol (RIP) è uno dei protocolli di routing più usati su reti locali. Anche se è ancora attivamente usato, è generalmente sostituito da protocolli di routing Link State come OSPF. III.2.1 Versioni disponibili RIPv1: usa il routing "classful". Gli aggiornamenti delle tabelle di routing non contengono la maschera di sottorete rendendo impossibile la creazione di sottoreti 63

64 di dimensione diversa all'interno della stessa rete. Non viene supportata nessuna forma di autenticazione, lasciando RIPv1 vulnerabile ad attacchi. RIPv2: include il trasporto delle informazioni sulla maschera di sottorete, supportando così il Classless Inter Domain Routing, CIDR. Per garantire la sicurezza degli aggiornamenti sono disponibili 2 metodi: autenticazione semplice con testo in chiaro e Md5 (un algoritmo crittografico di Hashing). Per mantenere la compatibilità all'indietro il limite di hop count rimane a 15. RIPng: una estensione del protocollo originale RIPv1 per supportare IPv6. III.2.2 Problemi del protocollo Il protocollo RIP nella sua semplicità presenta numerosi problemi: Genera grandi quantità di traffico di rete su reti a bassa capacità trasmissiva. Il numero di salti consentito (solo 15) al fine di evitare cicli limita moltissimo le dimensioni della rete. Spesso si vengono a creare problemi di count to infinity determinati da mancanza di aggiornamenti alle tabelle di routing: ogni nodo, infatti, memorizza solo le informazioni sui propri vicini ed è ignaro di eventuali problemi che possono sorgere in posizioni della rete non adiacenti, almeno fin quando non vengono ciclicamente aggiornati tutti i nodi. III.2.3 Ottimizzazioni Per risolvere, almeno parzialmente, i difetti di Rip si possono utilizzare alcune tecniche: Split horizon: aiuta a prevenire il count to infinity facendo in modo che ogni router consideri separatamente lo scenario di informazioni ricevute (dagli altri router della rete) e lo scenario che inoltra a sua volta nei regolari messaggi di routing. 64

65 Route poisoning: se un router non riesce più a raggiungere una destinazione automaticamente invia agli altri l informazione che quel nodo non è più raggiungibile (assegnandogli automaticamente valore 16 nell Hop count). Hold down: permette, tutte le volte che una route è rimossa dalla routing table, di non accettare alcun update sulla route stessa, se non prima di aver aspettato un certo periodo di tempo. Tale intervallo sarà quello necessario affinché tutta la rete sia aggiornata del link down. Triggered updates: permette di rendere più veloce la convergenza. Normalmente i protocolli di tipo Distance vector inviano gli updates ad intervalli regolari di tempo. La tecnica Triggered updates permette di inviare tali messaggi nel momento in cui si verificano dei cambiamenti nella topologia della rete, piuttosto che aspettare prefissati istanti di tempo. III.3 Link State I protocolli di tipo Link State sono basati sul concetto di "mappa distribuita": tutti i nodi posseggono una copia della mappa della rete ed essa stessa è in continuo aggiornamento. Per fare un esempio, la rete usata in precedenza: 65

66 sara' rappresentata dal seguente database: Da A Link Distanza A B 1 1 A D 3 1 B A 1 1 B C 2 1 B E 4 1 C B 2 1 C E 5 1 D A 3 1 D E 6 1 E B 4 1 E C 5 1 E D 6 1 In un protocollo Link State ogni nodo della rete acquisisce informazioni sullo stato dei collegamenti adiacenti ed inoltra queste informazioni a tutti gli altri nodi della rete tramite un Pacchetto Link State trasmesso tramite un algoritmo di link state broadcast. Un Pacchetto Link State (LSP) contiene: Stato di ogni link connesso al router Identità di ogni vicino connesso all'altro estremo del link Costo del link Numero di sequenza per il LSP Checksum Lifetime 66

67 Un LSP viene generato periodicamente o quando viene rilevata una variazione nella topologia locale ossia : Viene riconosciuto un nuovo vicino Il costo verso un vicino e' cambiato Si e' persa la connettività verso un vicino precedentemente raggiungibile Quando un nodo riceve un Pacchetto Link State confronta il numero di sequenza del pacchetto con quello dell'ultimo pacchetto ricevuto da quel nodo: se il numero di sequenza indica che il pacchetto è più recente di quello memorizzato, il nuovo pacchetto viene memorizzato e inoltrato a tutti i nodi collegati, eccetto quello da cui è stato ricevuto. se il numero di sequenza è invariato il pacchetto viene scartato. se il numero di sequenza indica che il pacchetto ricevuto è meno recente di quello memorizzato, quest'ultimo viene trasmesso al nodo mittente. Ogni nodo memorizza i pacchetti ricevuti e costruisce una mappa completa e aggiornata della rete: il Link State Database. Poichè tutti i nodi contengono lo stesso database ed eseguono lo stesso algoritmo di routegeneration, i percorsi sono coerenti e non si verificano loop. Ogni nodo esegue in maniera indipendente un algoritmo, generalmente una variante dell' Algoritmo di Dijkstra, per determinare il cammino minimo per raggiungere ogni nodo della rete ponendosi come radice dell'albero dei cammini minimi. 67

68 III.3.1 L algoritmo di Dijkstra L algoritmo di Dijkstra, del tipo "shortest path first", è nato per rendere più veloce ed efficiente l algoritmo di Bellman-Ford visto in precedenza. L'algoritmo SPF calcola il percorso più breve tra un nodo sorgente ed un altro nodo della rete, definendo: Un nodo radice (root), ossia il nodo che sta calcolando l algoritmo Un insieme PATH di nodi (ID, cost, link) per i quali si è già trovato il percorso migliore Un insieme TEMP di nodi (ID, cost, link) per i quali si sta cercando un percorso L'algoritmo e' il seguente : 1. Si inserisce il nodo root in PATH 2. Si inseriscono tutti i nodi vicini del precedente in TEMP 3. Si prende il nodo N con il percorso più piccolo in TEMP e lo si promuove in PATH 4. Per ogni vicino V del nodo N promosso: Se V non esiste ancora in TEMP lo si inserisce ora Se V già esiste se ne analizza il costo verso la root (D(root, N) + D(N, V)) e se questo è minore del precedente riportato in TEMP si aggiorna cost e link di quel nodo in TEMP 68

69 Osserviamo un esempio figurato dell algoritmo di Dijkstra: III.4 Il protocollo OSPF Il protocollo Open Shortest Path First o OSPF è uno dei protocolli di instradamento più diffusi che gestisce le tabelle di instradamento di una rete IP con il metodo del Link State. III.4.1 Caratteristiche aggiuntive del protocollo Bilanciamento del carico: Il protocollo è in grado anche di gestire casi in cui percorsi diretti verso la stessa destinazione abbiano costi differenti e ottimizzare il traffico. Gerarchizzazione della rete: OSPF permette di gestire diverse gerarchie all interno della rete. I gradi di gerarchia sono molto importanti nelle reti di calcolatori dato 69

70 che questi garantiscono maggiore scalabilità della struttura. Esso permette infatti la divisione di un dominio anche di grandi dimensioni in aree di dimensioni inferiori. Ciascun router non ha quindi più la necessità di essere in grado di raggiungere tutte le reti del dominio, ma è sufficiente che esso sia in grado di raggiungere la corretta area. III.4.2 Organizzazione di una rete OSPF Una rete OSPF è divisa in aree. Esse sono gruppi logici non sovrapposti di router le cui informazioni possono essere sommarizzate rispetto al resto della rete. Diversi tipi di aree "speciali" sono definite: Area Backbone: rappresenta il cuore di una rete OSPF. Tutte le altre aree sono collegate ad essa e il routing inter-area passa tramite un router di questa rete. Stub area: si intendono quei tipi di area che non ricevono route esterne. Le route esterne saranno poi definite e distribuite da un altro protocollo di Routing. Quindi, le stub area necessitano di relegare ad una route di default lo scambio per il traffico con quelle esterne al dominio di appartenenza. 70

71 III.4.3 Tipi di router OSPF OSPF definisce vari tipi di router. Sono definizioni logiche, e un router che usa OSPF potrebbe essere classificato come diversi dei seguenti tipi. Altro Autonomous System (ASBR) Area 1 R1 Area 2 H1 (IR) R 2 R 6 H 3 (IR) H 4 e t h 1 Backbone area R 3 (ABR) R 5 (ABR) R4 (Backbone router) H2 Pc Area Border Router (ABR): è un router che connette una o più aree OSPF all'area di backbone. È membro di tutte le aree alle quali è connesso. Un ABR mantiene in memoria copie multiple del database link-state, uno per ciascuna area alla quale appartiene. Autonomous System Boundary Router (ASBR): è un router connesso a più di un Autonomous system (sistemi autonomi di cui non è nota la topologia) che scambia informazioni di routing con router in altri AS. Un ASBR viene utilizzato per distribuire le rotte ricevute dagli altri AS attraverso il proprio AS. Internal router (IR): un router viene chiamato internal router se ha solo adiacenze OSPF con router nella stessa area. 71

72 Backbone router (BR): è un router con un'interfaccia verso l'area backbone. Un ABR è anche un BR, anche se non è necessario che sia vero l'inverso. Designated router (DR): esiste con lo scopo di ridurre il traffico di rete fornendo una sorgente per aggiornamenti di routing. Il DR memorizza una tabella completa sulla topologia della rete e manda gli aggiornamenti agli altri router attraverso il multicast. In questo modo tutti i router non devono costantemente aggiornarsi l'un l'altro, e possono ricevere tutti gli aggiornamenti da una singola sorgente. III.5 Quagga Proveremo ora costruire e testare delle reti utilizzando le tecniche di istradamento dinamico esaminate nei paragrafi precedenti. Il nostro principale alleato nella compilazione dinamica delle tabelle di routing sarà Quagga : una suite di software di Routing che permette l implementazione di protocolli quali OSPFv2, OSPFv3, RIP v1 e v2, RIPng e BGP-4 su varie piattaforme Unix, in particolare FreeBSD, Linux, Solaris e NetBSD. Quagga è una fork di GNU Zebra sviluppata da Kunihiro Ishiguro. E efficiente, relativamente semplice da usare e dispone di comandi di configurazione molto simili a quelli dei router Cisco. Essendo un progetto relativamente giovane non è esente da bug ma la frequenza con cui vengono pubblicate nuove release e la sua introduzione in diversi contesti (in seguito anche alla tendenza, da parte di molte società, di sostituire il proprio parco software con un 72