Capitolo 3
Descrizione delle MIB DiffSer
Introduzione:
L’architettura DiffServ necessita di un modello di gestione di rete, che può essere realizzato tramite il protocollo SNMP.
Per poter meglio visualizzare, e quindi più facilmente interpretare, le informazioni, che possiamo ottenere tramite un’interrogazione SNMP, è stato utilizzato il software Netview di IBM.
In questo capitolo, verrà spiegato il motivo per cui, nel nostro lavoro di tesi, è stato necessario scrivere nuove MIB relative alla QoS, per poter permettere di analizzare il Trial DiffServ.
L’obiettivo della realizzazione di questa implementazione infatti, è quello di interrogare tramite SNMP i vari router DiffServ, che fanno parte della rete sperimentale (Fig 3.1). Inoltre, volendo ottenere informazioni relative al traffico delle varie classi di servizio, è stato necessario sviluppare un sub-agent SNMP che inizializzi e aggiorni continuamente le MIB relative alla QoS, in maniera tale da ottenere, istante per istante, le informazioni sullo stato dei vari PHBs (Fig 3.1).
Figura 3.1: Architettura per il management SNMP
Nella prima parte del capitolo quindi, verranno brevemente riassunte le MIB descritte dall’RFC 3289, mostrandone il loro funzionamento ed i loro limiti. Nella seconda parte, sarà mostrato il procedimento di scrittura, che ha portato alla creazione di nuove MIB DiffServ. Infine sarà mostrata una descrizione dettagliata della realizzazione net-snmp.
3.1 DiffServ Informal Management Model
Insieme alla necessità di offrire servizio differenziato, come detto, si ha naturalmente la necessità di gestire la rete. I vari network service providers che forniscono DiffServ ai loro clienti, devono necessariamente configurare e controllare i loro router per essere in grado di soddisfare un Service Level Agreement (SLA).
Lo IETF DiffServ WG, ha prodotto un modello di gestione informale [9] così come un MIB[10], per aiutare i manager a gestire e controllare i loro router DiffServ.
Il DiffServ Informal Management Model [9] è basato sul DiffServ Architecture [6] ma focalizzato principalmente sulla parte relativa alla configurazione del router.
Nell’architettura del modello, sono stati definiti numerosi elementi funzionali, la cui combinazione porta a una datapath. L’Informal Management Model, specifica i possibili parametri di configurazione di questi elementi.
Il modello concettuale di un Router DiffServ, compresi gli elementi di gestione, è rappresentato nella figura sottostante (Fig 3.2). Può essere concluso dall’osservazione di questo modello, che gli aspetti principali di configurazione della gestione DiffServ sono relativi alla configurazione delle interfacce di ingresso e di uscita.
Figura 3.2: Blocchi funzionali di un Router DiffServ
3.2 RFC 3289 DiffServ Mib
Il DiffServ MIB, descrive principalmente gli aspetti di configurazione di router che realizzano il DiffServ Architecture. Esso contiene gli elementi funzionali del datapath, ed utilizzando diverse tabelle riesce ad organizzare la struttura completa del MIB.
Il Data Path Table, elenca il Differentiated Services Functional Data Paths all’interno di un router DiffServ. Ogni entry in questa tabella, è indicizzata da ifIndex e da ifDirection.
La seconda tabella definita è la Classifier Table. Essa permette che uno o più classifier element, di stessi o vari tipi, possano essere utilizzati insieme. Il compito di un classifier è quello di filtrare completamente tutti i pacchetti che vengono presentati al suo ingresso, confrontando alcune informazioni contenute nel pacchetto IP. Le informazioni che possiamo trovare nella Classifier Table descritta nel MIB, sono relative, alla configurazione degli elementi dei vari classifier, come:
• L’attivazione, la cancellazione o la disattivazione di un filtro, all’interno del MIB diffServClfrStatus • L’identificativo di un filtro, il filter-id
L’Algorithmic Drop Table, contiene le informazioni relative agli algoritmi che permettono di scartare pacchetti. Infatti, nel campo della MIB diffServAlgDropType, è possibile osservare 5 diversi algoritmi in base all’intero che possiamo leggere nel MIB, e sono:
1. other(1) 2. TailDrop(2) 3. headDrop(3) 4. randomDrop(4) 5. alwaysDrop(5)
Come possiamo osservare, questi dati, non indicano il numero di pacchetti che sono stati scartati durante la trasmissione di traffico appartenente ad una certa classe di servizio, informazione che risulta invece fondamentale durante l’analisi prestazionale di una qualsiasi rete. Un ulteriore tabella è la Random Drop Table, che contiene tra i suoi parametri, i dati configurazionali della massima dimensione della coda in uscita ad una certa interfaccia, che se superata determina uno scarto dei pacchetti in eccesso.
La Queue Table, controlla le varie discipline di coda che sono state settate, sul nostro router, inoltre la Scheduler Table risulta importante per la conoscenza dello Shaper e quindi per la parametrizzazione della disciplina di accodamento.
Quindi come appare evidente, non sono accuratamente descritti, all’interno del MIB dell’RFC 3289, i parametri relativi alle statistiche di traffico delle varie classi di servizio, che invece risultano fondamentali per poter controllare e monitorare l’intera rete DS.
Inoltre, nella parte relativa al classifier, non è descritto il comportamento dei filtri in ingresso ad una determinata interfaccia, ossia quali sono i campi del pacchetto IP che andiamo a controllare, e soprattutto, quale sia il valore del suddetto campo, cercando di rendere la visualizzazione il più semplice possibile.
Si è resa necessaria, per una corretta analisi di rete DS, la scrittura di nuove MIB per il DiffServ, in aggiunta a quelle definite nell’RFC 3289, concentrandosi su dati statistici relativi al traffico dei vari PHBs, e sulla gestione dei filtri in ingresso alle varie interfacce.
3.4 Scrittura delle DiffServ MIB in ASN.1
Per poter monitorare una rete DS, è stato necessario scrivere nuove MIB, che definissero in maniera dinamica i dati di traffico per ogni classe di servizio per poter conoscere istante per istante lo stato della rete. Per poter meglio visualizzare i parametri che vogliamo richiedere tramite una GetSnmp, è stato scelto di dividere le informazioni prima per interfaccia, successivamente per classe di servizio, in maniera tale che il nodo di base sia rappresentato dal numero dell’interfaccia e quello successivo sia rappresentato dalla classe di servizio. Osservando la figura 3.3 è facile capire che per ottenere le informazioni relative al Rate della classe expedited forwarding sull’interfaccia eth 0 è necessario riferire la get al seguente OID diffServCos.1.1.1 .
Figura 3.3: organizzazione delle MIB relative alle classi di servizio
Le informazioni che ci permettono di osservare il comportamento della rete in maniera dinamica sono:
• TxedPkts: il numero di pacchetti trasmessi, appartenenti ad una certa classe di servizio, in uscita da una determinata
interfaccia del router DiffServ.
• TxedBytes: il numero di Bytes trasmessi
• QuedPkts: il numero di pacchetti in coda, appartenenti ad una certa classe di servizio, in uscita da una determinata interfaccia • Qlen: la lunghezza media di una determinata coda
• Drops: il numero di pacchetti scartati, appartenenti ad una certa classe di servizio, in uscita da una certa interfaccia.
• Overlimits: il numero di pacchetti appartenenti ad una certa classe di servizio accodati perché durante la trasmissione è stato
superato SLA.
• Bps: il numero medio di Byte/sec trasmessi, misurato dall’inizio del monitoraggio della rete.
Inoltre per poter meglio comprendere il valore di questi dati, in relazione al PHB assegnato, abbiamo aggiunto informazioni relative alla configurazione delle varie classi di servizio su ogni interfaccia:
• Rate: il rate assegnato ad una certa classe di servizio, su una relativa interfaccia.
• Ceil: il massimo numero di Byte/sec che un certo profilo di traffico può trasmettere, se non è configurato il ceil coincide con il
rate.
• Cburst: il massimo numero di pacchetti, appartenenti ad una certa classe di servizio, che può essere aggiunto al ceil in un
quanto Round Robin, qualora non si stia servendo un'altra classe.
• Burst: il massimo numero di pacchetti, appartenenti ad una certa classe di servizio, che può essere aggiunto al rate medio in un
quanto Round Robin, qualora non si stia servendo un'altra classe.
Oltre all’informazioni relative al comportamento del traffico delle varie classi di servizio configurate, è stato necessario descrivere anche il comportamento dei filtri in ingresso ad ogni interfaccia di ogni router DS. In particolare per ogni possibile filtro configurato viene creata una tabella contenente determinate informazioni. Anche in questo caso, come è osservabile nella figura 3.4, per poter rendere più semplice la visualizzazione delle informazioni, tutte le tabelle sono definite per ogni interfaccia attiva.
Figura 3.4: Organizzazione delle MIB relative ai filtri
I parametri che abbiamo inserito in ogni tabella, sono:
• Filter Id: l’identificativo del filtro e quindi della tabella che contiene le informazioni di configurazione, se il Filter Id è nullo,
allora la tabella non può essere interrogata.
• Class Id: l’identificativo della classe di servizio a cui viene assegnato il traffico che rispetta le condizioni del filtro. • IP src Address: l’indirizzo IP della sorgente che genera il traffico.
• IP dst Address: l’indirizzo IP del destinatario
• Source Port: il numero della porta di ingresso da cui proviene il traffico, se tale numero è settato a zero, allora non è una delle
condizioni che devono essere soddisfatte, per appartenere ad un certo profilo di traffico.
• Dest Port: il numero della porta di uscita su cui deve finire il traffico, se tale numero è settato a zero, allora non è una delle
condizioni che devono essere soddisfatte, per appartenere ad un certo profilo di traffico.
• Protocol: il tipo di protocollo utilizzato
• DSCP: la condizione di classificazione da parte del filtro sulla base dell’osservazione del DiffServ Code Point • Status: il numero dei filtri attivi in totale su una determinata interfaccia.
Le informazioni che abbiamo elencato, sono state infine scritte seguendo le regole dello standard ASN.1 che andremo adesso a definire.
3.4.1 ASN.1
L’Abstract Syntax Notation One (ASN.1) è uno standard creato dall’ ISO (International Standards Organization), il cui scopo è quello di fornire un metodo che sia indipendente dalla macchina e dal sistema operativo, per descrivere i tipi di dati contenuti nelle MIB e le regole che fissano il metodo con il quale ciascuno di essi deve essere trasmesso.
Per capire meglio quest’ultimo concetto dobbiamo considerare l’architettura di comunicazione in un end-system dividendola in due componenti:
1. Un componente dedicato al trasferimento dati (data transfer component) riguardante i meccanismi per il trasferimento di dati tra due end-system.
Al livello dell’application component, le informazioni sono presentate tramite una sintassi (abstract syntax) indipendente dall’end-system, sarà poi compito di questo componente “mappare” le informazioni in modo da presentarle all’utente secondo una particolare forma. Similmente le informazioni “astratte” devono subire la stessa operazione di mappaggio per essere immagazzinate all’interno della MIB. Infine, questo componente deve anche “tradurre” in una sintassi di trasferimento (transfer syntax) tutti i tipi di dati definiti, ovvero ad ogni valore deve poter essere associata la propria forma binaria adatta ad essere trattata dal data transfer component.
Le regole di traduzione vengono definite come regole basi di cifratura (Basic Encoding Rules, BER) e definiscono dei metodi per cifrare i valori ASN.1 in una sequenza di ottetti (octet strings).
Esistono quattro diverse classi, nella quali si dividono i tipi definiti dalla notazione ASN.1:
• Universal: racchiude tutti i tipi di dati di uso comune ed i tipi strutturati (structured types) che consentono
l’implementazione di liste ordinate di oggetti
• Application wide: comprende i tipi di dati attinenti ad una particolare applicazione
• Context-specific: include i tipi di dati pertinenti ad una specifica applicazione, ma utilizzabili in un contesto limitato. • Private: a questa classe appartengono i tipi di dati definiti dagli utenti e non implementati in alcuno standard.
I tipi di dati base che si possono utilizzare nella definizione di un oggetto MIB, costituiscono un ristretto sottoinsieme della UNIVERSAL_CLASS, soltanto in questo modo infatti, è possibile raggiungere l’obiettivo di mantenere lo standard SNMP il più semplice possibile. Elenchiamo quindi i seguenti tipi utilizzati per la SMIv2 [11]:
• integer: intero a 32bit
• octect string: stringa di byte che rapprese dati arbitrari in forma binaria o di testo (lunghezza massima 65.535 byte) • null: valore nullo, è utilizzato quando non è verificata nessuna alternativa
• object identifier: OID rappresenta l’identificatore unico dell’oggetto ed è costituito da una sequenza di interi separati da
un punto
• sequnce, sequence of: sono utilizzate per costituire liste ordinate di valori appartenenti ad uno o più tipi.
Come detto precedentemente, l’APPLICATION CLASS contiene tutti quei tipi di dati attinenti a particolari applicazioni, ognuna delle quali deve definire i propri application data types.
Per quanto riguarda l’applicazione SNMP vengono definiti i seguenti tipi di dati:
- network address: questo tipo permette la selezione di un particolare formato di indirizzo nel caso di indirizzo IP 32 bit disponibili per la sua definizione.
- Counter32: contatore a 32 bit che incrementa da 0 a 232 –1 e che quindi ritorna a zero.
- Gauge32: intero a 32 bit che quando incrementa o decrementa non supera mai il valore 232 –1 e non assume mai valori
inferiori a zero. A differenza del counter, quando il gauge raggiunge li proprio valore massimo, lo mantiene fino a che il manager non lo resetta, oppure fino a che il conteggio successivo risulti minore, ed in questo caso il gauge decresce al valore appena calcolato.
Per poter definire gli oggetti all’interno di una MIB per esempio, l’ASN.1 presenta una notazione particolare che permette all’utente di estendere la sintassi definendo nuovi tipi ed i rispettivi valori (macro definitions ). Dobbiamo infatti distinguere tre livelli di definizione:
• macro definition: specifica la sintassi di un insieme di tipi di dati collegati tra loro utilizzati per definire un oggetto • macro instance: specifica un particolare tipo
In particolare, il costrutto (macro), usato per specificare il tipo di dati, lo stato e la semantica di un oggetto da gestire è l’OBJECT TYPE, le cui principali componenti sono per la SMIv1:
• syntax: specifica il tipo di dati di base associati all’oggetto (quindi può essere Integer, Counter 32 etc..)
• access: specifica se l’oggetto da gestire può essere soltanto letto (read-only), scritto (write-only, write-read), oppure non
accessibile (non accessible), in quest’utilmo caso il valore dell’oggetto non può essere né letto (get), ne settato (set).
• status: indica se la definizione di un oggetto è obbligatoria (mandatory), opzionale (optional), obsoleta (obsolate ) nel qual
coso l’oggetto non può essere implementato e la sua definizione è inserita solo per scopi storici, infine se la definizione di un oggetto è attuale e valida (current);
• descrPart: contiene una descrizione testuale leggibile dell’oggetto evidenziandone gli scopi, è una componente non necessaria
al fine della sintassi.
• Altri campi che sono opzionali che sono: indexPart, defvalPart, referPart etc…
Come esempio del costrutto OBJECT TYPE, riportiamo l’implementazione dell‘oggetto diffServCosEFTxedPks creato per contare il numero di pacchetti trasmessi dalla classe di servizio Expedited Forwarding su una certa interfaccia, come possiamo notare il valore dell’oggetto può essere solo letto e l’OID tramite il quale si accede a quest’oggetto è (1.3.6.1.2.1.12345.1.9.1.3.1)
diffServCosIf1EFTxedBytes OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-create STATUS current DESCRIPTION
"Total number of bytes belonging to EXPEDITED forwarding class, transmitted on the given interface." ::= { diffServCosEFIf1 1 }
Il costrutto infine, che ci permette di raggruppare gli oggetti affini all’interno di un modulo, è il MODULE IDENTITY; quest’ultimo, oltre ad includere le definizioni di OBJECT TYPE degli oggetti da gestire, contiene anche le informazioni per contattare l’autore del modulo, la data dell’ultimo aggiornamento, la storia delle modifiche ed una descrizione testuale del modulo. Nel nostro caso, abbiamo sfruttato il modulo definito all’interno dell’RFC 3289, ed abbiamo creato un nuovo ramo di MIB v2 (Fig 3.5) che contenga i parametri di traffico che secondo noi erano necessari per svolgere l’attività di analisi prestazionale di rete. Rimandiamo la scrittura completa delle DiffServMib, nell’appendice di questo lavoro di tesi.
Figura 3.5 inserimento nel Mibtree delle DiffServMib
3.5 Routine di supporto: net-snmp
net-snmp, è una suite che realizza il Simple Network Management Protocol (SNMP).
Questo pacchetto software, può essere scaricato da [12], e può essere eseguito su diversi sistemi operativi, nel nostro caso, è stata utilizzata la versione net-snmp-5-0-9 per Linux.
La suite comprende un agent che fornisce il supporto per numerosi MIB object nel MIB-2, una libreria che contiene una routine di supporto SNMP, e diversi strumenti che consentono di eseguire operazioni di Get Set e Trap su informazioni memorizzate in un MIB. Questa libreria consente inoltre ad applicazioni indipendenti di agire come un agent SNMP. Essa inoltre fornisce funzioni per quasi tutte le routine generali di SNMP, ricevendo e inviando SNMP-PDU. La versione del protocollo SNMP supportate, possono essere SNMPv1, SNMPv2 e SNMPv3.
Il nostro interesse è quello di generare, un sub-agent che funzioni in appoggio all’agent SNMP, vogliamo cioè utilizzare un approccio modulare, con vari moduli che realizzino nuove parti del MIB-tree. Questo è quello che viene chiamato Agent Extensibily Protocol (AgentX) [13].
Questo modello, come detto, utilizza sub-agent e master, comunicando su un canale come TCP/IP o UNIX Domain Sockets. I master-agent, cioè quelli di net-snmp, spediscono richieste che dovrebbero essere trattate da un sub-master-agent, per cui quest’ultimo restituisce le informazioni al master-agent, che a sua volta lo invia al manager entità.
Ecco un riassunto di che cosa accade, quando si esegue la suite net-snmp con una realizzazione DiffServCos Mib in pseudo-code. 1. start and initialize master agent
2. load DiffServCos MIB sub agent 3. while true
a. wait for request from manager
b. if request is for DiffServCos subtree
c. dispach to DiffServCos MIB Subagent (in subagent) d. call function that handles this OID
e. put values into theirs corrispective OID
f. send result back to master agent (end of sub-agent processing)
g. else /* request is for another sub-agent*/ h. ………
i. endif
j. construct SNMP response PDU, send to manager 4. endwhile
Riportiamo infine, alcune funzioni contenunte nel file example-demon.c, per poter definire in che modo vieni inizializzato e riempito il modulo delle MIB diffServ.
/* we're an agentx subagent? */ if (agentx_subagent) {
/* make us a agentx client. */
netsnmp_ds_set_boolean(NETSNMP_DS_APPLICATION_ID, NETSNMP_DS_AGENT_ROLE, 1);
/* initialize the agent library */ init_agent("example-demon");
/* If we're going to be a snmp master agent, initial the ports */ if (!agentx_subagent)
Tramite la funzione netsnmp_ds_set_boolean, riusciamo a definire al nostro demone SNMP, la presenza di un subagent, che inizializzerà il nostro modulo MIB, tramite alcune delle seguenti funzioni.
init_diffServCos(); //inizializzazione del modulo riferito ai parametri di traffico dei vari BA.
init_diffServFilterIf1Table(); //inizializzazione del modulo riferito ai parametri di configurazione, di tutti i filtri attivi sull’interfaccia 1.
Infine, per poter ottenere un aggiornamento continuo di questi valori, andremo continuamente (ad ogni richiesta SNMP) a richiamare delle funzioni che modificheranno opportunamente i parametri del MIB Module ottenuto.
while(keep_running) { find_statistics_If1(); arrayif1(); }
Le definizione di tutte le funzioni sopradette, possono essere trovate nel capitolo successivo, ed in maniera più esauriente all’interno dell’appendice di questa tesi.
