Monitoraggio e gestione dell'infrastruttura di rete di ... - SIAGAS

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

To Mom.

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

http://yum.opennms.org/repofiles/opennms-repo-stable-rhel5.noarch.rpm

http://yum.opennms.org/repofiles/opennms-repo-stable-rhel5.noarch.rpm

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

http://localhost:8080/opennms

http://localhost:8080/opennms

<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 scan="enable" user-defined="false">

<specific>192.168.200.1</specific>


<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”>


</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”>


</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” />


alias=”ewChanNoise” type=”gauge” />


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. Valutazioni finali

1

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

http://www.simpleweb.org/ietf/rfcs/complete/

http://www.simpleweb.org/ietf/rfcs/complete/

http://www.opennms.org/documentation/

http://www.opennms.org/documentation/

Monitoraggio e gestione dell'infrastruttura di rete di ... - SIAGAS

Documents

Transcript of Monitoraggio e gestione dell'infrastruttura di rete di ... - SIAGAS