7. Network Management Concepts

Questo argomento è stato trattato in networkSM.

---

Virtual Local Area Network (VLAN)

Spesso, le LAN sono configurate gerarchicamente, con ogni gruppo che dispone di una propria LAN, collegata ad altre LAN mediante una gerarchia di switch. Si tratta di una configurazione ideale che soffre però di alcuni svantaggi:

• mancanza di isolamento di traffico: sebbene il traffico di un gruppo sia localizzato all’interno di un singolo switch, il traffico broadcast attraversa tutta la rete. Si vuole isolare isolare il traffico sia per migliorare le prestazioni, evitando che il traffico broadcast diventi traffico inutile per diverse porzioni di rete, sia per questioni di sicurezza;
• uso inefficiente degli switch: sarebbe necessario uno switch per ogni rete;
• gestione degli utenti: è necessario cambiare il cablaggio fisico se un utente si sposta nel contesto di un altro switch.

Questi problemi sono risolti con l’introduzione di switch che supportano le Virtual Local Area Network (VLAN), che permettono di definire più LAN, virtuali, sull’infrastruttura di un’unica LAN. Infatti, due host sulla stessa VLAN possono comunicare tra di loro come se fossero collegati, in esclusiva, allo stesso switch.

Nell’approccio port-based, le porte dello switch sono divise in gruppi dal gestore della rete e ogni gruppo forma una VLAN; ogni VLAN forma poi un dominio di broadcast. Nel software di gestione dello switch, viene mantenuta una tabella con il mapping porte a VLAN, sulla base della quale lo switch va ad inviare frame alle porte che appartengono alla stessa VLAN.

Se bisogna fare in modo che più switch gestiscano la stessa rete (cioè interconnettere tra di loro più switch), l’approccio seguito è quello del VLAN trunking^[L’approccio sbagliato sarebbe connettere più volte lo switch, una volta per ogni VLAN, ad un altro switch, mantenendo l’associazione tra VLAN e gruppi di porte.], in cui vi è un’unica porta, la porta di trunk, per connettere più switch: la porta di trunk, infatti, appartiene a tutte le VLAN gestite dagli switch.

Per supportare le VLAN, è stato definito il formato frame ethernet esteso (802.1Q). Questo formato è simile a quello dell’ethernet standard, a cui sono aggiunti 4 byte all’intestazione che indicano l’identità della VLAN a cui il frame appartiene. Il tag della VLAN è aggiunto al frame dallo switch che invia il pacchetto sulla porta di trunking, elaborato e rimosso poi dallo switch ricevente. Il tag è costituito da 2 byte per il campo TPID (Tag Protocol Identifier) e da altri 2 byte per il campo Tag Control Information che contiene un identificativo della VLAN su 12 bit e un campo a 3 bit per la priorità.

Le VLAN possono essere definite anche in altri modi, come ad esempio sulla base dell’indirizzo MAC o sulla base dei protocolli del livello di rete.

Software Defined Network (SDN)

L’approccio SDN per la gestione della rete va contro l’approccio classico, per cui l’inoltro dei pacchetti è fatto unicamente mediante l’indirizzo di destinazione. Infatti, si segue un paradigma match-plus-action in cui la decisione sull’inoltro non è effettuata unicamente mediante l’indirizzo di destinazione, ma anche sulla base di altri campi, anche appartenenti a intestazioni di livelli diversi; anche l’inoltro stesso non è più l’unica azione possibile.

Le possibili azioni sono raccolte nella match-plus-action table, nota anche come flow table. Le proprietà di match-plus-action sono implementate sulla base di un controller remoto che si occupa di gestire ed installare le flow tables sui dispositivi (switch e router) deputati all’inoltro dei pacchetti (più correttamente chiamati packet switches). Ogni entry della tabella include:

• una serie di valori per campi delle intestazioni contro cui un pacchetto entrante viene controllato. Qualora nessuna entry sia compatibile, il pacchetto può essere scartato oppure inviato al controller remoto per ulteriore processamento;
• una serie di contatori, aggiornati ogni volta che sui pacchetti è possibile applicare una entry;
• una serie di azioni da svolgersi se il pacchetto corrisponde ad una entry.

Le proprietà di una SDN:

• inoltro basato sul flusso: il pacchetto può essere inoltrato sulla base di qualsiasi numero di valori presenti nelle intestazioni a livello di trasporto, di rete o di collegamento;
• seprazione del piano di controllo dal piano di inoltro;
• le funzioni del controllo di rete sono esterne agli switch: il piano di controllo è implementato via software;
• rete programmabile mediante applicazioni eseguite nel piano di controllo.

Il controller SDN ha 3 livelli:

1. livello di comunicazione;
2. livello di stato di rete;
3. livello di interfaccia.

Il livello di comunicazione consente la comunicazione tra il controller e i dispositivi di rete controllati, in cui il controller determina le operazioni di uno switch SDN remoto; il protocollo OpenFlow è implementato in praticamente tutti i controller SDN.

È cruciale che il controller abbia informazioni aggiornate sullo stato della rete, inclusi host, collegamenti, switch e altri dispositivi collegati. Per questo, il controller potrebbe conservare una copia delle tabelle che, insieme a tutte le altre informazioni fanno parte del livello di stato della rete.

Il controller interagisce poi con le applicazione di controllo della rete mediante l’interfaccia northbound, una collezione di API che permette alle applicazioni di controllo della rete di leggere e scrivere lo stato della rete e le flow table, nel livello di gestione dello stato. Le applicazioni possono chiedere di essere notificate quando avviene un evento che determina il cambiamento dello stato, in modo da svolgere azioni in riposta.

OpenFlow

OpenFlow è un protocollo che permette ad un controller di interagire direttamente con il piano di inoltro dei dispositivi di rete, rendendo possibile gestire il traffico in modo dinamico e programmatico, poiché consente di specificare come il controller può aggiungere, aggiornare o eliminare delle entry nella flow table.

Il concetto principale è che OpenFlow permette di separare il piano di controllo con il piano di inoltro, spostando il controllo in un controller SDN centralizzato.

Un dispositivo che implementa OpneFlow può essere usato sia come router (inoltro di datagrammi, livello 3) che come switch (inoltro di frame, livello 2).

Con OpenFlow, la flow table supporta anche le wildcards e, ad ogni entry, è associata una priorità^[Nel caso in cui è possibile applicare più criteri allo stesso pacchetto, si sceglie la regola con priorità più alta.]. Si rammenta che non ogni campo dell’intestazione IP può essere sfruttato (eg. TTL o dimensione del datagramma).

Le operazioni più comuni che vengono applicate sono:

• inoltro: un pacchetto può essere inoltrato ad una singola porta fisica oppure inviato in broadcast o in multicast ad un insieme di porte. Il pacchetto può anche essere incapsulato e inviato al controller remoto del dispositivo, che potrà performarci o meno delle azioni;
• drop: una entry senza azione corrisponde al pacchetto che viene scartato;
• modifica di campi: il valore di dieci campi di varie intestazioni può essere riscritto prima dell’inoltro su una determinata porta.

Messaggi OpenFlow - livello di comunicazione

Esistono diverse tipologie di messaggi che si possono inviare con OpenFlow a livello di comunicazione:

• configurazione, per consentire al controller di impostare determinati parametri della configurazione;
• modify-state, per aggiungere, rimuovere o modificare entry nella flow table e per impostare proprietà per le porte dello switch;
• read-state, per consentire al controller di raccogliere statistiche e i valori dei contatori dalla flow table e dalle porte dello switch;
• send-packet, usato dal controller per inviare uno specifico pacchetto da una specifica porta dello switch. Il pacchetto è incluso nel payload del messaggio;
• flow-removed, per informare il controller che una entry della flow table è stata rimossa, a causa di un timeout o di un messaggio di tipo modify-state;
• port-status, usato dallo switch per informare il controller di un cambiamento nello stato della porta;
• packet-in, usato per inviare un pacchetto al controller per processamento aggiuntivo, non solo quando non vi è alcuna entry che corrisponde al pacchetto nella flow table.

Internet Control Message Protocol (ICMP)

ICMP è un protocollo usato da host e router per scambiarsi informazioni relative al livello di rete; l’uso più tipico è quello di fare il report di errori.

ICMP è considerato parte di IP ma, dal punto di vista architetturale viene implementato al di sopra di IP: i messaggi ICMP sono inviati in datagrammi IP, alla stregua di segmenti TCP o UDP.

Un messaggio ICMP si compone di:

• tipo;
• campo codice;
• intestazione;
• i primi 8 byte del datagramma che ha causato il messaggio ICMP.

Ping e traceroute

Un’applicazione pratica di ICMP la si ritrova nell’applicazione ping, che invia un messaggio ICMP tipo 8 codice 0 (echo request) all’host specificato, di solito per motivi di diagnostica. L’host risponderà con un messaggio ICMP tipo 0 codice 0 (echo reply).

Similmente, l’applicazione traceroute permette di scoprire la rotta seguita da un pacchetto per raggiungere un altro host. Per farlo, si invano una serie di datagrammi IP ordinari su delle porte casuali. Ogni pacchetto, però, ha un TTL tale per cui, raggiunto l’$n$-esimo host, il pacchetto scade, causando l’invio di un messaggio ICMP tipo 11 codice 0 per informare il mittente.

Simple Network Management Protocol (SNMP)

La gestione della rete rappresenta da sempre una sfida, ben prima dell’introduzione delle SDN.

Nel contesto di SNMP, si definiscono:

• l’applicazione di managing server, che controlla la raccolta, processamento, analisi e mostra informazioni per la gestione della rete, in esecuzione in una stazione centralizzata per la gestione di rete nel centro delle operazioni di rete (NOC, Network Operation Center). Qui vengono poi avviate azioni per gestire il controllo della rete e amministratori di rete umani interagiscono con i dispositivi di rete;
• managed device, cioè un apparato di rete e relativo software che risiede su una rete gestita, come un host, un router o qualsiasi altro oggetto connesso. Possono poi esserci diversi managed objects in un managed device, cioè le varie componenti hardware che compongono il device nella sua interezza, ciascuno con i propri parametri di configurazione.

Ogni informazione di un managed object all’interno di un managed device viene raccolta in un Management Information Base (MIB), che può essere un contatore, un’informazione descrittiva (eg. versione di un software), informazione di stato (eg. se un dispositivo funziona correttamente), informazioni specifiche di un protocollo. Un MIB è un oggetto descritto in un data description language conosciuto come SMI (Structure of Management Information), di cui è fornita una definizione formale per assicurarsi che la sintassi e la semantica dei dati della gestione di rete siano ben definite e non ambigue.

Ci sono poi i network management agent, processi in esecuzione sul managed device che comunicano con il managing server, intraprendendo azioni locali sotto il comando del managing server.

Network Management Protocol

Si tratta di un protocollo eseguito tra il managing server e il managed device, che consente al primo di ottenere lo stato del secondo e prendere indirettamente azioni su questi dispositivi mediante i propri agenti, che possono usare il protocollo per informare il managing server di eventi non previsti.

SNMPv2

SNMPv2 è un protocollo a livello di applicazione che viene usato per trasmettere messaggi di controllo sulla gestione della rete ed informazioni tra un managing server e un agent che viene eseguito per conto di questo.

L’utilizzo più comune di SNMP è in modalità richiesta-risposta in cui un managing server invia una richiesta ad un SNMP agest, che riceve la richiesta, svolge delle azioni e invia una risposta alla richiesta. Le richieste sono usate per richiedere o modificare valori di oggetti MIB associati a managed device.

Il secondo uso più comune di SNMP è per inviare messaggi non sollecitati, detti trap message, ad un managing server, il cui scopo è quello di notificare il managing server di situazioni non previste che sono risultate da cambiamenti di valori di un oggetto MIB.

I tipi di messaggi definiti da SNMP sono 7 e sono generalmente noti come Protocol Data Unit (PDU).

I PDU, sono trasportabili da più protocolli a livello di trasporto e solitamente sono incapsulati in datagrammi UDP. Siccome UDP non implementa un trasporto dati affidabile, l’ID della richiesta della PDU viene usata dal managing server per rilevare richieste o risposte perse; resta a carico del managing server decidere se ritrasmettere una richiesta se non è stata ricevuta una risposta in un dato intervallo di tempo, con SNMP che non richiede nessuna particolare procedura per la ritrasmissione o che questa avvenga.

Zabbix

Zabbix è uno strumento open source utilizzato per monitorare e tracciare lo stato di diversi servizi e hardware di rete, che usa in modo estensivo SNMP.