Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato nale in Protocolli per Reti Mobili Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Anno Accademico 2013-2014 Candidato Umberto Coppola Bottazzi matr. N46/1041 Ai miei cari A zio Alfredo, indimenticabile insegnante 2 Indice Introduzione 4 Capitolo 1. Software Dened Network e OpenFlow 5 1.1 Panoramica SDN e OpenFlow 5 1.2 Architettura rete SDN 6 1.3 Standard OpenFlow 8 Capitolo 2. OpenvSwitch e Floodlight 12 2.1 OpenvSwitch 12 2.1.1 Avvio 15 2.2 Floodlight 16 2.2.1 Architettura 17 2.2.2 Module Applications 19 Capitolo 3. Implementazione di una rete SDN 21 3.1 Descrizione dell'ambiente 21 3.2 Simulazione rete SDN 21 Conclusioni 28 Appendice Installazione OpenvSwitch 29 Installazione Floodlight 31 Bibliograa 32 3 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Introduzione La rete Internet è una delle grandi invenzioni di successo mondiale del XX secolo. Ha consentito un accesso sconnato alle informazioni facendo cambiare radicalmente le modalità di comunicazione tra le persone e le organizzazioni. Purtroppo l'infrastruttura della rete Internet è rimasta nella stessa condizione per decenni e ciò ha ostacolato l'innovazione della tecnologia che è alla sua base. Tuttavia negli ultimi anni, con la diusione di applicazioni Cloud e la necessità di reti in mobilità, si sta cercando di rivisitare l'architettura Internet per aggiungere nuove funzionalità. Tra queste nuove architetture e nuovi standard,quelle che stanno avendo maggiore successo negli anni sono SDN e OpenFlow. SDN, acronimo che sta per Software-dened networking, propone l'ambiziosa visione di rendere i nodi della rete programmabili, introducendo opportuni livelli di astrazione, che possono essere acceduti attraverso delle interfacce di controllo. In queste architetture assume particolare rilievo il concetto di virtualizzazione delle reti, ovvero la possibilità di creare delle partizioni virtuali della loro infrastruttura di rete sica in modo tale da permettere ad un'instanza di controllo e alle rispettive applicazioni di utilizzare le partizioni assegnate. Ciò permetterebbe la coesistenza di più reti virtuali, tra loro isolate insistenti sulla medesima infrastruttura hardware. La centralizzazione della logica di controllo, può permettere di attuare più facilmente azioni di congurazione e ottimizzazione. Diventa quindi possibile implementare logiche di controllo prescindendo dalla complessità sica dei molteplici dispositivi di rete. Il protocollo che permette di svincolarsi dall'hardware di forwarding dei pacchetti è OpenFlow. 4 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Capitolo 1 Software Dened Network e OpenFlow 1.1 Panoramica SDN e OpenFlow Software Dened Networking è un'architettura di rete che introduce il disaccoppiamento tra il control plane e il data plane dei dispositivi garantendo una gestione ottimale della rete riducendone i tempi di risposta. In tal modo la decisione sulla gestione del traco viene presa da un altro dispositivo software, solitamente situato in un server esterno che ha il compito di denire regole in base alle quali un pacchetto deve essere eleborato. SDN fu sviluppato dai docenti di informatica McKeown e Scott Shenker dell'università di Stanford al ne di migliorare la sicurezza della rete grazie a un nuovo protocollo ow-based. Queste reti, essendo open, sono adatte allo sviluppo e alla ricerca; infatti nei comuni dispositivi di rete (switch e router) le due funzionalità di forwarding e di control si trovano nello stesso apparato; viceversa negli switch SDN è il Controller che gestisce il control path, mentre il datapath è sempre gestito dallo switch sico. Quest'ultimo comunica con il dispositivo di rete attraverso un protocollo di comunicazione, l'OpenFlow. 5 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight OpenFlow è uno standard di comunicazione per le reti SDN, fu creato dagli esperti della Open Networking Foundation (ONF) e negli anni ha ricevuto molti apprezzamenti da importanti aziende come Google e Facebook; in particolare il colosso di Mountain View si avvale dei servizi di OpenFlow per gestire meglio il carico della rete nei periodi di traco intenso. La versione attuale di OpenFlow è la 1.4. Una rete così costituita è in teoria più sicura, adabile e facile da gestire. Inoltre anche dal punto di vista delle prestazioni una SDN incrementa notevolmente lo sfruttamento delle risorse di rete a disposizione. I primi controller che supportano il protocollo OpenFlow sono stati sviluppati in C++, NOX e in Python, POX. Recentemente quello che ha avuto maggior diusione è Floodlight, che verrà trattato in questo elaborato. 1.2 Architettura rete SDN Il principio che sta alla base della struttura SDN è il disaccoppiamento tra il controllo della rete e l'architettura sica. Tutti i dispositivi che compongono sicamente la rete divengono programmabili, utilizzando uno standard che riesce a mettere in comunicazione il livello di trasmissione dati con quello di controllo (OpenFlow). Il controllo della rete è posto in un controller SW logicamente centralizzato, in queso modo si toglie il vincolo che l'intelligenza del dispositivo debba risiedere nel dispositivo stesso: ad esempio si può avere un nodo che controlla altri nodi della rete. Questo approccio è profondamente dirompente, poiché i nodi non decidono più in autonomia il loro comportamento, ma sono controllati da un'entità esterna. Il vantaggio di avere un controller software centralizzato è quello di avere completo controllo sulla rete: modicando il SW si fa in modo che la rete abbia un comportamento dierente e si ha un unico 6 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight punto di controllo che permette di avere una visione dell'intera rete. Una rete SDN può essere schematizzata in tre livelli: A livello più alto (Application Tier) si trovano le applicazioni che comunicano con il sistema operativo grazie a delle API messe a disposizione dallo stesso. Al layer intermedio, Controllo Plan Tier, è il protocollo OpenFlow che permette la comunicazione tra il controllore e il livello Data Plane Tier. In questo ultimo livello si trova l'infrastruttura vera e propria della rete, formata da switch e router. Con questa nuova architettura diminuisce radicalmente la complessità delle reti, che si liberano dai vincoli presenti nei comuni network. Infatti la con- gurabilità e l'adattamento delle reti diventa un processo semplice e veloce che permette di semplicare notevolmente la gestione; qui infatti non occorre ricongurare strumento per strumento l'intera rete al minimo cambiamento. Grazie 7 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight alla possibilità di poter lavorare direttamente sui ussi dati della rete per mezzo di applicazioni software, la ricongurazione avviene a livello software con l'aiuto di un'interfaccia. L'opportunità di personalizzare le reti a proprio piacimento migliora di netto la gestione di tutti i servizi di rete come il QoS, controllo della banda, ACL. Nel caso in cui sia necessario un aggiornamento di un dispositivo di rete o la sua sostituzione con un altro dispositivo a causa di un malfunzionamento, il controllore devia il traco verso quel nodo in altre direzioni attendendo che venga ripristinato. 1.3 Standard OpenFlow Il protocollo OpenFlow è ritenuto da molti un fattore abilitante, anche se non suciente, per realizzare la trasformazione verso i concetti di rete essibile e programmabile. L'interfaccia realizzata da OpenFlow si colloca al livello più basso di astrazione previsto dall'architettura SDN, essa permette infatti di svincolarsi dall'hardware di forwarding dei pacchetti. In questo senso, uno degli aspetti fondamentali, che sta alla base dell'attività di specica dello standard, consiste nella denizione di un modello comune dell'hardware di forwarding dei pacchetti che costituisce l'essenza dei dispositivi di networking. L'obiet- tivo del protocollo OpenFlow è quello di presentare all'esterno un modello di nodo generale e unicato, rendendo gli strati più alti dell'architettura di rete SDN indipendenti dall'implementazione del particolare vendor delle tecnologie impiegate nel piano di forwarding. OpenFlow rende programmabili le tabelle di classicazione ed instradamento dei pacchetti presenti negli apparati di networking (siano essi router o switch); in questo modo il contenuto (le cosiddette entry) può essere congurato dalle applicazioni, tramite un piano di controllo esterno al dispositivo, oerto da 8 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight un'opportuna interfaccia. Le tabelle utilizzate per la classicazione del traco a bordo dei router sono generalmente in grado di operare a velocità di linea e vengono sfruttate anche per realizzare funzioni aggiuntive al forwarding di base, quali: rewall, NAT, QoS, etc.. Nel modello del nodo OpenFlow, queste tabelle vengono denominate ow table e specicano le regole di trattamento associate a ciascun usso di traco. L'entità base con cui viene rappresentato e gestito il traco in OpenFlow è il usso di pacchetti (ow); quest'ultimo è denito da una regola di classicazione ottenuta specicando il contenuto di opportuni campi dell'intestazione tramite una entry della ow table. Il protocollo OpenFlow permette quindi al piano di controllo di denire in modo essibile e dinamico le regole di instradamento e trattamento dei pacchetti appartenenti ai diversi ussi di traco. Solitamente l'implementazione delle tabelle di classicazione dei pacchetti, che sovrintendono alle relative regole di inoltro, è una caratteristica proprietaria del particolare apparato di networking. Per superare questo modello, OpenFlow mira ad individuare e ed a rendere accessibili attraverso il protocollo, un insieme di funzioni supportate dalla maggior parte dei router o switch commerciali. mentre l'obiettivo principale consiste quindi nel denire un modello astratto dell'elemento che esegue il forwarding dei pacchetti, rendendolo programmabile attraverso un interfaccia aperta e standard. Uno schema molto semplicato dell'architettura OpenFlow è riportato nella Figura seguente. In particolare, lo schema di principio fa riferimento alla versione base dell'architettura, come denita dalla specica OpenFlow nella versione 1.0. I principali elementi funzionali del sistema, come si osserva dalla gura, sono i seguenti: 9 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight 1. le tabelle (Flow Tables) i cui elementi (entry) deniscono i ussi e le azioni associate, determinando il trattamento da applicare ai pacchetti appartenenti ai ussi stessi; 2. un canale sicuro (Secure Channel) tra il nodo ed un processo di controllo remoto (controller), che consente lo scambio di pacchetti e messaggi di comando; 3. il protocollo OpenFlow, come interfaccia di comunicazione standard ed aperta tra il nodo ed il controller; 4. le Group Table che permettono un'ulteriore eleborazione di un pacchetto già trattato con le Flow Tables. Sono costituite da un insieme di Group Entry, che assegnano a determinati gruppi di pacchetti ulteriori istruzioni che dovranno essere eseguite. Un OpenFlow Switch può contenere una o più Flow Tables disposte sequenzialmente in una Pipeline e numerate in base alla loro priorità. Il Pipeline Processing denisce come i pacchetti interagiscono con le Flow Tables. Un pacchetto viene prima confrontato con la Flow Table 0. Le successive tabelle saranno utilizzate in base all'esito del confronto con la prima. Nel caso di un 10 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight esito positivo, ossia quando un pacchetto viene associato con successo ad una Flow Entry, ne vengono eseguite le azioni corrispondenti. Una Flow Entry può anche mandare il pacchetto al confronto con un'altra Flow Table, l'importante è che si trovi sempre avanti nella pipeline. Difatti, una Flow Entry nella Flow Table 4 non potrà mai rimandare il pacchetto alla Flow Table 2. Quando non vi è un ulteriore matching, il Pipeline Processing si interrompe. Le apparecchiature di rete possono essere sia di tipo nativo OpenFlow, cioè in grado di svolgere tutte le sue funzioni tramite programmazione remota da parte di un controllore e sia di tipo tradizionale, in questo caso devono essere in grado di svolgere e interpretare comandi OpenFlow. Questi ultimi apparati vengono detti ibridi e rappresentano lo scenario più realistico nell'ipotesi di un'introduzione in rete in larga scala di questa tecnologia. OpenFlow supporta due modalità di inserimento dei ussi di dati: reattivo e proattivo. Il primo si verica quando un pacchetto raggiunge uno switch OpenFlow senza un usso corrispondente. Il pacchetto viene inviato al controller che lo valuta, aggiunge ussi appropriati e lascia allo switch l'inoltro. Nel caso proattivo già si conosce il percorso e i ussi vengono inviati agli switch prima dell'arrivo dei pacchetti veri e propri. 11 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Capitolo 2 OpenvSwitch e Floodlight Uno switch è un dispositivo di rete che si occupa di ricevere i frame a livello collegamento in ingresso e inoltrarli in uscita correttamente. Gli switch si possono dividere a livello funzionale in piano di controllo e piano di forwarding. Il piano di controllo contiene la funzione di instradamento, o routing, che si occupa di calcolare e determinare le rotte dei pacchetti. Il piano di forwarding utilizza le tabelle per decidere su quale porta o porte inoltrarli. Entrambe le funzioni sono implementate sullo stesso dispositivo. In uno switch OpenFlow il control plane e il data plan sono funzioni separate. La funzione di control plane è adata a un altro dispositivo -Controller- che si occuperà delle decisioni in merito all'instradamento. Il data plane sarà sempre eseguito dallo switch sico. 2.1 OpenvSwitch OpenvSwitch è uno switch virtuale multilivello rilasciato sotto licenza open source Apache 2.0. E' progettato per consentire una alta essibilità e portabilità. La maggior parte del codice è scritto in C. In gura è mostrata una delle possibili congurazioni di OVS: sullo stesso host si trovano più macchine virtuali collegate tra loro mediante OVS, che si 12 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight occupa di instradare i pacchetti. La gestione e il controllo del OVS è centralizzato. Ecco alcune delle funzionalità più importanti: • migrazione delle VM da host ad host; • pieno supporto alle VLAN (standard 802.1q); • supporto OpenFlow 1.0 con numerose estensioni; • QoS anche per singola VM; • tunnel GRE per connettere le VM anche in diversi data center (anche attraverso IPsec); 13 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight • visibilità del traco e statistiche avanzate grazie al supporto NetFlow, sFlow, SPAN, etc. ; • layer di compatibilità per il modulo bridge di linux (in questo modo tutti i software che già utilizzano il bridge non necessitano di alcuna modica per utilizzare Open vSwitch). I vantaggi introdotti dalla virtualizzazione della rete sono: • maggiore accoppiamento tra le macchine virtuali; • minore overhead per lo scambio di pacchetti inter-VM; • possibilità di decidere le policy di instradamento. Perchè dunque utilizzare OpenvSwitch e non l'implementazione di uno switch che ci viene oerta da tutti i sistemi operativi linux-based? OpenvSwitch è per lo più rivolto a implementazioni di piattaforma virtuali Multi-Server, che sono spesso caratterizzati da end-point dinamici e dalla frequente manutenzione delle interfaccie di rete virtuali. La mobilità è una questione importante per questi specici ambienti, infatti gli amministratori della rete devono permettere la migrazione delle VM tra host. Inoltre OVS supporta una serie di funzioni che permettono a un sistema di controllo di rispondere e adattarsi al variare della topologia della rete. Questo include un semplice supporto a applicazioni come NetFlow, IPFIX, e sFlow. Un'altra caratteristica primaria di OpenvSwitch è quella di supportare un database della rete (OVSDB) che ha la possibilità di creare trigger remoti. Usando OVSDB, si possono determinare il numero di switch virtuali, tutte le macchine host collegate, conguare, creare ed eliminare porte o 'tunnel' sul bridge. 14 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Questo è usato molto oggi, ad esempio, per rispondere alle nuove esigenze di essibilità e per monitorare le migrazioni di macchine virtuali. In denitiva si può dire che Openvswitch si concentra sulla necessità di un controllo della rete automatizzata e dinamica in ambienti di virtualizzazione basati su Linux. L'obiettivo di Open switch virtuale è quello di mantenere il codice in kernel più piccolo possibile (per avere buone prestazioni) e di riutilizzare i sottosistemi esistenti (ad esempio il riutizzo di sistemi QoS già presenti). OpenvSwitch è spesso oerto dalle distribuzioni più popolari come utility nello user-space. 2.1.1 Avvio Prima di iniziare si ha la necessità di congurare il database con questo comando: # ovsdb-server --remote=punix:/usr/local/var/run/openvswitch/db.sock --remote=db:Open_vSwitch,Open_vSwitch,manager_options --certificate=db:Open_vSwitch,SSL,certificate --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert --pidfile --detach Eventualmente se non si vuole utilizzare OVS con SSL si devono omettere private-key, certicate e bootstrap-ca-cert. Poi si deve conguare il daemon che gestisce gli switch OpenvSwitch attraverso l'utility ovs-vsctl in questo modo: # ovs-vsctl --no-wait init 15 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight L'opzione aggiuntiva no-wait è necessaria quando il daemon ovs-vswitchd non è ancora in esecuzione. Adesso con il comando: # ovs-vswitchd --pidfile --detach si avvii il daemon principale, che crea un le (ovs-switchd.pid) con il pid del processo che lo esegue e in più passa a una sessione background. Ora che ovs-vswitchd è avviato, si può utilizzare il comando ovs-vsctl per creare e settare bridge o altri componenti OpenvSwitch: # ovs-vsctl add-br mybridge In seguito per aggiungere una o più porte: # ovs-vsctl add-port mybridge vport1 # ovs-vsctl add-port mybridge vport2 2.2 Floodlight Floodlight[2] è un controllore per una rete SDN, che permette di gestire il comportamento degli Switch OpenFlow. Floodlight è supportato dalla Big Switch Network ed è a tutti gli eetti un controllore OpenFlow. E' scritto in java, il che lo rende multipiattaforma, e può essere semplicimente modicato attraverso un ambiente di sviluppo come Eclipse. 16 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight I vantaggi sono: • Funziona sia con switch sici che virtuali, basta che implementino il protocollo OpenFlow • E' un software Open. E' sviluppato da una comunità aperta di sviluppatori. • Facile da installare e da utilizzare, ore un sistema modulare che dà la possibilità agli sviluppatori di migliorarlo e ampliarlo. • Supporto dei meccanissimi di invio dei ussi reattivo e proattivo. 2.2.1 Architettura Essendo Floodlight un controllore per una rete SDN si ha anche qui la divisione tra il piano di controllo e il piano di switching. La gura mostra chiaramente questi due livelli, il livello di controllo e quello dei dati. Al livello più basso (Data Plane tier) si trovano sia OpenFlow Physical Switches che corrispondono a switch sici che Hypervisor (switch virtuali); al livello soprastante c'è il controllore Floodlight, che rappresenta il piano di controllo; al primo livello inne troviamo le applicazioni oerte dal controllore e quelle del sistema operativo. Floodlight non può essere denito solo come un controllore OpenFlow, ma anche come una collezione di applicazioni costruite al di sopra di esso. 17 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Il controllore realizza una serie di funzionalità comuni per una rete OpenFlow, quali routing, inserimento entry, mentre le applicazioni orono dierenti caratteristiche per servire le molteplici esigenze degli utenti. Floodlight inoltre adotta una architettura modulare per implementare le diverse caratteristiche del controllore. Con la successiva gura si possono notare le 3 componenti principali: 18 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight • Le Rest Applications; • Module Applications; • Floodlight Controller. Vediamo in dettaglio: le Rest Applications sono applicazioni che si interfacciano con il controllore tramite le REST API, tra di esse troviamo il Circuit Puscher, che costruisce i percorsi più brevi all'interno della rete SDN, e l'OpenStack Quantum Plugin, scritte entrambe in python. Inoltre Floodlight dà la possiblità di scriversi un'applicazione REST con un qualsiasi linguaggio di programmazione, per sfruttare a pieno la potenza di una rete OpenFlow. Le module Applications sono applicazioni che comunicano con il controller a una larghezza di banda superiore tramite un API Java; forniscono meccanismi quali Firewall, Forwarding, Learning Switch e altri. Inne il controllore ore sia servizi di base OpenFlow, quali, Trace, Controller Memory, sia servizi appositamente sviluppati per Floodlight, come Link Discovery, Packet Streamer e altri. 2.2.2 Module Applications Di seguito saranno descritte alcune applicazioni implementate come moduli Java in Floodlight: • Virtual Network Filter: applicazione utile per la creazione di reti virtuali basate su indirizzi MAC. Consente di creare reti logiche di livello 2 su uno stesso dominio; • Static Flow Entry Pusher: modulo utilizzato per l'installazione in specici switch di ow entries; 19 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight • Firewall: è anche essa implementata come un modulo Floodlight che applica regole ACL (Access Control List) utilizzando i ussi e monitorando il comportamento dei pacchetti in ingresso. Le regole ACL qui sono insiemi di condizioni che permettono di consentire o negare un usso di ingresso allo switch; • Port Down Reconciliation: riconcilia i ussi della rete quando una porta o un link si danneggiano. A seguito dell'evento Port_Down, il modulo elimina i ussi verso quella porta e rivaluta i percorsi del traco in base alla nuova topologia della rete. Senza Port Down Reconciliation il traco continuerebbe ad essere inoltrato verso la porta guasta; • Forwarding: Si occupa dell'inoltro dei pacchetti tra due dispositivi. Poichè Floodlight è stato progettato per lavorare con reti sia OpenFlow che non, il modulo Forwarding tiene conto delle caratteristiche di entrambi; • Hub: inoltra i pacchetti in ingresso verso tutte le porte attive. Di default non è abilitato; • Learning Switch: switch di secondo livello. elencare le tabelle degli switch correnti. 20 Utilizza una Rest API per Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Capitolo 3 Implementazione di una rete SDN 3.1 Descrizione dell'ambiente Si supponga di voler implementare una piccola rete SDN in ambiente Linux. Per far ciò è necessario avere un calcolatore con installata una delle tante distribuzioni oerte; in questo caso si è scelto Ubuntu 12.04. Si ha bisogno dell'installazione di un software per la virtualizzazione, che riesca ad emulare il comportamento di una macchina sica collegata in rete e per questo si è scelto VirtualBox. La topologia della rete può essere rappresentata in questo modo: Dopodichè si passa alla fase installazione e congurazione di OVS. 3.2 Simulazione rete SDN La prima fase del test consiste nel creare un ponte tra l'interfaccia di rete eth0 e l' IP Stack attraverso il bridge OVS. 21 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Supponiamo di avere a disposizione un calcolatore su cui gira la distribuzione linux Ubuntu 12.04 e su cui è installato OVS. Si conguri un bridge, assegnandoci la porta eth0: # # # # # ovs-vsctl add-br mybridge ovs-vctl add-port mybridge eth0 ifconfig eth0 0 ifconfig mybridge up dhclient mybridge L'istruzione ifcong eth0 0 fa in modo che l'interfaccia eth0 non abbia più assegnato un indirizzo IP; le due successive istruzioni invece abilitano l'interfaccia di rete virtuale mybridge assegnandola un indirizzo IP mediante protocollo DHCP. Dando in seguito il comando: # ovs-vsctl show # ifconfig si può vedere quanto precedentemente congurato. Si è passati quindi a una congurazione di rete del genere: 22 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Verichiamo la connettività con il comando ping: ping wikipedia.it Ora si supponga di voler collegare due host virtuali collegati alla rete per mezzo del bridge OVS. Si devono inanzitutto creare le interfacce sul bridge OVS; per far questo assegniamo vport1 alla VM1 e vport2 alla VM2 Attraverso i comandi tun/tap si creano le periferiche virtuali. In particolare il comando TUN si occupa di simulare una periferica di rete di tipo punto-punto mentre il comando TAP simula un dispositivo di livello 2 # ip tuntap add mode tap vport1 # ip tuntap add mode tap vport2 Dopo aver creato le interfacce virtuali, si devono attivare: # ifconfig vport1 up # ifconfig vport2 up Si aggiunga al bridge OVS le porte appena create: # ovs-vsctl add-port mybridge vport1 # ovs-vsctl add-port mybridge vport2 23 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Avviate le due macchine virtuali si può vericare la connettività con il comando ping. 24 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Il traco di rete delle due macchine virtuali passa tutto attravero lo switch OpenFlow; in questo modo si può gestire in modo semplice la rete andando a modicare le tabelle dello switch via software. Inoltre si possono vericare le corrispondenze tra gli indirizzi MAC dei dispositivi attraverso il comando ovs-appctl fdb/show mybridge, che restituisce: Dopo aver congurato correttamente le due macchine virtuali, si potrà avviare la terza VM, su cui si è precedentemente installato Floodlight. Si è fatta questa scelta, di collegare il controllore con un'altra macchina virtuale, solo per ragioni di convenienza, infatti il controllore poteva essere ovunque su internet. Avviato oodlight, questo si mette in attesa di ricevere un attach di uno switch OpenFlow. Prima di collegare correttamente OpenvSwich e Floodlight si deve settare 25 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Openvswitch in modalità Secure in questo modo: # ovs-vsctl set-fail-mode mybridge secure La modalità di default è Standalone, in cui è OVS ad avere la responsabilità per l'inoltro dei pacchetti nel caso in cui il controller non riesca; viceversa nella modalità secure è solo il controllore ad essere responsabile del traco di rete che passa attraverso lo switch. Settiamo il controllore: # ovs-vsctl set-controller mybridge tcp:192.168.1.197:6633 Nella VM3, il controllore avverte che si è connesso allo switch OpenFlow sulla porta 6633 Floodlight tra le tante applicazioni che ore ce ne è una di grande utilità: l'interfaccia graca o GUI che permette di visualizzare l'intera topologia della rete, gli switch che controlla, le ow table. 26 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Per un'ulteriore verica si può dare il comando ovs-vsctl show che restisce la topologia dell'OpenvSwitch con il controllore, come in gura: 27 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Conclusioni Il potenziale impatto del paradigma SDN sulle reti del futuro potrebbe abilitare lo sviluppo di nuovi ecosistemi di servizi ICT. L'introduzione di diversi livelli di astrazione di rete coniugata con la virtualizzazione integrata delle risorse IT e di rete potrebbe permettere di estendere alla rete i paradigmi attualmente utilizzati all'interno dei Data Center. Le soluzioni SDN potrebbero permettere alle applicazioni di avere una vista astratta della rete, come se fosse governata da un piano di controllo concettualmente centralizzato: diventerebbe quindi possibile implementare logiche di controllo astraendo dalla complessità sica della molteplicità di apparati. In particolare Floodlight introduce caratteristiche funzionali e innovative che altri controllori prima di lui non possedevano. Il cuore dell'architettura SDN assomiglia dunque ad un sistema di moduli software di controllo, interagenti fra di loro e capaci di attuare più facilmente azioni di congurazione e ottimizzazione delle risorse di rete; tuttavia questa stessa centralizzazione logica potrebbe avere dei punti critici, quali ad esempio livelli di prestazioni, adabilità, scalabilità e stabilità. 28 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Appendice Installazione OpenvSwitch Per l'installazione del OVS, in ambiente Linux, occorrono di 4 componenti: • l'utility make, che serve per automatizzare il processo di creazione dei le che dipendono da altri le; • un compilatore C, nel nostro caso si è scelta la versione 4.8.2; • la libreria libssl, utile per stabilire una connessione sicura e autentica tra OpenvSwitch e un controllore OpenFlow; • l'interprete Python. Sia l'utility make che il compilatore C possono essere installati a partire dal pacchetto build-essential. E' consigliato installare il pacchetto Git se si vogliono apportare modiche sostanziali al software e condividerle con altri sviluppatori. Si scarichi l'ultima versione dal sito https://github.com/openvswitch/ovs . Dal terminale ci si posizioni nella directory ovs, dopodichè si dia il comando: ./boot.sh 29 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight In seguito si può congurare il package con il comando: ./configure --with-linux=/lib/modules/`uname -r`/build L'opzione del congure serve per caricare il modulo in modalità kernel.Di default tutti i le di installazione sarrano creati nel percorso /usr/share/. . A questo punto si deve procedere con l'utility: # make # make install per installare gli eseguibili e le pagine del manuale(manpages). Installiamo: # make modules_install # /sbin/modprobe openvswitch Open vSwitch si serve di un protocollo per la sua gestione e congurazione, OVSDB (Open vSwitch Database), che permette di creare, gestire, eliminare possibili bridge virtuali o anche singole porte. A tale scopo si deve inizializzare la congurazione del db: mkdir -p /usr/local/etc/openvswitch # ovsdb-tool create /usr/local/etc/openvswitch/conf.db vswitchd/vswitch.ovsschema 30 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Installazione Floodlight Floodlight, essendo un software basato su Java ha bisogno come requisiti di una JDK e del tool ant che permette di automatizzare il processo di sviluppo di applicazioni Java-based. Dopo aver scaricato il progetto Floodlight dal sito uciale http://www.projectoodlight.org/download/ si deve dare il comando: # ant nella cartella appena creata. Una volta che ant ha terminato il processo di build si può avviare oodlight in questo modo # java -jar target/floodlight.jar Dopodichè il controllore si metterà in attesa di ricevere un attach da parte di un dispositivo OpenFlow. 31 Sperimentazione del paradigma SDN mediante OpenvSwitch e Floodlight Bibliograa [1]Open vSwitch software https://github.com/openvswitch/ovs [2]Floodlight Project http://www.projectfloodlight.org/floodlight/ [3]Documentazione Floodlight http://www.openflowhub.org/display/floodlightcontroller/Floodlight+Documentation [4]Documentazione OpenvSwitch http://openvswitch.org/support/ [5]OpenFlow Tutorial http://archive.openflow.org/wk/index.php/OpenFlow_Tutorial [6]OpenFlow Switch Specication http://archive.openflow.org/documents/openflow-spec-v1.1.0.pdf 32
© Copyright 2024 ExpyDoc
