Università degli Studi di Padova
Facoltà di Scienze Matematiche, Fisiche e Naturali
Corso di Laurea in Informatica
RELAZIONE FINALE
Monitoraggio e gestione dell'infrastruttura di rete di un ISP
mediante il protocollo SNMP e tecnologie Open Source
Padova, Novembre 2009
Contenuti
Introduzione 5.................................................................................................................WebEthical s.r.l. 6
..................................................................................................Organizzazione aziendale 7..................................................................................................................................Tutor 8
...........................................................................................................................Il progetto 8........................................................................Descrizione delle componenti del progetto 9
Network Management 12................................................................................................................Gestione di rete 13
....................................................................................................................Modello ISO 13.........................................................................................................Infrastrutture di rete 15.........................................................................................................Il protocollo SNMP 16
.....................................................................................................Le componenti di base 17..........................................................................................................ANS.1, SMI e BER 19
....................................................................................................Il formato dei messaggi 21................................................................................................Evoluzione del protocollo 22
.......................................................................................Management Information Base 24
Lo stage 27.............................................................................................................Obiettivi originali 28
....................................................................Suddivisione temporale in fasi preventivata 28...........................................................................................................Analisi dei requisiti 29
..............................................................................................Studio delle problematiche 30............................................Verifica su analisi dei requisiti e studio delle problematiche 33
.................................................................................................Installazione del software 35...........................................................................................................Requisiti hardware 35
.............................................................................................................Requisiti software 36..............................................................................................Installazione e primo avvio 38
..................................................................................Configurazione delle impostazioni 39.........................................................................................................................Discovery 39
......................................................................................................................Capabilities 41..............................................................................................................................Polling 44
.................................................................................................................Data collection 45.......................................................................Configurazione per la rete di WebEthical 51
.............................................................Verifica dell’installazione e della configurazione 52...............................................................Impostazione delle notifiche e dell’accesso web 52
.........................................................................................Stesura della documentazione 54
Valutazioni finali 55...........................................................................................Valutazione del lavoro svolto 56
.............................................................................................Nuove conoscenze acquisite 57
Bibliografia 59
4
1. Introduzione
In questo primo capitolo sarà presentata l’azienda ospitante l’attività di stage, argomen-
to centrale di questa relazione; ne saranno descritti gli ambiti lavorativi, la realtà aziendale e le
figure di riferimento assegnatemi.
Alea Iacta Est
Gaio Giulio Cesare, 49 a.C.
con scarsa modestia, il motto scelto da Essentia dopo la scissione da Eutelia
1
1.1. WebEthical s.r.l.
L’azienda WebEthical è una società a responsabilità limitata con sede legale in contrà
Mure di San Rocco, 19 a Vicenza; lavori di ristrutturazione hanno obbligato il trasferimento
temporaneo degli uffici in via Meucci, 68 ad Arcugnano (VI), ed è lì che lo stage è stato svolto.
WebEthical è un WISP, proprietario di una rete wireless che copre dal proprio nodo
principale di distribuzione la città di Padova e con dei rilanci punto-punto i comuni di Villa-
franca Padovana ed Abano Terme; si occupa principalmente di fornire connessione Internet
via Hiperlan alle aziende operanti in quelle aree dove ancora manchi la copertura ADSL o,
fenomeno in aumento nell’ultimo periodo, che semplicemente preferiscano una connessione
di questo tipo anche come alternativa in caso di necessità.
La scelta di seguire quasi esclusivamente aziende piuttosto che privati è motivata dal
proposito di offrire un servizio qualitativamente elevato, dovendo perciò scegliere di portare i
propri servizi ad un insieme limitato di esigente clientela.
In particolare, la ditta è in grado di offrire servizi di:
• Project Management di soluzioni INTRANET/EXTRANET avanzateLe aziende che si appoggiano a WebEthical per la realizzazione e la gestione del pro-prio sistema informatico possono contare anche sulla progettazione della rete azienda-le, sia essa solamente locale o condivisa tra più sedi dislocate su territorio più o meno ampio;
• Soluzione di connettività wireless privata e pubblicaL’attività principale di WebEthical, in quanto WISP, è fornire connettività ad Internet tramite collegamento wireless; tale servizio è rivolto sia ad aziende private che ad enti pubblici;
• Gestione delle informazioni tramite soluzioni web/Internet based
• Amministrazione ed installazione di S.O. su piattaforme Microsoft e LinuxUn altro aspetto della gestione del sistema informatico delle aziende che si avvalgono di WebEthical consiste nell’installazione presso le stesse dei sistemi operativi che esse preferiscono e/o meglio si adattano alle loro necessità;
• Sistemistica e configurazioni reti aziendaliOltre alla progettazione e alla realizzazione delle reti (aspetto puramente telecomuni-cativo), WebEthical provvede anche alla configurazione delle stesse tenendo in consi-derazione gli aspetti di sicurezza che risultano essere molto importanti visto il target cui questa ditta si rivolge;
• Realizzazione software stand-alone su commissione
6
Su richiesta WebEthical realizza anche applicazioni “su misura” alle aziende;
• Connettività e fonia, tradizionale e VOIPData l’esperienza maturata in ambito di servizi di rete e dato l’intento di essere l’unico punto di riferimento in ambito tecnologico per i propri clienti, WebEthical si è specia-lizzata anche nel fornire servizi di fonia, tradizionali e VOIP, questi ultimi in partico-lare sempre più richiesti dalle aziende;
• Adeguamento alla normativa sulla privacy (Redazione DPS e Misure Minime)WebEthical si offre inoltre di portare i propri clienti in linea con le ultime norme vi-genti in materia di salvaguardia della privacy.
Grazie a una fitta rete di collaboratori possono avvalersi inoltre delle seguenti specializzazioni:
• Web design e Immagine CoordinataCreazione di siti web professionali graficamente curati e loro indicizzazione sui più popolari motori di ricerca;
• Costruzione di siti web, programmazione .aspCreazione di siti dinamici e applicazioni web
• Videosorveglianza, passiva e attivaNecessità aziendale molto sentita è quella di monitorare l’ambiente lavorativo tramite telecamere; rendere tale sistema gestibile via web è una comodità apprezzata da molte aziende;
• Streaming audio-video
• Teleconferenza
1.2. Organizzazione aziendale
Nel periodo passato presso l’azienda ho potuto verificare quali fossero le principali attivi-
tà aziendali e come esse fossero gestite: per la maggior parte il tempo lavorativo viene impiega-
to su due fronti, uno tecnologico-informatico e uno commerciale.
Per quanto riguarda la parte tecnica essa è rivolta primariamente a fornire assistenza ai
propri clienti, sia dando informazioni al telefono che procedendo a opere di gestione, queste
ultime concentrate sul controllo remoto per risolvere i disguidi minori o per accertare la neces-
sità di un intervento in loco. Altra attività importante e molto presente è rappresentata dallo
studio di nuove soluzioni tecnologiche da offrire alle ditte potenziali clienti.
La realizzazione di ogni progetto di entità significativa vede una riunione iniziale tra tut-
to il personale che sarà coinvolto, in modo da studiarne complessità e prevedere il più accura-
7
tamente possibile quanti e quali risorse esso richieda. Dopodiché si passa alla suddivisione del
progetto in parti il più possibile indipendenti l’una dall’altra che vengono poi ripartite tra i
presenti. Questo modo di procedere riduce al minimo la necessità di interazione tra le varie
persone coinvolte, e questo risulta molto importante visto che l’impegno di ogni persona non è
solitamente rivolto ad un progetto unico alla volta ma a più progetti in contemporanea.
1.3. Tutor
WebEthical ha predisposto due supervisori per aiutarmi nelle fasi iniziali di ambienta-
mento e in quelle più frequenti di difficoltà, dall’inserimento di una password alla vera e pro-
pria necessità di una mano esperta: Eugenio Castellani e Pierfrancesco Marsiaj.
Il primo è un collaboratore interno, nonché titolare effettivo dell’azienda, il secondo un
consulente esterno. In particolare Eugenio Castellani mi ha fornito le informazioni necessarie
ad individuare i requisiti del progetto, descrivendomi la struttura della rete aziendale e la
configurazione degli apparati wireless utilizzati.
Pierfrancesco Marsiaj invece mi ha aiutato principalmente ad approfondire la conoscen-
za di alcuni comandi del sistema operativo linux e ad apprendere appieno la configurazione
della rete aziendale.
1.4. Il progetto
L’obiettivo principale del progetto originale vedeva la creazione di una suite che permet-
ta di integrare parzialmente o totalmente gli applicativi:
OpenRadius
The Dude
Zenoss
Radio Mobile
al fine di agevolare la gestione, la manutenzione ed il monitoraggio degli apparati radio e di
rete dell’infrastruttura operativa aziendale.
Il progetto prevedeva inoltre la creazione ex-novo di un modulo di gestione remota spe-
cifico per gli apparati radio Wifless di Essentia, uno dei leader del mercato italiano. Questi
8
applicativi avrebbero dovuto trovare un’integrazione tale da offrire, dove possibile, un comune
front-end di accesso e/o condividere le informazioni relative all’architettura.
Posizione, tipologia di apparato, configurazione, anagrafica: sono tutte informazioni che
sarebbe utile mettere a disposizione di ogni applicativo.
Il progetto risulta essere molto ampio e diversificato e richiede conoscenze non solo in-
formatiche ma anche fondamenti di telecomunicazioni, per questo è stato suddiviso in 4 sot-
to-progetti: l’azienda ha previsto di impiegare due stagisti che si occupassero di due dei sot-
to-progetti che andranno a comporre il progetto illustrato; le parti mancanti al completamen-
to dell’opera saranno implementate da personale aziendale.
Vediamo quali sono i sotto-progetti appena menzionati.
1. Sviluppare, integrando componenti OpenSource esistenti, un sistema che permetta
di verificare visivamente su mappe geografiche la copertura teorica di un apparato
radio di data potenza e di visualizzarne i coni di copertura.
2. Predisporre un sistema di autenticazione distribuita per gli apparati radio dei clienti
3. Installare e configurare un sistema di monitoraggio remoto dei parametri operativi
degli apparati di rete
4. Creazione ex novo di un modulo di gestione remota specifico per gli apparati radio
Wifless di Essentia, uno dei leader del mercato italiano.
1.5. Descrizione delle componenti del progetto
Verifica copertura radio
Essendo WebEthical un Wireless Internet Service Provider, risulta fondamentale sapere
se una determinata area di territorio sia coperta del segnale radio degli apparati di cui è pro-
prietaria: in caso contrario sarà infatti impossibile portare connessione ad una ditta avente se-
de in quell’area.
Per verificare la copertura del segnale è necessario recarsi in loco e testare la qualità di
ricezione e il livello di rumore. Questa operazione risulta essere scomoda e dispendiosa in
termini tempo, e in alcuni casi porta solo a constatare che il segnale non sarebbe mai potuto
arrivare a causa di ostacoli importanti quali colline, palazzi o semplicemente alberi.
9
Per risparmiare tempo prima di passare al test sul luogo si procede ad un controllo su
carta geografica della presenza di ostacoli naturali insormontabili, attività comunque laborio-
sa da fare a mano: è importante automatizzare il tutto con un software che, date le coordinate
geografiche e le caratteristiche degli apparati, mostri quali aree possano essere raggiunte e
quali no, salvo ovviamente altri ostacoli di tipo artificiale.
A questo scopo è utilizzabile il software RadioMobile.
Sistema di autenticazione
Offrire connettività ad aziende tramite wireless comporta serie problematiche di sicu-
rezza data la facilità di intercettazione del segnale: chiunque fosse dotato di un dispositivo ca-
pace di captare onde a 5,4 GHz potrebbe infatti accedere senza fatica al traffico generato da
ogni azienda della cui antenna potesse avere visibilità fisica - un requisito certamente triviale.
Per ovviare a questo problema il traffico deve essere cifrato.
Altra necessità aziendale è poter autenticare ogni utente in modo tale da offrire deter-
minati servizi solamente ad alcuni utenti discriminandone altri e offrire inoltre una quantità di
banda diversificata alle varie utenze senza dover istruire ogni punto di accesso a tale proposito.
Tali problematiche sono risolvibili configurando un server Radius e implementando
quindi quanto descritto dal protocollo WPA2-Enterprise.
Monitoraggio remoto degli apparati
Il crescente numero di installazioni di dispositivi di rete e la crescente estensione del-
l’area in cui l’azienda offre i propri servizi hanno portato il titolare a sentire la necessità di
monitorare il comportamento dei vari dispositivi in modo centralizzato. Il desiderio è quello di
avere un software che permetta di controllare a distanza il funzionamento dei vari dispositivi,
siano essi router, firewall, access point o server.
Tramite tale software si dovrebbe poter verificare lo stato della generica apparecchiatu-
ra, nonché ricevere informazioni sulla sua tipologia, sul sistema operativo su di essa installato e
sulle sue condizioni di funzionamento.
È importante inoltre poter visualizzare graficamente il carico di rete sulla base dei vari
tipi di traffico, in modo tale da poter capire ad esempio se sia sovraccaricata dall’uso di un de-
terminato applicativo.
10
Modulo per la gestione remota degli apparati Wifless
Gli apparati Wifless di Essentia che WebEthical ha scelto di utilizzare possiedono delle
caratteristiche particolari che li rendono per alcuni aspetti superiori rispetto agli apparati delle
aziende concorrenti; il front-end web per la gestione degli apparati non è purtroppo tra que-
ste, rendendo necessaria la delega di diversi aspetti gestionali avanzati alla configurazione via
ssh da console.
L’azienda ha espresso il desiderio di creare un nuovo front-end, o di estendere quello
esistente, in modo tale da poter usufruire di tutte le funzioni disponibili anche tramite inter-
faccia grafica.
11
2. Network Management
Il concetto di gestione di rete assume diversi significati per diverse persone. A volte indica
un tecnico che, solitario, controlla l’attività di una piccola rete attraverso qualche semplice
quanto datato programma. In altri casi la gestione della rete prevede vasti database, anche di-
stribuiti, popolati con dati raccolti dall’infrastruttura in maniera automatica, analizzati da
macchine dedicate e sufficientemente potenti da generare grafici della topologia e del traffico
in tempo reale. In generale, la gestione di rete è un servizio che utilizza svariati strumenti, ap-
plicazioni e apparati per aiutare il responsabile della rete nelle attività di monitoraggio e ma-
nutenzione della stessa.
Management is manifest in a number of ways. Man-agement is related to activities which control or monitor the use of resources. Within Open Systems the resources can be those which provide data storage or processing capabilities, or they can be those which provide intercon-nection capabilities. It is only the latter and the commu-nications concerning their management which fall within the scope of OSI Management standardization.
Human beings are ultimately responsible for managing the OSI Environment, although responsibilities may be delegated to automated processes.
International Standard ISO/IEC 7498-4, 1989Open Systems Interconnection
Basic Reference ModelManagement framework
Introduction 1
2.1. Gestione di rete
I primi anni ’80 furono teatro di un’enorme espansione nell’area delle infrastrutture di
rete. Le imprese seppero riconoscere i vantaggi in termini di riduzione delle spese e aumento
di produzione, ed introdussero ed espansero le reti aziendali praticamente alla stessa velocità
cui nuove tecnologie venivano rese disponibili. Nel giro di pochi anni diventarono frequenti
anche le difficoltà conseguenti all’adozione di un gran numero di diverse (e, a volte, incompa-
tibili) tecnologie.
I problemi conseguenti alla frenetica espansione di infrastrutture considerate sempre più
importanti colpirono sia lo svolgimento delle normali operazioni di manutenzione della rete
che la progettazione delle sue espansioni; ogni nuova tecnologia introdotta richiedeva un ap-
posito team di esperti. Le sole necessità di organico per gestire i vasti ed eterogenei sistemi che
erano stati assemblati furono sufficienti a mandare in crisi intere aziende. Si presentò un biso-
gno urgente di tecnologie standard che potessero essere utilizzate attraverso l’intera infrastrut-
tura per gestire la rete e il suo utilizzo (compresa la pianificazione delle espansioni) in maniera
automatizzata.
Il concetto di “gestione della rete” comprende, in questo caso, lo sviluppo, l’integrazione
e il coordinamento di hardware, software e personale umano per il monitoraggio, il test, l’in-
terrogazione, la configurazione, l’analisi, la valutazione ed il controllo della rete e delle sue ri-
sorse così da permetterne il corretto funzionamento a costi ragionevoli.
2.2. Modello ISO
L’Organizzazione Internazionale per gli Standard (ISO) ha inserito la gestione di rete
all’interno della sua iniziativa volta a definire un modello per l’Interconnessione di Sistemi
Aperti (OSI), con lo scopo di riuscire a gestire oggetti che rappresentino i sette strati del mo-
dello di riferimento e i servizi di comunicazione forniti dalle reti basate su tale famiglia di pro-
tocolli.
Il documento ISO/IEC 7498-4, datato 15/11/1989, definisce rigorosamente il frame-
work per coordinare lo sviluppo di standard presenti e futuri per la gestione di sistemi aperti
interconnessi (OSI Management); il suo scopo non è specificare servizi e protocolli necessari né
presentare specifiche di implementazione né essere un riferimento per determinarne la corret-
13
tezza, piuttosto si impegna a definire la terminologia, i concetti e le attività che la gestione di
un sistema richiede.
Viene definito l’ambiente di gestione OSI (OSI Management environment) come il sottoinsieme
degli ambienti OSI concernente strumenti e servizi necessari a monitorare, controllare e co-
ordinare le attività di “interconnessione”; prevede sia la possibilità per i manager di di racco-
gliere informazioni ed esercitare il controllo, sia le funzionalità necessarie a mantenere una
conoscenza aggiornata dello stato delle risorse e report aggiornati sul loro utilizzo.
Gli oggetti gestiti vengono definiti come “la visione di una risorsa dell’ambiente soggetta a
gestione, come una connessione o un elemento fisico necessario ad una comunicazione; si trat-
ta quindi della visione astratta di una risorsa rappresentante le sue proprietà nell’ottica (e con
lo scopo) della sua gestione. Un oggetto è definito in termini dei suoi attributi, delle operazioni
supportate, delle notifiche che potrebbe emettere e delle relazioni con altri managed objects.
Il set degli oggetti gestiti entro un sistema, insieme ai loro attributi, costituisce l’insieme del-
le informazioni di gestione di quel sistema (Management Information Base - MIB).”
La gestione OSI è necessaria per diversi scopi, opportunamente catalogati dall’ente in
cinque aree funzionali:
• gestione degli errori e dei guasti: ha lo scopo di rilevare, isolare, registrare, notificare e ri-
spondere a le condizioni di guasto della rete; questi eventi impediscono al sistema di soddi-
sfare gli obiettivi previsti, e possono essere temporanei o persistenti; una volta identificato,
isolato e risolto il problema, la soluzione viene testata ed estesa su tutti i sottosistemi; la rile-
vazione e la sua risoluzione vengono infine registrate.
• gestione della configurazione: permette al responsabile di rete di configurare hardware e
software dei dispositivi appartenenti alla rete, e in particolare registra ogni modifica alle in-
formazioni di configurazione; quest’area ha particolare importanza poiché spesso si verifica-
no problemi di rete in seguito a modifiche ai file di configurazione, e indizi importanti per la
loro risoluzione sono facilmente rintracciabili in un apposito database.
• gestione delle prestazioni: risponde alle necessità di quantificare, misurare, stendere rap-
porti, analizzare e controllare le prestazioni di differenti componenti di rete, che possono
essere sia dispositivi come router e host, sia astrazioni come un percorso attraverso la rete;
garantisce prestazioni almeno accettabili a fronte del variare delle richieste di traffico; esem-
14
pi delle variabili tenute in considerazione sono la capacità di banda utilizzata (throughput), il
tempo di risposta degli utenti e l’utilizzo della linea.
La gestione delle prestazioni è composta da tre stadi: la prima fase prevede la raccolta
di dati riguardanti le variabili di interesse per l’amministrazione di rete; dopo un periodo
ritenuto sufficiente di normale utilizzo delle risorse, si procede con l’analisi dei dati accumu-
lati per determinare i valori entro cui le variabili potranno spaziare mantenendo le presta-
zioni a livelli accettabili; vengono infine definite le azioni da intraprendere nel caso di supe-
ramento del livello di attenzione da parte dei valori tenuti in considerazione.
• gestione della contabilità: permette al responsabile di rete di specificare, registrare e con-
trollare l’accesso degli utenti e dei dispositivi alle risorse di rete; quote di utilizzo, addebiti
basati sull’uso e privilegi degli accessi alle risorse rientrano nella gestione della contabilità;
quest’area rende massima l’equità di accesso alle risorse tra i diversi utenti, conseguente-
mente minimizzando la possibilità di problemi dovuti a congestioni del traffico; come nel
campo della gestione delle prestazioni, così la gestione delle quote di accesso si basa su
un’analisi preliminare degli utilizzi delle risorse e sull’introduzione di regole basate su queste
osservazioni.
• gestione della sicurezza: controlla gli accessi alle risorse di rete in accordo con politiche
ben definite in modo che la rete non possa subire attacchi (intenzionali o meno) e che le in-
formazioni riservate siano accessibili solo al personale autorizzato; le autorità di certificazio-
ne (CA) e i dispositivi come i firewall ne fanno parte.
Tali settori riassumono le principali attività in cui si esplicano le funzionalità di Network
Management, e sono ovviamente utilizzabili per descrivere le attività di gestione di rete anche
se questa viene effettuata utilizzando per il colloquio tra stazione di gestione ed elementi di
rete protocolli non OSI; quest’ultimo è anzi il caso più frequente, ed oggi il Network Mana-
gement è usualmente basato su meccanismi proprietari o, sempre più frequentemente, sul pro-
tocollo di gestione SNMP, definito nell’ambito della famiglia di protocolli TCP/IP.
2.3. Infrastrutture di rete
La maggior parte delle architetture per la gestione di rete si basano sulla stessa struttura
e sulle stesse relazioni tra gli elementi: le unità gestite (managed), quali computer, terminali o
15
più genericamente unità componenti l’infrastruttura, eseguono costantemente uno o più pro-
cessi che permettono loro di inviare notifiche nel caso rilevassero problemi (non solamente
guasti ma anche, ad esempio, il superamento del livello di attenzione per alcuni parametri im-
postati dall’utente). In seguito alla ricezione di questi avvisi, le entità di gestione (managing entiti-
es) sono programmate per reagire eseguendo una o più azioni, e.g. notificare un operatore (an-
che al cellulare), registrare l’evento, arrestare il sistema, tentare una risoluzione automatica.
Le entità di gestione possono anche interrogare gli agenti residenti nelle stazioni gestite,
in maniera automatica o su precisa richiesta di un utente, per controllare il valore di determi-
nate variabili; gli agenti sono moduli software che inizialmente compilano le informazioni re-
lative ai dispositivi in cui risiedono, successivamente salvano questi dati in un apposito databa-
se e infine li inviano (in maniera proattiva o reattiva) alle entità di gestione entro i sistemi di ge-
stione di rete (NMSs) tramite un protocollo per la gestione di rete.
2.4. Il protocollo SNMP
Già agli albori delle connessioni tra computer, i progettisti di rete ipotizzavano un mon-
do in cui ogni apparecchiatura elettrica, dall’home theatre al tostapane passando per frigorife-
ro e lavatrice, fosse connessa alla stessa rete e in grado di inviare e ricevere informazioni ri-
16
guardanti il proprio funzionamento in un formato comune, facilitando le operazioni di gestio-
ne remota; senza scostarsi molto dalla futuristica idea, venne sviluppata una tecnologia in gra-
do di gestire qualsiasi apparecchio connesso alla rete senza grandi sforzi, uno standard per
rendere disponibili a chi di dovere le variabili ritenute di interesse e per il formato dei messag-
gi da inviare e ricevere. Il Simple Network Management Protocol (Protocollo Semplice per la Gestione di
Rete, SNMP) è un protocollo operante a livello applicazione che facilita lo scambio di informa-
zioni di gestione tra le apparecchiature di rete rendendo possibile un controllo centralizzato
dell’infrastruttura; fa parte della suite di protocolli TCP/IP (Transmission Control Protocol/
Internet Protocol) definita dalla Internet Engineering Task Force (IETF), e permette all’am-
ministratore della rete di gestirne la performance, di individuarne e risolverne i problemi e di
pianificarne l’estensione.
2.4.1. Le componenti di base
Una rete gestita attraverso SNMP è formata, ad alto livello, da tre componenti
fondamentali: i dispositivi da gestire (managed devices), gli agenti e agenti proxy, e il sistema di
gestione di rete (NMS).
• i dispositivi da gestire sono nodi della rete contenenti un agente SNMP; raccolgo-
no ed eventualmente immagazzinano le informazioni da rendere disponibili ai NMS.
Può essere un host, un router o un hub, uno switch o un bridge, un server o una
stampate;
• gli agenti sono dei moduli software che risiedono all’interno dei dispositivi da
gestire o, nel caso di agenti proxy (che agiscono cioè per conto di altri) all’interno di
dispositivi a loro connessi; il loro compito è di controllare le informazioni necessarie
alla gestione dell’apparato ed essere in grado di inviarle ai NMS in un formato com-
patibile;
• i sistemi di gestione di rete eseguono le applicazioni per monitorare e controllare le
unità da gestire; i NMS non sono solitamente macchine dotate di grande potenza di
calcolo, ma hanno a disposizione risorse proporzionate e comunque sufficienti alla
dimensione della rete da controllare.
17
I messaggi vengono scambiati attraverso quattro basilari comandi: read, write,
trap, e istruzioni per la navigazione (traversal operations).
• il comando read è usato dal NMS per monitorare lo stato dei dispositivi, ri-
chiedendo lo stato delle variabili rese disponibili dall’agente;
• il comando write è usato dal NMS per controllare lo stato dei dispositivi mo-
dificando il valore delle variabili all’interno del dispositivo;
• trap è usato dai dispositivi da gestire per comunicare al NMS, in maniera
asincrona, l’occorrenza di eventi di particolare rilevanza;
• le istruzioni per la navigazione sono utilizzate dal NMS per determinare
quali siano le variabili supportate da un dispositivo e per estrapolare dati in maniera
sequenziale da quelle organizzate logicamente in forma tabulare, come ad esempio
le tabelle di routing.
SNMP ha un’implementazione di tipo client/server, in cui l’applicazione client è
costituita dal sistema di gestione di rete che per svolgere le sue funzioni interroga le
applicazioni server costituite dagli agenti; il database gestito da questi ultimi è chiama-
to Management Information Base (MIB), un insieme di informazioni per la gestione del-
l’apparecchio organizzato gerarchicamente composto da oggetti (managed objects) ognuno
dei quali identificato da un object identifier (OID) univoco. SNMP prevede la possibilità di
estendere questo insieme con informazioni specifiche in base alle necessità di un agen-
te o di un utente attraverso l’aggiunta di nuovi MIB, elementi analizzati in seguito.
Tutti gli apparecchi comunicanti via SNMP devono comprenderne appieno i
messaggi, il che pone qualche problema. Il primo si presenta in quanto diversi lin-
guaggi di programmazione utilizzano diversi insiemi di tipi di dato (interi, stringhe,
caratteri, byte...): per fare un esempio, un agente che comunicasse lo stato di un dispo-
sitivo con tipi di dato Java potrebbe non essere compreso da un manager SNMP scritto
in C. Per risolvere il problema SNMP utilizza la Notazione Astratta per la Sintassi uno
(ASN.1) per definire i tipi di dato utilizzati nella costruzione di un messaggio; essendo
ASN.1 indipendente dai linguaggi di programmazione, gli agenti e i manager SNMP
possono essere scritti in qualsiasi linguaggio per qualsiasi piattaforma. Nonostante l’uso
coerente di una notazione comune per i tipi dei dati scambiati, esiste un altro ostacolo
18
allo scambio di informazioni: come dovranno essere codificate? Ad esempio, la fine di
una stringa sarà identificata da un carattere null o in altro modo? Un valore booleano
sarà rappresentato con un byte (come in C++) o con due (come in Visual Basic)?
ASN.1 include delle specifiche anche per la codifica dell’informazione e, per mantene-
re coerenza con la S di Simple, il set di regole utilizzato è il BER (Basic Encoding Rules).
2.4.2. ANS.1, SMI e BER
L’ASN.1 è una notazione astratta per la sintassi del trasferimento dati, su una
rete, tramite messaggi. Descrive le strutture dati necessarie a rappresentazione, codifi-
ca, trasmissione e decodifica dell’informazione; fornisce un insieme di regole formali
per definire la struttura di oggetti che siano indipendenti dall’architettura delle mac-
chine in cui vengono creati e che impediscano le ambiguità.
Un sottoinsieme modificato di ASN.1, detto Struttura delle Informazioni per la Gestio-
ne (Structure of Management Information, SMI), è definito all’interno di SNMP per descrive-
re insiemi coerenti di oggetti MIB; questi insiemi sono chiamati moduli MIB.
La SMI descritta entro la prima versione di SNMP definisce l’uso di alcuni tipi
di dato direttamente derivati da ASN.1 e di altri introdotti appositamente per il proto-
collo; è innanzitutto definito il sottoinsieme di tipi di dato di ASN.1 richiesto, nello
specifico:
• nome, che funge da Identificativo Oggetto;
• sintassi, per definire il tipo di dato dell’oggetto, ad esempio Integer o String;
• encoding, per descrivere come l’informazione associata all’oggetto da gestire sia
formattata per la trasmissione attraverso la rete.
I tipi di dato specifici della SMI si possono dividere in due categorie: semplici e
specifici dell’applicazione; quelli di tipo semplice hanno tutti valori univoci e possono esse-
re
• interi, con segno e nell’intervallo [-231 .. 231-1];
• stringhe di ottetti, in sequenze ordinate di 0 .. 65535 ottetti;
19
• ID oggetto, proveniente dall’insieme di identificativi istanziati secondo le regole
di specificate da ASN.1; gli object identifiers svolgono un ruolo chiave all’interno di ogni
messaggio SNMP, perché un campo di questo tipo contiene l’OID usato dall’agente
per identificare univocamente un parametro.
I tipi di dato specifici dell’applicazione definiti dalla SMI sono
• indirizzi di rete, rappresentanti indirizzi di un particolare protocollo; SMIv1 suppor-
ta solo indirizzi IPv4 in 32 bit, con un tipo specifico, mentre SMIv2 utilizza più generi-
camente stringhe di ottetti, quindi anche retrocompatibili;
• contatori, interi non negativi che incrementano fino ad un valore massimo (la
dimensione definita nella prima versione è di 32 bit) prima di ricominciare da 0;
• indicatori (gauges), interi non negativi che possono aumentare o diminuire entro
dei valori di minimo e massimo specificati; sono utili per identificare un punto in
funzione del tempo, e.g. l’utilizzo del processore, piuttosto che dati monotonicamente
crescenti come potrebbero essere le richieste di connessione;
• ticchettii (time ticks): rappresentano, in centesimi di secondo, il tempo a partire da
un evento;
• opachi (opaques): rappresentano una codifica arbitraria utilizzata per poter invia-
re informazioni in stringhe non conformi ad alcun tipo di dato;
• interi, un’informazione di valore intero con segno; è una ridefinizione del tipo
di dato proprio di ASN.1, dove la precisione richiesta non è specificata;
• interi senza segno, come sopra solamente riferito a dati costantemente non nega-
tivi.
Le Regole Fondamentali per la Codifica (Basic Encoding Rules - BER) definiscono il
modo e l’ordine con cui i messaggi verranno trasmessi sulla rete; la regola più fonda-
mentale stabilisce che ogni campo verrà codificato con tre valori: Tipo, Lunghezza e Da-
ti. Tipo specifica, utilizzando un singolo byte, il tipo di dato trasportato; Lunghezza iden-
tifica la dimensione in byte del campo Dati che, ovviamente, contiene l’informazione
oggetto di interesse.
20
Alcuni tipi di dato, come le sequenze, sono composti modularmente da diversi
campi più piccoli, rendendo semplice una rappresentazione annidata dei tipi di dato
complessi.
2.4.3. Il formato dei messaggi
Il formato dei messaggi di SNMP specifica quali campi vadano inclusi nel mes-
saggio e in quale ordine; ad alto livello (e bassa precisione) il messaggio è composto da
svariati livelli di campi innestati, dove il più esterno è l’intero messaggio costituito da
una sequenza formata dai campi Versione, Community String e PDU1.
I primi due campi sono di tipo primitivo, Intero e Stringa di Ottetti rispettiva-
mente, quindi la loro rappresentazione non aumenta il numero di livelli, mentre il
campo PDU è a sua volta rappresentato da un tipo di dato complesso per contenere
un comando specifico e gli operandi che indichino le istanze di oggetti coinvolte dal-
l’operazione; i primi tre campi, dopo quattro byte utilizzati per identificare il tipo di
PDU in esame, sono tutti di tipo semplice (Intero) e trasportano, in ambo le direzioni:
• un ID della richiesta, per associarla alla risposta (ricordando che la comunicazio-
ne avviene attraverso UDP);
• un codice errore, eventualmente utilizzato dall’agente remoto per registrare un
evento inatteso;
21
1 Nel contesto delle reti organizzate a pacchetti (packet-switched), in particolare quelle multiprotocollo, il termine PDU identifica l’informazione inviata attraverso livelli diversi, generalmente detta payload nel contesto del livello inferiore.
• un indice errore per trasmettere, eventualmente, un puntatore all’oggetto causa
dell’errore.
Il quarto campo è nuovamente di tipo complesso, e trasporta una lista (rappre-
sentata con una sequenza) di coppie (sequenza a loro volta) di valori: il primo campo tra-
sporta l’OID di un’istanza di un oggetto, mentre il secondo può contenere il nuovo
valore da scrivere nella variabile indicata (i cui tipi devono ovviamente concordare)
oppure un valore null (0x00) per preservare lo spazio che sarà occupato dalla risposta
alla richiesta di informazioni.
2.4.4. Evoluzione del protocollo
L’implementazione iniziale (SNMPv1)2 fu introdotta nel 1988 per facilitare l’ac-
celerazione dello sviluppo di Internet su larga scala e della sua commercializzazione,
ma fu approvato più per necessità che per la sua correttezza teorica: all’epoca il biso-
gno di nuove tecnologie era di molto superiore alle effettive possibilità di implementare
un sistema standard per la sicurezza e l’autenticazione su Internet, quindi la soluzione
proposta fu accettata come temporanea.
Le sue caratteristiche principali, mantenute nelle revisioni successive, sono:
• l’utilizzo della porta 161 per la normale comunicazione con gli agenti;
• la dimensione massima del pacchetto SNMP fissata a 65507 byte, limitata so-lamente dalla dimensione del payload UDP;
• l’utilizzo della porta 162 per le comunicazioni asincrone da Agent a Manager (comandi Trap).
22
2 RFC 1065-1067 e successivi aggiornamenti
Le seguenti operazioni sono rese disponibili dalla prima versione dello standard:
• Get, utilizzata dal Manager per reperire un’informazione dal MIB dell’Agent;
• Get-next, impiegata ricorsivamente per accessi multipli;
• Set, necessaria per impostare un valore specifico all’interno del MIB del-l’agent;
• Trap, sfruttata dall’Agent per notificare il Manager di situazioni particolari.
Il canale di comunicazione, come detto, è assunto connectionless e opera a livello
Transport attraverso il protocollo UDP, di conseguenza la consegna del pacchetto non
è garantita.
La successiva evoluzione (SNMPv2)3, introdotta nel 1993, fu orientata alla corre-
zione delle “leggerezze” presenti nella prima versione: tipi di dato e codici di errore
limitati, scarse prestazioni, sicurezza inesistente, regole non documentate; furono in-
trodotti i nuovi comandi Getbulk, che permetteva di evitare una serie di richieste
Get-next per ottenere un insieme di dati, e Inform, per consentire ad un NMS di
inviare messaggi Trap ad un altro manager e ricevere una risposta, e un nuovo proto-
collo interamente orientato alla sicurezza per gestire integrità, confidenzialità, autenti-
cazione e controllo degli accessi.
Inoltre, per quanto riguarda la SMI, furono introdotte le stringhe di bit (bit strings),
composte da zero o più bit con un preciso ruolo variabile a seconda del caso, ed au-
mentate le espressività di network address e counter, rendendo il primo in grado di suppor-
tare tipi di indirizzo diversi e il secondo compatibile con interi a 64 bit, per limitare il
problema dell’overflow.
Le novità riguardanti la sicurezza non ebbero però riscontri positivi, sia da parte
degli utenti che dei produttori dell’hardware, principalmente a causa delle difficoltà
incontrate nel loro utilizzo, fu quindi reso nuovamente possibile il controllo degli acces-
si tramite una stringa (community) trasmessa in chiaro assieme alla richiesta di informa-
zioni, creando uno standard “di fatto” ma largamente accettato chiamato SNMPv2c
(per Community); questo, per quanto pratico, impedì l’implementazione di vera e pro-
pria autenticazione e spinse molti produttori hardware, di rimando, a non implemen-
23
3 RFC 1441-1452 e successivi aggiornamenti
tare le operazioni set, riducendo SNMP ad un’infrastruttura di monitoraggio nono-
stante gli ambiziosi presupposti.
2.4.5. Management Information Base
Il Database delle Informazioni di Gestione (MIB) è una collezione di informazioni or-
ganizzate gerarchicamente; vi si accede tramite un protocollo per la gestione di rete
quale SNMP e sono composti da oggetti gestiti identificati da ID oggetto univoci.
Un oggetto di questo tipo (chiamato managed object, MIB object, object o MIB con lo
stesso valore) è una tra un numero qualsiasi di specifiche caratteristiche del dispositivo
da gestire; gli oggetti MIB sono un’aggregazione di una o più istanze di oggetti, essen-
zialmente delle variabili.
I Moduli MIB includono molti oggetti (valori) per misurare e monitorare le atti-
vità 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 (come ad esempio sysUpTime,
che misura da quanto tempo il device non venga riavviato) e un valore numerico
espresso in dot-notation (il numero identificativo del sysUpTime è 1.3.6.1.2.1.1.3.0)
univoci. Si può facilmente intuire come sia preferibile identificare gli oggetti con il loro
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.
Esistono due tipi di oggetto, scalari e tabulari: gli scalari (discrete objects) definiscono
una singola istanza di un oggetto, mentre i tabulari (table objects) comprendono più
istanze in relazione tra loro raggruppandole in tabelle MIB. Un esempio di oggetto del
primo tipo potrebbe essere dfl1600IfPktsTotCnt, un oggetto scalare con una singola
istanza, l’intero indicante il numero di pacchetti inviati dall’interfaccia del firewall
DFL1600 prodotto dalla D-Link.
Conversione di un oggetto in dot-notation
24
Gli oggetti tabulari permettono di raggruppare una serie di dati che un dispositi-
vo deve supportare. Le tabelle vengono distinte dagli oggetti discreti, in quanto posso-
no svilupparsi senza limiti. Per esempio, SNMP definisce l'oggetto “ifDescr” (come og-
getto standard SNMP) che indica la descrizione testuale di ogni interfaccia supportata
dal dispositivo in questione; visto che i vari dispositivi della rete possono essere confi-
gurati con più di un’interfaccia, questo oggetto può evidentemente essere rappresenta-
to solo con un insieme di valori. Per convenzione gli oggetti SNMP sono sempre rag-
gruppati in una “Entry Directory”, all'interno della quale ogni oggetto viene definito
con il suffisso “Table” (per esempio, l'oggetto “ifDescr” appena citato si trova nella di-
rectory “ifEntry” contenuta a sua volta nella directory “ifTable”).
Il protocollo prevede alcuni vincoli sugli oggetti tabellari:
• ogni oggetto dell’”Entry Directory” di una tabella deve contenere lo stesso
numero di elementi degli altri oggetti contenuti nella stessa “Entry Directory”. Gli
oggetti della tabella si possono considerare come insiemi omogenei di dati;
• nella creazione di un nuovo oggetto Entry, SNMP richiede che un valore sia
associato con ogni tabella in un singolo messaggio SNMP (PDU): per creare una riga
in una tabella, tramite il comando Set, un valore deve essere specificato per ogni
elemento della riga;
• se si vuole cancellare una riga della tabella, SNMP richiede che almeno un og-
getto abbia un elemento di controllo che sia in grado di realizzare la cancellazione
desiderata. Questa procedura è necessaria solo quando si cancella una riga e non
quando si cancella una tabella SNMP.
Un object ID, come anticipato, identifica univocamente un oggetto nella gerarchia
MIB; questa gerarchia può essere figurata come un albero con una radice anonima e i
cui livelli vengono assegnati da diverse organizzazioni: gli ID oggetto dei livelli più vi-
cini all’origine appartengono a diverse organizzazioni per gli standard, mentre quelli
dei livelli più in basso sono gestiti da organizzazioni associate.
25
I produttori di hardware possono definire ramificazioni di private includendo gli
oggetti gestibili nel contesto dei loro prodotti; i MIB non riconosciuti come standard
vengono generalmente inclusi nel ramo experimental anche se, così come directory, risulta
essere praticamente vuoto; management, infine, contiene gli oggetti MIB supportati da
tutti i dispositivi.
26
3. Lo stage
Artistically, and most importantly, OpenNMS, in its entirety, is open source software forged from the philoso-phies of both the Free Software Foundation (FSF) and the Open Source Initiative (OSI) providing a free, enter-prise grade, network management system to the world.
David Hustacepresident of the OpenNMS Group, inc.
1
3.1. Obiettivi originali
Il progetto assegnatomi dall’azienda prevedeva:
l’installazione e configurazione un sistema di monitoraggio remoto dei parametri operativi
degli apparati di rete in grado di individuare le criticità (saturazione di banda, routes non di-
sponibili, malfunzionamenti degli apparati) e segnalarne i risultati ad un centro operativo at-
traverso l’uso di allarmi
e inoltre:
trovare un’integrazione in modo tale da offrire, ove possibile, un comune front-end di accesso
e/o condivisione delle informazioni relative all'architettura. Posizione, tipologia di apparato,
configurazione, anagrafica sono tutte informazioni che sarebbe utile mettere a disposizione di
ogni applicativo.
Tale obiettivo verrà considerato raggiunto quando saranno ultimati i seguenti punti:
• Installazione e messa in opera di un software NMS, preferibilmente Free e Open-Source.
Strumenti:Hardware: PC Desktop Intel Core 2 DuoOS: Linux CentOS 5.2Applicativi di riferimento: TheDude, Zenoss, Nagios
• Configurazione del software e impostazione delle regole relative agli allarmi.
• Configurazione del software per quanto riguardi l’accesso da parte di utenti non am-ministratori (sola consultazione, anche limitata nel numero di sezioni).
• Impostazione di appropriate regole relative a ingressi e uscite dai firewall aziendali.
• Stesura della documentazione relativa al lavoro svolto.A progetto ultimato si richiede di redigere della documentazione ad uso interno del personale tecnico della ditta WebEthical, in cui si possa trovare una descrizione del lavoro effettuato e della modalità operativa seguita per la sua realizzazione.
3.2. Suddivisione temporale in fasi preventivata
Prima dell’inizio dell’attività di stage è stato concordato e steso un piano di lavoro pre-
ventivo per stimare la durata totale del progetto e una sua suddivisione in fasi.
28
Come illustrato dal grafico di Gantt erano stati previsti 40 giorni lavorativi a tempo pie-
no, per un totale di 320 ore suddivise in diversi segmenti:
• Analisi dei requisiti
• Studio delle problematiche
• Verifica su Analisi dei requisiti e Studio delle problematiche
• Installazione del software
• Configurazione delle impostazioni per la rete di WebEthical
• Verifica di Installazione e Configurazione; tuning delle impostazioni
• Impostazione del front-end web
• Redazione della documentazione
La suddivisione temporale ha successivamente dovuto subire delle modifiche per evi-
denziare le iterazioni delle fasi di Installazione e Configurazione rese necessarie da verifiche
non andate a buon fine.
3.3. Analisi dei requisiti
In questa fase è stata importante la comunicazione con il titolare della ditta, per capire a
fondo le necessità che hanno portato alla richiesta di sviluppo di questo progetto e poter effet-
tuare delle scelte che portassero alla realizzazione di un prodotto che si avvicinasse il più pos-
sibile alle effettive necessità aziendali.
I requisiti obbligatori individuati sono stati:
29
• Gestione centralizzata del monitoraggio
• Notifiche immediate degli allarmi; utilizzo di una scala di priorità per le segnalazioni
• Possibilità da parte degli utenti di visualizzare lo stato delle proprie connessioni
• Mantenimento di uno storico di ragionevole estensione nel tempo
• Impostazione di un front-end per la gestione dei parametri relativi ai punti già elencati
• Utilizzo di strumenti open source
• Trasparenza per l’utente finale
Sono stati proposti anche dei requisiti opzionali:
• Evidenziare protocollo e destinazione delle connessioni congestionanti la rete
• Accesso remoto agli strumenti di gestione
3.4. Studio delle problematiche
Fase di studio delle tecnologie da utilizzare, del contesto in cui saranno inserite (la rete
aziendale) e della soluzione software più adatta: sono stati analizzati i protocolli coinvolti, la
loro utilizzabilità a fini commerciali e i NMS open source disponibili sul mercato.
Considerazioni sui protocolli
Il successo di SNMP è direttamente riconducibile all’uniformità di accesso ai dispositivi
di rete che rende disponibile: si tratta infatti a tutti gli effetti di una Application Program Interface
(API) verso la rete che rende possibile la scrittura di programmi generici di network manage-
ment in grado di lavorare con una grande varietà di dispositivi senza necessità di modifiche;
senza un protocollo come SNMP si sarebbe dovuto ricorrere ad innumerevoli applicazioni
create ad-hoc dai produttori di hardware appositamente per funzionare soltanto con le loro
apparecchiature.
I grandi punti di forza del protocollo sono la vastissima diffusione e la capacità di adat-
tarsi a qualsiasi dispositivo faccia parte di una rete; meno sfruttata e sviluppata, ma comunque
presente e propositiva, è l’estensibilità: siccome le funzioni degli agenti SNMP possono essere
estese per soddisfare le specifiche di ogni componente hardware, e soprattutto esistendo un
meccanismo abbastanza semplice per sviluppare le applicazioni software che poi dovranno
30
interfacciarsi con certe tipologie di agenti, SNMP dispone un grande numero di specifiche per
la gestione non strettamente legate alla gestione di apparati di rete, ma anche per esempio per
la gestione di una stampante.
Uno dei punti deboli risulta invece, nonostante le promesse, la semplicità: il protocollo è
definito da un insieme di regole particolarmente articolato rendendone complicata l’imple-
mentazione che a volte varia tra i produttori; una delle conseguenze è l'inefficienza, sia a livel-
lo di potenza di calcolo che di banda utilizzati: in alcune situazioni può capitare che risponde-
re ad una query richieda l’esecuzione di molti più calcoli del necessario a causa delle particolari
strutture dati utilizzate, inoltre buona parte della limitata dimensione del messaggio viene ma-
lamente utilizzata con informazioni descrittive e dati codificati in maniera discutibile.
Sebbene anche questo protocollo sia oggetto di critiche e non privo di imperfezioni, pos-
siamo comunque dire che per quanto riguarda la complessità delle sue 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 riguar-
di l’efficienza e l’occupazione di banda possiamo dire che lo sviluppo delle tecnologie di co-
municazione può nascondere parzialmente il fatto che molte informazioni che viaggiano in
pacchetti SNMP siano in sostanza inutili.
Una delle critiche più difficili da spiegare sul protocollo SNMP nasce dalla domanda
“Perché SNMP, sebbene non abbia ampia visibilità come altri tool di gestione di rete, è il più
utilizzato?”. Come è possibile che questo protocollo sia il più utilizzato senza avere alle spalle
una serie di documenti che ne attestino la superiorità? Quando si utilizzano telnet o netstat e si
accede ad un dispositivo di rete scaricando tutte le informazioni desiderate, non si compiono
le stesse operazioni per cui SNMP è stato creato?
In effetti esistono vie alternative a SNMP, ma sono state soppiantate dalla sua generale
popolarità e interoperabilità. La completezza di questo protocollo e la sua capacità di adattarsi
ad ogni dispositivo per realizzare tutte le funzioni di amministrazione di rete portano alla con-
clusione che di fatto non esistano alternative 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 in maniera uniforme.
31
Considerazioni sugli applicativi
Le attività che un buon NMS deve essere in grado di eseguire
Alarm Polling: funzionalità fondamentale di ogni software SNMP è la possibilità di
fissare delle soglie sui valori degli oggetti MIB e rispondere con una determinata sequenza di
azioni qualora queste fossero violate; si tratta di funzioni che tengono costantemente sotto
controllo la rete e l’integrità dei dispositivi connessi, in grado quindi di determinare quali tra
questi siano attivi e in uno stato consistente (on line) e quali abbiano smesso di rispondere (off
line).
Trend Monitoring: necessità che sorge assieme alla funzionalità di raccolta dei dati è
quella di monitorare il loro trend durante tutte le fasi del normale utilizzo dell’infrastruttura
per determinare l’intervallo di tolleranza delle variazioni e poter utilizzare e interpretare cor-
rettamente le notifiche del sistema.
Trap Monitoring: il manager SNMP deve essere in grado di ricevere e filtrare i mes-
saggi TRAP che gli siano inviati dalle componenti connesse; si tratta di un elemento impor-
tante dello standard che permette alle apparecchiature di eseguire operazioni di auto analisi,
ma trattandosi di notifiche asincrone si rende necessario un sistema di filtraggio per eliminare
quelle inutili o non pertinenti.
Management Tool Set: il software di gestione più comune è il MIB browser, che
permette all’utente di navigare tra i MIB noti al NMS o tra quelli resi disponibili da una parti-
colare apparecchiatura.
MIB compiler
Va notato come queste funzionalità siano orientate alla presentazione grafica dei dati,
quindi al rendere comprensibile e facilmente interpretabile il prodotto delle elaborazioni
compiute su di essi una volta raccolti in quantità sufficiente.
La maggior parte degli oggetti MIB risulta essere read-only, fornendo da un lato un’ot-
tima base per la fase di raccolta dati attraverso il protocollo SNMP, dall’altro limitandone le
potenzialità per quanto riguardi le modifiche di configurazione: l’uso del comando Set è limi-
tato a piccole correzioni di impostazioni di secondaria importanza, anche per motivi di sicu-
rezza.
32
I programmi considerati durante questa fase preliminare sono stati, su indicazione
aziendale, Nagios, Cacti e Zenoss Core: la scelta tra uno degli applicativi free e open source
proposti si è basata sui livelli di attività e partecipazione delle rispettive community, sulla do-
cumentazione disponibile oltre ovviamente alle affinità con gli obiettivi fissati.
Nagios, come anche indicato nella sua documentazione (“Nagios is not designed to be a repla-
cement for a full-blown SNMP management application like HP OpenView”), non è realmente predispo-
sto per il risultato che intendevamo raggiungere: si tratta essenzialmente di una struttura im-
postata per applicare il remote plugin model impiegando il demone NRPE per eseguire sulll’host
remoto degli script creati ad-hoc che inviino periodicamente i risultati delle loro interrogazio-
ni; questo modello non è apparso ragionevole visti l’eterogeneità delle macchine da monitora-
re, il loro complessivamente esiguo numero (poco più di una sessantina) e motivi di sicurezza
(un errore qualsiasi durante l’esecuzione, anche solo un aumento del carico per il processore,
avrebbe potuto danneggiare intere giornate di lavoro a più di un’azienda), inoltre il manteni-
mento e la presentazione di dati storici appaiono decisamente sottovalutati mentre erano stati
indicati come requisito obbligatorio; considerando che i pochi e mal documentati plugin pre-
senti erano orientati a risolvere le stesse problematiche obiettivo di SNMP, l’applicativo è stato
scartato. Cacti, similmente, non è orientato agli obiettivi identificati, quanto piuttosto alla pre-
sentazione organizzata di dati già raccolti e immagazzinati, ed è stato quindi rimosso dalle
possibilità relative al progetto principale, ma tenuto in considerazione per sviluppi futuri.
Zenoss Core si presentava ottimamente, offrendo tutte le funzionalità ritenute necessarie
e una buona varietà di plugin, definiti “facilmente estendibili”, divisi in categorie per definire
la gestione di ogni aspetto della rete; la comunità appariva sviluppata e attivamente partecipe
su forum, chat e pagine di documentazione, si è quindi optato per l’adozione di questo stru-
mento software.
3.5. Verifica su analisi dei requisiti e studio delle
problematiche
Questa fase, di ruolo fondamentale, ha visto il coinvolgimento del titolare dell’azienda e
del tutor aziendale assegnatimi. Lo scopo di una verifica su analisi dei requisiti era quello di
poter poi realizzare il progetto con la certezza di ottenere quanto effettivamente richiesto dal-
33
l’azienda, sia per quanto riguardi il risultato prodotto sia per gli strumenti realizzati, è infatti
evidente come in caso di errore nell’individuazione corretta dei requisiti si possa arrivare al
termine del periodo di stage avendo realizzato un progetto non corrispondente a quanto ri-
chiesto dall’azienda. La verifica sullo studio delle problematiche invece aveva come scopo
quello di portare a conoscenza il tutor aziendale di come avevo pensato di realizzare il proget-
to, ottenendo da lui opinioni e consigli preziosi data l’esperienza pluriennale nel campo.
La fase di verifica è stata prolungata rispetto alle previsioni per accertare completamente
l’attuabilità della soluzione ipotizzata, in particolare in relazione alle operazioni necessarie ad
“istruire” il software alla raccolta di dati specifici degli apparati in utilizzo presso WebEthical:
verificata la semplicità dell’installazione (l’unico requisito è infatti un server MySQL con un
socket attivo), si è scelto di verificarne l’efficacia “sul campo” installandolo e testandolo sulla
rete locale degli uffici, comunque un aggregato di apparati molto simili a quelli utilizzati
commercialmente.
La scelta, non esattamente comune per una fase di verifica, si è rivelata fortunata perché
ha evidenziato importanti incompatibilità con la maggior parte dei router e degli switch utiliz-
zati; sormontare questo ostacolo sarebbe equivalso alla scrittura di un nuovo modulo apposito,
operazione non improponibile che saremmo stati disposti ad affrontare non fosse stato per la
completa assenza di documentazione gratuita sull’argomento: Zenoss Inc. fornisce infatti i
propri prodotti sotto licenza GPLv2 avendo cura di includere un adeguato valore aggiunto
alle versioni a pagamento, nello specifico una molto più vasta documentazione, insiemi di plu-
gin ufficiali praticamente onnicomprensivi e l’accesso ai forum frequentati dagli sviluppatori.
Constatata l’incompatibilità tra i requisiti obbligatori e i software proposti, si è concor-
dato di modificare il piano di progetto e di tornare alla fase di Studio delle problematiche per
identificare un applicativo più adatto a risolvere le necessità aziendali. È bastata una breve ri-
cerca a maglie larghe per notare, in mezzo a quelli già noti, la comparsa di un nuovo nome
usato con una frequenza notevole e associato a tutti gli argomenti toccati dai requisiti:
OpenNMS.
Rilasciato interamente sotto licenza GPLv2, con espliciti obiettivi di scalabilità e porta-
bilità, è ormai ritenuto la vera alternativa open source ai prodotti di Network Management; le
sue “tre metà” (termine preso in prestito direttamente dalla documentazione) sono
34
• Monitoraggio automatico dei servizi di reteValutazione dello stato dei server in base alla disponibilità dei servizi forniti, tra i quali
• Servizi web: HTTP, HTTPS, FTP
• Servizi di posta: POP3, IMAP, SMTP, Excange
• Database: SQLServer, mySQL, Postgres, Oracle, Sybase, Informix
• Servizi di rete: SNMP, DNS, SSH, DHCP, LDAP
• SNMP data collectionMisurazioni tradizionali delle performance e dello stato della rete via SNMP
• Gestione degli eventi e notificheRisposta automatica a determinate circostanze e invio di notifiche al personale
3.6. Installazione del software
3.6.1. Requisiti hardware
Per gestire una rete di medie dimensioni (200 elementi circa) i requisiti minimi di
OpenNMS sono
• un processore Pentium III da 1GHz o equivalente/superiore
• 256MB di RAM, anche se trattandosi di software scritto in Java è caldamente consigliato averne almeno il doppio
• 200MB di spazio libero sull’hard disk per i file di sistema, più circa 400MB per un database con una persistenza ragionevole e fino a 2GB (configurabili) per i file di log, dettaglio utile per le operazioni di debug
Considerando l’innata necessità di frequenti scritture sul disco, sia per la natura
del database che quella dei dati raccolti in relazione al tempo, viene sconsigliato l’uso
di RAID-5 (striped disks with distributed parity) in favore di RAID-1 (mirroring) o RAID-1+0
(mirroring then striping) che evitano il continuo ricalcolo di checksum; per motivi simili, vie-
ne sconsigliato anche l’uso di LVM, un overlay software trasparente al sistema operativo
che fornisce l’illusione di una continuità tra partizioni diverse.
35
3.6.2. Requisiti software
Preparazione: il package manager principale per le distribuzioni di Linux predi-
sposte ad installare gli applicativi da pacchetti in formato RPM (RedHat, Fedora e
quella utilizzata durante lo stage, CentOS) è yum; questo sistema di installazione è
estremamente diffuso, e OpenNSM inc. ha appositamente reso disponibili dei pacchet-
ti che automatizzano il processo di aggiornamento degli indirizzi dei repository con
quelli per scaricare i file necessari per l’installazione, rendendo la fase preliminare
semplice quanto digitare il comando
rpm -Uvh http://yum.opennms.org/repofiles/opennms-repo-stable-rhel5.noarch.rpm
Java: OpenNMS è scritto principalmente in Java, a parte alcune invocazioni JNI
a codice C per implementazioni a basso livello, come ad esempio ICMP; è necessario
installare JDK aggiornato almeno alla versione 5.0, in quanto è presente del codice
JSP per la generazione dinamica delle pagine web dell’interfaccia che dovrà essere
compilato. La semplicità di installazione attraverso un package manager rende l’ope-
razione banale:
yum install jdk
PostgreSQL: un DBMS relazionale per mantenere informazioni sugli apparati
connessi ma anche riguardo ad eventi, notifiche e malfunzionamenti; durante la fase di
installazione è necessario che il server Postgres sia raggiungibile via TCP/IP (anche su
localhost) e che il processo installante abbia permessi di scrittura; è consigliata una ver-
sione superiore alla 8 per motivi di prestazioni, ma è utilizzabile qualsiasi versione suc-
cessiva alla 7.4. Le distribuzioni di Linux basate su RedHat chiamano questo applica-
tivo RedHat Database, quindi il comando per ottenere e installare il pacchetto sarà
sudo yum -y install rhdb-server
Come detto, è necessario che Postgres sia in grado di accettare connessioni già
durante la fase di installazione del NMS, impostiamo quindi i parametri relativi nei file
postgresql.conf e pg_hba.conf, creati nella cartella pgsql/data al primo av-
vio del server.
36
Il primo file controlla le impostazioni di base di PostgreSQL; essendo necessario
che l’applicazione sia in ascolto su un socket IP e non semplicemente su uno locale di
Unix (IPC) imposteremo listen_address = ‘localhost’ per assicurare la pre-
senza del socket e max_connections e shared_buffers rispettivamente almeno a
256 e 1024 per garantire risposta alle richieste di connessione; il secondo file controlla
gli apparati e gli utenti che possano accedere al database, e trattandosi di una macchi-
na dedicata al Network Management la cosa più semplice e funzionale da fare è ga-
rantire accesso da localhost a chiunque verso qualsiasi database aggiungendo
# TYPE DATABASE USER IP-ADDRESS IP-MASK METHOD
local all all trust
host all all 127.0.0.1/32 trust
host all all ::1/128 trust
Per terminare la configurazione iniziale di Postgres va accertata l’inizializzazione
del database eseguendo come utente postgres, dalla cartella pgsql/bin, il coman-
do ./initdb -D ../data -E “UNICODE” e infine riavviando il database ese-
guendo dalla stessa cartella ./pg_ctl -D ../data start.
L’ultimo accorgimento relativo al database è l’installazione di una versione otti-
mizzata della procedura iplike, indispensabile per riconoscere gli indirizzi IP espres-
si in intervalli e tramite wildcard: è possibile utilizzarne una scritta in PostgreSQL, ma
la perdita in performance è notevole rispetto a quella scritta in C disponibile come
download separato nella pagina principale di OpeNMS su Sourceforge.
JICMP: l’implementazione in Java di ICMP (Internet Control Message Protocol, uno
dei fondamenti della suite TCP/IP utilizzato per operazioni a basso livello come il rou-
ting o, nel livello applicazione, per effettuare ping) non è mai stata adeguata ad essere
utilizzata per scopi di network management; OpenNMS risolve il problema utilizzan-
do codice C posizionato in una libreria esterna e invocato tramite Java Native Interfa-
ce; l’installazione è semplificata dalla disponibilità di un pacchetto apposito, installabile
digitando semplicemente
yum install jicmp
37
JRobin è una libreria scritta interamente in Java, porting del già eccellente (ma
scritto in C) RRDtool, avente come scopo la memorizzazione e analisi di dati frutto di
campionamenti in maniera efficiente e sistematica; questo strumento è in particolare
orientato al mantenimento di uno storico dei dati, infatti gli espliciti riferimenti alla
politica Round Robin sottolineano come i dati vengano memorizzati in maniera circo-
lare, sovrascrivendo quelli precedenti dopo un lasso di tempo manualmente definito e,
eventualmente, applicando delle funzioni di consolidamento (average, minimum, maxi-
mum, total, last) ai dati più vecchi per preservarne gli aspetti rilevanti; questa dipenden-
za è risolta dall’installer del NMS.
Tomcat è un prodotto della Apache Software Foundation che implementa un
server web e l’ambiente necessario all’esecuzione di codice Java appositamente creato
per la generazione dinamica di contenuti;
3.6.3. Installazione e primo avvio
L’installazione del software è facilitata dalla modularizzazione dei pacchetti di-
sponibili, che permette di scegliere la configurazione più conveniente in base alle ne-
cessità:
sudo yum install opennms-core
installa le componenti principali del programma, responsabili di discovery, polling, data col-
lection, notifications.
sudo yum install opennms-docs
installa la documentazione e le pagine man
sudo yum install opennms-webapp-standalone
installa l’interfaccia web predisposta per essere eseguita da Tomcat
Una volta installati i pacchetti necessari si potrà procedere con la prima configu-
razione dell’applicazione eseguendo $OPENNMS_HOME/bin/runjava -s per impo-
stare la posizione di Java Runtime Environment, e $OPENNMS_HOME/bin/install
-l /usr/local/lib -dis per preparare il database Postgres, impostare la posi-
38
zione di JICMP e di JRobin (-l) e testare il buon esito delle operazioni, inclusa quella
di installazione di iplike (-dis).
La procedura di installazione è terminata; si può avviare il programma eseguen-
do /etc/init.d/opennms start
Accedendo alla pagina http://localhost:8080/opennms con un browser web si
potrà effettuare il login, inserendo “admin” come nome utente e password, e comin-
ciare ad utilizzare il software di Network Management.
L'effettivo funzionamento del sistema può essere verificato tramite il comando
/etc/init.d/opennms status accertandosi che tutti i processi siano in modalità
running.
Quando si eseguono delle modifiche ai files di configurazione è necessario riav-
viare l’applicazione digitando /etc/init.d/opennms restart.
3.7. Configurazione delle impostazioni
3.7.1. Discovery
Dal momento che la maggior parte dei servizi di rete sono forniti utilizzando
TCP/IP, OpenNMS utilizza l’indirizzo di rete come un’informazione di importanza
centrale: le unità fondamentali oggetto di monitoraggio sono chiamate interfacce, e
ognuna è univocamente identificata da un indirizzo IP. I servizi sono mappati sulle in-
terfacce e se, in una fase successiva, saranno riconosciuti come residenti su uno stesso
apparato verranno allora unificati in un nodo.
Il processo di inizializzazione di OpenNMS è chiamato discovery, ed è diviso in
due fasi: riconoscere gli indirizzi IP da monitorare e identificare i servizi forniti da
quell’indirizzo; la prima fase è molto più semplice della seconda.
Questa operazione è controllato dal file discovery-configuration.xml,
posizionato nella cartella $OPENNMS_HOME/etc, ed è compiuta da un processo che
invia ICMP ping ai definiti range di indirizzi e che registra le risposte pervenute entro il
timeout come un evento di tipo new suspect.
Il file di configurazione è così composto:
39
<discovery-configuration threads=”1” packets-per-second=”1”
initial-sleep-time=”300000”
restart-sleep-time=”86400000”
retries=”3” timeout=”800”>
<include-range retries=”2” timeout=”3000”>
<begin>192.168.1.1</begin>
<end>192.168.1.200</end>
</include-range>
<exclude-range>
<begin>192.168.1.170</begin>
<end>192.168.1.180</end>
</exclude-range>
</discovery-configuration>
Gli attributi del tag globale sono:
• threadsil numero di thread che saranno impiegati nel processo di discovery;
• packets-per-secondil numero di pacchetti ICMP generati ogni secondo; di default è 1, ma il va-lore può essere aumentato se la latenza della rete e il numero di thread con-sentono un più rapido svolgimento delle operazioni;
• initial-sleep-timeil tempo, in millisecondi, che trascorrerà tra l’avvio del programma e l’inizio delle operazioni; questo attributo è importante perché permette di garantire il completo avvio del programma prima dell’inizio delle operazioni;
• restart-sleep-timeuna volta completato il processo di discovery, questo sarà il tempo, in millise-condi, che trascorrerà prima del ripetersi dell’operazione; di default è 24 ore;
• retriesil numero di interrogazioni che saranno effettuate verso un indirizzo IP pri-ma di determinarne l’inutilizzo;
40
• timeoutil tempo, in millisecondi, durante il quale il processo di discovery attenderà una risposta da un indirizzo IP prima di ritenerlo inutilizzato.
Una volta definiti i defaults (i.e. gli attributi globali che saranno utilizzati salvo
override da parte di tag successivi) sarà necessario definire il range di indirizzi IP da tene-
re in considerazione durante le operazioni, utilizzando i quattro tag
• specificuno specifico indirizzo IP da analizzare;
• include-rangedefinisce un intervallo di indirizzi IP da inserire nel processo utilizzando i tag begin e end;
• exclude-rangecon le stesse modalità del tag precedente, definisce un insieme di indirizzi da ignorare durante i processi di discovery;
• include-urlindica un file (tramite la sintassi file:[full-path]) contenente una lista verticale di indirizzi da includere nel processo.
Tutti i tag sono opzionali e possono essere presenti un numero illimitato di volte;
l’esito di ogni passo di questo processo sarà registrato nel file discovery.log conte-
nuto in $OPENNMS_HOME/logs/daemon. Per necessità o preferenza la fase di disco-
very può essere aggirata tramite l’azione add interface presente nell’interfaccia web nella
sezione admin, tuttavia si tratta di un’operazione consigliata solamente in caso di appa-
recchiature configurate appositamente per non rispondere a richieste ping, come ad
esempio è frequentemente il caso dei firewall.
3.7.2. Capabilities
Terminato il processo di discovery e generato quindi l’insieme di eventi new suspect,
la responsabilità viene ceduta al demone con il compito di identificare i servizi che
ogni nodo è in grado di offrire (capabilities): capsd. Questo processo è responsabile del-
l’identificazione dei servizi attivi su ogni indirizzo, ed il suo funzionamento è impostato
dal file capsd-configuration.xml, che definisce alcuni parametri generali e un
41
insieme di protocolli da testare; se un protocollo non è citato all’interno del file
OpenNMS lo ignorerà completamente.
Il tag globale del file gestisce il comportamento di base del demone:
<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”>
I suoi attributi aggiuntivi sono
• management-policycontrolla il comportamento del demone nei confronti degli indirizzi IP iden-tificati dagli eventi new suspect: se il suo valore è managed allora tutti gli eventi di questo tipo saranno controllati a meno che non siano inclusi in un range che li definisca esplicitamente come unmanaged in coda al file stesso; se viene impostato ad unmanaged il comportamento sarà speculare;
• max-suspect-thread-pool-sizeimposta il numero di thread che saranno creati per effettuare il controllo del-le capabilities sui nuovi indirizzi IP rilevati; aumentarlo significa accelerare il processo di discovery iniziale al costo di maggiori risorse di sistema;
• max-rescan-thread-pool-sizeconfigura lo stesso comportamento dell’attributo precedente, ma relativa-mente agli indirizzi già identificati;
• abort-protocol-scans-if-no-routequesto parametro è molto importante in relazione alla velocità del processo di discovery: se, inviando richieste verso un indirizzo IP ad una porta specifi-ca per verificare la disponibilità di un servizio, venisse riscontrato un’ecce-zione di tipo no route to host il motivo sarebbe in teoria l’irraggiungibilità del-l’host; in pratica, invece, alcuni degli apparati di rete (come ad esempio i fi-rewall) potrebbero causare questo errore. Se il valore di questo attributo è “false” allora i messaggi di questo tipo saranno ignorati, mentre se fosse “true” il demone capsd terminerebbe la ricerca di servizi su quell’indirizzo.
I protocolli supportati nativamente dal NMS sono moltissimi, praticamente tutti
i più comuni che possano essere resi disponibili da qualsiasi apparato connesso e rag-
giungibile in una rete; per ognuno di essi è possibile specificare delle impostazioni per
42
verificarne il corretto funzionamento, incluso anche uno o più range di indirizzi da
considerare o ignorare nel caso di servizi non offerti da tutte le macchine in rete; ad
esempio, per verificare il funzionamento dell’agente SNMP andrà aggiunto del testo
simile al seguente:
<protocol-plugin protocol="SNMP"
class-name="org.opennms.netmgt.capsd.plugins.SnmpPlugin"
scan="on" user-defined="false">
<protocol-configuration scan="on" user-defined="false">
<range begin="192.168.1.0" end="192.168.1.254"/>
<property key="timeout" value="4000"/>
<property key="retry" value="3"/>
</protocol-configuration>
<protocol-configuration scan="off" user-defined="false">
<range begin="192.168.1.170" end="192.168.1.180"/>
</protocol-configuration>
<protocol-configuration scan="enable" user-defined="false">
<specific>192.168.200.1</specific>
</protocol-configuration>
<property key="timeout" value="2000"/>
<property key="retry" value="2"/>
</protocol-plugin>
Il test per accertare la presenza di un demone SNMP su una macchina si con-
cretizza in più fasi: inizialmente viene effettuata la richiesta dell’oggetto avente per
OID .1.3.6.1.2.1.1.2.0 (cioè SNMPv2-MIB::sysObjectID.0), che dovrebbe ritornare
una stringa indicante il nome dell’apparato con cui si sta cercando di comunicare; se
l’esito è positivo, vengono inviate altre tre interrogazioni SNMP per ricevere le altre
informazioni di sistema, la ipAddrTable e la ifTable: se anche (tutte) queste informa-
zioni vengono correttamente ricevute sarà effettuata la scansione delle capabilities di
tutti gli indirizzi IP presenti nella ipAddrTable, e di quelli che risultassero avere a loro
43
volta un demone SNMP attivo sarà controllata un’eventuale mappatura su un’interfac-
cia nota della ifTable; tra tutte le interfacce con un indirizzo e un server SNMP attivo
identificate verrà selezionata come primaria quella con l’indirizzo minore, e sarà utiliz-
zata per tutte le interrogazioni successive.
3.7.3. Polling
Una volta riconosciuti gli elementi della rete, il compito di OpenNMS diventa
quello di raccogliere informazioni riguardanti la rete: il metodo più semplice per rac-
cogliere le informazioni più basilari è il polling, avere cioè dei processi (monitor) che pe-
riodicamente si connettano alle risorse e verifichino che ancora rispondano.
Il funzionamento del processo è gestito dal file poller-configuration.xml
(anch’esso posizionato nella cartella $OPENNMS_HOME/etc), che divide gli apparati da
monitorare in package logici per definirne i servizi e la rispettiva frequenza di polling con
precisione; grazie a questa organizzazione è possibile definire anche un preciso calen-
dario dei downtime delle unità per evitare il sollevamento di notifiche inutili. Le infor-
mazioni all’interno del file sono strutturate in questo modo:
<poller-configuration threads="30" serviceUnresponsiveEnabled="false">
<node-outage status="on"
pollAllIfNoCriticalServiceDefined="true">
<critical-service name="ICMP"/>
</node-outage>
I comportamenti che vengono configurati dall’header del file sono
• threadsil massimo numero di thread che saranno impiegati nelle operazioni di pol-ling;
• serviceUnresponsiveEnabledun’operazione di polling si conclude con esito positivo quando vengono effet-tuate una connessione ad una porta di un’interfaccia remota e un’interroga-zione al servizio relativo che ritorni un risultato previsto, mentre il servizio è considerato offline se non risponde entro un timeout; alcune reti sono però fre-quenti manifestare ritardi ed errori di trasmissione, quindi è stata introdotta questa opzione per identificare un malfunzionamento critico soltanto nel ca-
44
so di un errore nella connessione alla porta e non nella risposta; per abilitare questo comportamento all’attributo va dato il valore “true”;
• node-outageil primo evento che viene sollevato in caso di errore è “NodeLostService”, e se più di un servizio viene evidenziato come offline saranno riportate notifiche multiple; qualora non fossero tutti i servizi verrebbe notificato “Interface-Down”, e se tutte le interfacce avessero generato eventi di questo tipo si avrebbe una notifica “NodeDown”; dando all’attributo status ila valore “on”, in quest’ultima situazione le notifiche precedenti verrebbero elimina-te; il processo si basa sulla risposta del critical-service per riconoscere nuovamente il nodo come online, ma se questo non è definito il comporta-mento è controllato dall’attributo pollAllIfNoCriticalServiceDefi-ned: se il suo valore è “false” sarà interrogato il primo tra i servizi del package in sua vece.
Un package è definito da un nome, un insieme di interfacce da interrogare e i ser-
vizi da considerare su ogni interfaccia; se ne possono definire diversi, e le interfacce
possono comparire in più di uno di essi. La definizione si apre con il tag
<package name=”test”>
seguito dal filtro IPADDR IPLIKE *.*.*.* per identificare le interfacce da include-
re e dalla definizione dei range di indirizzi IP da considerare; a questo punto sono elen-
cati i servizi da interrogare, ad esempio:
<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>
Il parametro della query è localhost perché per un server DNS rispondere con
un errore è segno di buon funzionamento; alcune implementazioni della Microsoft
non seguono questo comportamento, ma non è stato possibile verificarlo a causa della
non disponibilità di piattaforme di questo tipo.
3.7.4. Data collection
45
Il metodo per raccogliere informazioni ulteriori rispetto al semplice stato degli
apparati di rete è attraverso i collectors i quali, una volta accertato il funzionamento del
demone SNMP sul dispositivo remoto durante la fase di discovery, consulteranno il file
di configurazione collectd-configuration.xml, che come nel caso del polling
divide le interfacce in package, e inizieranno l’invio di query SNMP in base al contenuto
del file datacollection-config.xml che, per ogni package, definisce quali infor-
mazioni raccogliere. Il file snmp-config.xml contiene le informazioni necessarie per
comunicare con gli agenti remoti, ad esempio:
<snmp-config retry=”3” timeout=”800”
read-community=”public” write-community=”private”>
<definition version=”v2c”>
<specific>192.168.1.5</specific>
</definition>
<definition retry=”4” timeout=”2000”>
<range begin=”192.168.1.1” end=”192.168.1.253”/>
<range begin=”192.168.3.1” end=”192.168.3.2”/>
</definition>
<definition read-community=”public” write-community=”cilbup”>
<specific>192.168.1.254</specific>
</definition>
</snmp-config>
Con questo file si ha la possibilità di personalizzare i parametri per ogni specifico
range di indirizzi. Ad esempio per ogni sottorete si possono definire delle communities
differenti o modificare la porta attraverso cui stabilire lo scambio di informazioni. Tali
soluzioni, pur non risolvendo pienamente il problema sicurezza, sicuramente scorag-
giano eventuali attacchi.
Come anticipato, è il file datacollection-config.xml a determinare quali
valori saranno richiesti ad ogni interfaccia e package: così come ci sono pacchetti di pol-
ler per monitorare a livello dei servizi, vengono utilizzati dei collection packages per con-
trollare la raccolta dei dati; le operazioni di polling vengono effettuate verso svariati ser-
46
vizi eterogenei, e allo stesso modo sarebbe possibile ottenere informazioni da diverse
sorgenti, ma al momento è implementata soltanto la raccolta via SNMP.
All’interno di questo file, quindi, sono definiti diversi schemi che riuniscono gli
OID da interrogare in gruppi che saranno mappati in sistemi i quali, a loro volta, saran-
no mappati sulle interfacce utilizzando i systemOID.
L’unico parametro definito esternamente agli schemi (quindi globale) serve a de-
finire la posizione in cui saranno memorizzate le informazioni reperite da collectd.
<datacollection-config rrdRepository = “/var/OpenNMS/rrd/snmp/”>
Una volta definito il repository locale si identificano le snmp-collection deside-
rate:
<snmp-collection name="default"
maxVarsPerPdu = "50"
snmpStorageFlag = "all">
L’attributo name dovrà corrispondere al valore del tag key=”collection”
definito entro un package nel file di configurazione del processo collectd, altrimenti
le impostazioni non saranno applicate a nessuna istanza del processo di raccolta;
maxVarsPerPdu identifica un limite superiore al numero di variabili SNMP che pos-
sano essere recuperate con una interrogazione GET-BULK in un solo pacchetto;
snmpStorageFlag determina se il processo di raccolta sarà eseguito su ogni interfac-
cia (quando il suo valore è “all”) oppure solo su quella principale (“primary”): l’in-
fluenza del valore di questa variabile è principalmente sulle dimensioni del Round Ro-
bin Database nel caso caso di una rete in cui fossero presenti un gran numero di appa-
rati multi-interfaccia (come switch o router), mentre sarà quasi nulla qualora le com-
ponenti di rete principali fossero server (che generalmente operano con una sola inter-
faccia). Il valore di quest’ultima variabile è un ottimo esempio di discriminante nella
definizione di diversi package e schemi per la raccolta dei dati da elementi di rete etero-
genei.
Nella sezione successiva viene definito il comportamento del database relativa-
mente alla memorizzazione e alla ciclicità dei dati: in fase di inizializzazione viene al-
47
locato lo spazio per mantenere le informazioni per un periodo deciso a priori; questo
significa che lo spazio occupato non aumenterà nel tempo, ma anche che la sua per-
centuale aumenterà rapidamente nelle prime fasi di utilizzo.
<rrd step = “300”>
<rra>RRA:AVERAGE:0.5:1:8928</rra>
<rra>RRA:AVERAGE:0.5:12:8784</rra>
<rra>RRA:MIN:0.5:12:8784</rra>
<rra>RRA:MAX:0.5:12:8784</rra>
</rrd>
L’attributo step definisce la granularità dei dati, in secondi: un valore di 300
indica che nuove informazioni saranno salvate ogni 5 minuti per ogni step. Ogni RRD
è una composizione di RRA (dove l’ultima lettera significa Archivi) formati da un certo
numero di step: i dati raccolti ad ogni iterazione vengono consolidati in un valore unico
che sarà infine salvato nel database.
La sintassi del tag che definisce questo comportamento è
RRA:Cf:xff:steps:rows, dove Cf esprime la funzione utilizzata per il consolida-
mento (AVERAGE, MAX, MIN, LAST); xff è un valore razionale che esprime la percen-
tuale di valori UNKNOWN (sconosciuti, per qualsiasi motivo) ammessi prima di conside-
rare tale anche il valore consolidato; steps rappresenta il numero di campioni che
formeranno un archivio (ad esempio, se la dimensione di uno step è 5 minuti e il loro
numero è 12, l’archivio conterrà il consolidamento dei dati raccolti nell’arco di un’ora);
rows infine indica il numero di valori che saranno contenuti nell’RRA.
Chiariamo con un esempio:
RRA:AVERAGE:0.5:1:8928 indica che sarà creato un archivio dei valori medi di
ogni step e che ne saranno salvato 8928; se la dimensione dello step fosse di 300 secondi,
e se il ciclo di interrogazioni si ripetesse ogni 5 minuti, il valore considerato sarebbe
uno soltanto e media, massimo, minimo e ultimo coinciderebbero; 8928 campioni presi
ogni 5 minuti 24 ore al giorno si traduce in un archivio che preserva i dati 31 giorni
prima di sovrascriverli; le righe successive, RRA:AVERAGE:0.5:12:8784 e le seguen-
ti, specificano come usare le diverse funzioni di aggregazione per compattare i cam-
48
pionamenti effettuati ogni 5 minuti in nuovi dati che spazino un’ora ciascuno: un dato
medio per evidenziare l’utilizzo nel tempo, uno massimo e uno minimo per i picchi e le
valli di utilizzo; 8784 campioni da un’ora ciascuno significano in 366 giorni di storico.
Prima di poter specificare i gruppi per la raccolta dei dati bisogna aver definito un
resourceType personalizzato per ogni tipo di risorsa che si vuole interrogare:
<resourceType name=”essentiaWireless” label=”Essentia Wireless Chan Info”>
<persistenceSelectorStrategy
class=”org.opennms.netmgt.collectd.PersistAllSelectorStrategy”/>
<storageStrategy
class=”org.opennms.netmgt.dao.support.IndexStorageStrategy”/>
</resourceType>
L’attributo nome è solamente un identificativo per riferire la risorsa successiva-
mente e per creare la sottodirectory nel repository di RRD; label è utilizzato dall’in-
terfaccia web come nome “friendly”; i due tag definiti all’interno definiscono se e come
i dati vadano scritti su disco, ma non sono disponibili implementazioni diverse quindi
non ci sarebbe alcun motivo per modificarli.
Finalmente si possono definire i gruppi di risorse da monitorare, ognuno con i
propri specifici oggetti MIB:
<group name=”mib2-essentia-wireless-log” ifType=”all”>
<mibObj oid=”.1.3.6.1.4.25658.2.2.1.51” instance=”essentiaWireless”
alias=”ewRxAclFail” type=”gauge” />
<mibObj oid=”.1.3.6.1.4.25658.2.2.1.96” instance=”essentiaWireless”
alias=”ewChanNoise” type=”gauge” />
<mibObj oid=”.1.3.6.1.4.25658.2.2.1.100” instance=”essentiaWireless”
alias=”ewChanFreq” type=”gauge” />
</group>
e i sistemi su cui saranno mappati i gruppi, in base al system object ID ritornato
dagli agenti in esecuzione sulle apparecchiature remote che univocamente identifica il
tipo di apparato interrogato:
<systemDef name="Essentia">
49
<sysoidMask>.1.3.6.1.4.1.25658.2.</sysoidMask>
<collect>
<includeGroup>mib2-essentia-wireless-log</includeGroup>
<includeGroup>ucd-sysstat</includeGroup>
</collect>
</systemDef>
In questo esempio viene chiesto al NSM di interrogare le unità che abbiano un
sysOID che inizi con .1.3.6.1.4.1.25658.2. (quello delle unità Wifless prodotte
da Essentia) per ricevere, oltre ad alcune informazioni la cui raccolta è definita di de-
fault dal sistema, il gruppo di dati da noi definito che, per la precisione, include il nu-
mero di pacchetti ricevuti e scartati a causa delle politiche di ACL, il rumore in dBm
sul canale utilizzato e la frequenza attuale utilizzata dal canale stesso.
Il passo finale è la definizione delle regole per la creazione di grafici ricavati dai
dati raccolti, da inserire nel file snmp-graph.properties: la sintassi utilizzata viene
direttamente da RRDtool, in particolare dalla sua branca rrdgraph, l’insieme delle
funzioni usate per creare grafici da database strutturati a round robin:
report.essentia.wireless.log.name=Antennae Info Log
report.essentia.wireless.log.columns= ewRxAclFail, ewChanNoise, ewChanFreq
report.essentia.wireless.log.type= essentiaWireless
report.essentia.wireless.log.command=--title="Antennae Info Log" \
DEF:acl={rrd1}:ewRxAclFail:AVERAGE \
DEF:noise={rrd2}:ewChanNoise:AVERAGE \
DEF:freq={rrd3}:ewChanFreq:AVERAGE \
GPRINT:acl:AVERAGE:" Avg \\: %8.2lf %s" \
GPRINT:acl:MIN:"Min \\: %8.2lf %s" \
GPRINT:acl:MAX:"Max \\: %8.2lf %s\\n" \
AREA:noise#ff0000:"Noise " \
GPRINT:freq:AVERAGE:" Avg \\: %8.2lf %s" \
GPRINT:freq:MIN:"Min \\: %8.2lf %s" \
GPRINT:freq:MAX:"Max \\: %8.2lf %s\\n"
50
La presentazione dei report relativi ai sistemi definiti manualmente, nella relativa
sezione dell’interfaccia web, avverrà una volta aggiunto il relativo nome alla lista re-
ports contenuta all’inizio dello stesso file:
#report keys, list ALL prefab reports here!
reports=traffic, octets, errors, discards, avgbusy5, freemem, \
bufferfails, kerneltasks, kernelmem, \
cpuPercentBusy, \
memory, \
Essentia.wireless.log \
3.8. Configurazione per la rete di WebEthical
Come anticipato, i router utilizzati dall’azienda per veicolare il segnale wireless sono del-
la serie Wifless prodotti da Essentia; il loro funzionamento è gestito da un sistema operativo
Linux minimale su architettura ARMv5 BigEndian, e per la connettività forniscono due porte
Fast-Ethernet (abilitate anche all’alimentazione dell’apparato) MIL-like (circolari, ad incastro
sicuro per l’utilizzo all’aperto) e due connettori RF per collegare le antenne.
La loro documentazione è particolarmente estesa per quanto riguardi l’installazione, il
routing e la configurazione in generale, ma è risultata povera di dettagli riguardanti gli argo-
menti toccati dal progetto; per ottenere una lista degli oggetti MIB resi disponibili dalle appa-
recchiature è stato necessario telefonare direttamente all’azienda produttrice che mi ha fornito
delle credenziali di accesso temporanee ad un loro server FTP dal quale ho potuto scaricare
una lista in formato testuale formattata in maniera non standard e scarsamente commentata;
gli oggetti di interesse sono stati identificati manualmente attraverso ricerche testuali (e.g. noise,
dropped, fail, strength), ma abbreviazioni discutibili ed errori di battitura hanno lasciato aperta la
possibilità concreta di qualche svista.
I firewall impiegati sono tutti D-Link della serie DFL; la loro documentazione è molto
più completa, dettagliata e facilmente reperibile in rete rispetto al caso precedente, ma è risul-
tata anche molto meno necessaria vista la scelta di controllarne solamente il livello di utilizzo
della CPU (in seguito a sovraccarichi causati probabilmente da un’errata configurazione del
port forwarding), funzionalità resa disponibile dai pacchetti inclusi con OpenNMS.
51
Seguendo la procedura già descritta, sono stati definiti nuovi resourceType, group e
systemDef per le informazioni da tenere sotto controllo: gli utenti connessi al nodo, la banda
utilizzata da ogni interfaccia, il rumore e la frequenza del canale radio correnti (citati come
esempio), i pacchetti rifiutati a causa del CRC e quelli ritrasmessi; dei firewall, come detto, è
stato considerato solamente il carico della CPU; i server (di posta e web) non sono stati consi-
derati in quanto già gestiti da tecnologie diverse e comunque installati in sede.
3.9. Verifica dell’installazione e della configurazione
La macchina su cui era stata eseguita l’installazione è stato a questo punto lasciato attivo
diverse ore per controllare non solo l’effettivo funzionamento dei processi di raccolta dei dati
ma anche l’overhead che questi avrebbero potuto causare alla rete o, più probabilmente, alle
apparecchiature stesse, incluso il computer incaricato di gestire le operazioni.
In effetti il firewall aziendale con il compito di filtrare il traffico uscente ha improvvisa-
mente iniziato ad avere difficoltà nelle operazioni fino a necessitare di un riavvio ogni due ore,
e sul computer stesso erano notabili dei periodici rallentamenti: era lampante la necessità di
impostare un minore numero di thread e dei timeout differenziati tra i vari “gruppi di raccol-
ta”; l’effetto risultante è stato esattamente quello auspicato di una distribuzione molto più uni-
forme del carico di lavoro e di un annullamento dei problemi riscontrati in precedenza, anche
nel corso di più di una giornata di attività.
I dati risultavano infine correttamente raccolti e memorizzati nel RRD all’interno del
repository definito inizialmente: ogni mibObject dei gruppi la cui raccolta sia attiva viene salvato in
un file .jrd, usando l’alias dell’oggetto stesso come nome, nella sottodirectory identificata dal-
l’ID numerico del nodo; per ogni interfaccia del nodo viene inoltre creata una cartella identi-
ficata dal suo oggetto ifDescr (e.g. eth0) e dal relativo MAC address.
3.10. Impostazione delle notifiche e dell’accesso web
Le notifiche vengono inviate automaticamente dal sistema all’indirizzo e-mail definito
per l’utente amministratore nella totalità dei casi, con le impostazioni di default; modificando i
file users.xml e groups.xml si possono creare nuovi utenti e associarli a uno o più gruppi,
e queste informazioni possono essere utilizzate per personalizzare sia i destinatari delle notifi-
52
che sia per limitare gli accessi all’interfaccia web; il file destinationPaths.xml descrive le
modalità di notifica, mentre restringere l’accesso a determinate sezioni in base all’utente è un
risultato ottenibile con semplicità attraverso la stessa interfaccia web.
Il contenuto del file di configurazione è, inizialmente, il seguente:
<destinationPaths>
<path name=”Email-Admin”>
<target>
<name>Admin</name>
<command>javaEmail</command>
</target>
</path>
</destinationPaths>
Il tag path, identificato univocamente dal nome, specifica il target della notifica (co-
me insieme di gruppi e/o utenti) e il comando da invocare per eseguire l’operazione, e al suo
interno può anche definire una sezione escalate con parametro delay, per aggiungere
target secondari nel caso la notifica non venisse risolta entro il tempo indicato.
Una volta specificati i destinatari delle notifiche si potrà procedere ad associarli agli
eventi veri e propri, modificando il file notification.xml:
<notification name="interfaceDown" status="on">
<uei>uei.opennms.org/nodes/interfaceDown</uei>
<rule>IPADDR != '0.0.0.0'</rule>
<destinationPath>Email-Admin</destinationPath>
<text-message>All services are down on interface %interfaceresolve%
(%interface%) on node %nodelabel%. New Outage records have been created and
service level availability calculations will be impacted until this outage
is resolved.
</text-message>
<subject>[OpenNMS] Notice #%noticeid%: %interfaceresolve% (%interfa-
ce%) on node %nodelabel% down.</subject>
<numeric-message>111-%noticeid%</numeric-message>
</notification>
53
3.11. Stesura della documentazione
Gli ultimi tre giorni di stage sono stati dedicati alla stesura della documentazione neces-
saria alla ditta per avere un resoconto di quanto realizzato, completa di descrizione di tutte le
funzionalità disponibili. Il documento è stato scritto per il personale tecnico aziendale, contie-
ne perciò un manuale d’uso per l’utilizzo del front-end web e una guida per la ripetizione del
lavoro svolto, specificando anche le versioni dei software utilizzati. In questo modo il progetto
può essere realizzato nuovamente senza dover ricominciare da zero lo studio, riducendo così
al minimo i tempi.
54
4.1. Valutazione del lavoro svolto
Il risultato finale è risultato, a parere sia mio che dei responsabili aziendali, di buon livel-
lo: le necessità di controllare lo stato di una rete in continua espansione su una base territoriale
estesa su più province erano forti, e prima di questo progetto l’automatismo delle operazioni
era praticamente nullo, limitato a tentativi manuali di raggiungere gli apparati remoti con ses-
sioni di ping a campione e, eventualmente, connessioni fisiche in loco in situazioni non solo
scomode ma anche, a volte, pericolose (ricordando che si tratta di apparati wireless spesso po-
sizionati non solo sui tetti di capannoni aziendali ma anche in cima a tralicci alti centinaia di
metri); le notifiche di situazioni “pericolose”, come possono essere un utilizzo troppo intenso
della banda o dei processori dei router, erano affidate ai sistemisti dei clienti nel caso notassero
comportamenti anomali, e la scoperta della causa e la localizzazione dell’errore ha richiesto in
alcuni casi intere giornate di ricerche.
Il sistema ottenuto è risultato stabile nonostante la modesta potenza di calcolo della sin-
gola macchina impiegata per la raccolta dei dati, a dimostrazione della concreta potenza e
buona programmazione del NMS utilizzato; la messa in opera dell’interfaccia web verso
l’esterno, predisposta ma non ancora applicata, non richiederà sforzi eccessivi dei già presenti
ed esperti collaboratori aziendali.
Il protocollo SNMP ha delle basi teoriche solide che ne hanno garantito non solo la so-
pravvivenza ma anche un’ampia diffusione anche a distanza di quasi un ventennio dalla sua
introduzione. Come già spiegato, la S di Simple non ha ampi riscontri né dal lato utente finale
né da quello del programmatore; l’estensibilità teorizzata si è rivelata con gli anni praticamen-
te inapplicabile, affidata alla buona volontà dei produttori hardware che hanno comunque
implicitamente nel tempo relegato il ruolo del sistema a “valore aggiunto” degli apparati pro-
dotti; lo spazio di crescita per i software NMS è veramente grande, ma resta legato alle fun-
zionalità rese disponibili dalle apparecchiature la cui scelta diventa quindi determinante.
La sicurezza resta il più evidente neo del sistema: il protocollo francamente non ne offre
alcuna se non nella sua terza revisione, ma questa risulta praticamente inutilizzata principal-
mente per le difficoltà di implementazione sia dal lato client che dal lato server; la già citata
frequente soluzione adottata è quella di non implementare nemmeno le funzionalità set, in ef-
56
fetti risolvendo la maggior parte del problema, ma questa scelta ha limitato notevolmente le
potenzialità e probabilmente lo sviluppo di una tecnologia particolarmente utile.
Difficoltà serie sono state riscontrate nella comunicazione con i produttori degli apparati
utilizzati dall’azienda per l’infrastruttura: probabilmente sottovalutando le possibilità di questa
tecnologia su scala piccolo-media, è stata fornita una documentazione particolarmente scarsa
e sinceramente criptica, ricca di abbreviazioni di carattere strettamente personale, al limite dei
commenti che è frequente trovare tra righe di codice scritto a livello amatoriale, e anche la
comunicazione con persone fisiche è risultata di basso livello e a volte controproducente.
Aggirare gli ostacoli è stata un’operazione sicuramente interessante ma dispendiosa ed
evitabile; la sensazione finale è stata di un lavoro svolto quasi sperimentalmente, che proba-
bilmente non sarebbe stato opportuno affidare a personale più qualificato e quindi più eco-
nomicamente esigente.
4.2. Nuove conoscenze acquisite
Da questa esperienza ho appreso molto, nell’ambito delle reti e delle tecnologie wireless
oltre ovviamente a realtà lavorative a cui non avevo mai avuto possibilità di prendere parte:
l’utilizzo esclusivo del sistema operativo Linux, innanzitutto, ha forzato un ampliamento
notevole delle mie conoscenze al riguardo, soprattutto nell’ambito delle reti e delle imposta-
zioni relative alla connettività delle macchine;
la struttura della rete locale aziendale ha evidenziato la necessità di approfondire il fun-
zionamento “sul campo” di apparecchiature come firewall e switch: la coabitazione di due
imprese completamente indipendenti aveva obbligato una divisione totale di due sottoreti che
condividevano la connessione, e la necessità di diversi server da parte di entrambi rendeva la
topologia di rete particolarmente interessante;
le tecniche di controllo e gestione remota delle unità di rete sono state un argomento
completamente nuovo quanto ampio e interessante; i protocolli e le metodologie utilizzati era-
no stati soltanto sfiorati in sede universitaria, e l’esperienza pratica ha consolidato molto di
quanto appreso solamente in via teorica;
il fatto che l’azienda operasse in maniera esclusiva con apparecchiature wireless mi ha
fatto conoscere un insieme di processi aziendali sia su argomenti completamente nuovi, quali
57
l’installazione e configurazione di apparati radio, sia su alcuni già appresi ma mai verificati a
livello pratico, come la sicurezza delle reti che, pur esulando dagli scopi del progetto, suscitano
un discreto interesse soprattutto trattandosi di tecnologie in continua espansione.
58
Bibliografia
Andrew S. Atanenbaum “Computer Networks” - Pearson, 2003
Manualistica dei firewall D-Link
Manualistica dei router di Essentia
cisco.com/en/US/docs/internetworking/technology/handbook/SNMP.pdf
cisco.com/en/US/docs/internetworking/technology/handbook/NM-BASICS.pdf
en.wikipedia.org/wiki/SNMP
en.wikipedia.org/wiki/Management_Information_Base
en.wikipedia.org/wiki/Abstract_Syntax_Notation_One
en.wikipedia.org/wiki/OSI_model
en.wikipedia.org/wiki/TCP/IP_model
www.simpleweb.org/ietf/rfcs/complete/
www.opennms.org/documentation/
tomcat.apache.org/
www.postgresql.org/
oss.oetiker.ch/rrdtool/doc/rrdtool.en.html
en.wikipedia.org/wiki/Network_Management
1
Top Related