5.2.1
Presentazione del componente
Il ruolo del modulo myARPModule.py pu`o essere riconducibile quello della ge- stione degli host. Pi`u nel dettaglio, viene svolta la triplice funzione di:
1. mantenere informazioni aggiornate sulla posizione degli host all’interno della rete;
2. consentire il corretto scambio di messaggi ARP da essi generati; 3. notificare la scoperta o la rimozione di un host ai moduli interessati.
La classe che implementa il componente prende il nome di ARPHandler. Per permettere lo svolgimento del primo compito, tale classe `e stata provvista di un dizionario – hosts – che mappa ciascuno switch (ciascun identificativo di uno switch) in un ulteriore dizionario, il quale costituisce una corrispondenza tra l’indirizzo IP di un host e la tupla formata dal suo indirizzo MAC e dal numero della porta dello switch tramite la quale `e possibile raggiungerlo. In breve:
s e l f. h o s t s [ s w i t c h _ i d ][ h o s t _ i p ] = ( h o s t _ m a c , s w i t c h _ p o r t ).
Ogni volta che un nuovo nodo viene scoperto, si procede all’inserimento delle informazioni d’interesse nell’apposito dizionario. Poich´e, in linea di principio, un host potrebbe disconnettersi dallo switch corrente per poi (eventualmente) collegarsi altrove, sorge la necessit`a di liberarsi delle informazioni precedente- mente memorizzate e divenute ormai obsolete. A tale scopo, il modulo dispone del dizionario timeouts, analogo ad hosts, nel quale l’indirizzo IP del nodo viene fatto corrispondere ad un timer. In sintesi:
s e l f. t i m e o u t s [ s w i t c h _ i d ][ h o s t _ i p ] = T i m e r 1 .
L’esaurimento di detto timer impone la necessit`a di accertarsi se il nodo in esame sia ancora esistente o meno. Precisamente, l’approccio adottato `e quello denominato soft-state: la ricezione di un pacchetto causa il “rinfresco” del timer associato alla sorgente. Rinfrescare un timer significa farlo ripartire dal valore iniziale, nel nostro caso memorizzato dalla variabile hostTimeout. L’applica- zione assume che tale valore sia pari a 10 minuti. Un host che tace per pi`u di hostTimeout secondi “entra in quarantena”. Esiste infatti un terzo dizionario – lastChance – strutturalmente identico a timeouts, ma dotato di timer ca- ratterizzati da una durata inferiore. In lastChance s’inseriscono gli indirizzi IP degli host che hanno visto scadere il proprio timeout. Brevemente:
s e l f. l a s t C h a n c e [ s w i t c h _ i d ][ h o s t _ i p ] = T i m e r 2 .
Contestualmente all’inserimento in lastChance, il controller genera un’ARP Request “ad-hoc”, in modo da sollecitare una risposta da parte dell’host in qua- rantena. Se tale risposta viene ricevuta entro lo scadere del nuovo timer (in lastChance), quello originario (in timeouts) viene ripristinato e ci si limita a rimuovere da lastChance l’indirizzo IP del nodo; altrimenti, l’host viene dichia- rato non pi`u esistente e le informazioni ad esso relative vengono eliminate da tutti i dizionari (hosts, timeouts e lastChance).
Per la seconda funzionalit`a, nella tabella di ogni switch viene installata una regola permanente4 che imponga d’inviare al controller tutti i pacchetti ARP ricevuti su una qualsiasi delle porte di cui lo switch `e in possesso.
Il terzo punto `e ottenuto facendo in modo che venga sollevato l’evento HostEvent ogni qual volta si aggiungano o si rimuovano informazioni da hosts. Tale evento possiede i flag added e removed da settare, rispettivamente, nel primo e nel secondo caso. Vengono riportati, inoltre, gli indirizzi MAC ed IP
4Come illustrato nel capitolo 3, una regola permanente `e caratterizzata da idle timeout e hard timeout entrambi nulli.
Applicazione di controllo 45
del nodo in esame, oltre all’identificativo dello switch ed il relativo numero di porta cui l’host `e connesso.
5.2.2
Analisi del codice
Il codice relativo al modulo in esame pu`o essere recuperato consultando il paragrafo D.2.
Gestione delle ARP Request
La gestione delle ARP Request `e affidata al metodo manageARPRequests(). Per ogni ARP Request ricevuta da uno switch, il controller verifica che sia presente la corrispondenza host ip:(host mac, switch port) relativa all’host che ha inviato la richiesta. In caso di esito positivo, esso si limita a rinfrescare il timer associato; altrimenti, inserisce tale corrispondenza negli appositi dizionari, avvia un nuovo timer e solleva un evento per notificare la scoperta del nodo ai moduli interessati.
Se l’indirizzo MAC ricercato `e quello relativo al default gateway per la sotto- rete, si provvede a costruire e consegnare la risposta necessaria. Questa conterr`a l’indirizzo fisico corrispondente alla porta dello switch dalla quale `e stato rice- vuto il messaggio ARP. Altrimenti, il MAC d’interesse `e necessariamente quello relativo ad un host appartenente alla sottorete. In tal caso, il controller si limita ad inoltrare la richiesta.
Se si `e a conoscenza del legame host ip:(host mac, switch port) per l’host di destinazione, l’inoltro coinvolge esclusivamente la porta corretta; al- trimenti, viene fatto ricorso alla tecnica del flooding (paragrafo 3.2). L’utilizzo del flooding in una rete contenente cicli fisici (quelli di routing si suppongono scongiurati) pu`o essere potenzialmente distruttivo [22]. La gestione di questa vulnerabilit`a `e rimandata al paragrafo 5.5.
La figura 5.2 riassume quanto `e stato detto finora. Gestione delle ARP Reply
Il metodo cui viene affidata la gestione delle ARP Reply `e manageARPReplies(). La struttura della funzione `e simile a quella appena descritta.
Se il controller `e gi`a in possesso della corrispondenza host ip:(host mac, switch port) relativa all’host che ha generato la risposta, si limita a rinfrescare il timer associato; in caso contrario, aggiunge le informazioni d’interesse negli appositi dizionari, avvia un nuovo timer e solleva un evento per notificare la scoperta del nodo ai moduli interessati. All’interno della prima casistica, rientra anche un host in quarantena che invii una risposta entro lo scadere del timer presente in lastChance. La ricezione di detta risposta dimostra che il nodo in esame `e ancora esistente e, dunque, consente al controller di poter rimuovere il suo indirizzo IP dall’apposito dizionario.
Se il pacchetto `e diretto al default gateway, siamo in presenza di una risposta ad una richiesta generata dal controller da parte di un host in quarantena. Tale
ARP Request
sorgente
nota rinfresca timer
memorizza informazioni, avvia timer e solleva evento per default gateway costruisci e recapita risposta destinazione nota inoltra la richiesta sulla porta corretta
inoltra la richiesta tramite flooding END n s n s n s
Applicazione di controllo 47
situazione `e gi`a stata trattata al passo precedente: dunque, non necessita di alcuna azione supplementare. Altrimenti, la risposta viene consegnata all’host della sottorete cui era diretta originariamente. Si osservi come, in questo caso, la conoscenza del nodo di destinazione da parte del controller venga data per scontata: dal momento che una risposta presuppone sempre una richiesta, le informazioni relative all’host di destinazione saranno gi`a state memorizzate.
La figura 5.3 riassume, in forma grafica, le azioni specificate dal metodo trattato.
Gestione dei pacchetti non ARP
Poich´e un controller SDN entra in possesso di qualsiasi pacchetto per il quale uno switch connesso non possiede una regola valida all’interno della propria tabella, esiste la possibilit`a che il modulo in esame veda recapitarsi delle trame Ethernet il cui campo Type presenti un valore diverso da 0x08065. Il gi`a citato “principio di non interferenza” suggerirebbe che myARPModule.py ignorasse tali tipologie di messaggio, essendo verosimile che la loro gestione sia competenza di altri moduli. D’altro canto, la ricezione di un pacchetto conferma l’esistenza della propria sorgente. La scelta che `e stata fatta `e quindi quella di limitarsi a rinfrescare il timer associato ad un host, qualora venisse consegnato al modulo un pacchetto non ARP (in pratica, IP) da questi generato.
Si potrebbe obiettare che se uno switch possedesse una regola valida per il pacchetto in transito, il controller non verrebbe chiamato in causa, cui segui- rebbe il mancato rinfresco del timer associato alla sorgente. Da questo punto di vista, la totale assenza di regole nelle tabelle degli switch parrebbe preferibi- le. `E necessario per`o osservare come l’adozione di una strategia di questo tipo imponga che il controller entri in possesso di qualunque pacchetto ricevuto da qualunque switch presente nella rete. Poich´e il controller costituisce, a prescin- dere, il “collo di bottiglia” di un’architettura SDN (paragrafo 3.3), si `e preferito non aggiungere questo ulteriore carico di lavoro. Occorre inoltre sottolineare che il coinvolgimento del controller comporta, nella maggior parte dei casi, la perdita di alcuni pacchetti; elemento che fornisce un ulteriore pretesto per non adottare la soluzione di cui sopra.
Gestione degli host in quarantena
Il metodo checkHost() viene invocato allo scadere di un qualsiasi timer presente in timeouts, associato ad un host di cui il controller `e venuto a conoscenza. Il compito della funzione `e quello di “mettere in quarantena” tali nodi, secondo le modalit`a discusse in precedenza.
Nel caso in cui un host in quarantena non risponda alla sollecitazione gene- rata dal controller, si dovr`a procedere alla sua rimozione dai dizionari dedicati ed alla generazione della conseguente notifica, diretta ai moduli interessati. Di tutto questo, si occupa il metodo removeHost().
5Valore esadecimale utilizzato nelle intestazioni delle trame Ethernet per codificare il protocollo ARP.
ARP Reply sorgente nota sorgente in quarantena rimuovi da quarantena memorizza informazioni, avvia timer e solleva evento rinfresca il timer per default gateway inoltra la risposta sulla porta corretta
END n s n s n s
Applicazione di controllo 49