Network monitoring tramite snmp

ALMA MATER STUDIORUM

UNIVERSITÀ DEGLI STUDI DI BOLOGNA

SECONDA FACOLTÀ DI INGEGNERIA SEDE DI CESENA

Corso di Laurea in Ingegneria Informatica

STRUMENTI PER IL MONITORAGGIO DI RETE TRAMITE PROTOCOLLO SNMP

Elaborato in RETI DI TELECOMUNICAZIONI L-B

Relatore: Prof. Walter Cerroni

Presentato da:

Nicola Calisesi

Sessione Prima Anno Accademico 2004/2005

2

Introduzione

Capitolo 1 >> Network Management

1.1 Network Management (Gestione di rete)

1.2 Modello ISO

1.3 Infrastrutture di rete

Capitolo 2 >> Il Protocollo SNMP

2.1 Introduzione al protocollo SNMP

2.2 Considerazioni sul protocollo

2.3 Evoluzione del protocollo

2.3.1 SNMP v1

2.3.2 SNMP v2

2.3.3 SNMP v3

2.4 Standard SNMP

2.4.1 Formato dei messaggi

2.4.2 Messaggi TRAP

2.4.3 Standard per gli oggetti SNMP

2.4.4 Estensione delle funzioni SNMP

2.5 MIB

2.5.1 Classificazione MIB

2.5.1.1 Discrete MIB Objects

2.5.1.2 Table MIB Objects

2.5.2 Tipologie MIB

5

6

10

12

15

17

19

19

22

23

25

26

29

30

31

32

34

34

35

36

INDICE

3

2.5.3 Valori di accesso ai MIB

2.5.4 Compilare un MIB

Capitolo 3 >> Software SNMP

3.1 Requisiti di un software SNMP

3.2 Installazione

3.2.1 Requisiti di sistema

3.2.2 Elenco dei pacchetti necessari

3.2.3 Installazione Java

3.2.4 Installazione RRDTool

3.2.5 Installazione PostgreSQL

3.2.6 Installazione Tomcat4

3.2.7 Configurazione PostgreSQL

3.2.8 Installazione e avvio OpenNMS

3.2.9 Possibili Problematiche

3.3 OpenNMS

3.3.1 OpenNMS Discovery

3.3.2 OpenNMS Capsd

3.3.3 OpenNMS Polling

3.4 OpenNMS SNMP

3.4.1 SNMP-Config.xml

3.4.2 DataCollection-Config.xml

3.5 Architettura

3.6 Altre funzioni

39

40

41

44

44

44

45

46

46

46

47

48

49

50

55

58

60

62

63

65

70

71

INDICE

4

Considerazioni finali

Bibliografia

Elenco delle figure

72

73

74

INDICE

5

Introduzione Lo straordinario sviluppo delle reti di computer dell’ultimo decennio ha aper-

to nuovi scenari per quanto riguarda l’utilizzo dei personal computer, si pensi a co-

me si è modificato l’utilizzo di Internet grazie alla banda larga, e soprattutto a come

è cambiata la concezione del personal computer, trasformando un computer isolato

in uno strumento in grado di comunicare con tutto il mondo.

Ovviamente lo sviluppo delle reti porta ad un inevitabile incremento delle lo-

ro dimensioni e se fino a poco tempo fa il concetto di rete era legato ad ambiti a-

ziendali o comunque locali, adesso le reti possono coprire intere aree geografiche.

Questa crescita in dimensioni e in numero di host collegati crea agli amministratori

notevoli problemi di gestione e manutenzione della rete; infatti se una rete di esten-

de in un’area molto vasta non è detto che l’amministratore sia in grado di raggiun-

gere fisicamente e in qualsiasi momento tutti gli host e tutti i nodi della rete, quindi

per rimediare a questi problemi si utilizzano programmi che siano in grado di moni-

torare la rete e di prevenire possibili guasti ai dispositivi collegati.

Nel 1989 nasce il protocollo SNMP che viene pensato come punto di partenza

su cui sviluppare dei sistemi che siano in grado di risolvere e prevedere tutti i pro-

blemi che nascono dalla gestione di una rete. La versatilità di questo protocollo gli

ha permesso di trovare da subito un riscontro positivo dal mondo degli sviluppatori

e dalle aziende del settore, infatti dopo la prima versione ne sono state implementa-

te altre due (anche se la prima continua ad essere la più utilizzata). Oggi lo standard

SNMP è supportato da una grandissima quantità di dispositivi alcuni dei quali esu-

lano dalla categoria dei componenti di rete come ad esempio alcune stampanti, sen-

za dimenticare che viene sponsorizzato da aziende come HP e IBM che vendono i

due software commerciali più diffusi.

L’obiettivo di questa tesi è analizzare tutta la teoria che sta dietro a questo

protocollo (nei primi capitoli) e analizzare un software open source in grado di ge-

stire dei nodi che siano equipaggiati con agenti SNMP.

Introduzione

6

Network Management

Capitolo 1 Network Management 1.1 Network Management (Gestione di rete) Prima di immetterci nella reale gestione della rete, consideriamo alcuni scena-

ri illustrativi del mondo reale, esterno alle reti, in cui un sistema complesso ha molti

componenti che interagiscono e devono essere monitorati, gestiti e controllati da un

responsabile. Le centrali elettriche (almeno per come sono rappresentate dai me-dia

popolari) hanno una sala di controllo dove interruttori, manometri e luci monitorano

a distanza lo stato (temperatura, pressione flusso) di valvole, tubi, cavi e altri com-

ponenti dell'impianto. Questi dispositivi permettono all'operatore di monitorare i

componenti principali dell'impianto e lo avvertono (la famosa luce rossa lampeg-

giante di avvertimento) quando un guasto è imminente. L'operatore dell'impianto

compie azioni per controllare questi componenti. In modo analogo, la cabina di pi-

lotaggio di un aereo è strumentata per permettere al pilota di controllare e comanda-

re i molti componenti che costituiscono un aeroplano. In questi due esempi, il

"responsabile" effettua un monitoraggio sui dispositivi remoti e analizza i loro da-ti

per assicurarsi che essi siano operativi e che funzionino entro i limiti prescritti, con-

trolla reattivamente il sistema attraverso regolazioni in risposta alle variazioni che

intervengono nel sistema stesso o nel suo ambiente, e gestisce efficacemente il siste-

ma (per esempio, rilevando tendenze comportamenti anomali, permettendo di inter-

venire prima che sorgano problemi seri). In questo senso, il responsabile della rete

monitorerà attivamente, gestirà e controllerà il sistema che gli è affidato.

Nei primi giorni del funzionamento delle reti, quando le reti di calcolatori era-

no strumenti di ricerca e non ancora un'infrastruttura critica usata da milioni di per-

sone al giorno, la "gestione della rete" era sconosciuta. Se si incontrava un proble-

ma di rete, si metteva in funzione qualche ping per localizzare la fonte del problema

e quindi modificare la regolazione del sistema, riparare hardware o software o chia-

mare un collega in grado di farlo. (Un'esposizione ben fatta dedicata al primo

7

Network Management

"crash" serio dell'ARPAnet, del 27 otto-

bre 1980, molto prima che gli strumenti

per la gestione della rete fossero dispo-

nibili, e degli sforzi fatti per risolvere e

comprendere il guasto si trova nel [1]).

Con la crescita di Internet pubblica e

delle intranet private da piccole unità a

un'enorme infrastruttura globale, è au-

mentata anche la necessità di una gestio-

ne più sistematica del gigantesco nume-

ro di componenti hardware e software

all'interno di queste reti.

Per motivare il nostro studio della gestione delle reti, cominciamo con un

semplice esempio in cui analizzeremo una piccola rete composta da tre router e da

un certo numero di host e server in Figura 1.1.

Anche in una rete così semplice ci sono molti scenari [2] in cui un responsabile del-

la rete può trarre enorme profitto dall'avere gli appropriati strumenti per la sua ge-

stione:

• Rilevazione di un guasto di una scheda d'interfaccia a un host o a un router.

Con appropriati strumenti di gestione della rete, un'entità di rete (per esem-

pio il router A) può segnalare al responsabile della rete che una delle sue

interfacce è fuori servizio. (Questo è certo preferibile a una chiamata telefo-

nica al NOC (Network Operations Center) da parte di un utente irascibile

che avverte che la connessione di rete non funziona!). Un responsabile che

monitora e analizza attivamente il traffico sulla rete, in realtà può essere in

grado di evitare l'irascibile utente rilevando in anticipo i problemi alle inter-

facce e sostituendo la scheda prima che si guasti. Questo può essere fatto,

per esempio, se il responsabile ha notato un incremento degli errori di che-

cksum nei frame che sono stati inviati attraverso l'interfaccia prossima al

guasto.

Figura 1.1 Schema di rete

8

Network Management • Monitoraggio degli host. Qui, il responsabile della rete può controllare pe-

riodicamente che tutti gli host della rete siano accesi e operativi. Ancora una

volta, il responsabile della rete può essere in grado di anticipare la risposta a

un problema (un host fuori uso) prima che il guasto sia riferito da un utente.

• Monitoraggio del traffico per aiutare nell'utilizzo delle risorse. Un respon-

sabile della rete può monitorare gli schemi del traffico da sorgente a destina-

zione e rilevare, per esempio, che attraverso la commutazione dei server fra i

segmenti LAN, la quantità di traffico che attraversa molte LAN può dimi-

nuire significativamente. Immaginate l'allegria generale (specialmente nei

dirigenti amministrativi) quando si raggiungono migliori prestazioni senza

costi di equipaggiamento. In modo analogo, attraverso il monitoraggio del-

l'utilizzazione dei link, un responsabile della rete può determinare che un

segmento LAN, o il link verso il mondo esterno sia sovraccarico e che è ne-

cessario un link con una larghezza di banda superiore, che dovrà quindi es-

sere approvvigionato (rappresentando un costo per l’azienda). Il responsabi-

le della rete può anche desiderare la notifica automatica nel caso in cui i li-

velli di congestione su un link eccedano un dato valore soglia, per poter met-

tere a disposizione un link con larghezza di banda superiore prima che la

congestione diventi seria.

• Rilevazione rapida dei cambiamenti nelle tabelle di instradamento. La flut-

tuazione dei percorsi (variazioni frequenti nelle tabelle di instradamento)

possono indicare instabilità nell'instradamento o perdita di configurazione in

un router. Certamente il responsabile della rete che ha impropriamente con-

figurato un router preferirà scoprire da solo l'errore, prima che la rete si

blocchi.

• Monitoraggio per gli SLA. Con l'avvento degli accordi sul livello di servizio

(SLA, Service Level Agreements, contratti che definiscono specifiche metri-

che prestazionali e accettabili livelli di prestazioni dei

9

provider di rete rispetto a tali metriche) l'interesse per il monitoraggio del

traffico è aumentato in modo significativo negli ultimissimi anni. La UUnet

e l'AT&T sono due dei principali provider che garantiscono gli SLA ai loro

clienti. Questi SLA comprendono disponibilità del servizio (o interruzione),

latenza, throughput e requisiti di notificazione dell’interruzione. È chiaro

che se i criteri di prestazioni devono essere parte di un contratto fra un pro-

vider di rete e i suoi utenti, allora le prestazioni di misura e di gestione sono

di grande importanza per il responsabile della rete.

• Rilevazione delle intrusioni. Un responsabile della rete può volere che gli sia

notificato quando il traffico in rete arriva da o è diretto a una sorgente so-

spetta (per esempio, host o numero di porta). In modo analogo, il responsa-

bile può desidera-re rilevare (e in molti casi filtrare) l'esistenza di certi tipi di

traffico (per esempio, pacchetti instradati da sorgente, o un grande numero

di pacchetti SYN diretti a un dato host) che si sanno essere caratteristici di

attacchi alla sicurezza.

Network Management

10

1.2 Modello ISO L'International Organization for Standards (ISO) [3] ha creato un modello di

gestione di rete per cercare di catalogare e collocare ogni scenario di rete possibile

in uno schema più strutturato. Vengono così definite cinque aree di gestione della

rete [2]:

• Gestione delle prestazioni. L'obiettivo della gestione delle prestazioni è di

quantificare, misurare, stendere rapporti, analizzare e controllare le presta-

zioni (per esempio, utilizzazione, throughput) di differenti componenti di

rete. Questi componenti comprendono sia dispositivi singoli (per esempio,

link, router e host), sia astrazioni end-to-end come un percorso attraverso la

rete. In seguito vedremo che gli standard protocollari, come il protocollo

semplice per la gestione delle reti (SNMP, Simple Network Management

Protocol) [4], hanno un ruolo centrale nella gestione delle prestazioni in

Internet.

• Gestione dei guasti. L'obiettivo della gestione dei guasti è di registrare, rile-

vare e rispondere alle condizioni di guasto nella rete. La linea di separazione

fra gestione dei guasti e gestione delle prestazioni è piuttosto confusa. Pos-

siamo pensare alla gestione dei guasti come all'immediato intervento su un

difetto transitorio della rete (per esempio, interruzione del servizio di un link

di un host o di un router, di hardware o software), mentre la gestione delle

prestazioni agisce in tempi più lunghi, per fornire livelli accettabili di presta-

zioni di fronte al variare delle richieste di traffico e all'occasionale guasto di

un dispositivo di rete. Come con la gestione delle prestazioni, il protocollo

SNMP ha un ruolo centrale nella gestione dei guasti.

• Gestione della configurazione. La gestione della configurazione permette a

un responsabile di rete di seguire i dispositivi che appartengono alla rete ge-

stita e di effettuarne la configurazione hardware e software. Una panoramica

Modello ISO

11

della gestione della configurazione e dei requisiti per le reti basate su IP si

può trovare nel [22].

• Gestione della contabilità (accounting). La gestione della contabilità per-

mette al responsabile della rete di specificare, registrare e controllare l'acces-

so degli utenti e dei dispositivi alle risorse di rete. Quote di utilizzazione,

addebiti basati sull’uso e privilegi di allocazione degli accessi alle risorse

rientrano tutti nella gestione della contabilità.

• Gestione della sicurezza. L'obiettivo della gestione della sicurezza è di con-

trollare gli accessi alle risorse di rete in accordo ad alcune politiche ben defi-

nite. Il centro di distribuzione delle chiavi e l'autorità di certificazione appar-

tengono alla gestione della sicurezza. L'uso di firewall (letteralmente, barrie-

re parafiamma) per monitorare e controllare i punti esterni di accesso a una

rete.

Dopo aver dato diverse definizioni sui vari aspetti della gestione di rete ci si potreb-

be chiedere: "Che cos'è la gestione della rete?". L’esposizione precedente ha moti-

vato la necessità di gestione della rete senza dare una definizione di gestione di rete,

quindi adesso proviamo a farlo nella maniera più sintetica possibile:

"La gestione della rete comprende l'azionamento, l'integrazione e il coordinamento

di hardware, software ed elementi umani per monitorare, verificare, son-dare, con-

figurare, analizzare, valutare e controllare la rete e le risorse degli ele-menti per

soddisfare le prestazioni operative in tempo reale e i requisiti di qualità del servizio

(QoS) a un costo ragionevole". [5]

Modello ISO

12

1.3 Infrastrutture di rete Nel paragrafo precedente abbiamo visto che la gestione della rete richiede la

possibilità di "monitorare, verificare, sondare, configurare,... e controllare"

hardware e software e i componenti in una rete. Poiché i dispositivi di rete sono di-

stribuiti, questo richiederà come minimo che il responsabile della rete sia in grado

di ottenere dati (per esempio, a scopi di monitoraggio) da un'entità remota e di ef-

fettuare cambiamenti all'entità remota (per esempio, regolazioni) su quella remota

entità. Un'analogia umana risulterà utile per comprendere l'infrastruttura necessaria

per la gestione della rete.

Immaginate di essere a capo di una vasta organizzazione che ha filiali sparse

in tutto il mondo. Il vostro lavoro è assicurare che tutti i pezzi della vostra organiz-

zazione operino senza difficoltà. Come potete farlo? Come minimo, periodicamente

raccogliete dati dalle filiali in forma di rapporti e di varie misure quantitative di atti-

vità, produttività e budget. Occasionalmente (ma non sempre) vi sarà notificato e-

splicitamente che c'è un problema in una delle filiali; il manager di una filiale che

vuole salire i gradini della scala gerarchica della società può inviarvi un rapporto

non sollecitato che indica come le cose funzionino senza problemi nella sua filiale.

Voi ordinerete i rapporti ricevuti, sperando di trovare dovunque solo cose che fun-

zionano bene, ma senza dubbio troverete problemi che richiederanno la vo-stra at-

tenzione. Potrete iniziare un dialogo da-uno-a-uno con una delle filiali che ha pro-

blemi, ottenere più dati per comprendere meglio il problema e quindi passare un

ordine esecutivo ("Fate questi cambiamenti!") al manager della filiale.

In questo scenario umano molto comune è implicita un'infrastruttura per con-

trollare l'organizzazione: l’amministratore, il sito remoto sotto controllo (la filiale),

il vostro agente remoto (il manager della filiale), i protocolli di comunicazione (per

trasmettere i rapporti standard e il dialogo da-uno-a-uno) e i dati (il contenuto dei

rapporti e le misure quantitative di attività, produttività e budget). Ciascuno di que-

sti componenti nella gestione di un'organizzazione umana ha una controparte nella

Infrastrutture di rete

13

gestione della rete.

L'architettura di un sistema di gestione della rete è concettualmente identica

alla semplice analogia di organizzazione umana. Identifichiamo ora tre componenti

principali nell'architettura di gestione della rete [2]: un'entità di gestione, i dispositi-

vi da gestire e un protocollo di gestione della rete.

L'entità di gestione è un'applicazione, che tipicamente coinvolge un uomo,

funzionante in una stazione centralizzata di gestione della rete nel centro operativo

di rete (NOC). L'entità di gestione è il sito di attività per la gestione della rete; essa

controlla la raccolta, l'elaborazione, l'analisi e/o l'esposizione delle informazioni di

ge-stione. È da qui che partono le azioni per controllare il comportamento della rete,

ed è qui che i responsabili umani interagiscono con i dispositivi della rete.

Un dispositivo da gestire è una parte dell'equipaggiamento di rete (compreso

il suo software) che risiede sulle rete da gestire. Questa è la filiale nella nostra ana-

logia umana. Un dispositivo da gestire può essere un host, un router, un bridge, ecc.

All'interno di un dispositivo da gestire ci possono essere molti oggetti da gestire.

Questi sono parti reali di hardware all'interno del dispositivo (per esempio, la sche-

da di interfaccia di rete) e il set di parametri di configurazione per le parti di

hardware e software (per esempio, un protocollo di instradamento intradominio co-

me il RIP). Nella nostra analogia umana, gli oggetti da gestire possono essere gli

uffici all'interno della filiale . Questi oggetti da gestire hanno associate parti di in-

formazio-ni che sono raccolte in una base di informazioni per la gestione (MIB,

Management Information Base) [6]; vedremo che i valori di queste parti di informa-

zioni sono disponi-bili all’entità di gestione. Nella nostra analogia umana, il MIB

corrisponde ai dati quantitativi (misure di attività, produttività e budget, con l'ultimo

impostabile dall'entità di gestione!) scambiati fra la filiale e la sede. Infine, residen-

te anch'esso in ciascun dispositivo da gestire, c'è un agente di gestione della rete,

un processo funzionante nel dispositivo da gestire che comunica con l'entità di ge-

stione, che compie azioni locali sul dispositivo da gestire su comando e controllo

dell'entità di gestione. L'agente di gestione della rete è il manager della filiale nella


14

nostra analogia umana.

La terza parte di un'architettura è il protocollo di gestione della rete. Il proto-

collo funziona tra l'entità di gestione e i dispositivi da gestire, permettendo all'entità

di gestione di chiedere lo stato dei dispositivi da gestire e indirettamente di agire su

essi attraverso i suoi agenti. Gli agenti possono usare il protocollo di gestione della

rete per informare l'entità di gestione degli eventi eccezionali (per esempio, guasti

dei componenti o violazione delle soglie di prestazione). È importante notare che il

protocollo di gestione della rete non gestisce la rete di per sé; piuttosto esso fornisce

uno strumento con cui il responsabile può agire ("monitorare, provare, sondare,

configurare, analizzare, valutare e controllare") sulla rete. Questa è una sottile ma

importante distinzione.


15

Capitolo 2 Il protocollo SNMP 2.1 Introduzione al protocollo SNMP SNMP nasce nel 1989 e viene definito dalla Internet Engineering Task Force

(IETF)[7]; da quel momento SNMP diventa uno standard industriale per controllare

gli apparati di rete tramite un’unica applicazione di controllo. SNMP rappresenta

una serie di funzioni e protocolli per la gestione di rete che comunicano tra di loro

attraverso l’Internet Protocol (IP), infatti la prima implementazione avviene su pro-

tocollo TCP/IP, ma in seguito verrà sviluppato anche su reti IPX e AppleTalk. Que-

sto protocollo permette agli amministratoti di rete di individuare ed inseguito isolare

i componenti difettosi che si possono trovare su una rete, configurare i vari compo-

nenti in remoto e monitorare lo stato e le performance della rete.

SNMP è passato attraverso alcune revisioni fino all'attuale versione 3:

• SNMPv1: descritto nelle [8] rappresenta la prima versione, utilizza l'invio dei

nomi di community (utilizzati come password) in chiaro;

• SNMPv2: descritto nelle [9] in cui sono state aggiunte nuove funzionalità tra

cui la crittografia tramite MD5;

• SNMPv3: descritto nelle [10] è lo standard finale, ma al momento raramente

utilizzato;

Come altri protocolli dello Strato di Applicazione del modello OSI (livello 7),

SNMP utilizza normalmente l’UDP [11] (User Datagram Protocol) e un metodo di

comunicazione client/server. SNMP è composto da due parti:

• Manager, il manager è un’applicazione software che viene installata su un

computer della rete che verrà utilizzato come stazione di controllo

(Management Station) o Network Management Station (NMS); i software che

si trovano in commercio e anche in rete, gratuitamente, sono diversi e

Protocollo SNMP

16

soprattutto si trovano per tutte le piattaforme più diffuse (UNIX, PC e Macin

tosh) in modo da non obbligare l’amministratore di rete ad orientarsi su una

determinata piattaforma.

• Agenti e Agenti Proxy, gli agenti risiedono sui dispositivi della rete (switch,

router,…) e generano informazioni come i vari indirizzi di rete del dispositivo

oppure trasmettono statistiche sul traffico del nodo in cui sono installati. Le

informazioni vengono memorizzate all’interno di Management Information

Bases o MIBs.

Gli agenti proxy svolgono le stesse funzioni di un agente normale ma operano

per conto di dispositivi su cui non è implementato SNMP.

SNMP è un’implementazione di tipo client/server. L’applicazione client, chia-

mata Network Manager, crea una connessione virtuale verso un’altra applicazione

server, chiamata SNMP Agent, che gira su un dispositivo remoto come uno switch

o un router, vedi Figura 2.

Il database che viene gestito dall’agente SNMP è più comunemente conosciuto co-

me MIB (Management Information Base) ed è una raccolta di valori statistici e di

controllo riferiti al dispositivo. SNMP permette di estendere questi valori standard

con valori specifici per particolari necessità di un agente o di un utente sempre at-

traverso l’utilizzo dei MIBs, che vedremo in dettaglio in seguito.

Figura 2.1 Implementazione Client/Server

Protocollo SNMP

17

2.2 Considerazioni sul protocollo

Uno dei punti di forza di protocollo SNMP è la sua incredibile diffusione e la

capacità di adattarsi a qualsiasi dispositivo che faccia parte di una rete di computer,

infatti gli agenti SNMP si possono trovare su computer, bridge di rete, switch, rou-

ter, modem e anche stampanti. Il motivo per cui SNMP è nato e per il quale tuttora

è così diffuso è la sua interoperabilità. In più questo protocollo è flessibile ed esten-

sibile in base alle necessità che si presentano. Siccome le funzioni degli agenti

SNMP possono essere facilmente estese, per soddisfare le specifiche di ogni com-

ponente hardware, e soprattutto esiste un meccanismo abbastanza semplice per svi-

luppare le applicazioni software che poi dovranno interfacciarsi con certe tipologie

di agenti, SNMP dispone un grande numero di specifiche per la gestione non stret-

tamente legate alla gestione di apparati di rete, ma anche per esempio per la gestio-

ne di una stampante.

Dopo aver parlato dei motivi che hanno reso famoso questo protocollo, ora

illustriamo anche i suoi punti deboli. Innanzitutto a discapito del nome Simple

Network Management Protocol, SNMP è un protocollo molto complicato da imple-

mentare, per stessa ammissione dei progettisti, un nome più appropriato sarebbe

stato Moderate Network Management Protocol, ma anche questa definizione po-

trebbe sembrare alquanto generosa se si pensa alla complessità delle regole che co-

dificano questo protocollo. Un altro punto debole è l’efficienza del protocollo; in-

fatti molta banda utilizzata viene in realtà sprecata con informazioni inutili come

per esempio la versione del protocollo che viene trasmessa in tutti i pacchetti o altre

informazioni sui data descriptors inserite in ogni pacchetto. Il modo con cui il pro-

tocollo identifica le variabili (come le stringhe di byte, dove ogni byte corrisponde a

un particolare nodo in una database MIB) comporta un inutile spreco di buona parte

del messaggio.

Sebbene anche questo protocollo sia oggetto di critiche e non privo di imper-

fezioni, possiamo comunque dire che per quanto riguarda la complessità delle sue

Protocollo SNMP

18

regole, il problema è esclusivamente dei programmatori in quanto l’utente finale

non sarà mai in grado di capire a fondo la complessità degli algoritmi con i suoi dati

vengono trattati. Invece per quanto riguarda l’efficienza e l’occupazione di banda

possiamo dire che lo sviluppo delle tecnologie di comunicazione può nascondere

parzialmente il fatto che molte informazioni che viaggiano in pacchetti SNMP sono

in sostanza inutili.

Una delle critiche più difficili da spiegare sul protocollo SNMP nasce dalla

domanda: “Perché SNMP sebbene non abbia una visibilità, come altri tool di gestio-

ne di rete, è il più utilizzato?”. In effetti non esiste nessuna guida o nessun RFC il

quale dica che SNMP è meglio di altri tool come “telnet” o “netstat”. Come è possi-

bile che questo protocollo sia il più utilizzato senza avere alle spalle una serie di

documenti che attestino la sua superiorità rispetto ad altri tool? Quando si utilizza

telnet, si accede ad un dispositivo di rete e si scaricano tutte le informazioni neces-

sarie, non è la stessa cosa che fa SNMP?

Un altro problema che non chiarisce questa faccenda sono i venditori, infatti

chi vende software basati su SNMP li presenta semplicemente come una alternativa

alle shell remote piuttosto che un nuovo prodotto per la gestione e l’analisi della

rete; infatti l’attenzione viene posta sulla GUI (Grafical User Interface) anziché sul

sistema automatico di configurazione dei dispositivi, sulla raccolta di dati e sulla

capacità di lavorare su grandi network.

Per rispondere a tutte le domande che ci siamo posti, possiamo innanzitutto

che in effetti esistono vie alternative a SNMP ma sono state soppiantate dalla gene-

rale popolarità e interoperabilità di SNMP. La completezza di questo protocollo e la

sua capacità di adattarsi ad ogni dispositivo per realizzare tutte le funzioni di ammi-

nistrazione di rete, portano alla conclusione che di fatto non esistono alternativa a

SNMP; un altro aspetto da non dimenticare è il fatto che SNMP sia oggi il metodo

più efficace, e probabilmente il solo, per gestire network di grandi dimensioni.

Protocollo SNMP

19

2.3 L’evoluzione del protocollo SNMP

In questo paragrafo verrà fatta una panoramica abbastanza rapida sull’evolu-

zione del protocollo SNMP, poi i concetti principali verranno ripresi in seguito.

2.3.1 SNMP v1

Le caratteristiche principali del protocollo che nascono e si mantengono tali

anche dopo la realizzazione delle versioni successive sono:

• I moduli Agent sono in ascolto sulla porta UDP 161;

• Le risposte sono inviate alla Network Management Station (Manager) utiliz-

zando un numero di porta casuale;

• La dimensione massima del pacchetto SNMP è limitata solamente dalla mas-

sima dimensione del payload UDP(65507 byte);

• I messaggi di errore e le eccezioni (Trap) sono spediti dall'Agent al Manager

in maniera asincrona utilizzando la porta UDP 162.

Le principali operazioni del protocollo SNMPv1 sono:

• GET: utilizzata dal Manager per reperire un valore dal MIB dell'Agent

MANAGER

get

AGENTE

MIB

response

Evoluzione Protocollo SNMP

20

• GET-NEXT: utilizzata dal Manager per accedere ricorsivamente sul MIB.

• SET: utilizzata dal Manager per impostare un valore sul MIB.

• TRAP: utilizzata dall'Agent per inviare messaggi di errore al Manager.

MANAGER

getNext

AGENTE

MIB

response

MANAGER

set

AGENTE

MIB

response

MANAGER AGENTE

trap

Figura 2.2 Scambio di messaggi SNMPv1


21

Il protocollo SNMP assume che i canali di comunicazione siano connection-

less, quindi utilizza come protocollo di livello Transport, il protocollo UDP. Di con-

seguenza, il protocollo SNMP non garantisce l'affidabilità dei pacchetti SNMP.

Per concludere il discorso sulla versione 1 mostriamo nella figura in seguito il

formato del pacchetto SNMP che si articola in 3 parti:

• Numero di versione.

• Community String utilizzata come password.

• Uno o più payload di tipo SNMP.

Versione Community SNMP PDU

SNMP Message

Figura 2.3 Livello di scambio dei messaggi SNMP

Figura 2.4 Struttura Pacchetto SNMP


22

2.3.2 SNMP v2

Nella versione 2 del protocollo non sono state apportate modifiche sostanziali, seb-

bene la versione precedente del protocollo avesse molte limitazioni: presenza di re-

gole non documentate; codici di errori limitati; tipi di dato limitati; scarse prestazio-

ni; dipendenza dal protocollo di trasporto; assenza di gerarchia nell'architettura Ma-

nager/Agent; scarsa sicurezza. Possiamo sintetizzare le modifiche principali mo-

strando le due funzioni che sono state aggiunte GetBulk:

MANAGER

getBulk

AGENTE

MIB

response

E la funzione Inform che presenta una sostanziale novità dato che in questo caso è l’agente che interroga il manager per ottenere una informazione:

MANAGER AGENTE

MIB response

inform



23

2.3.3 SNMP v3

A partire dalla seconda metà del 1999 è disponibile una ulteriore versione del

protocollo SNMP, la versione 3. Poiché le differenze con le precedenti sono notevo-

li, ne vediamo le caratteristiche maggiormente innovative. Si tratta della terza ver-

sione del protocollo e nasce, in special modo, per sopperire alle mancanze dei suoi

predecessori nell’ambito della sicurezza delle trasmissioni. Questo protocollo è sta-

to pensato, inoltre, per essere scalabile, duraturo, per quanto riguarda la sua archi-

tettura, portabile, compatibile con le precedenti versioni (usa gli stessi MIB).

Nonostante ciò, la versione 3 non ha, almeno per ora, trovato grosso spazio

sul mercato, dove continua a farla da padrone la versione 1, forse anche perchè, no-

nostante fosse fra gli obiettivi di questa nuova versione, la maggiorazione del nume-

ro delle caratteristiche è andato a scapito della semplicità del protocollo.

La classica architettura di tipo Manager/Agent, nella versione 3, è stata sosti-

tuita da una più complessa composta da Motore ed Applicazioni. Infatti, un’entità

SNMP v.3 è composta da:

• Snmp-Engine (Motore) che contiene un Dispatcher (smistatore di messaggi),

un sottosistema per elaborare i messaggi, uno per la sicurezza e uno per il

controllo dell’accesso;

• Snmp-Applications (Applicazione): contiene un generatore di comandi, un

ricettore di notifiche, un risponditore ai comandi e altre funzioni.

Il formato dei messaggi di SNMP versione 3 è sostanzialmente diverso da

quello delle precedenti versioni; infatti include anche alcuni parametri di sicurezza

ed il controllo dell'accesso. Tramite appropriate politiche di sicurezza, SNMPv3

consente di accettare messaggi solo nel caso in cui alcune domande ricevano una

risposta affermativa o, comunque, valida come ad esempio:

• Il messaggio è autentico?

• Chi vuole eseguire una certa operazione? (Usa l'autenticazione con chiavi di

crittografia pubbliche e private)


24

• Quali oggetti sono coinvolti dall'operazione?

• Quali diritti di accesso ha il richiedente sull'oggetto al quale vuole accedere?

Queste politiche di sicurezza sono implementate tramite crittografia, funzioni di

hash e altri strumenti che consentono l'autenticazione dei pacchetti (ad esempio

contro un attacco di sniffing e ripetizione di pacchetto), delle password e, anche,

delle PDU (le quali possono essere codificate). Tramite diversi livelli di sicurezza si

può stabilire se consentire un accesso:

• senza autenticazione (no pwd/no Priv)

• con autenticazione (Pwd/no Priv)

• con autenticazione e codifica dei dati (pwd/Priv).


25

2.4 Standard SNMP

Dopo fatto una breve panoramica sulle tre versione dell’SNMP e sulla sua

evoluzione, passiamo adesso ad una analisi più dettagliata del protocollo e dei suoi

standard. Ci sono molti modi in cui affrontare l’analisi dell’SNMP e uno di questi è

vedere SNMP come tre standard distinti [12]:

1. Formato dei Messaggi, SNMP è un protocollo standard di comunicazione

che definisce dei messaggi in formato UDP. Questa parte dello standard ha

subito una notevole involuzione che non produce quasi nessuna conseguenza

per l’utente, ma suscita grande interesse per il programmatore.

2. Set di Oggetti, Il set di Oggetti in questione non è altro che un insiemi di va-

lori (che SNMP chiama “object), che possono essere richiesti a un dispositivo;

in questo set ci sono i valori utili al monitoraggio TCP, IP, UDP,… Ogni og-

getto è identificato da un nome ufficiale e con un identificatore numerico che

è espresso in dot-notation (per esempio 1.2.1.3.12).

3. Metodo standard per la creazione di un oggetto, certamente questa proprie-

tà è una della ragioni per cui si è affermato lo standard SNMP; infatti è possi-

bile estendere il set degli oggetti definendone di nuovi ad-hoc per il proprio

hardware in modo da poter così personalizzare i componenti prodotti.

Standard SNMP

26

2.4.1 Formato dei messaggi

Come abbiamo già visto in precedenza possono essere definite cinque tipolo-

gie di messaggi SNMP che sono: la richiesta “get” che come valore di risposta rice-

ve il nome dell’oggetto interrogato; la richiesta “get-next” richiede un altro nome o

valore di un oggetto che si trova su un altro dispositivo, che abbia un nome SNMP

valido; il comando “set” richiede a quale set di oggetti corrisponde un valore speci-

fico; il comando “response” viene generato dal dispositivo agente e serve ad inviare

i dati che sono stati richiesti dagli altri comandi; il comando “trap” viene generato

anch’esso dal dispositivo agente (quindi dal device di rete) in maniera asincrona

quando deve segnalare o notificare un evento speciale al network manager.

Tutti questi messaggi viaggiano sulla rete incapsulati in PDUs (Protocol Data Unit)

e lo scambio di questi tra i dispositivi avviene tramite protocollo SNMP. L’attuale

formato di questi messaggi non si può definire semplice o conveniente, ma fortuna-

tamente la loro complessità viene mascherata al manager dai software che li gesti-

scono.

Vediamo ora più in dettaglio questi comandi che sono stati creati per soddi-

sfare ogni esigenza di un amministratore di rete:

• GET REQUEST. L’amministratore può richiedere valori specifici tramite il

comando get per determinare le prestazioni e le condizioni di funzionamento

del dispositivo. Molti di questi valori possono essere determinati esclusiva-

mente analizzando i messaggi generati dal protocollo SNMP senza la necessi-

tà di creare un inutile overhead facendo il login sul dispositivo o stabilendo

appositamente una connessione TCP.

• GET NEXT REQUEST. Questo comando viene utilizzato dagli amministra-

tori per “navigare” sulla rete alla ricerca di tutti i dispositivi che supportano il

protocollo SNMP. Questa operazione di ricerca parte dal manager di rete e

viene reiterata da ogni nodo SNMP che incontra, sempre attraverso lo stesso

Standard SNMP

27

comando, fino a quando non viene riscontrato qualche errore; a questo punto

il manager è in grado di mappare tutti i nodi SNMP della rete di sua compe

tenza. Siccome in inglese questo processo di ricerca viene definito “walk”,

tutti i nomi degli oggetti MIB incontrati verranno definiti “walked”.

• SET REQUEST. Questo comando mette a disposizione del manager un me-

todo per effettuare delle operazioni associate al dispositivo di rete come ad

esempio disabilitare l’interfaccia, disconnettere degli utenti, pulire i registri,

ecc. In sostanza il “set” permette di configurare e controllare in modo remoto

il dispositivo tramite SNMP.

• GET RESPONSE. Questo comando viene utilizzato dal device di rete per

rispondere alle richieste che gli vengono inoltrate tramite get, get-next e set.

• TRAP MESSAGE. Un altro comando fornito dall’SNMP Standard che con-

siste in un meccanismo attraverso il quale i dispositivi di rete possono manda-

re delle comunicazioni sul loro stato ai network manager, generalmente questa

funzione viene utilizzata per notificare degli errori. Per ricevere i pacchetti

trap di solito è necessario configurare i vari dispositivi di rete in modo che

questi restino in attesa della ricezione.

Queste tipologie di messaggi appartengono alla prima versione del protocollo

SNMP, infatti questi comandi vanno integrati con altri tre comandi che sono stati

introdotti nella versione 2:

• GET BULK REQUEST. Questo comando serve ad accumulare in una unica

transazione request/response molte informazioni relative ad un dispositivo. In

pratica il get-bulk si comporta come una serie di interazione GetNext request/

response, eccetto nel caso in cui sia sufficiente una singola interazione.

Standard SNMP

28

• SNMPv2 TRAP REQUEST. Nella seconda versione è stato introdotto una

tipologia di messaggi trap che ha caratteristiche quasi identiche alla versione

precedente ma con qualche piccola differenza, perciò si è resa necessaria la

definizione di un nuovo messaggio trap.

• INFORM REQUEST. Questo comando non comunica valori nuovi, ma ha

solo la funzione di confermare la notifica di certi eventi al manager di rete.

Per concludere la panoramica sui messaggi vediamo in Figura come questi

PDUs vengono incapsulati dentro un messaggio Ethernet.

Figura 2.6 Incapsulamento dei messaggi

Standard SNMP

29

2.4.2 Messaggi TRAP

I messaggi TRAP sono dei messaggi che vengono inviati in maniera asincrona

da un Agente verso il Manager per segnalare degli eventi particolari. Le definizioni

di questi eventi si trovano nel [13]. I seguenti messaggi TRAP sono quelli che pos-

siamo incontrare più frequentemente:

• ColdStart - l’agente si è autonomamente avviato o riavviato e i dati potrebbe-

ro aver subito delle alterazioni.

• WarmStart - l’agente si è autonomamente riavviato ma non c’è stata alcuna

alterazione dei dati.

• LinkDown - una interfaccia connessa è passata dallo stato di link UP allo sta-

to DOWN

• LinkUp - una interfaccia connessa è passata in uno stato di link UP

• AuthenticationFailure - il nome della community per accedere al dispositivo

è errato

I messaggi seguenti sono altri messaggi TRAP, ma hanno un uso meno fre-

quente e anche una rilevanza minore al fine della gestione della rete:

• Enterprise - valore del sysObjectID (vedi oggetti MIB) dell’agente.

• Agent-addr - valore dll’indirizzo di rete dell’agente.

• Specific-trap - identificatore di un particolare messaggio TRAP.

• Time-stamp - tempo trascorso dall’ultimo avvio dell’agente.

• Variable-bindings - Lista di variabili contenenti informazioni sul messaggio

TRAP.

• Vendor-specific - specifici messaggi TRAP aggiunti dai produttori dei dispo-

sitivi.

Standard SNMP

30

2.4.3 Standard per gli oggetti SNMP

La lista dei valori che un oggetto può supportare è spesso chiamata SNMP

“Management Information Base” MIB. Capita di frequente che si senta abusare di

questo termine per descrivere ogni oggetto SNMP o una parte della gerarchia del

protocollo, mentre in realtà MIB è semplicemente un’astrazione come Database, a

cui possono essere attribuiti molti significati, che possono ingannare gli utenti meno

esperti.

La grande varietà di valori SNMP nello standard MIB sono definiti nel RFC

1213. Lo standard MIB include molti oggetti (valori) per misurare e monitorare le

attività IP, TCP e UDP, l’instradamento IP, le connessioni TCP, le interfacce e il

sistema in generale. Tutti questi valori sono associati ad un nome ufficiale (come ad

esempio sysUpTime, che misura da quanto tempo è acceso il device dall’ultimo av-

vio) e un valore numerico ufficiale espresso in dot-notation ( il numero identificati-

vo del sysUpTime è 1.3.6.1.2.1.1.3.0). Si può facilmente intuire che è preferibile

esprimere le varie funzioni con il proprio nome piuttosto che in dot-notation, un po’

come succede con gli indirizzi di Internet dove è preferibile memorizzare un nome

piuttosto che un indirizzo IP. Nel prossimo paragrafo poi si parlerà diffusamente dei

MIB.

Figura 2.7 Traduzione di un valore in dot-notation [14]

Standard SNMP

31

2.4.4 Estensione delle funzioni SNMP

Come si diceva in precedenza uno dei punti di forza del protocollo è la sua

facilità di manipolazione ed estensione, infatti possiamo affermare che SNMP è di-

ventato lo standard principale nella gestione delle reti per la sua capacità di aumen-

tare l'insieme degli oggetti standard del MIB con nuovi valori specifici per le deter-

minate applicazioni e determinati dispositivi. Una funzione può essere aggiunta sen-

za particolari problemi, poiché è stato definito un metodo standard per incorporare

nuove funzionalità nei dispositivi dello SNMP e nei software che gestiscono la rete;

questo standard è di solito seguito da un il processo che solitamente viene chiamato

"compiling new MIB” (compilare un nuovo MIB), che permette all'utente di ag-

giungere le definizioni del nuovo MIB sul sistema. Queste definizioni sono fornite

solitamente dai tutorial dell’azienda, che produce il device, in file di testo special-

mente formattate usando la sintassi standard ASN.1. [15] (ASN.1 fa riferimento alla

“Abstract Syntax Notation One”, che è un tipo linguaggio dichiarativo di non sem-

plice comprensione, adottato da SNMP ed usato anche per altre applicazioni, come

crittografia e CMIP protocol).

Da notare che il MIB di un dispositivo SNMP è solitamente fisso; viene pro-

gettato e implementato dalla casa produttrice del device e in genere non può essere

aggiunta nessuna funzione o modificata una già esistente. Per questo motivo quando

si parla di estendibilità SNMP ci si riferisce al software che amministra il protocollo

SNMP, infatti è il software che può essere facilmente compilato o ricompilato per

interfacciarsi con le funzioni aggiuntive del dispositivo di rete.

Standard SNMP

32

2.5 MIB

Per usare efficacemente SNMP, gli utenti devono conoscere SNMP

Management Information Base (MIB), che definisce tutti i valori che il protocollo è

in grado di leggere o di settare. Per diventare esperto in SNMP, un manager

network deve per forza approfondire la sua conoscenza del MIB.

SNMP MIB è organizzato con una struttura ad albero, molto simile a quella

usata dai pc per organizzare i files in directory come si vede in Figura.

Come si vede dalla figura la cartella radice (root) non ha nome, poi seguono le tre

cartelle principali in cui sono contenuti tutti i sottoalberi che contengono le defini-

zioni di tutti gli standard tra cui anche Internet che è contenuto in una sottocartella

di ISO (International Organization for Standardization), il nostro interesse infatti

cade sul contenuto del sottoalbero Internet.

Figura 2.8 Albero MIB – Root and Subtree

MIB

33

L’insieme di standardizzazioni che riguardano Internet possono essere suddivise in

quattro rami principali (come si vede nella Figura 2.9):

• i rami “directory” e “experimental” sono sostanzialmente privi di valori e og-

getti che abbiano un significato rilevante;

• il ramo “management" è molto importante per il nostro studio e contiene tutti

gli standard degli oggetti supportati da tutti i dispositivi della rete (o perlome-

no la grande maggioranza);

• il ramo "private" invece contiene le definizioni degli standard per gli oggetti

SNMP creati dai vari produttori e implementati sui propri dispositivi.

La struttura ad albero descritta è una parte integrante dello standard SNMP,

comunque le parti su cui porremo l’attenzione sono le “foglie” (leaf) di questo albe-

ro, ossia gli standard che realmente definiscono le funzioni a disposizione dell’am-

ministratore di rete.

Figura 2.9 Albero MIB - Leaf

MIB

34

2.5.1 Classificazione MIB

Generalmente, gli oggetti SNMP possono essere divisi in due categorie simili

ma con piccole sostanziali differenze che riflettono l'organizzazione in una struttura

ad albero[12]:

1. Discrete MIB Objects. Gli oggetti “discreti” SNMP contengono solamente

una parte precisa e ben definita dei dati utili alla gestione. Questi oggetti sono

spesso distinti dai Table Objects (descritti sotto) aggiungendo un'estensione

“.0”(dot-zero) ai loro nomi (se l'estensione “.0” viene omessa da un nome di

un oggetto SNMP, è sempre considerata implicita).

2. Table MIB Objects. Gli oggetti SNMP definiti “table”(tabella) contengono

parti multiple di dati o valori per la gestione. Questa categoria di oggetti si

distingue dagli oggetti “discrete” aggiungendo “.” (dot-extension) ai loro no-

mi seguito da un numero che distingua unicamente il valore particolare a cui

si fa riferimento.

La dot-extension si riferisce in certa letteratura al numero dell’istanza dell’og-

getto SNMP. Nel caso degli oggetti "discrete", questo numero sarà zero, mentre nel

caso degli oggetti “table”, questo numero sarà l'indice nella tabella SNMP.

2.5.1.1 Discrete MIB Objects

Molti oggetti SNMP sono discreti, questo significa che l'operatore deve sol-

tanto conoscere il nome dell’oggetto e nessun’altra informazione. Gli oggetti discre-

ti rappresentano spesso dei valori standard di un dispositivo, particolarmente utili

per ricavare informazioni dalla rete al fine di monitorare e soprattutto confrontare le

prestazioni dei dispositivi di vari produttori. Se l'estensione (numero dell’istanza)

dell’oggetto non è specificata, esso viene presupposto come “0” (dot-zero).

MIB

35

2.5.1.2 Table MIB Objects

Le tabelle SNMP sono dei tipi speciali di oggetti SNMP, che permettono di

raggruppare una serie di dati che un dispositivo deve supportare. Le tabelle vengono

distinte dagli oggetti discreti, in quanto possono svilupparsi senza limiti. Per esem-

pio, SNMP definisce l'oggetto “ifDescr” (come oggetto standard SNMP) che indica

la descrizione testuale di ogni interfaccia supportata dal dispositivo in questione;

visto che i vari dispositivi della rete possono essere configurati con più di un'inter-

faccia, questo oggetto è ovvio che non può essere rappresentato con un singolo va-

lore ma solo con un insieme di valori come un array.

Per convenzione gli oggetti SNMP sono sempre raggruppati in una “Entry

Directory”, all'interno della quale ogni oggetto viene definito con il suffisso

“Table” (per esempio l'oggetto “ifDescr” descritto precedentemente si trova nella

directory “ifEntry” contenuta a sua volta nella directory “ifTable”).

Il protocollo prevede parecchi vincoli sugli oggetti SNMP come vedremo nel-

l’elenco che segue:

1. Ogni oggetto dell’”Entry Directory” di una tabella deve contenere lo stesso

numero di elementi come gli altri oggetti gli altri oggetti contenuti nella stessa

“Entry Directory”, dove il numero delle istanze di tutti i valori è lo stesso. Gli

oggetti della tabella si possono considerare come insiemi omogenei di dati.

2. Nella creazione di un nuovo oggetto Entry, SNMP richiede che un valore sia

associato con ogni tabella Entry in un singolo messaggio SNMP (PDU). Ciò

significa che per creare una riga in una tabella, tramite il comando SET, un

valore deve essere specificato per ogni elemento della riga.

3. Se si vuole cancellare una riga della tabella, SNMP richiede che almeno un

oggetto che abbia un elemento di controllo che sia in grado di realizzare la

cancellazione desiderata. Questo procedura è necessaria solo quando si can-

cella una riga e non quando si cancella una tabella SNMP.

MIB

36

2.6 Tipologie di oggetti MIB

Gli oggetti MIB sono caratterizzati da specifici tipi di valori e il protocollo è

molto rigido nella definizione di questi “primitive types”:

• Text Type MIB Objects. SNMP definisce un tipo “DisplayString” che può

contenere qualsiasi tipo di informazione testuale (solitamente con un massimo

di 256 caratteri). Il testo può contenere solo i caratteri stampabili. Gli esempi

di questo tipo di oggetto includono il “sysDescr” e i valori “ifDescr”. Questo

tipo di oggetto è abbastanza comune come oggetto MIB.

• Counter Type MIB Objects. SNMP definisce contatore, quella tipologia di

valori che possono essere solo incrementati. Il contatore è il tipo più diffuso di

oggetto MIB standard ed include oggetti come “ipInReceives”,

“ipOutRequests” e “snmpInPkts”. Il contatore può raggiungere un valore mas-

simo e non può mai scendere sotto lo zero.

• Gauge Type MIB Objects. SNMP definisce “gauge”, quei valori numerici

che possono essere incrementati o decrementati. Questo tipo si trova soltanto

in poche situazioni tra gli oggetti MIB, sebbene venga spesso riportato tra gli

oggetti MIB “private” dei produttori). Gli esempi di questo tipo di oggetto

includono il “tcpCurrEstab”.

• Integer Type MIB Objects. SNMP definisce un tipo base di “integer” che

può contenere valori positivi o negativi. Questo valore viene solitamente so-

stituito con oggetti di tipo “gauge” o “counter”, ma a volte viene espresso tra i

MIBs "private" sulle guide dei produttori.

• EnumVal Type MIB Objects. SNMP definisce tipi di valori “enumerati”,

quei valori che associano un'etichetta testuale con un valore numerico. Questo

MIB

37

tipo di dati è abbastanza comune nello standard MIB e tra questi troviamo

“ifAdminStatus”,che ha come valori predefiniti “1=up”, “2=down” e

“3=testing”. Generalmente questi valori vengono formattati affinché vengano

secondo la convenzione “nome(numero)”.

• Text Type MIB Objects. SNMP definisce un tipo di oggetti “TimeTicks”

che rappresenta un tempo trascorso, che viene rilevato con una precisione al

centesimo di secondo, anche se non viene mai utilizzato un dato con questa

precisione dato che la notazione che si usa è questa “HH:MM:SS:hh”. Si noti

che ogni oggetto “time” è sempre un tempo trascorso, per esempio, il valore

del “sysUpTime” indica il tempo trascorso dall’ultimo avvio del dispositivo.

• Object Type MIB Objects. SNMP definisce un tipo di oggetti “object” per

contenere l’idenficatore di un altro oggetto SNMP. Se l'oggetto chiamato è

compilato nel MIB, il nome visualizzato è uguale al nome dell'oggetto SNMP.

Un esempio di questo tipo di oggetto è il “sysObjectID”.

• IPAddr Type MIB Objects. SNMP definisce un tipo di oggetti “IP address”

per identificare l’indirizzo IP di un dispositivo della rete. Questo tipo di og-

getto viene visualizzato quasi sempre nella convenzionale dot-notation degli

indirizzi IP. Gli esempi di questo tipo di oggetto includono “ipRouteDest”,

“ipRouteNextHop” e “ipRouteMask”.

• PhysAd Type MIB Objects. SNMP definisce un tipo di oggetti “phyisical

address” (indirizzo fisico) dove vengono memorizzati gli indirizzi MAC del

dispositivo della rete. I responsabili visualizzano spesso questo tipo di oggetto

come una sequenza di valori esadecimali preceduti dalla parola “hex:” e sepa-

rati da due punti. Questa tipologia di oggetti include “ifPhysAddress”.

MIB

38

• String Type MIB Objects. SNMP definisce un tipo di oggetti “stringa” per

contenere stringhe di byte arbitrarie. Se la stringa di byte contiene soltanto i

caratteri di ASCII, i manager visualizzano questo valore come stringa di testo.

Altrimenti, i responsabili visualizzano questo tipo come sequenza dei valori

esadecimali, premettendo “hex:” la parola chiave hex seguita dai due punti.

Questo tipo di valore è raro, ma occasionalmente viene riportato negli oggetti

MIBs “private” dei produttori.

• Table Type MIB Objects. Il tipo “table” è un oggetto che contiene i valori di

una tabella. Questo tipo di oggetti è sempre un nome intermedio che contiene

il nome dell’Entry Directory a cui appartiene, che a sua volta contiene i vari

Table Objects.

• Branch Type MIB Objects. Il tipo “branch” (tradotto letteralmente significa

ramo) è un oggetto che contiene delle “ramificazioni” addizionali degli ogget-

ti elencati finora.

MIB

39

2.5.3 Valori di accesso dei MIB

Ogni oggetto dello SNMP è definito per avere un accesso particolare, uno

“read-only”, “read/write”, “write-only” che determini se l'utente può leggere il valo-

re dell'oggetto, leggere e scrivere il valore di un oggetto (usando il comando SET) o

soltanto scrivere il valore.

SNMP definisce una community per mettere in relazione un agente SNMP ed

uno o più manager SNMP. Ogni ordine NMP ha associata la stringa della relativa

community. I nomi delle stringhe vengono configurati dal manager della rete.

Queste stringhe forniscono una misura di sicurezza per le informazioni conte-

nute negli oggetti, anche se non possiamo definirle delle passwords; infatti le strin-

ghe più comunemente usate sono “public” e “private”. Il dispositivo che riceve un

comando SNMP prima controlla che la stringa community abbia un valore valido,

dopo l’accesso agli oggetti richiesti verifica i permessi di read/write.

Tuttavia, è consigliabile rendere questi nomi di community non visibili in mo-

do da limitare la possibilità di avere accessi di utenti esterni o non autorizzati.

MIB

40

2.5.4 Compilare un oggetto MIB

Una delle componenti principali di cui non può fare a meno un buon respon-

sabile di rete che utilizza SNMP è un “MIB Compiler” che permette di creare nuovi

MIB da aggiungere al sistema di amministrazione. Questo concetto può confondere

i nuovi utenti probabilmente a causa della strana nomenclatura legata a questo ter-

mine.

Quando un MIB viene compilato in un software SNMP Manager, l’ammini-

stratore si deve accertare che questa funzione sia supportata dall’agente sulla rete. Il

concetto è simile ad aggiungere un nuovo schema a un database. L'agente non è in-

fluenzato dalla compilazione del MIB (poiché è già “informato” delle funzioni che

può supportare). Ovviamente all’atto della compilazione del MIB, il responsabile

deve sapere quali sono le funzioni speciali supportate dall'agente ed accede a questi

oggetti come se fossero componenti standard del set di oggetti.

Solitamente, quando un MIB è compilato su un sistema, il programmatore de-

ve creare anche delle nuove directory che corrispondano agli oggetti. Questi indici

possono essere visualizzati tramite un “MIB Browser", che è un componente di am-

ministrazione SNMP molto comune e viene incorporato in tutti i sistemi di network

management. Questi nuovi oggetti possono essere possono non essere accettati da

una agente, che genera dei warning, e ne possono anche modificare le prestazioni.

Gli oggetti MIB sono documentati con la sintassi ASN.1, che è un tipo di lin-

guaggio dichiarativo non semplice da comprendere, adottato da SNMP ed usato in

poche altre applicazioni. L'utente può ottenere le definizioni ASN.1 di un nuovo

dispositivo o di nuovo agente SNMP, trasferendo il file che contiene queste defini-

zioni sul proprio sistema e lanciando un “MIB Compiler” per tradurle. Teoricamen-

te tutti gli agenti supportano le definizioni dei MIBs descritte nel [23] e la maggior

parte dei agenti dispone anche di funzioni aggiuntive.

MIB

41

Capitolo 3 Software SNMP 3.1 Requisiti di un software per SNMP Nei capitoli precedenti abbiamo mostrato le caratteristiche che descrivono il

protocollo SNMP, ma ancora non abbiamo pienamente giustificato il fatto che

SNMP sia preferibile ad altri tipi di protocolli d'amministrazione.

La risposta più semplice a questo quesito sta nel fatto che SNMP è stato pro-

gettato per cercare di uniformare l’accesso ai dispositivo di rete. SNMP è un Appli-

cation Program Interface (API) verso la rete, in modo che i programmi general-

purpose di network management possono essere scritti facilmente per lavorare con

una grande varietà di dispositivi differenti. Senza SNMP, ci sarebbe certamente una

miriade di applicazioni speciali e custom-written (scritte ad-hoc), in grado di opera-

re soltanto con l'apparecchiatura specifica del produttore. In più SNMP è un modo

economico di determinazione della condizione dei dispositivi senza l'esigenza del

login remoto o dell'autenticazione, inoltre permette di reperire velocemente una

grande mole di dati su reti anche su larga scala.

Quali sono i componenti che non posso mancare in un buon software per la gestione

del protocollo SNMP?

• Alarm Polling Functions. Tutti i migliori software SNMP forniscono delle

funzionalità per fissare delle soglie sui valori degli oggetti MIB SNMP e ri-

spondono con un certo tipo di notifica quando queste soglie sono violate.

Queste funzioni tengono costantemente sotto controllo la rete e l’integrità di

tutti i dispositivi connessi, quindi la capacità di determinare quali dispositivi

stanno rispondendo (cioè in linea) e quali dispositivi non stanno rispondendo

(cioè off-line o faulted).

Installazione Software SNMP

42

• Trend Monitoring Function. Un’altra funzione fondamentale per un

manager SNMP è la possibilità di monitorare un valore SNMP durante un pe-

riodo prolungato, in modo da poter ricavare un range di tolleranza e soprattut-

to cercare di individuare un trend di questo dato. Questo tipo di funzione può

essere usato per determinare il carico della rete nel tempo guardando la quan-

tità di traffico sulla banda a disposizione). Un tipico output di queste funzioni

di amministrazione è un grafico dell’utilizzazione della rete durante un certo

arco temporale (un giorno, una settimana,…)

• Trap Monitoring Functions. Il manager SNMP deve essere in grado di rice-

vere e filtrare i messaggi TRAP che gli arrivano dai componenti sulla rete. I

traps SNMP sono una parte importante dello standard SNMP e permettono ai

dispositivi di fare un’auto-analisi delle loro condizioni di funzionamento.

Questi messaggi trap sono gestiti tipicamente dal manager di rete a cui giun-

gono sottoforma di notifiche di eventi. Dato che i traps sono asincroni ed e-

sterni al controllo del manager di rete, quest’ultimo può attivare delle funzioni

di filtraggio dei messaggi per eliminare quelli non pertinenti o quelli comple-

tamente inutili.

• Management Tool Set. Tutti i software SNMP dispongono di un tool set. Il

tool di gestione SNMP più comune è il MIB Browser, che permette che all’u-

tente di controllare gli oggetti MIB di un dispositivo particolare; infatti spesso

il MIB Browser è l'interfaccia principale per la regolazione dei valori SNMP

di un agente e si può utilizzare per fare le opportune regolazioni sempre trami-

te protocollo SNMP.

• MIB Compiler. Il manager SNMP deve poter disporre di un oggetto MIB in

grado di aggiungere delle funzioni al set già presente sui dispositivi della rete,

ciò implica l'esigenza assoluta di un compilatore MIB in modo da potere inte-

grare e utilizzare le funzioni speciali messe a disposizioni dai produttori di

componenti di rete.


43

E’ importante sottolineare che le suddette caratteristiche del software manager

SNMP sono pensate specialmente per la visualizzazione a video e quindi per rende-

re più leggibile la grande mole di dati prodotta da una rete di vaste dimensioni.

La maggior parte degli oggetti MIB sono read-only e vengono sfruttati molto

bene dal protocollo SNMP che ne ricava le informazioni sulla condizione della rete

e determina la salute della rete; di contro diventa meno potente quando è necessario

apportare delle modifiche alle impostazioni di rete, anche se il comando SET

(spesso realizzato completamente da un browser MIB) permette di apportare qual-

che correzione alle configurazioni dei dispositivi via SNMP.

Dopo aver fatto queste premesse dobbiamo cercare un software in grado di

mostrare come funzioni realmente un Manager SNMP. Ovviamente i software in

commercio sono moltissimi sia commerciali sia open source. Tra i software com-

merciali i due leader del settore sono OpenView di HP e Tivoli di IBM, mentre in

ambito open source non ci sono software di spicco anche se uno tra quelli esaminati

è sembrato molto interessanti: OpenNMS.

La scelta è ricaduta su un software open source gratuito ovviamente e tra i due so-

pra elencati OpenNMS sembrava quello più completo e con uno sviluppo maggiore;

quindi tutto il resto del capitolo sarà dedicato a questo tool e verrà spiegato cosa

richiede a livello di strumenti, come si installa, come si configura e quali sono le

sue funzioni principali.


44

3.2 Installazione

3.2.1 Requisiti di sistema

I requisiti minimi richiesti per l'installazione e l'esecuzione di OpenNMS pos-

sono essere riassunti nei seguenti tre punti:

• Processore: 1 Ghz o superiore.

• Memoria RAM: 256MB, anche se è comunque consigliato un minimo di 512

MB.

• Memoria su disco fisso: circa 25MB servono per l'installazione di base, per

quanto riguarda lo spazio da riservare alle informazioni di gestione che ver-

ranno raccolte nel tempo si può stimare, in maniera del tutto approssimativa,

un minimo di 3MB per ogni interfaccia da interrogare. Considerati poi i file di

logs del programma che crescono nel tempo si può ritenere che per una confi-

gurazione minima lo spazio su disco a disposizione debba essere superiore ad

1 GB.

3.2.2 Elenco dei pacchetti necessari

Il software di installazione è disponibile sul sito di SourceForge alla seguente

pagina web: https://sourceforge.net/project/showfiles.php?group_id=4141. Le ver-

sioni disponibili sono diverse a seconda del sistema operativo Linux che si intende

utilizzare. In questo lavoro di tesi è stata scelta la distribuzione Fedora Core 3 e la

versione di OpenNMS [16] è la 1.2.3. Prima di procedere ad installare OpenNMS

bisogna corredare il nostro sistema Linux dei seguenti pacchetti:

• Java: OpenNMS è scritto quasi interamente in linguaggio Java [17].


45

• Tomcat4 [18]: è un Java servlet engine. In pratica Tomcat è il server web che

utilizza OpenNMS per garantire agli utenti l'accesso alle proprie risorse.

• RRDtool [19]: consente una rapida memorizzazione dei dati raccolti in un pic-

colo spazio di memoria e la rappresentazione degli stessi in modalità grafica.

• PostgreSQL[20]: è il database di OpenNMS.

• Curl: consente mediante uno script (/etc/init.d/opennms status) di sapere se

tutti i componenti che costituiscono OpenNMS stanno funzionando corretta-

mente.

3.2.3 Installazione Java

È importante installare SDK anziché il JRE, poiché Tomcat dovrà compilare

il codice del Java (che richiede javac il quale si trova in SDK). Dovrete usare la

piattaforma del Java 2 della Sun, edizione standard, versioni 1.4 o successive (è

consigliabile utilizzare la versione 1.4.2 o successive). Tutti i pacchetti sono scari-

cabili dal sito http://java.sun.com.

Una volta accettati i termini della licenza per l’utilizzo del software è possibi-

le scaricare il pacchetto; siccome utilizziamo una versione di Linux (Fedora Core 3)

che è RPM-based sarà sufficiente scaricare il pacchetto .rpm che ci interessa e in-

stallarlo, senza dover fare ricorso al pacchetto .bin e in seguito al compilatore per

installarlo.


46

3.2.4 Installazione RRDTool

Questo tool è fondamentale per poi poter installare OpenNMS, infatti compa-

re anche tra le dipendenze; questo pacchetto si può scaricare sul sito http://

people.ee.ethz.ch/~oetiker/webtools/rrdtool.

Per l’installazione si possono fare due scelte. La prima è seguire l’installazio-

ne sulla guida del sito sopra citato nella sezione Documentation -> rrdbuild, in que-

sta procedura si utilizzano tutti i pacchetti con codice sorgente che deve poi essere

compilato e installato, inoltre prima di poter installare rrdtool è necessario installare

cinque librerie aggiuntive, è chiaro che questa procedura diventa lunga e abbastanza

macchinosa. La seconda opzione è quella di scaricare rrdtool come pacchetto RPM

dal sito http://dag.wieers.com/packages/rrdtool/ e installarlo semplicemente tramite

il comando rpm.

3.2.5 Installazione PostgreSQL

Per l’installazione del PostgreSQL si può provvedere in fase di installazione

del sistema operativo selezionando semplicemente il pacchetto PostgreSQL oppure

sul sito http://www.postgresql.org/download/ dove si trova tutto il necessario all’in-

stallazione.

3.2.6 Installazione Tomcat4

Il pacchetto RPM del Tomcat4 per Fedora Core 3 si trova molto velocemente

sull’FTP di OpenNMS ftp://ftp.opennms.org/pub/dependencies/tomcat4/, all’interno

di questa directory ci sono due file da scaricare e installare entrambe: tomcat4-

4.1.18-full.1jpp.noarch.rpm and tomcat4-webapps-4.1.18-full.1jpp.noarch.rpm.


47

3.2.7 Configurazione PostgreSQL

E' necessario, a questo punto, effettuare alcune modifiche sui files di configu-

razione di PostgreSQL; tali files vengono creati una volta che viene lanciato Po-

stgreSQL, per cui è necessario eseguire tale operazione prima. Si localizza la

directory dei dati di PostgreSQL, di solito /var/lib/pgsql/data e si cercano i files

postgresql.conf e pg_hba.conf.

Nel file postgresql.conf bisogna cambiare tre parametri:

• tcpip_socket = true (è necessario che non ci sia preposto il carattere

di commento #, questo consentirà ad OpenNMS di interrogare il database) • max_connections = 256

• shared_buffers = 1024

Nel file pg_hba.conf invece bisogna modificare il file in modo che le uniche

righe non commentate (e quindi senza # ) siano le seguenti:

# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD

local all all trust

host all all 127.0.0.1 255.255.255.255 trust

host all all ::1 ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

trust


48

3.2.8 Installazione e avvio di OpenNMS

A questo punto è possibile scaricare dal sito web https://sourceforge.net/

project/showfiles.php?group_id=4141 i file RPM per installare OpenNMS relativi

al proprio sistema operativo, in questo caso Fedora Core 3. Per l’installazione è suf-

ficiente seguire i seguenti comandi:

# rpm -i opennms-1.2.3-0_<distribution>.<platform>.rpm

# rpm -i opennms-webapp-1.2.3-0_<distribution>.<platform>.rpm

# rpm -i opennms-docs-1.2.3-0_<distribution>.<platform>.rpm

Prima di lanciare il programma è necessario settare alcuni path:

• il path del JRE # $OPENNMS_HOME/bin/runjava -s <path JRE>

• il path del postgreSQL # $OPENNMS_HOME/bin/install -disU

• il path delle Web Application # $OPENNMS_HOME/bin/install -y -w $CA-TALINA_HOME/webapps -W $CATALINA_HOME/server/lib

La procedura di installazione adesso è terminata, per avviare il programma:

/etc/init.d/opennms start

Aprendo un browser web, come Mozilla, alla pagina http://localhost:8080/opennms

si effettua il login, come nome utente “admin” come password ”admin”, e si ha ac-

cesso al software di Network Management.

L'effettivo funzionamento del sistema può essere verificato tramite il comando: /etc/init.d/opennms status

controllando che tutti i campi siano in modalità running.

Quando si eseguono delle modifiche ai files di configurazione è necessario fermare

il programma e farlo ripartire: /etc/init.d/opennms restart

Il riavvio completo della macchina non è mai richiesto, però in alcuni casi può risul-

tare necessario, considerata la natura “unstable” del prodotto utilizzato.


49

3.2.9 Possibili Problematiche

Niente è perfetto, può quindi capitare che qualcosa non funzioni in tal caso la

prima cosa da fare è cercare di capire dai files di log di OpenNMS quale può essere

il problema. Tali files si trovano, di solito, in /var/log/opennms e gli eventuali pro-

blemi sono da cercarsi nelle righe dove compaiono i campi FATAL e ERROR.

Se non compare la home page di OpenNMS verificare che sia Tomcat che

OpenNMS stiano funzionando correttamente, dopodichè se le cose continuano a

non funzionare cambiare l'indirizzo ovvero utilizzare http://localhost:8080/

opennms. La maggior parte dei problemi è dovuta alle configurazioni degli applica-

tivi Java e PostgreSQL.

E' possibile chiedere supporto alla mailing list e alla documentazione ufficiale

di OpenNMS. Gli indirizzi sono riportati di seguito:

• http://www.opennms.org • http://sourceforge.net/docman/?group_id=4141 • https://sourceforge.net/mail/?group_id=4141 • http://wiki.opennms.org/tiki-list_faqs.php

Bisogna tenere presente che il progetto OpenNMS evolve in maniera molto rapida e

versioni successive a quella utilizzata in questa tesi si susseguono rapidamente, per

cui bisogna fare estrema attenzione a ciò che si utilizza e alla documentazione che

si consulta.


50

3.3 OpenNMS

Rilasciato sotto licenza GPL, OpenNMS rappresenta, come detto, la vera al-

ternativa open source ai prodotti di Network Management proprietari ponendosi

come obiettivo la scalabilità e la portabilità. Esso consente a uno o più utenti di ac-

cedere ai seguenti servizi:

• Servizi Web: HTTP e HTTPS

• Servizi di Posta: POP3, IMAP e SMTP

• Database: Oracle, Sybase, Informix, SQLServer, MySQL e Postgres

• Servizi di Rete: ICMP, SNMP, DNS, DHCP,FTP, SSH e LDAP

• Altri Servizi: Citrix e Lotus Domino IIOP

Per quel che riguarda il Network Management, OpenNMS sfrutta le potenzia-

lità offerte dal protocollo SNMP dialogando con gli agenti presenti, ognuno, sui va-

ri nodi della rete secondo le modalità descritte nei capitoli precedenti.

OpenNMS è scritto quasi interamente in linguaggio Java, le uniche eccezioni

riguardano il database (PostgreSQL) e i grafici (RRDtool), e ciò rende il prodotto

eseguibile su qualsiasi piattaforma. I files di configurazione sono scritti in eXtensi-

ble Markup Language (XML) e i dettagli per l'installazione sono riportati nei para-

grafi precedenti.

OpenNMS

51

Si accede al sistema mediante un browser web al seguente indirizzo http://

localhost:8080/opennms e dopo aver effettuato il login “admin” e password

“admin” viene visualizzata la home page.

All'interno della home page è riportata, oltre ad un elenco dei nodi non fun-

zionanti, una situazione generale riguardante i servizi (Categories) presenti nella

rete con le relative percentuali di funzionamento nelle ultime 24 ore.

Come si vede dalla figura, sono presenti i links che consentono di visualizzare

i tempi di risposta per tutti i nodi attivi presenti sulla rete e i dati prestazionali per

quelli equipaggiati con l'agent SNMP. Navigando all'interno del sistema, attraverso

links di facile comprensione, si trova una completa descrizione per ogni singolo no-

do e per ogni interfaccia riconosciuta, come si vede in figura alla pagina seguente.

Figura 3.1 Schermata principale di OpenNMS

OpenNMS

52

In particolare viene dedicata una pagina all'interno della quale si trovano tutte

le informazioni che interessano un particolare nodo. Oltre ad una dettagliata crono-

logia degli avvenimenti che hanno interessato il nodo in questione sino a quel parti-

colare istante, nella stessa pagina vengono visualizzate le interfacce, identificate dal

proprio indirizzo IP, con i relativi servizi associati.

A fondo pagina sono riportate ulteriori due sezioni: una riguardante gli ultimi

guasti che hanno interessato il nodo, con i relativi riferimenti temporali, e uno ri-

guardante il tipo di software agent di cui il nodo è provvisto.

L'amministratore avendo sempre una situazione chiara e precisa di ciò che sta

avvenendo, può, da un'unica postazione, controllare tutti i nodi della rete localizzan-

do tempestivamente eventuali malfunzionamenti.

Figura 3.2 Nodo Linux

OpenNMS

53

Vengono riportati di seguito alcuni collegamenti [21] che si trovano frequen-

temente in OpenNMS:

• Admin : rimanda ad una pagina, riportata in figura 3.3, dove è possibile ag-

giungere o rimuovere i nodi e modificare le procedure di interrogazione e no-

tifica. Viene, inoltre, fornita una breve descrizione per ogni operazione ese-

guibile come ulteriore ausilio all'utilizzo.

• View Events : fornisce una lista di tutti gli avvenimenti verificatisi su un par-

ticolare nodo.

• Asset Info : consente di scrivere o leggere informazioni di carattere generale

relative al nodo.

• Response Time : visualizza i grafici dei tempi di risposta relativi ad alcuni

protocolli o servizi (DNS, ICMP, etc.).

• SNMP Performance : visualizza i grafici dei dati SNMP raccolti riguardanti

ad esempio il traffico in ingresso e in uscita, la memoria disponibile o l'utiliz-

zo della CPU.

• Rescan : effettua una nuova interrogazione di un nodo.

OpenNMS

54

Si passa quindi ad un'analisi più dettagliata sulla metodologia di funzionamento di

OpenNMS per poter effettuare le opportune modifiche atte a soddisfare le specifi-

che esigenze per la gestione della rete.

Figura 3.3 Schermata Admin

OpenNMS

55

3.3.1 OpenNMS Discovery

Quando OpenNMS viene lanciato, automaticamente viene eseguita un proce-

dura di discovery, che consiste nell'effettuare una serie di pings su un determinato

range di indirizzi IP, per controllare la presenza di tutte le interfacce attive sulla re-

te.

Tale procedura di ricerca è regolamentata dal contenuto del file discoverycon-

figuration.xml presente nella cartella /etc/opennms. Il suo contenuto è riportato di

seguito:

<discovery-configuration threads="1"

packets-persecond="1"

initial-sleep-time="300000"

restart-sleeptime="86400000"

retries="3"

timeout="800">

<include-range retries="2" timeout="3000">

<begin>192.168.0.1</begin>

<end>192.168.0.254</end>

</include-range>

<include-url>

file:/opt/OpenNMS/etc/include

</includeurl>

</discovery-configuration>

OpenNMS

56

I campi contenuti in tale file hanno i seguenti significati:

• Threads: rappresenta il numero delle volte in cui viene eseguito il processo di

discovery.

• Packets-per-second: rappresenta il numero di pacchetti ICMP inviati al se-

condo.

• Initial-sleep-time: è il tempo, espresso in millisecondi, che deve trascorrere

dopo l'avvio di OpenNMS perchè il processo di discovery possa iniziare.

• Restart-sleep-time: è il tempo che deve passare prima che il processo di di-

scovery ricominci.

• Timeout: rappresenta la soglia di tempo limite in cui il sistema aspetta una

risposta da un particolare indirizzo IP.

• Retries: indica il numero di tentativi effettuati prima di decidere che l'indiriz-

zo IP interrogato in realtà non esiste.

Resta da definire qual'è il range di indirizzi da scandagliare o quale quello da

escludere, per far ciò esistono quattro modalità:

1. <specific>ip-address</specific>: dove ip-address è l'indirizzo

specifico che si vuole interrogare.

2. Specificando l’indirizzo iniziale e quello finale <include-range>

<begin>start-ip-address</begin>

<end>end-ip-address</end>

</include-range>

OpenNMS

57

3. Escludendo un certo range di indirizzi <exclude-range>

<begin>start-ip-address</begin>

<end>end-ip-address</end>

</exclude-range>

4. <include-url>file:filename</include-url>: dove filename

indica un path in cui vi è un file di testo con una lista di indirizzi IP.

Il processo di discovery può essere analizzato tramite il file discovery.log creato

nella cartella /var/log/opennms, infatti questo processo può essere comunque evitato

per poter aggiungere un nuovo nodo da monitorare, infatti si può fare in maniera

immediata aggiungendo il nuovo indirizzo IP tramite l'interfaccia web nella sezione

“admin” -> “add interface” seguendo le indicazioni riportate.

Tuttavia la procedura di discovery è comunque valida in quanto in reti abbastanza

estese è facile che si aggiungano nuovi nodi prima che l'amministratore ne venga a

conoscenza. Per cui il sistema stesso, anche se con una certa latenza, risulta comun-

que in grado di rilevare una nuova entità.

OpenNMS

58

3.3.2 OpenNMS Capsd

Mentre il processo di discovery si occupa solo di scoprire un nuovo nodo pre-

sente sulla rete, chi raccoglie le informazioni generiche relative alla nuova macchi-

na è il demone capsd, il cui funzionamento è regolamentato dal file di configurazio-

ne capsd-configuration.xml.

Tramite questo demone, OpenNMS verifica l'esistenza di un particolare servi-

zio attraverso la ricerca dei seguenti protocolli e applicativi:

• Citrix

• DHCP

• DNS

• Domino IIOP

• FTP

• HTTPS

• HTTP

• ICMP

• LDAP

• Microsoft Exchange

• Notes HTTP

• POP3

• SMB

• SMTP

• SNMP

• TCP

OpenNMS

59

Le prime righe che si incontrano in capsd-configuration.xml descrivono il suo fun-

zionamento: <capsd-configuration

rescan-frequency="86400000"

initial-sleep-time="300000"

management-policy="managed"

max-suspect-thread-pool-size = "6"

max-rescan-thread-pool-size = "3"

abort-protocol-scans-if-no-route = "false">

Capsd effettua una ricerca continua su ogni interfaccia per verificare se nuovi

servizi vengono aggiunti. La frequenza con cui tale ricerca viene effettuata è stabili-

ta dal campo rescan-frequency espresso in millisecondi. Come per il processo di

discovery, capsd aspetta un certo periodo di tempo, initial-sleep-time, per iniziare la

sua raccolta dati dopo che OpenNMS è partito. Il parametro management-policy

regolamenta il comportamento di capsd. In pratica “settando” tale campo al valore

“managed” si fa in modo che capsd raccolga informazioni solo per quel range di

indirizzi IP, definiti alla fine del file, che sono indicati con “managed”.

All'interno di capsd-configuration.xml è contenuta una sezione per ognuno

dei servizi sopra elencati. Ad esempio per il protocollo ICMP troviamo la seguente

configurazione:

<protocol-plugin protocol = "ICMP"

class-name="org.opennms.netmgt.capsd.Icmp.Plugin"

scan = "on" user-defined ="false">

<property key = "timeout" value = "2000"/>

<property key = "retry" value = "2"/>

</protocol-plugin>

OpenNMS

60

Ogni volta che un nuovo nodo viene aggiunto il demone capsd inizia ad inter-

rogare la relativa interfaccia alla scoperta di tutti i servizi presenti in modo da moni-

torarne lo stato di funzionamento.

Un servizio o un protocollo che non sia stato scoperto o contemplato dal de-

mone capsd non potrà essere gestito o monitorato da OpenNMS per cui è necessario

verificare che tutti i nodi che vengono aggiunti nel sistema abbiano un indirizzo IP

compreso nel range di indirizzi definito all'interno di capsd-configuration.xml.

3.3.3 OpenNMS Polling

Il processo di polling, già descritto all'inizio di questo capitolo, è configurabi-

le in OpenNMS modificando opportunamente il file di configurazione pollerconfi-

guration.xml che si trova nella directory /etc/opennms. Esaminandone il contenuto

si trova:

<poller-configuration threads="30"

serviceUnresponsiveEnabled="false">

<node-outage status="on"

pollAllIfNoCriticalServiceDefined="true">

<critical-service name="ICMP"/>

</node-outage>

Il processo di polling consiste (mediante un numero massimo di tentativi o

threads) nello stabilire una connessione con una particolare porta di una interfaccia

remota e quindi verificare periodicamente che un determinato servizio restituisca

una risposta.

OpenNMS

61

Se non si riceve tale risposta entro un certo periodo di tempo, o timeout, il

servizio è considerato inattivo. Nelle reti più complesse possono succedersi dei gua-

sti di modesta entità, quindi può verificarsi che una risposta non giunga entro il

timeout prefissato senza però che il servizio a cui si riferisce sia effettivamente inat-

tivo.

Per evitare queste situazioni si setta il campo serviceUnresponsiveEnabled =

“true” in modo che quando una risposta non giunge in tempo il sistema notifica tale

evento come “service unresponsive” e non come guasto. Quando un servizio su un

nodo viene considerato definitivamente inattivo si genera un evento chiamato

“NodeLostService”.

Se tutti i servizi associati ad una interfaccia sono inattivi allora anche l'inter-

faccia viene considerata inattiva e viene generato un evento chiamato

“InterfaceDown”. Analogamente se tutte le interfacce di un nodo vengono dichiara-

te inattive allora anche il nodo è considerato inattivo e l'evento corrispondente è

detto “NodeDown”. Se viene generato un “NodeDown” e il campo node-outage sta-

tus="on" allora tutti gli eventi di “InterfaceDown” e “NodeLostService” vengono

soppressi e viene visualizzato solo quello di “NodeDown”. In questo caso invece di

interrogare tutti i servizi che erano associati al nodo se ne interroga solo uno, il cri-

tical service che di default è ICMP. Quando tale servizio ritornerà attivo allora il

processo di polling riprenderà ad interrogare anche gli altri.

OpenNMS offre la possibilità di definire dei poller packages in modo da sta-

bilire dei livelli di servizio differenziati. Si può definire un poller package assegnan-

do un nominativo, i servizi che si vogliono monitorare e gli indirizzi IP dove tali

servizi verranno cercati a seconda dell'importanza che ognuno riveste all'interno di

tutta la rete. Per ogni servizio inoltre si possono impostare i parametri relativi al

polling infatti prendendo ad esempio il caso riguardante il servizio DNS:

OpenNMS

62

<service name="DNS" interval="300000"

user-defined="false" status="on">

<parameter key="retry" value="3"/>

<parameter key="timeout" value="5000"/>

<parameter key="port" value="53"/>

<parameter key="lookup" value="localhost"/>

</service>

Tale configurazione ha il seguente significato: il servizio DNS viene interrogato

ogni 5 minuti (interval=“300000”), tale servizio non è stato definito dall'utente

(user-defined=“false2) ed il polling per questo servizio è attivo (status=“on”).

3.4 OpenNMS SNMP

Finora sono stati descritti i processi di discovery e polling con cui il sistema di

Network Management interroga le risorse della rete alla ricerca di nodi e servizi

presenti; una volta che tali risorse sono state acquisite resta il problema di come ge-

stire le informazioni ad esse relative e stabilire quali dati sono di interesse strategico

per la gestione. Tali compiti sono delegati, come visto nel capitolo precedente, al

protocollo SNMP.

La configurazione delle operazioni SNMP con OpenNMS è possibile tramite

due file allocati nella directory /etc/opennms:

1. snmp-config.xml

2. datacollection-config.xml

Vedremo nei prossimi due paragrafi come effettuare le varie configurazioni.

OpenNMS

63

3.5.1 Snmp-config.xml

Snmp-config.xml stabilisce quali siano i contenuti dei parametri usati per dia-

logare con i vari agents SNMP presenti sulla rete:

<snmp-config retry="3" timeout="800"

read-community="public"

write-community="private">

<definition version="v2c">

<specific>192.168.0.1</specific>

</definition>

<definition retry="4" timeout="2000">

<range begin="192.168.1.1" end="192.168.1.254"/>

<range begin="192.168.3.1" end="192.168.3.254"/>

</definition>

<definition read-community="pippo"

write-community="paperino">

<range begin="192.168.2.1" end="192.168.2.254"/>

</definition>

<definition port="1161">

<specific>192.168.5.50</specific>

</definition>

</snmp-config>

OpenNMS

64

I vari campi hanno i seguenti significati:

• Retry: numero di tentativi che vengono effettuati per connettersi all'agent

SNMP.

• Timeout: il tempo, espresso in millisecondi, che OpenNMS aspetta per una

risposta da parte dell'agent.

• Read-community: la “read-community” di default.

• Write-community: la “write-community” di default; OpenNMS non prevede

la possibilità di effettuare operazioni di set.

• Version: versione di SNMP utilizzata.

• Port: porta di comunicazione.

Si ha la possibilità di personalizzare questi parametri per ogni specifico range

di indirizzi. Ad esempio per ogni sottorete si possono definire delle communities

differenti o addirittura modificare il numero di porta attraverso cui stabilire lo scam-

bio di informazioni. Tali soluzioni anche se non risolvono pienamente il problema

sicurezza, sicuramente scoraggiano eventuali attacchi e quindi possono essere con-

siderati dei buoni deterrenti.

OpenNMS

65

3.5.2 DataCollection-config.xml

Datacollection-config.xml rappresenta uno dei file più importanti di tutto il

sistema poiché stabilisce quanti e quali dati debbano essere acquisiti per ogni speci-

fica interfaccia. Esaminandolo in maniera dettagliata si trova:

<datacollection-config

rrdRepository = "/var/opennms/rrd/snmp/">

Il percorso rrdRepository indica dove vengono memorizzati i dati SNMP raccolti.

Per ogni risorsa di rete viene creata una specifica cartella, identificata dal numero

che OpenNMS assegna a ciascun nodo monitorato, all'interno della quale sono con-

tenuti i files .rrd relativi alle statistiche.

<snmp-collection name="default"

maxVarsPerPdu = "50"

snmpStorageFlag = "all">

Il campo maxVarsPerPdu pone un limite superiore al numero di variabili con-

tenute in un pacchetto di risposta ad una GetNextRequest (se si ha un agent lento si

può pensare di ridurre tale valore per non sovraccaricarlo). Il campo snmpStorage-

Flag può assumere due valori “all” o “primary” a seconda che si vogliano interroga-

re tutte le interfacce di un dato nodo oppure solo quella indicata come primaria.

Verranno ora analizzate le definizioni di “groups” e “systems”. I primi sono

costituiti da un insieme di OIDs che fanno riferimento ad un particolare gruppo di

statistiche, ad esempio riferendosi al group mib2-interfaces:

<group name = "mib2-interfaces" ifType = "all">

<mibObj oid=".1.3.6.1.2.1.2.2.1.10"

instance="ifIndex"

alias="ifInOctets"

type="counter"/>

OpenNMS

66

<mibObj oid=".1.3.6.1.2.1.2.2.1.13"

instance="ifIndex"

alias="ifInDiscards"

type="counter"/>

<mibObj oid=".1.3.6.1.2.1.2.2.1.14"

instance="ifIndex"

alias="ifInErrors"

type="counter"/>

<mibObj oid=".1.3.6.1.2.1.2.2.1.16"

instance="ifIndex"

alias="ifOutOctets"

type="counter"/>

<mibObj oid=".1.3.6.1.2.1.2.2.1.19"

instance="ifIndex"

alias="ifOutDiscards"

type="counter"/>

<mibObj oid=".1.3.6.1.2.1.2.2.1.20"

instance="ifIndex"

alias="ifOutErrors"

type="counter"/>

</group>

Ad ogni gruppo viene associato un nome e il tipo di interfaccia, stabilito nel campo

ifType, che si intende interrogare per ottenere le informazioni relative agli OIDs

riportati. I valori che può assumere ifType possono essere i seguenti:

• all: vengono interrogate tutte le interfacce.

• ignore: si usa quando l'informazione che si vuole ottenere riguarda una carat-

teristica generale del nodo ed è quindi indipendente dall'interfaccia.

OpenNMS

67

I “systems” invece riguardano gli agent SNMP che si trovano sui nodi da mo-

nitorare, ad esempio riferendosi all'agent Net-SNMP, che verrà illustrato in maniera

più approfondita nel seguito di questa tesi, si trova la seguente definizione:

<systemDef name = "Net-SNMP">

<sysoidMask>.1.3.6.1.4.1.2021.250.</sysoidMask>

<collect>

<includeGroup>mib2-interfaces-net-snmp

</includeGroup>

<includeGroup>mib2-host-resources-storage

</includeGroup>

<includeGroup>mib2-host-resources-system

</includeGroup>

<includeGroup>mib2-host-resources-memory

</includeGroup>

<includeGroup>ucd-loadavg

</includeGroup>

</collect>

</systemDef>

Il sysoidMask riguarda il system OID specifico per ogni agent. Come si nota vengo-

no inclusi tutti i gruppi che interessano ai fini del monitoraggio. E' importante sotto-

lineare la flessibilità che OpenNMS offre all'amministratore di rete in quanto si può

usare, previa opportuna configurazione, qualsiasi tipo di agent SNMP personaliz-

zando la raccolta delle statistiche secondo specifiche esigenze.

OpenNMS

68

Nelle figure sottostanti sono riportati alcuni grafici ottenibili con OpenNMS.

OpenNMS

69

Tali dati riguardano una macchina Linux equipaggiata con agent Net-SNMP e rap-

presentano una porzione delle informazioni che si possono raccogliere con O-

penNMS tramite le operazioni definite dal protocollo SNMP, in particolare:

• Bits In/Out: le statistiche di traffico di ingresso e uscita espresse in bit/sec.

• System Uptime: il periodo di tempo di accensione della macchina espresso in

numero di giorni e sue frazioni.

• Number of Processes: il numero di processi attivi.

• Load Average: le statistiche riguardanti i valori di traffico medio raccolti su

intervalli di 1, 5 e 15 minuti rispettivamente.

• CPU Use: l' utilizzo della CPU.

Figura 3.4 Snapshots di alcuni grafici di OpenNMS

OpenNMS

70

3.5 Architettura

Per concludere la nostra panoramica su OpenNMS, mostriamo nella figura

sottostante uno schema che rappresenta l’architettura di questo software.

Figura 3.5 Architettura di OpenNMS

OpenNMS

71

3.5 Altre funzioni

OpenNMS è configurabile attraverso la sezione admin per l'invio di notifica

tramite posta elettronica quando si verifica un malfunzionamento di grave entità. E’

possibile integrare il servizio di e-mail [21], inviate direttamente da OpenNMS, con

un servizio di SMS fornito da un operatore mobile o implementato con degli stru-

menti ad hoc sfruttando ad esempio un SMS Gateway; in questo modo si ottiene

uno strumento potente e vantaggioso che consente all'amministratore di rete di esse-

re sicuro del funzionamento della stessa in qualsiasi momento, anche quando il si-

stema lavora autonomamente senza la presenza di un operatore umano.

Oltre alla notifica dei guasti, tramite posta elettronica, è possibile inviare dei

rapporti periodici riguardanti il funzionamento generale dei servizi monitorati in

formato pdf con la possibilità di evidenziare i nodi e i servizi meno performanti.

OpenNMS consente all'amministratore di estendere l'accesso al sistema di ge-

stione ad altri utenti ( gestione dell'accounting ), assegnando ad ognuno specifici

privilegi.

Considerato che il sistema di gestione lavora con le prime due versioni del

protocollo SNMP c'è da tenere in conto il problema non banale riguardante la sicu-

rezza. La trasmissione in chiaro del community name consente a qualsiasi utente

non autorizzato di introdursi nel sistema e avere accesso alle informazioni di gestio-

ne. Un metodo per risolvere tale inconveniente può essere quello di integrare O-

penNMS con un sistema di anti-intrusione come può essere il pacchetto Snort che

ad esempio generi, in caso di allarme, un messaggio di trap ad-hoc destinato alla

stazione di gestione.

OpenNMS

72

Considerazioni finali L’obiettivo di questa tesi è la creazione di un piccolo manuale che introduca il

lettore alle basi del protocollo SNMP. Questo protocollo durante il percorso della

tesi ha svelato tutte le sue potenzialità ed i motivi per cui è il protocollo più diffuso

per la gestione di rete, infatti nei primi capitoli si parla diffusamente del perchè que-

sto protocollo si sia affermato vincendo la concorrenza di altri tool di gestione di

rete.

Le basi teoriche che lo supportano sono molto solide e il fatto che si utilizzi

ancora la prima versione (sebbene abbia diverse lacune) dopo sedici anni dalla sua

nascita è sinonimo di una buona progettazione. La definizione di nuove funzioni

utilizza un linguaggio dichiarativo (ASN.1) poco chiaro e soprattutto usato in po-

chissime applicazioni, ma questa problematica rimane confinata al mondo degli svi-

luppatori, mentre per gli utenti questo fatto non ha nessuna rilevanza. In realtà

quando si parla di estendibilità di SNMP si fa riferimento più che altro ai program-

mi Manager, che possono essere facilmente migliorati con nuove funzioni, mentre

gli agenti forniti sui dispositivi generalmente non permettono modifiche al software

interno.

Il software esaminato, OpenNMS, funziona solo su sistemi Linux e si è rivela-

to uno strumento molto potente di monitoraggio di rete, infatti oltre ad avere molte

funzioni mirate per il protocollo SNMP, dispone di ottime funzionalità di monito-

raggio. La rielaborazione di dati è molto accurata ed è facile ottenere informazioni e

grafici in merito al lavoro svolto dalla rete. Inoltre è anche possibile effettuare delle

modifiche di configurazione ai dispositivi da una postazione remota, in modo da

assecondare i cambiamenti continui della morfologia della rete. Nella prima parte

del terzo capitolo si trova anche una spiegazione dettagliata del software necessario

per installare OpenNMS, poiché la sua esecuzione necessita di diversi tool.

Unico neo del protocollo è la sicurezza, questo argomento è trattato marginal-

mente nella tesi in quanto viene affrontato in maniera approfondita solo nella terza

versione del protocollo che ancora oggi stenta a decollare e non viene supportata da

quasi nessun dispositivo.

Considerazioni finali

73

Bibliografia

[1] RFC 789

[2] J. F. Kurose, K.W. Ross “Internet e Reti di Calcolatori”, Seconda Ed., 2003

[3] http://www.iso.org

[4] RFC 2570

[5] T. Saydam, T. Magedanz “From Networks and Network Management into

Service and Service Management”, Journal of Network and System Management,

1996

[6] RFC 2788 - Network Services Monitoring MIB

[7] www.ietf.org

[8] RFC 1155, RFC 1156, RFC 1157

[9] RFC 1450, RFC 1451, RFC 1452

[10] RFC 2571, RFC 2572, RFC 2573, RFC 2574

[11] RFC 768

[12] “ACE-SNMP, an introductory overview on SNMP”, http://www.ddri.com.

[13] RFC 1098

[14] “SNMP Devoloper’s Guide – HP OpenView Integration Series”, Cap. 2 “An

Overview on SNMP”

[15] RFC 3727

[16] http://www.opennms.org

[17] http://www.sun.com

[18] http://jakarta.apache.org/tomcat/

[19] http://people.ee.ethz.ch/~oetiker/webtools/rrdtool/

[20] http://www.postgresql.org/

[21] http://etd.adm.unipi.it/theses/available/etd-4062005-143133/unrestricted/

Capitolo3.pdf

[22] RFC 3139

[23] RFC 1213

Bibliografia

74

Elenco delle figure

Figura 1.1 Schema di rete

Figura 2.1 Implementazione Client/Server


Figura 2.3 Livello di scambio dei messaggi SNMP

Figura 2.4 Struttura Pacchetto SNMP


Figura 2.6 Incapsulamento dei messaggi

Figura 2.7 Traduzione di un valore in dot-notation

Figura 2.8 Albero MIB – Root and Subtree

Figura 2.9 Albero MIB – Leaf

Figura 3.1 Schermata principale di OpenNMS

Figura 3.2 Nodo Linux

Figura 3.3 Schermata Admin

Figura 3.4 Snapshots di alcuni grafici di OpenNMS

Figura 3.5 Architettura di OpenNMS

Elenco delle figure

Network monitoring tramite snmp

Documents

Transcript of Network monitoring tramite snmp