LOAD BALANCING CON OPENFLOW AUTORI: Bruno Federico Busti Samuel Lista Angelo Pistillo Alessandro

Indice: 1 Introduzione 2 Strumenti utilizzati 2.1 OpenFLow 2.2 Nox 2.3 Mininet 2.4 Wireshark 2.5 Putty Winscp 2.6 2.7 Xming

3 Scenario simulato 3.1 Semplificazioni 3.2 Funzionamento 3.2.1 Ipotesi di funzionamento 3.2.2 Comportamento di un client 3.2.3 Comportamento di un server 4 Descrizione codice 4.1 Gestione statica della tabella Porta-MAC-IP (server) 4.2 Riempimento della tabella Porta-MAC-IP (client) 4.3 Gestione risposte ARP 4.4 Installazione flussi 4.4.1 Codice 4.4.2 Descrizione funzionamento 5 Algoritmi di scelta 5.1 Algoritmo casuale 5.2 Algoritmo round robin 6 Prestazioni e conclusioni 6.1 Misure 6.2 Conclusioni 7 Guida alla simulazione 8 Bibliografia e link utili

3 4 4 4 4 5 5 6 6 7 7 7 7 8 8 9 9 9 10 13 13 15 17 17 17 19 19 20 21 23

2

1. Introduzione Il lavoro presentato nel seguito mette a confronto due algoritmi diversi per effettuare tecniche di bilanciamento di carico. Il bilanciamento di carico importante quando pi server, con lo stesso IP e che mettono a disposizione lo stesso servizio sono raggiungibili da molti client. Lalgoritmo di load balancing decide quale server far rispondere alla richiesta in arrivo dai client. Lo scenario implementato nel nostro progetto prevede sette client con indirizzi MAC e IP differenti e tre server con indirizzi MAC diversi che fanno per riferimento allo stesso indirizzo IP. I due algoritmi presi in considerazione sono stati il round robin, ossia la scelta sequenziale, e un algoritmo di scelta casuale. Il nostro lavoro stato quello di modificare e migliorare un progetto gi esistente su questo argomento. La nuova implementazione consiste in una gestione dello scambio dei pacchetti ARP tra client/server e controllore che, come si dimostrer nell'analisi delle prestazioni, ha portato benefici in termini di tempi di risposta alle richieste. La piattaforma che ha permesso la realizzazione del bilanciamento di carico OpenFlow che mette a disposizione un protocollo di comunicazione tra switch e controllore. Per la realizzazione del progetto si sarebbe potuto utilizzare anche la piattaforma di simulazione Netkit, tuttavia la nostra scelta ricaduta su Mininet perch quest'ultima offre una macchina virtuale gi utilizzata a Stanford nel corso CS244: Advanced Topics in Networking con tutti gli strumenti necessari (Nox e OpenFlow) gi installati e predisposti. Per contro complesso implementare all'interno della macchina virtuale Mininet altri strumenti che non siano quelli dati. La programmazione del controllore stata realizzata in C++.

3

2. Strumenti utilizzati 2.1 OpenFLow E' una piattaforma completamente Open Source che nasce alla Stanford University per la sperimentazione di nuovi protocolli di commutazione (switching) e instradamento (routine). Si rivela fin da subito un ottimo strumento da affiancare alla programmazione per la fondamentale facilit con cui si possono provare e testare il funzionamento di nuovi protocolli. In poco tempo si riesce a raccogliere i risultati e le criticit di una determinata rete, e si pu agire su di essa con modifiche strutturali e di carico. Si hanno cos nuovi vantaggi, ottenibili prima solo attraverso la costosa creazione di reti per l'esecuzione dei test: una nuova strada verso l'aumento di velocit delle reti, l'efficienza energetica, la sicurezza e l'ottimizzazione. Nello specifico OpenFlow formato da tre parti: tabelle di flusso installate sugli Switch, un Controller e un protocollo che il Controller usa per comandare gli Switch. Il Controller agisce sugli switch secondo le regole contenute all'interno delle tabelle di flusso.

2.2 Nox

NOX un Controller open-source. Il suo scopo quello di fornire una piattaforma semplificata per la scrittura di software di controllo di rete. I programmi scritti in NOX (utilizzando C + + o Python) hanno un controllo della rete a livello di flusso. Questo significa che si possono determinare quali flussi sono consentiti nella rete e il percorso che adottano. Inoltre, NOX fornisce programmi per l'accesso allo stato di rete tra cui la topologia della rete e la posizione di tutti gli host rilevati. E' ancora in fase di sviluppo, ed attualmente utilizzato in una serie di implementazioni su larga rete di produzione. NOX stato progettato per supportare sia le reti aziendali di grandi dimensioni con centinaia di switch (a sostegno di molte migliaia di host) sia per le reti domestiche con un singolo interruttore in esecuzione. NOX pu essere interposto su qualsiasi flusso e tra i principali scopi troviamo la possibilit per gli sviluppatori di controllare tutte le attivit della rete compresi il forwarding e il routing. L'ultima versione completa di NOX, contiene il codice per eseguire una serie di funzioni di rete comuni (inclusa l'identificazione della topologia, l'individuazione e l'autenticazione degli host, e il routing).

2.3 Mininet

Mininet un progetto che fornisce un API per simulare una rete Multi-Node su una singola macchina. Il codice di Mininet quasi interamente Python tranne per una piccola utility scritta in C. Generalmente, quasi ogni sistema operativo virtualizza le risorse di calcolo utilizzando un processo di astrazione. Mininet, invece, utilizzando la virtualizzazione basata su processi, riesce a gestire molti host (con successo fino a 4096) e switch su un singolo kernel del sistema operativo.

4

In particolare Mininet crea Switch OpenFlow, Controller per comutare gli interruttori, e gli Host per comunicare attraverso la rete simulata. Gli switch e gli host sono collegati tramite coppie di Ethernet virtuale (veth) . Sebbene Mininet attualmente dipenda dal kernel Linux, in futuro potr supportare altri sistemi operativi con la virtualizzazione basata sui processi, come ad esempio i contenitori di Solaris o FreeBSD jails.

2.4 Wireshark Wireshark (noto in precedenza come Ethereal) un software per analisi di protocollo, packet sniffer, e controllo della struttura di una rete. A differenza di altri simili, WireShark fornito di interfaccia grafica e maggiori funzionalit di ordinamento e filtraggio. Permette all'utente di osservare tutto il traffico presente sulla rete, dai bit di controllo fino ai messaggi dei protocolli applicativi, in modo pi chiaro e intuitivo. Tipicamente si riferisce alle reti Ethernet, ma possibile analizzare altri tipi di rete fisica. Diventa quindi uno strumento utile per svariati scopi: dallo sviluppo di protocolli, la ricerca e risoluzione di problemi, per il controllo del traffico di una rete. Wireshark consente inoltre di applicare e combinare tra loro una vastissima gamma di filtri, mostrandoci il risultato delle catture tramite una serie di pannelli tesi a rendere la consultazione quanto pi comoda possibile. I filtri BPF (acronimo di Berkeley Packet Filter) sono la tecnologia che rende Wireshark un tool cos potente e versatile. Il BPF, a differenza di quanto si creda comunemente, un autentico micro-linguaggio di programmazione (con tanto di istruzioni mnemoniche in Assembly!) che viene compilato ed eseguito a runtime sui pacchetti che vengono intercettati da tool come tcpdump e Wireshark. Tali filtri, importanti quando si ha la necessit di isolare soltanto una parte dei pacchetti che sono stati catturati, e su una rete a 100Mbit possono essercene centinaia di migliaia al secondo, vengono compilati in modo da avere le migliori prestazioni possibili quando si sta facendo una cattura in tempo reale. Il loro utilizzo semplice e si basa soltanto sulla conoscenza del nome dei campi di ogni singolo protocollo. Facciamo un esempio: se desideriamo visualizzare soltanto i pacchetti ICMP, non dovremmo far altro che scrivere nel campo Filter della finestra principale di Wireshark la parola chiave icmp. Se vogliamo evidenziare tutti i pacchetti che vengono o vanno verso un determinato IP, diciamo 1.2.3.4, il filtro relativo sar: ip.dst == 1.2.3.4 || ip.src == 1.2.3.4. Che tradotto significa: visualizza soltanto quei pacchetti in cui il campo di destinazione (ip.dst) o (||) il campo sorgente (ip.src) del protocollo IP corrispondano (==) a 1.2.3.4. Altri esempi li vedremo in seguito.

2.5 Putty

PuTTY uno dei pi quotati emulatori di terminale, in grado di agire da client per l'impiego dei protocolli Secure Shell (SSH), Telnet e rlogin. Gli utenti pi avanzati possono per utilizzarlo anche come strumento di diagnostica, grazie alla capacit di generare segmenti TCP contenenti messaggi arbitrari. Lo sviluppo di questo ottimo software iniziato nel lontano 1999: il livello di maturit 5

raggiunto oggi quindi elevatissimo, cos come il numero di caratteristiche di contorno offerte dalla chiara interfaccia grafica.

2.6 Winscp WinSCP (Windows Secure Copy) un client SFTP e FTP di tipo grafico open source per Microsoft Windows. realizzato in linguaggio C++. La sua funzione principale quella del trasferimento tra un computer locale ed uno remoto. In pi WinSCP consente semplici funzionalit di file manager. Per trasferimenti sicuri usa Secure Shell (SSH) e supporta il protocollo SCP in aggiunta al SFTP. Lo sviluppo di WinSCP partito intorno al maggio 2000 ed in continuo aggiornamento. Originariamente il progetto era ospitato dall'Universit di Economia di Praga, dove i suoi ideatori lavoravano. Sin dal 16 luglio 2003 la sua licenza GPL ed possibile reperirlo presso SourceForge.net.

2.7 Xming Xming un server X open source per Windows. E' particolarmente utile nel caso ci si voglia connettere da Windows al server grafico di una macchina remota unix-based.

6

3. Scenario simulato

3.1 Semplificazioni La simulazione effettuata attraverso lutilizzo di Mininet stata semplificata per alcuni aspetti: - gestione statica di indirizzi client e server - enumerazione sequenziale degli indirizzi IP e corrispondenza con il relativo indirizzo MAC (IP: 10.0.0.2 MAC: 00:00:00:00:00:02) - lutilizzo di soli 7 client e 3 server ( possibile usarne di pi modificando le relative tabelle statiche di inizializzazione nel codice) - sulla nostra rete viaggiano solo pacchetti Arp ed Echo.

3.2 Funzionamento

3.2.1 Ipotesi di funzionamento Tutti i client conoscono lindirizzo IP del server a cui vogliono fare richieste. Nella nostra gestione statica questo indirizzo 10.0.0.9. 7

3.2.2 Comportamento di un client Il client si pu trovare in due differenti situazioni: nella sua cache ARP non c corrispondenza tra lindirizzo IP del server e MAC. Il client invia una ARP REQUEST che viene elaborata dal controllore. Il controllore in grado di rispondere alla richiesta informando il client dellindirizzo MAC del server; nella sua cache ARP presente una corrispondenza tra IP del server e MAC. Il client in grado di inviare una ECHO REQUEST usando i dati trovati nella cache ARP. Il controllore riceve il pacchetto e installa il flusso corretto. In questo caso per il client loperazione di scelta del controllore risulta completamente trasparente, cio il client pensa di comunicare con il server corrispondente al MAC conosciuto nella cache ARP ma, in realt, il controllore ha selezionato con quale server farlo comunicare. 3.2.3 Comportamento di un server Il server si comporta in maniera simile. La differenza che la richiesta ARP da un server avviene solo in conseguenza di una ECHO REQUEST arrivata da un client.

8

4. Descrizione codice 4.1 Gestione statica della tabella Porta-MAC-IP (server) Come accennato in precedenza una delle semplificazione stata quella di gestire una tabella statica contenente IP del server (10.0.0.9) e indirizzi MAC dei tre server. La tabella inizializzata con i seguenti valori: tabella[7].port=8; tabella[7].mac="00:00:00:00:00:09"; tabella[7].ip=150994954; tabella il nome della struttura che contiene porta, mac address e ip address. [7] perch larray parte dallindice 0, quindi alla posizione corrisponde il server connesso alla porta 8 . Il mac address pu essere inserito con tale notazione perch definita nella libreria "netinet++/ethernetaddr.hh". LIP deve essere inserito con notazione big endian: 150994954 corrisponde a 00001010-00000000-0000000-00001001 cio 10.0.0.9.

4.2 Riempimento della tabella Porta-MAC-IP (client)

Per il corrette funzionamento del controllore necessario tenere aggiornata la tabella che contiene porta, indirizzo MAC e indirizzo IP dei client. A questo scopo ogni volta che arriva un pacchetto che non abbia una sorgente multicast si inseriscono i dati imparati nella struttura tabella. Per riconoscere se bisogna intervenire si valuta la condizione: if (!flow.dl_src.is_multicast()) Quando la condizione verificata si aggiorna la tabella solo quando il pacchetto arriva da un port associate a client: z=pi.in_port-1; if(z>8&255; pacchetto.data( )[30]=flow.nw_dst>>16&255; pacchetto.data( )[31]=flow.nw_dst>>24;

Nella tabella loperazione di mascheratura per compilare il campo IP: #byte 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 IP 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 Mask 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 Ris 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 >> un operatore bit a bit che trasla il secondo (successivamente terzo e quarto) byte per applicare la maschera. //Target MAC address: (6 byte) (target il client) pacchetto.data( )[32]=flow.dl_src.octet[0]; pacchetto.data( )[33]=flow.dl_src.octet[1]; pacchetto.data( )[34]=flow.dl_src.octet[2]; pacchetto.data( )[35]=flow.dl_src.octet[3]; pacchetto.data( )[36]=flow.dl_src.octet[4]; pacchetto.data( )[37]=flow.dl_src.octet[5]; //Target IP address: (client) pacchetto.data( )[38]=flow.nw_src&255; pacchetto.data( )[39]=flow.nw_src>>8&255; pacchetto.data( )[40]=flow.nw_src>>16&255; pacchetto.data( )[41]=flow.nw_src>>24; Per inviare il pacchetto si usa il comando: send_openflow_packet(pi.datapath_id, pacchetto,flow.in_port ,out, true);

12

pi.datapath_id segnala su quale switch inviare il pacchetto nel caso di topologie che ne prevedono pi di uno; pacchetto il buffer che vogliamo inviare; Terzo e quarto campo sono rispettivamente porta di uscita e ingresso.

4.4 Installazione flussi

Un flusso una regola di instradamento che il controllore pu inserire nella relativa tabella dello switch. In generale quando arriva un pacchetto allo switch, questo verifica se presente una regola che gli indichi su quale porta inviarlo e, quando non ne trova nessuna adatta, invia il pacchetto al controllore. Il controllore con i comandi mostrati nel successivo paragrafo in grado di generare la regola necessaria. 4.4.1 Codice Installazione del flusso tra client e server (per il caso server => si opera in maniera analoga) : ofp_flow_mod* ofm; Puntatore alla varibile necessaria per scrivere il flusso. ofm = (ofp_flow_mod*) raw_of.get(); ofm->header.version = OFP_VERSION; ofm->header.type = OFPT_FLOW_MOD; ofm->header.length = htons(size); htons host to network short una funzione che converte dalla notazione host (little endian) alla notazione network (big endian). ofm->match.wildcards = htonl(0); htonl host to network long. ofm->match.in_port = htons(flow.in_port); flow.in_port la porta di arrivo del pacchetto al controllore ofm->match.dl_vlan = flow.dl_vlan; ofm->match.dl_vlan_pcp = flow.dl_vlan_pcp memcpy(ofm->match.dl_src, flow.dl_src.octet, sizeof ofm->match.dl_src); flow.dl.src e' l'indirizzo MAC della sorgente

13

memcpy( destinazione, source, size) copia lindirizzo MAC della sorgente nella variabile che serve a verificare se la regola da utilizzare o no. memcpy(ofm->match.dl_dst, flow.dl_dst.octet, sizeof ofm->match.dl_dst); ofm->match.dl_type = flow.dl_type; ofm->match.nw_src = flow.nw_dst; flow.nw_src lindirizzo IP della sorgente; ofm->match.nw_dst = flow.nw_src; flow.nw_dst lindirizzo IP della destinazione; ofm->match.nw_proto = flow.nw_proto; nw_proto il protocollo di rete utlizzato, nel nostro caso IP; ofm->match.nw_tos = flow.nw_tos; ofm->match.tp_src = flow.tp_src; flow.tp_src la porta TCP/UDP della sorgente; ofm->match.tp_dst = flow.tp_dst flow.tp_dst la porta TCP/UDP della destinazione; ofm->cookie = htonll(0); ofm->command = htons(OFPFC_ADD); OFPC_ADD il comando per aggiungere un flusso; ofm->buffer_id = htonl(buffer_id); ofm->idle_timeout = htons(5); Abbiamo impostato il timeout della regola a 5 secondi. ofm->hard_timeout = htons(OFP_FLOW_PERMANENT); ofm->priority = htons(OFP_DEFAULT_PRIORITY); ofm->flags = htons(ofd_flow_mod_flags());

14

ofp_action_dl_addr& action_dst =*((ofp_action_dl_addr*)((uint8_t*)ofm -> actions)); memset(&action_dst, 0, sizeof(ofp_action_dl_addr)); action_dst.type= htons(OFPAT_SET_DL_DST); action_dst.len=htons(sizeof(ofp_action_dl_addr)); memcpy(action_dst.dl_addr, re_assign.octet, OFP_ETH_ALEN); ofp_action_output& action = *((ofp_action_output*)((uint8_t*)ofm->actions+ sizeof(ofp_action_dl_addr))); memset(&action, 0, sizeof(ofp_action_output)); action.type = htons(OFPAT_OUTPUT); action.len = htons(sizeof(ofp_action_output)); action.max_len = htons(0); action.port = htons(out); send_openflow_command(pi.datapath_id, &ofm->header, true); Il comando per inviare il nuovo flusso allo switch. 4.4.2 Descrizione funzionamento Se il pacchetto una richiesta ARP, questo viene inviato dal client verso i server con un indirizzo MAC di tipo broadcast: il controllore applica l'algoritmo di load balancing e sceglie il numero di una porta d'uscita a cui associato l'indirizzo MAC di un server. Il codice descritto nel paragrafo 4.3 si occupa della creazione e dellinvio del pacchetto di risposta. Ricevendo questo pacchetto il client crede di avere ricevuto la risposta ARP dal server quando in realt stato il controllore a gestire la risposta. Il client pu ora inviare il pacchetto con la richiesta di servizio. Dato che il server a cui connettersi gi stato scelto durante la fase di scambio dei messaggi ARP, l'algoritmo non viene applicato al pacchetto contenente la richiesta di servizio ma, al suo arrivo, il controllore installa un flusso, cio una regola di instradamento, tra il client e il relativo server. Quando il server vedr arrivare una richiesta di servizio vorr sapere l'indirizzo MAC del client. Far a sua volta quindi una richiesta ARP con indirizzo di destinazione broadcast. Anche in questo caso il controllore catturer la richiesta ARP del server rispondendo con il MAC address del client. Il server creder di avere ricevuto la risposta ARP dal client. Risponder quindi alla richiesta di servizio e nel momento in cui questa arriver al controllore verr installato un flusso da server a client. 15

Nel caso in cui, invece, il pacchetto sia il primo di una nuova connessione, inviato cio da un client che conosce gi l'indirizzo MAC di una delle destinazioni, il controllore applica l'algoritmo per scegliere un server a cui assegnare la richiesta di servizio il quale avr per in generale un MAC diverso da quello richiesto dal client. Ci avviene perch, avendo tutti i server lo stesso indirizzo IP, i client associano a questo un solo indirizzo MAC, quello del primo server contattato, e mantengono questa associazione nella loro cache ARP. Per risolvere questo problema necessario che il controllore cambi l'indirizzo MAC all'interno del pacchetto inviato dal client in modo che questo non venga ignorato dal server scelto. Infatti, nel caso l'indirizzo MAC non venisse cambiato e il server scelto ricevesse un messaggio con un indirizzo di destinazione diverso dal proprio, il pacchetto in questione verrebbe scartato. La sostituzione dell'indirizzo MAC viene effettuata quando si installa un flusso tra un client e il relativo server. Affinch il server possa rispondere al client necessario che il controllore installi anche un flusso di ritorno che implementi la regola per far si che il traffico inviato dal server venga instradato verso il client. In questa fase viene anche cambiato l'indirizzo MAC sorgente in modo che il client veda arrivare pacchetti inviati dalla destinazione da lui precedentemente richiesta e non ignori quindi i pacchetti.

16

5. Algoritmi 5.1 Algoritmo casuale Per l'applicazione dell'algoritmo casuale, all'arrivo di una nuova richiesta di connessione da parte di un client, viene scelto casualmente una porta d'uscita dello switch relativo ad un determinato server utilizzando la funzione: srand(time(NULL) che inizializza il generatore di numeri casuali che, senza di essa, fornirebbe sempre lo stesso risultato. L'istruzione successiva out = rand( )%(NUM_SERVER)+(NUM_CLIENT+1) assegna alla variabile out un valore che parte da NUM_CLIENT+1 a cui viene sommato casualmente un numero che va da 0 a NUM_SERVER. Quindi i valori che out pu assumere sono {8 , 9 , 10}. srand e rand sono contenute nella libreria stdlib.h L'algoritmo viene applicato solo se il pacchetto proviene da una delle porte assegnate a un client, se relativo a una richiesta ARP oppure il primo pacchetto di una nuova connessione. Infatti si valuta la seguente condizione: if(pi.in_port >=0 && pi.in_port =0 && pi.in_port