Professional Documents
Culture Documents
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
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++.
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.
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.
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.
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.
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<NUM_CLIENT){ tabella[z].mac=flow.dl_src; tabella[z].port=pi.in_port; tabella[z].ip=flow.nw_src; } pi.in_port-1 necessario per far corrispondere lindice della tabella (che parte da 0) e lindice della porta (che inizia da 1). tabella aggiornata solo quando il pacchetto arriva da un client perch le righe relative ai server sono gi state inizializzate e non devono essere modificate.
Il controllore riconosce i pacchetti ARP che transitano e risponde alla richiesta in sostituzione del client o del server. Per intercettare i pacchetti ARP controlliamo la lunghezza del pacchetto in arrivo al controllore con la condizione : pi.total_len==42 && flow.dl_dst.is_broadcast( ) Lulteriore controllo sulla porta di arrivo del pacchetto permette di sapere se la richiesta arriva da un client o da un server e rispondere di conseguenza. Per generare il pacchetto serve una spazio di memoria di 42 byte da riempire byte per byte con i corretti parametri. Per dichiarare il buffer necessario si usa: Array_buffer pacchetto(42); La classe Array_buffer contenuta nella libreria buffer.hh. I campi del pacchetto ARP sono rappresentati nella immagine sottostante:
Di seguito significato e breve descrizione di ogni campo: Indirizzo MAC dest. Indirizzo MAC sorg. Tipo: il valore 0x806 indica il tipo ARP; HW Type: specifica la tipologia di indirizzo fisico presente nel frame. Il valore 1 indica un indirizzo fisico di tipo ethernet; Protocol Type: indica il protocollo di livello network al quale appartiene lindirizzo di cui vogliamo conoscere il corrispondente MAC Address . Il valore 0800 indica il protocollo IP; HLen: indica la lunghezza in byte dellindirizzo fisico (6 byte per MAC); PLen: indica la lunghezza in byte dellindirizzo del livello network (4 byte per IP); Operation: indica se si tratta di richiesta di informzioni (ARP_request) o di una risposta (ARP_reply). In caso di ARP_request ha valore 1 mentre in caso di ARP_reply ha valore 2; Sender HA: indica lindirizzo fisico dellapparato trasmittente; Sender PA: indica lindirizzo del protocollo network dellapparato trasmittente; Target HA: indica lindirizzo fisico dellapparato destinatario; 10
Target PA: indica lindirizzo del protocollo network dellapparato destinatario. Limplementazione realizzata la seguente : //MAC destination (6byte) pacchetto.data( )[0]=flow.dl_src.octet[0]; pacchetto.data( )[1]=flow.dl_src.octet[1]; pacchetto.data( )[2]=flow.dl_src.octet[2]; pacchetto.data( )[3]=flow.dl_src.octet[3]; pacchetto.data( )[4]=flow.dl_src.octet[4]; pacchetto.data( )[5]=flow.dl_src.octet[5]; flow.dl_src il mac address sorgente; octet definito nella libreria netinet++/ethrnetaddr.hh e permette di selezionare un byte su sei dellindirizzo MAC; //MAC source (6byte) pacchetto.data( )[6]=tabella[out-1].mac.octet[0]; pacchetto.data( )[7]=tabella[out-1].mac.octet[1]; pacchetto.data( )[8]=tabella[out-1].mac.octet[2]; pacchetto.data( )[9]=tabella[out-1].mac.octet[3]; pacchetto.data( )[10]=tabella[out-1].mac.octet[4]; pacchetto.data( )[11]=tabella[out-1].mac.octet[5]; out-1 utilizzato nel caso di risposta del controllore al client //Type: ARP (0x0806) (2byte) pacchetto.data( )[12]=8; pacchetto.data( )[13]=6; //Hardware type: Ethernet (0x0001) (2byte) pacchetto.data( )[14]=0; pacchetto.data( )[15]=1; //Protocol type: IP (0x0800) (2byte) pacchetto.data( )[16]=8; pacchetto.data( )[17]=0; //Hardware size: 6 (1 byte) pacchetto.data( )[18]=6; //Protocol size: 4 (1 byte) pacchetto.data( )[19]=4; //Opcode: reply (0x0002) (2 byte) pacchetto.data( )[20]=0; pacchetto.data( )[21]=2; E una risposta ARP; 11
//Sender MAC address: (6byte) (sender il server) pacchetto.data( )[22]=tabella[out-1].mac.octet[0]; pacchetto.data( )[23]=tabella[out-1].mac.octet[1]; pacchetto.data( )[24]=tabella[out-1].mac.octet[2]; pacchetto.data( )[25]=tabella[out-1].mac.octet[3]; pacchetto.data( )[26]=tabella[out-1].mac.octet[4]; pacchetto.data( )[27]=tabella[out-1].mac.octet[5]; //Sender IP address: 10.0.0.9 (ip del server) pacchetto.data( )[28]=flow.nw_dst&255; pacchetto.data( )[29]=flow.nw_dst>>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.
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
<=
NUM_CLIENT
&&((pi.total_len==42
&&
IM_ARP_ritorno[anz]!=1)
||
(
pi.total_len!=42
&&
ARP[id_cli]!=1))
17
Dal punto di vista logico il contatore viene valutato modulo n, dove n il numero dei server. Operativamente il counter pu assumere solo i valori {1,2, . NUM_SERVER} che vengono sommati al numero di client: out=(NUM_CLIENT + counter); ottenendo in ogni situazione un numero di porta che si riferisce ad un server. Anche in questo caso 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 <= NUM_CLIENT &&((pi.total_len==42 && IM_ARP_ritorno[anz]!=1) || ( pi.total_len!=42 && ARP[id_cli]!=1))
18
6.
Prestazioni
e
conclusioni
6.1
Misure
Per
valutare
le
prestazioni
degli
algoritmi
implementati
si
proceduto
in
due
fasi:
1. misurazione
del
tempo
di
risposta
al
ping
quando
il
client
non
ha
memorizzata
alcuna
associazione
tra
indirizzo
IP
del
server
e
relativo
indirizzo
MAC.
Si
valutano
in
questo
modo
le
prestazioni
della
nuova
gestione
delle
risposte
ARP
affidata
al
controllore:
Le misure sono state ripetute 35 volte e in tabella ne rappresentato il valore medio. Il comando usato stato: ping 10.0.0.9 c 1 consecutivamente da ogni client. Dopo aver verificato con il comando: arp a che la cache ARP fosse effettivamente vuota; 2. misurazione del tempo di risposta al ping quando il client gi a conoscenza dellindirizzo MAC del server, in questo caso si valuta le prestazione dellinstallazione dei flussi con reassignamento:
Le misure sono state effettuando eseguendo il comando ping 10.0.0.9 c 100 da ogni client collegato. 19
6.2 Conclusioni
Dallanalisi delle prestazioni possiamo affermare che, coerentemente con le aspettative, la nuova gestione delle risposte alle richieste ARP introduce un ottimo miglioramento. Abbiamo verificato che aumentando lintellingenza dello switch, affidandogli compiti normalmente lasciati agli host, si ottengono tempi di risposta ridotti di circa 3 volte. Non si sono visti miglioramenti significativi quando il controllore deve solo elaborare i flussi correti poich non si intervenuti su questo aspetto. Il progetto espandabile eliminando alcune limitazioni come la gestione statica dei server e affidandosi ad una piattaforma di simulazione che possa consentire il confronto con un algoritmo di scelta che valuti effettivamente il server che in quel momento sta gestendo meno connessioni.
20
21
Se i timeout delle connessioni non sono ancora scaduti verranno visualizzati i flussi ancora validi. Per trasferire i file comodo utilizzare il sofware WinSCP. Su piattaforme MAC/Linux si effettua la connessione SSH dal terminale con il comando: ssh X openflow@192.168.56.101 (indirizzo IP da verificare nella macchina virtuale) Per copiare file da e verso la macchina virtuale si pu usare il comando scp da terminale.
22
Internetworking con TCP/IP Vol. 1, Douglas E. Comer, V ed. 2006 C++ - La guida completa, Herbert Schildt, IV ed. - 2003
Sito ufficiale OpenFlow http://www.openflow.org/ Sito ufficiale NOX http://noxrepo.org/wp/ Sito ufficiale Wireshark http://www.wireshark.org/ Tutorial OpenFlow e download macchina virtuale http://www.openflow.org/wk/index.php/OpenFlow_Tutorial Mailing list NOX-Dev http://www.mail-archive.com/nox-dev@noxrepo.org/info.html Mininet http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/MininetDocumentation Archivio mailing list NOX-Dev http://noxrepo.org/pipermail/nox-dev/ Rfc 826 - An Ethernet Address Resolution Protocol http://tools.ietf.org/html/rfc826 Xming http://sourceforge.net/projects/xming/
23