ALMA MATER STUDIORUM UNIVERSITÀ DEGLI STUDI DI BOLOGNA SECONDA FACOLTÀ DI INGEGNERIA SEDE DI CESENA Corso di Laurea in Ingegneria Informatica STRUMENTI PER IL MONITORAGGIO DI RETE TRAMITE PROTOCOLLO SNMP Elaborato in RETI DI TELECOMUNICAZIONI L-B Relatore: Prof. Walter Cerroni Presentato da: Nicola Calisesi Sessione Prima Anno Accademico 2004/2005
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ALMA MATER STUDIORUM
UNIVERSITÀ DEGLI STUDI DI BOLOGNA
SECONDA FACOLTÀ DI INGEGNERIA SEDE DI CESENA
Corso di Laurea in Ingegneria Informatica
STRUMENTI PER IL MONITORAGGIO DI RETE TRAMITE PROTOCOLLO SNMP
Elaborato in RETI DI TELECOMUNICAZIONI L-B
Relatore: Prof. Walter Cerroni
Presentato da:
Nicola Calisesi
Sessione Prima Anno Accademico 2004/2005
2
Introduzione
Capitolo 1 >> Network Management
1.1 Network Management (Gestione di rete)
1.2 Modello ISO
1.3 Infrastrutture di rete
Capitolo 2 >> Il Protocollo SNMP
2.1 Introduzione al protocollo SNMP
2.2 Considerazioni sul protocollo
2.3 Evoluzione del protocollo
2.3.1 SNMP v1
2.3.2 SNMP v2
2.3.3 SNMP v3
2.4 Standard SNMP
2.4.1 Formato dei messaggi
2.4.2 Messaggi TRAP
2.4.3 Standard per gli oggetti SNMP
2.4.4 Estensione delle funzioni SNMP
2.5 MIB
2.5.1 Classificazione MIB
2.5.1.1 Discrete MIB Objects
2.5.1.2 Table MIB Objects
2.5.2 Tipologie MIB
5
6
10
12
15
17
19
19
22
23
25
26
29
30
31
32
34
34
35
36
INDICE
3
2.5.3 Valori di accesso ai MIB
2.5.4 Compilare un MIB
Capitolo 3 >> Software SNMP
3.1 Requisiti di un software SNMP
3.2 Installazione
3.2.1 Requisiti di sistema
3.2.2 Elenco dei pacchetti necessari
3.2.3 Installazione Java
3.2.4 Installazione RRDTool
3.2.5 Installazione PostgreSQL
3.2.6 Installazione Tomcat4
3.2.7 Configurazione PostgreSQL
3.2.8 Installazione e avvio OpenNMS
3.2.9 Possibili Problematiche
3.3 OpenNMS
3.3.1 OpenNMS Discovery
3.3.2 OpenNMS Capsd
3.3.3 OpenNMS Polling
3.4 OpenNMS SNMP
3.4.1 SNMP-Config.xml
3.4.2 DataCollection-Config.xml
3.5 Architettura
3.6 Altre funzioni
39
40
41
44
44
44
45
46
46
46
47
48
49
50
55
58
60
62
63
65
70
71
INDICE
4
Considerazioni finali
Bibliografia
Elenco delle figure
72
73
74
INDICE
5
Introduzione Lo straordinario sviluppo delle reti di computer dell’ultimo decennio ha aper-
to nuovi scenari per quanto riguarda l’utilizzo dei personal computer, si pensi a co-
me si è modificato l’utilizzo di Internet grazie alla banda larga, e soprattutto a come
è cambiata la concezione del personal computer, trasformando un computer isolato
in uno strumento in grado di comunicare con tutto il mondo.
Ovviamente lo sviluppo delle reti porta ad un inevitabile incremento delle lo-
ro dimensioni e se fino a poco tempo fa il concetto di rete era legato ad ambiti a-
ziendali o comunque locali, adesso le reti possono coprire intere aree geografiche.
Questa crescita in dimensioni e in numero di host collegati crea agli amministratori
notevoli problemi di gestione e manutenzione della rete; infatti se una rete di esten-
de in un’area molto vasta non è detto che l’amministratore sia in grado di raggiun-
gere fisicamente e in qualsiasi momento tutti gli host e tutti i nodi della rete, quindi
per rimediare a questi problemi si utilizzano programmi che siano in grado di moni-
torare la rete e di prevenire possibili guasti ai dispositivi collegati.
Nel 1989 nasce il protocollo SNMP che viene pensato come punto di partenza
su cui sviluppare dei sistemi che siano in grado di risolvere e prevedere tutti i pro-
blemi che nascono dalla gestione di una rete. La versatilità di questo protocollo gli
ha permesso di trovare da subito un riscontro positivo dal mondo degli sviluppatori
e dalle aziende del settore, infatti dopo la prima versione ne sono state implementa-
te altre due (anche se la prima continua ad essere la più utilizzata). Oggi lo standard
SNMP è supportato da una grandissima quantità di dispositivi alcuni dei quali esu-
lano dalla categoria dei componenti di rete come ad esempio alcune stampanti, sen-
za dimenticare che viene sponsorizzato da aziende come HP e IBM che vendono i
due software commerciali più diffusi.
L’obiettivo di questa tesi è analizzare tutta la teoria che sta dietro a questo
protocollo (nei primi capitoli) e analizzare un software open source in grado di ge-
stire dei nodi che siano equipaggiati con agenti SNMP.
Introduzione
6
Network Management
Capitolo 1 Network Management 1.1 Network Management (Gestione di rete) Prima di immetterci nella reale gestione della rete, consideriamo alcuni scena-
ri illustrativi del mondo reale, esterno alle reti, in cui un sistema complesso ha molti
componenti che interagiscono e devono essere monitorati, gestiti e controllati da un
responsabile. Le centrali elettriche (almeno per come sono rappresentate dai me-dia
popolari) hanno una sala di controllo dove interruttori, manometri e luci monitorano
a distanza lo stato (temperatura, pressione flusso) di valvole, tubi, cavi e altri com-
ponenti dell'impianto. Questi dispositivi permettono all'operatore di monitorare i
componenti principali dell'impianto e lo avvertono (la famosa luce rossa lampeg-
giante di avvertimento) quando un guasto è imminente. L'operatore dell'impianto
compie azioni per controllare questi componenti. In modo analogo, la cabina di pi-
lotaggio di un aereo è strumentata per permettere al pilota di controllare e comanda-
re i molti componenti che costituiscono un aeroplano. In questi due esempi, il
"responsabile" effettua un monitoraggio sui dispositivi remoti e analizza i loro da-ti
per assicurarsi che essi siano operativi e che funzionino entro i limiti prescritti, con-
trolla reattivamente il sistema attraverso regolazioni in risposta alle variazioni che
intervengono nel sistema stesso o nel suo ambiente, e gestisce efficacemente il siste-
ma (per esempio, rilevando tendenze comportamenti anomali, permettendo di inter-
venire prima che sorgano problemi seri). In questo senso, il responsabile della rete
monitorerà attivamente, gestirà e controllerà il sistema che gli è affidato.
Nei primi giorni del funzionamento delle reti, quando le reti di calcolatori era-
no strumenti di ricerca e non ancora un'infrastruttura critica usata da milioni di per-
sone al giorno, la "gestione della rete" era sconosciuta. Se si incontrava un proble-
ma di rete, si metteva in funzione qualche ping per localizzare la fonte del problema
e quindi modificare la regolazione del sistema, riparare hardware o software o chia-
mare un collega in grado di farlo. (Un'esposizione ben fatta dedicata al primo
7
Network Management
"crash" serio dell'ARPAnet, del 27 otto-
bre 1980, molto prima che gli strumenti
per la gestione della rete fossero dispo-
nibili, e degli sforzi fatti per risolvere e
comprendere il guasto si trova nel [1]).
Con la crescita di Internet pubblica e
delle intranet private da piccole unità a
un'enorme infrastruttura globale, è au-
mentata anche la necessità di una gestio-
ne più sistematica del gigantesco nume-
ro di componenti hardware e software
all'interno di queste reti.
Per motivare il nostro studio della gestione delle reti, cominciamo con un
semplice esempio in cui analizzeremo una piccola rete composta da tre router e da
un certo numero di host e server in Figura 1.1.
Anche in una rete così semplice ci sono molti scenari [2] in cui un responsabile del-
la rete può trarre enorme profitto dall'avere gli appropriati strumenti per la sua ge-
stione:
• Rilevazione di un guasto di una scheda d'interfaccia a un host o a un router.
Con appropriati strumenti di gestione della rete, un'entità di rete (per esem-
pio il router A) può segnalare al responsabile della rete che una delle sue
interfacce è fuori servizio. (Questo è certo preferibile a una chiamata telefo-
nica al NOC (Network Operations Center) da parte di un utente irascibile
che avverte che la connessione di rete non funziona!). Un responsabile che
monitora e analizza attivamente il traffico sulla rete, in realtà può essere in
grado di evitare l'irascibile utente rilevando in anticipo i problemi alle inter-
facce e sostituendo la scheda prima che si guasti. Questo può essere fatto,
per esempio, se il responsabile ha notato un incremento degli errori di che-
cksum nei frame che sono stati inviati attraverso l'interfaccia prossima al
guasto.
Figura 1.1 Schema di rete
8
Network Management • Monitoraggio degli host. Qui, il responsabile della rete può controllare pe-
riodicamente che tutti gli host della rete siano accesi e operativi. Ancora una
volta, il responsabile della rete può essere in grado di anticipare la risposta a
un problema (un host fuori uso) prima che il guasto sia riferito da un utente.
• Monitoraggio del traffico per aiutare nell'utilizzo delle risorse. Un respon-
sabile della rete può monitorare gli schemi del traffico da sorgente a destina-
zione e rilevare, per esempio, che attraverso la commutazione dei server fra i
segmenti LAN, la quantità di traffico che attraversa molte LAN può dimi-
nuire significativamente. Immaginate l'allegria generale (specialmente nei
dirigenti amministrativi) quando si raggiungono migliori prestazioni senza
costi di equipaggiamento. In modo analogo, attraverso il monitoraggio del-
l'utilizzazione dei link, un responsabile della rete può determinare che un
segmento LAN, o il link verso il mondo esterno sia sovraccarico e che è ne-
cessario un link con una larghezza di banda superiore, che dovrà quindi es-
sere approvvigionato (rappresentando un costo per l’azienda). Il responsabi-
le della rete può anche desiderare la notifica automatica nel caso in cui i li-
velli di congestione su un link eccedano un dato valore soglia, per poter met-
tere a disposizione un link con larghezza di banda superiore prima che la
congestione diventi seria.
• Rilevazione rapida dei cambiamenti nelle tabelle di instradamento. La flut-
tuazione dei percorsi (variazioni frequenti nelle tabelle di instradamento)
possono indicare instabilità nell'instradamento o perdita di configurazione in
un router. Certamente il responsabile della rete che ha impropriamente con-
figurato un router preferirà scoprire da solo l'errore, prima che la rete si
blocchi.
• Monitoraggio per gli SLA. Con l'avvento degli accordi sul livello di servizio
(SLA, Service Level Agreements, contratti che definiscono specifiche metri-
che prestazionali e accettabili livelli di prestazioni dei
9
provider di rete rispetto a tali metriche) l'interesse per il monitoraggio del
traffico è aumentato in modo significativo negli ultimissimi anni. La UUnet
e l'AT&T sono due dei principali provider che garantiscono gli SLA ai loro
clienti. Questi SLA comprendono disponibilità del servizio (o interruzione),
latenza, throughput e requisiti di notificazione dell’interruzione. È chiaro
che se i criteri di prestazioni devono essere parte di un contratto fra un pro-
vider di rete e i suoi utenti, allora le prestazioni di misura e di gestione sono
di grande importanza per il responsabile della rete.
• Rilevazione delle intrusioni. Un responsabile della rete può volere che gli sia
notificato quando il traffico in rete arriva da o è diretto a una sorgente so-
spetta (per esempio, host o numero di porta). In modo analogo, il responsa-
bile può desidera-re rilevare (e in molti casi filtrare) l'esistenza di certi tipi di
traffico (per esempio, pacchetti instradati da sorgente, o un grande numero
di pacchetti SYN diretti a un dato host) che si sanno essere caratteristici di
attacchi alla sicurezza.
Network Management
10
1.2 Modello ISO L'International Organization for Standards (ISO) [3] ha creato un modello di
gestione di rete per cercare di catalogare e collocare ogni scenario di rete possibile
in uno schema più strutturato. Vengono così definite cinque aree di gestione della
rete [2]:
• Gestione delle prestazioni. L'obiettivo della gestione delle prestazioni è di
quantificare, misurare, stendere rapporti, analizzare e controllare le presta-
zioni (per esempio, utilizzazione, throughput) di differenti componenti di
rete. Questi componenti comprendono sia dispositivi singoli (per esempio,
link, router e host), sia astrazioni end-to-end come un percorso attraverso la
rete. In seguito vedremo che gli standard protocollari, come il protocollo
semplice per la gestione delle reti (SNMP, Simple Network Management
Protocol) [4], hanno un ruolo centrale nella gestione delle prestazioni in
Internet.
• Gestione dei guasti. L'obiettivo della gestione dei guasti è di registrare, rile-
vare e rispondere alle condizioni di guasto nella rete. La linea di separazione
fra gestione dei guasti e gestione delle prestazioni è piuttosto confusa. Pos-
siamo pensare alla gestione dei guasti come all'immediato intervento su un
difetto transitorio della rete (per esempio, interruzione del servizio di un link
di un host o di un router, di hardware o software), mentre la gestione delle
prestazioni agisce in tempi più lunghi, per fornire livelli accettabili di presta-
zioni di fronte al variare delle richieste di traffico e all'occasionale guasto di
un dispositivo di rete. Come con la gestione delle prestazioni, il protocollo
SNMP ha un ruolo centrale nella gestione dei guasti.
• Gestione della configurazione. La gestione della configurazione permette a
un responsabile di rete di seguire i dispositivi che appartengono alla rete ge-
stita e di effettuarne la configurazione hardware e software. Una panoramica
Modello ISO
11
della gestione della configurazione e dei requisiti per le reti basate su IP si
può trovare nel [22].
• Gestione della contabilità (accounting). La gestione della contabilità per-
mette al responsabile della rete di specificare, registrare e controllare l'acces-
so degli utenti e dei dispositivi alle risorse di rete. Quote di utilizzazione,
addebiti basati sull’uso e privilegi di allocazione degli accessi alle risorse
rientrano tutti nella gestione della contabilità.
• Gestione della sicurezza. L'obiettivo della gestione della sicurezza è di con-
trollare gli accessi alle risorse di rete in accordo ad alcune politiche ben defi-
nite. Il centro di distribuzione delle chiavi e l'autorità di certificazione appar-
tengono alla gestione della sicurezza. L'uso di firewall (letteralmente, barrie-
re parafiamma) per monitorare e controllare i punti esterni di accesso a una
rete.
Dopo aver dato diverse definizioni sui vari aspetti della gestione di rete ci si potreb-
be chiedere: "Che cos'è la gestione della rete?". L’esposizione precedente ha moti-
vato la necessità di gestione della rete senza dare una definizione di gestione di rete,
quindi adesso proviamo a farlo nella maniera più sintetica possibile:
"La gestione della rete comprende l'azionamento, l'integrazione e il coordinamento
di hardware, software ed elementi umani per monitorare, verificare, son-dare, con-
figurare, analizzare, valutare e controllare la rete e le risorse degli ele-menti per
soddisfare le prestazioni operative in tempo reale e i requisiti di qualità del servizio
(QoS) a un costo ragionevole". [5]
Modello ISO
12
1.3 Infrastrutture di rete Nel paragrafo precedente abbiamo visto che la gestione della rete richiede la
possibilità di "monitorare, verificare, sondare, configurare,... e controllare"
hardware e software e i componenti in una rete. Poiché i dispositivi di rete sono di-
stribuiti, questo richiederà come minimo che il responsabile della rete sia in grado
di ottenere dati (per esempio, a scopi di monitoraggio) da un'entità remota e di ef-
fettuare cambiamenti all'entità remota (per esempio, regolazioni) su quella remota
entità. Un'analogia umana risulterà utile per comprendere l'infrastruttura necessaria
per la gestione della rete.
Immaginate di essere a capo di una vasta organizzazione che ha filiali sparse
in tutto il mondo. Il vostro lavoro è assicurare che tutti i pezzi della vostra organiz-
zazione operino senza difficoltà. Come potete farlo? Come minimo, periodicamente
raccogliete dati dalle filiali in forma di rapporti e di varie misure quantitative di atti-
vità, produttività e budget. Occasionalmente (ma non sempre) vi sarà notificato e-
splicitamente che c'è un problema in una delle filiali; il manager di una filiale che
vuole salire i gradini della scala gerarchica della società può inviarvi un rapporto
non sollecitato che indica come le cose funzionino senza problemi nella sua filiale.
Voi ordinerete i rapporti ricevuti, sperando di trovare dovunque solo cose che fun-
zionano bene, ma senza dubbio troverete problemi che richiederanno la vo-stra at-
tenzione. Potrete iniziare un dialogo da-uno-a-uno con una delle filiali che ha pro-
blemi, ottenere più dati per comprendere meglio il problema e quindi passare un
ordine esecutivo ("Fate questi cambiamenti!") al manager della filiale.
In questo scenario umano molto comune è implicita un'infrastruttura per con-
trollare l'organizzazione: l’amministratore, il sito remoto sotto controllo (la filiale),
il vostro agente remoto (il manager della filiale), i protocolli di comunicazione (per
trasmettere i rapporti standard e il dialogo da-uno-a-uno) e i dati (il contenuto dei
rapporti e le misure quantitative di attività, produttività e budget). Ciascuno di que-
sti componenti nella gestione di un'organizzazione umana ha una controparte nella
Infrastrutture di rete
13
gestione della rete.
L'architettura di un sistema di gestione della rete è concettualmente identica
alla semplice analogia di organizzazione umana. Identifichiamo ora tre componenti
principali nell'architettura di gestione della rete [2]: un'entità di gestione, i dispositi-
vi da gestire e un protocollo di gestione della rete.
L'entità di gestione è un'applicazione, che tipicamente coinvolge un uomo,
funzionante in una stazione centralizzata di gestione della rete nel centro operativo
di rete (NOC). L'entità di gestione è il sito di attività per la gestione della rete; essa
controlla la raccolta, l'elaborazione, l'analisi e/o l'esposizione delle informazioni di
ge-stione. È da qui che partono le azioni per controllare il comportamento della rete,
ed è qui che i responsabili umani interagiscono con i dispositivi della rete.
Un dispositivo da gestire è una parte dell'equipaggiamento di rete (compreso
il suo software) che risiede sulle rete da gestire. Questa è la filiale nella nostra ana-
logia umana. Un dispositivo da gestire può essere un host, un router, un bridge, ecc.
All'interno di un dispositivo da gestire ci possono essere molti oggetti da gestire.
Questi sono parti reali di hardware all'interno del dispositivo (per esempio, la sche-
da di interfaccia di rete) e il set di parametri di configurazione per le parti di
hardware e software (per esempio, un protocollo di instradamento intradominio co-
me il RIP). Nella nostra analogia umana, gli oggetti da gestire possono essere gli
uffici all'interno della filiale . Questi oggetti da gestire hanno associate parti di in-
formazio-ni che sono raccolte in una base di informazioni per la gestione (MIB,
Management Information Base) [6]; vedremo che i valori di queste parti di informa-
zioni sono disponi-bili all’entità di gestione. Nella nostra analogia umana, il MIB
corrisponde ai dati quantitativi (misure di attività, produttività e budget, con l'ultimo
impostabile dall'entità di gestione!) scambiati fra la filiale e la sede. Infine, residen-
te anch'esso in ciascun dispositivo da gestire, c'è un agente di gestione della rete,
un processo funzionante nel dispositivo da gestire che comunica con l'entità di ge-
stione, che compie azioni locali sul dispositivo da gestire su comando e controllo
dell'entità di gestione. L'agente di gestione della rete è il manager della filiale nella
Infrastrutture di rete
14
nostra analogia umana.
La terza parte di un'architettura è il protocollo di gestione della rete. Il proto-
collo funziona tra l'entità di gestione e i dispositivi da gestire, permettendo all'entità
di gestione di chiedere lo stato dei dispositivi da gestire e indirettamente di agire su
essi attraverso i suoi agenti. Gli agenti possono usare il protocollo di gestione della
rete per informare l'entità di gestione degli eventi eccezionali (per esempio, guasti
dei componenti o violazione delle soglie di prestazione). È importante notare che il
protocollo di gestione della rete non gestisce la rete di per sé; piuttosto esso fornisce
uno strumento con cui il responsabile può agire ("monitorare, provare, sondare,
configurare, analizzare, valutare e controllare") sulla rete. Questa è una sottile ma
importante distinzione.
Infrastrutture di rete
15
Capitolo 2 Il protocollo SNMP 2.1 Introduzione al protocollo SNMP SNMP nasce nel 1989 e viene definito dalla Internet Engineering Task Force
(IETF)[7]; da quel momento SNMP diventa uno standard industriale per controllare
gli apparati di rete tramite un’unica applicazione di controllo. SNMP rappresenta
una serie di funzioni e protocolli per la gestione di rete che comunicano tra di loro
attraverso l’Internet Protocol (IP), infatti la prima implementazione avviene su pro-
tocollo TCP/IP, ma in seguito verrà sviluppato anche su reti IPX e AppleTalk. Que-
sto protocollo permette agli amministratoti di rete di individuare ed inseguito isolare
i componenti difettosi che si possono trovare su una rete, configurare i vari compo-
nenti in remoto e monitorare lo stato e le performance della rete.
SNMP è passato attraverso alcune revisioni fino all'attuale versione 3:
• SNMPv1: descritto nelle [8] rappresenta la prima versione, utilizza l'invio dei
nomi di community (utilizzati come password) in chiaro;
• SNMPv2: descritto nelle [9] in cui sono state aggiunte nuove funzionalità tra
cui la crittografia tramite MD5;
• SNMPv3: descritto nelle [10] è lo standard finale, ma al momento raramente
utilizzato;
Come altri protocolli dello Strato di Applicazione del modello OSI (livello 7),
SNMP utilizza normalmente l’UDP [11] (User Datagram Protocol) e un metodo di
comunicazione client/server. SNMP è composto da due parti:
• Manager, il manager è un’applicazione software che viene installata su un
computer della rete che verrà utilizzato come stazione di controllo
(Management Station) o Network Management Station (NMS); i software che
si trovano in commercio e anche in rete, gratuitamente, sono diversi e
Protocollo SNMP
16
soprattutto si trovano per tutte le piattaforme più diffuse (UNIX, PC e Macin
tosh) in modo da non obbligare l’amministratore di rete ad orientarsi su una
determinata piattaforma.
• Agenti e Agenti Proxy, gli agenti risiedono sui dispositivi della rete (switch,
router,…) e generano informazioni come i vari indirizzi di rete del dispositivo
oppure trasmettono statistiche sul traffico del nodo in cui sono installati. Le
informazioni vengono memorizzate all’interno di Management Information
Bases o MIBs.
Gli agenti proxy svolgono le stesse funzioni di un agente normale ma operano
per conto di dispositivi su cui non è implementato SNMP.
SNMP è un’implementazione di tipo client/server. L’applicazione client, chia-
mata Network Manager, crea una connessione virtuale verso un’altra applicazione
server, chiamata SNMP Agent, che gira su un dispositivo remoto come uno switch
o un router, vedi Figura 2.
Il database che viene gestito dall’agente SNMP è più comunemente conosciuto co-
me MIB (Management Information Base) ed è una raccolta di valori statistici e di
controllo riferiti al dispositivo. SNMP permette di estendere questi valori standard
con valori specifici per particolari necessità di un agente o di un utente sempre at-
traverso l’utilizzo dei MIBs, che vedremo in dettaglio in seguito.
Figura 2.1 Implementazione Client/Server
Protocollo SNMP
17
2.2 Considerazioni sul protocollo
Uno dei punti di forza di protocollo SNMP è la sua incredibile diffusione e la
capacità di adattarsi a qualsiasi dispositivo che faccia parte di una rete di computer,
infatti gli agenti SNMP si possono trovare su computer, bridge di rete, switch, rou-
ter, modem e anche stampanti. Il motivo per cui SNMP è nato e per il quale tuttora
è così diffuso è la sua interoperabilità. In più questo protocollo è flessibile ed esten-
sibile in base alle necessità che si presentano. Siccome le funzioni degli agenti
SNMP possono essere facilmente estese, per soddisfare le specifiche di ogni com-
ponente hardware, e soprattutto esiste un meccanismo abbastanza semplice per svi-
luppare le applicazioni software che poi dovranno interfacciarsi con certe tipologie
di agenti, SNMP dispone un grande numero di specifiche per la gestione non stret-
tamente legate alla gestione di apparati di rete, ma anche per esempio per la gestio-
ne di una stampante.
Dopo aver parlato dei motivi che hanno reso famoso questo protocollo, ora
illustriamo anche i suoi punti deboli. Innanzitutto a discapito del nome Simple
Network Management Protocol, SNMP è un protocollo molto complicato da imple-
mentare, per stessa ammissione dei progettisti, un nome più appropriato sarebbe
stato Moderate Network Management Protocol, ma anche questa definizione po-
trebbe sembrare alquanto generosa se si pensa alla complessità delle regole che co-
dificano questo protocollo. Un altro punto debole è l’efficienza del protocollo; in-
fatti molta banda utilizzata viene in realtà sprecata con informazioni inutili come
per esempio la versione del protocollo che viene trasmessa in tutti i pacchetti o altre
informazioni sui data descriptors inserite in ogni pacchetto. Il modo con cui il pro-
tocollo identifica le variabili (come le stringhe di byte, dove ogni byte corrisponde a
un particolare nodo in una database MIB) comporta un inutile spreco di buona parte
del messaggio.
Sebbene anche questo protocollo sia oggetto di critiche e non privo di imper-
fezioni, possiamo comunque dire che per quanto riguarda la complessità delle sue
Protocollo SNMP
18
regole, il problema è esclusivamente dei programmatori in quanto l’utente finale
non sarà mai in grado di capire a fondo la complessità degli algoritmi con i suoi dati
vengono trattati. Invece per quanto riguarda l’efficienza e l’occupazione di banda
possiamo dire che lo sviluppo delle tecnologie di comunicazione può nascondere
parzialmente il fatto che molte informazioni che viaggiano in pacchetti SNMP sono
in sostanza inutili.
Una delle critiche più difficili da spiegare sul protocollo SNMP nasce dalla
domanda: “Perché SNMP sebbene non abbia una visibilità, come altri tool di gestio-
ne di rete, è il più utilizzato?”. In effetti non esiste nessuna guida o nessun RFC il
quale dica che SNMP è meglio di altri tool come “telnet” o “netstat”. Come è possi-
bile che questo protocollo sia il più utilizzato senza avere alle spalle una serie di
documenti che attestino la sua superiorità rispetto ad altri tool? Quando si utilizza
telnet, si accede ad un dispositivo di rete e si scaricano tutte le informazioni neces-
sarie, non è la stessa cosa che fa SNMP?
Un altro problema che non chiarisce questa faccenda sono i venditori, infatti
chi vende software basati su SNMP li presenta semplicemente come una alternativa
alle shell remote piuttosto che un nuovo prodotto per la gestione e l’analisi della
rete; infatti l’attenzione viene posta sulla GUI (Grafical User Interface) anziché sul
sistema automatico di configurazione dei dispositivi, sulla raccolta di dati e sulla
capacità di lavorare su grandi network.
Per rispondere a tutte le domande che ci siamo posti, possiamo innanzitutto
che in effetti esistono vie alternative a SNMP ma sono state soppiantate dalla gene-
rale popolarità e interoperabilità di SNMP. La completezza di questo protocollo e la
sua capacità di adattarsi ad ogni dispositivo per realizzare tutte le funzioni di ammi-
nistrazione di rete, portano alla conclusione che di fatto non esistono alternativa a
SNMP; un altro aspetto da non dimenticare è il fatto che SNMP sia oggi il metodo
più efficace, e probabilmente il solo, per gestire network di grandi dimensioni.
Protocollo SNMP
19
2.3 L’evoluzione del protocollo SNMP
In questo paragrafo verrà fatta una panoramica abbastanza rapida sull’evolu-
zione del protocollo SNMP, poi i concetti principali verranno ripresi in seguito.
2.3.1 SNMP v1
Le caratteristiche principali del protocollo che nascono e si mantengono tali
anche dopo la realizzazione delle versioni successive sono:
• I moduli Agent sono in ascolto sulla porta UDP 161;
• Le risposte sono inviate alla Network Management Station (Manager) utiliz-
zando un numero di porta casuale;
• La dimensione massima del pacchetto SNMP è limitata solamente dalla mas-
sima dimensione del payload UDP(65507 byte);
• I messaggi di errore e le eccezioni (Trap) sono spediti dall'Agent al Manager
in maniera asincrona utilizzando la porta UDP 162.
Le principali operazioni del protocollo SNMPv1 sono:
• GET: utilizzata dal Manager per reperire un valore dal MIB dell'Agent
MANAGER
get
AGENTE
MIB
response
Evoluzione Protocollo SNMP
20
• GET-NEXT: utilizzata dal Manager per accedere ricorsivamente sul MIB.
• SET: utilizzata dal Manager per impostare un valore sul MIB.
• TRAP: utilizzata dall'Agent per inviare messaggi di errore al Manager.
MANAGER
getNext
AGENTE
MIB
response
MANAGER
set
AGENTE
MIB
response
MANAGER AGENTE
trap
Figura 2.2 Scambio di messaggi SNMPv1
Evoluzione Protocollo SNMP
21
Il protocollo SNMP assume che i canali di comunicazione siano connection-
less, quindi utilizza come protocollo di livello Transport, il protocollo UDP. Di con-
seguenza, il protocollo SNMP non garantisce l'affidabilità dei pacchetti SNMP.
Per concludere il discorso sulla versione 1 mostriamo nella figura in seguito il
formato del pacchetto SNMP che si articola in 3 parti:
• Numero di versione.
• Community String utilizzata come password.
• Uno o più payload di tipo SNMP.
Versione Community SNMP PDU
SNMP Message
Figura 2.3 Livello di scambio dei messaggi SNMP
Figura 2.4 Struttura Pacchetto SNMP
Evoluzione Protocollo SNMP
22
2.3.2 SNMP v2
Nella versione 2 del protocollo non sono state apportate modifiche sostanziali, seb-
bene la versione precedente del protocollo avesse molte limitazioni: presenza di re-
gole non documentate; codici di errori limitati; tipi di dato limitati; scarse prestazio-
ni; dipendenza dal protocollo di trasporto; assenza di gerarchia nell'architettura Ma-
nager/Agent; scarsa sicurezza. Possiamo sintetizzare le modifiche principali mo-
strando le due funzioni che sono state aggiunte GetBulk:
MANAGER
getBulk
AGENTE
MIB
response
E la funzione Inform che presenta una sostanziale novità dato che in questo caso è l’agente che interroga il manager per ottenere una informazione:
MANAGER AGENTE
MIB response
inform
Figura 2.5 Scambio di messaggi SNMPv2
Evoluzione Protocollo SNMP
23
2.3.3 SNMP v3
A partire dalla seconda metà del 1999 è disponibile una ulteriore versione del
protocollo SNMP, la versione 3. Poiché le differenze con le precedenti sono notevo-
li, ne vediamo le caratteristiche maggiormente innovative. Si tratta della terza ver-
sione del protocollo e nasce, in special modo, per sopperire alle mancanze dei suoi
predecessori nell’ambito della sicurezza delle trasmissioni. Questo protocollo è sta-
to pensato, inoltre, per essere scalabile, duraturo, per quanto riguarda la sua archi-
tettura, portabile, compatibile con le precedenti versioni (usa gli stessi MIB).
Nonostante ciò, la versione 3 non ha, almeno per ora, trovato grosso spazio
sul mercato, dove continua a farla da padrone la versione 1, forse anche perchè, no-
nostante fosse fra gli obiettivi di questa nuova versione, la maggiorazione del nume-
ro delle caratteristiche è andato a scapito della semplicità del protocollo.
La classica architettura di tipo Manager/Agent, nella versione 3, è stata sosti-
tuita da una più complessa composta da Motore ed Applicazioni. Infatti, un’entità
SNMP v.3 è composta da:
• Snmp-Engine (Motore) che contiene un Dispatcher (smistatore di messaggi),
un sottosistema per elaborare i messaggi, uno per la sicurezza e uno per il
controllo dell’accesso;
• Snmp-Applications (Applicazione): contiene un generatore di comandi, un
ricettore di notifiche, un risponditore ai comandi e altre funzioni.
Il formato dei messaggi di SNMP versione 3 è sostanzialmente diverso da
quello delle precedenti versioni; infatti include anche alcuni parametri di sicurezza
ed il controllo dell'accesso. Tramite appropriate politiche di sicurezza, SNMPv3
consente di accettare messaggi solo nel caso in cui alcune domande ricevano una
risposta affermativa o, comunque, valida come ad esempio:
• Il messaggio è autentico?
• Chi vuole eseguire una certa operazione? (Usa l'autenticazione con chiavi di
crittografia pubbliche e private)
Evoluzione Protocollo SNMP
24
• Quali oggetti sono coinvolti dall'operazione?
• Quali diritti di accesso ha il richiedente sull'oggetto al quale vuole accedere?
Queste politiche di sicurezza sono implementate tramite crittografia, funzioni di
hash e altri strumenti che consentono l'autenticazione dei pacchetti (ad esempio
contro un attacco di sniffing e ripetizione di pacchetto), delle password e, anche,
delle PDU (le quali possono essere codificate). Tramite diversi livelli di sicurezza si
può stabilire se consentire un accesso:
• senza autenticazione (no pwd/no Priv)
• con autenticazione (Pwd/no Priv)
• con autenticazione e codifica dei dati (pwd/Priv).
Evoluzione Protocollo SNMP
25
2.4 Standard SNMP
Dopo fatto una breve panoramica sulle tre versione dell’SNMP e sulla sua
evoluzione, passiamo adesso ad una analisi più dettagliata del protocollo e dei suoi
standard. Ci sono molti modi in cui affrontare l’analisi dell’SNMP e uno di questi è
vedere SNMP come tre standard distinti [12]:
1. Formato dei Messaggi, SNMP è un protocollo standard di comunicazione
che definisce dei messaggi in formato UDP. Questa parte dello standard ha
subito una notevole involuzione che non produce quasi nessuna conseguenza
per l’utente, ma suscita grande interesse per il programmatore.
2. Set di Oggetti, Il set di Oggetti in questione non è altro che un insiemi di va-
lori (che SNMP chiama “object), che possono essere richiesti a un dispositivo;
in questo set ci sono i valori utili al monitoraggio TCP, IP, UDP,… Ogni og-
getto è identificato da un nome ufficiale e con un identificatore numerico che
è espresso in dot-notation (per esempio 1.2.1.3.12).
3. Metodo standard per la creazione di un oggetto, certamente questa proprie-
tà è una della ragioni per cui si è affermato lo standard SNMP; infatti è possi-
bile estendere il set degli oggetti definendone di nuovi ad-hoc per il proprio
hardware in modo da poter così personalizzare i componenti prodotti.
Standard SNMP
26
2.4.1 Formato dei messaggi
Come abbiamo già visto in precedenza possono essere definite cinque tipolo-
gie di messaggi SNMP che sono: la richiesta “get” che come valore di risposta rice-
ve il nome dell’oggetto interrogato; la richiesta “get-next” richiede un altro nome o
valore di un oggetto che si trova su un altro dispositivo, che abbia un nome SNMP
valido; il comando “set” richiede a quale set di oggetti corrisponde un valore speci-
fico; il comando “response” viene generato dal dispositivo agente e serve ad inviare
i dati che sono stati richiesti dagli altri comandi; il comando “trap” viene generato
anch’esso dal dispositivo agente (quindi dal device di rete) in maniera asincrona
quando deve segnalare o notificare un evento speciale al network manager.
Tutti questi messaggi viaggiano sulla rete incapsulati in PDUs (Protocol Data Unit)
e lo scambio di questi tra i dispositivi avviene tramite protocollo SNMP. L’attuale
formato di questi messaggi non si può definire semplice o conveniente, ma fortuna-
tamente la loro complessità viene mascherata al manager dai software che li gesti-
scono.
Vediamo ora più in dettaglio questi comandi che sono stati creati per soddi-
sfare ogni esigenza di un amministratore di rete:
• GET REQUEST. L’amministratore può richiedere valori specifici tramite il
comando get per determinare le prestazioni e le condizioni di funzionamento
del dispositivo. Molti di questi valori possono essere determinati esclusiva-
mente analizzando i messaggi generati dal protocollo SNMP senza la necessi-
tà di creare un inutile overhead facendo il login sul dispositivo o stabilendo
appositamente una connessione TCP.
• GET NEXT REQUEST. Questo comando viene utilizzato dagli amministra-
tori per “navigare” sulla rete alla ricerca di tutti i dispositivi che supportano il
protocollo SNMP. Questa operazione di ricerca parte dal manager di rete e
viene reiterata da ogni nodo SNMP che incontra, sempre attraverso lo stesso
Standard SNMP
27
comando, fino a quando non viene riscontrato qualche errore; a questo punto
il manager è in grado di mappare tutti i nodi SNMP della rete di sua compe
tenza. Siccome in inglese questo processo di ricerca viene definito “walk”,
tutti i nomi degli oggetti MIB incontrati verranno definiti “walked”.
• SET REQUEST. Questo comando mette a disposizione del manager un me-
todo per effettuare delle operazioni associate al dispositivo di rete come ad
esempio disabilitare l’interfaccia, disconnettere degli utenti, pulire i registri,
ecc. In sostanza il “set” permette di configurare e controllare in modo remoto
il dispositivo tramite SNMP.
• GET RESPONSE. Questo comando viene utilizzato dal device di rete per
rispondere alle richieste che gli vengono inoltrate tramite get, get-next e set.
• TRAP MESSAGE. Un altro comando fornito dall’SNMP Standard che con-
siste in un meccanismo attraverso il quale i dispositivi di rete possono manda-
re delle comunicazioni sul loro stato ai network manager, generalmente questa
funzione viene utilizzata per notificare degli errori. Per ricevere i pacchetti
trap di solito è necessario configurare i vari dispositivi di rete in modo che
questi restino in attesa della ricezione.
Queste tipologie di messaggi appartengono alla prima versione del protocollo
SNMP, infatti questi comandi vanno integrati con altri tre comandi che sono stati
introdotti nella versione 2:
• GET BULK REQUEST. Questo comando serve ad accumulare in una unica
transazione request/response molte informazioni relative ad un dispositivo. In
pratica il get-bulk si comporta come una serie di interazione GetNext request/
response, eccetto nel caso in cui sia sufficiente una singola interazione.
Standard SNMP
28
• SNMPv2 TRAP REQUEST. Nella seconda versione è stato introdotto una
tipologia di messaggi trap che ha caratteristiche quasi identiche alla versione
precedente ma con qualche piccola differenza, perciò si è resa necessaria la
definizione di un nuovo messaggio trap.
• INFORM REQUEST. Questo comando non comunica valori nuovi, ma ha
solo la funzione di confermare la notifica di certi eventi al manager di rete.
Per concludere la panoramica sui messaggi vediamo in Figura come questi
PDUs vengono incapsulati dentro un messaggio Ethernet.
Figura 2.6 Incapsulamento dei messaggi
Standard SNMP
29
2.4.2 Messaggi TRAP
I messaggi TRAP sono dei messaggi che vengono inviati in maniera asincrona
da un Agente verso il Manager per segnalare degli eventi particolari. Le definizioni
di questi eventi si trovano nel [13]. I seguenti messaggi TRAP sono quelli che pos-
siamo incontrare più frequentemente:
• ColdStart - l’agente si è autonomamente avviato o riavviato e i dati potrebbe-
ro aver subito delle alterazioni.
• WarmStart - l’agente si è autonomamente riavviato ma non c’è stata alcuna
alterazione dei dati.
• LinkDown - una interfaccia connessa è passata dallo stato di link UP allo sta-
to DOWN
• LinkUp - una interfaccia connessa è passata in uno stato di link UP
• AuthenticationFailure - il nome della community per accedere al dispositivo
è errato
I messaggi seguenti sono altri messaggi TRAP, ma hanno un uso meno fre-
quente e anche una rilevanza minore al fine della gestione della rete:
• Enterprise - valore del sysObjectID (vedi oggetti MIB) dell’agente.
• Agent-addr - valore dll’indirizzo di rete dell’agente.
• Specific-trap - identificatore di un particolare messaggio TRAP.
• Time-stamp - tempo trascorso dall’ultimo avvio dell’agente.
• Variable-bindings - Lista di variabili contenenti informazioni sul messaggio
TRAP.
• Vendor-specific - specifici messaggi TRAP aggiunti dai produttori dei dispo-
sitivi.
Standard SNMP
30
2.4.3 Standard per gli oggetti SNMP
La lista dei valori che un oggetto può supportare è spesso chiamata SNMP
“Management Information Base” MIB. Capita di frequente che si senta abusare di
questo termine per descrivere ogni oggetto SNMP o una parte della gerarchia del
protocollo, mentre in realtà MIB è semplicemente un’astrazione come Database, a
cui possono essere attribuiti molti significati, che possono ingannare gli utenti meno
esperti.
La grande varietà di valori SNMP nello standard MIB sono definiti nel RFC
1213. Lo standard MIB include molti oggetti (valori) per misurare e monitorare le
attività IP, TCP e UDP, l’instradamento IP, le connessioni TCP, le interfacce e il
sistema in generale. Tutti questi valori sono associati ad un nome ufficiale (come ad
esempio sysUpTime, che misura da quanto tempo è acceso il device dall’ultimo av-
vio) e un valore numerico ufficiale espresso in dot-notation ( il numero identificati-
vo del sysUpTime è 1.3.6.1.2.1.1.3.0). Si può facilmente intuire che è preferibile
esprimere le varie funzioni con il proprio nome piuttosto che in dot-notation, un po’
come succede con gli indirizzi di Internet dove è preferibile memorizzare un nome
piuttosto che un indirizzo IP. Nel prossimo paragrafo poi si parlerà diffusamente dei
MIB.
Figura 2.7 Traduzione di un valore in dot-notation [14]
Standard SNMP
31
2.4.4 Estensione delle funzioni SNMP
Come si diceva in precedenza uno dei punti di forza del protocollo è la sua
facilità di manipolazione ed estensione, infatti possiamo affermare che SNMP è di-
ventato lo standard principale nella gestione delle reti per la sua capacità di aumen-
tare l'insieme degli oggetti standard del MIB con nuovi valori specifici per le deter-
minate applicazioni e determinati dispositivi. Una funzione può essere aggiunta sen-
za particolari problemi, poiché è stato definito un metodo standard per incorporare
nuove funzionalità nei dispositivi dello SNMP e nei software che gestiscono la rete;
questo standard è di solito seguito da un il processo che solitamente viene chiamato
"compiling new MIB” (compilare un nuovo MIB), che permette all'utente di ag-
giungere le definizioni del nuovo MIB sul sistema. Queste definizioni sono fornite
solitamente dai tutorial dell’azienda, che produce il device, in file di testo special-
mente formattate usando la sintassi standard ASN.1. [15] (ASN.1 fa riferimento alla
“Abstract Syntax Notation One”, che è un tipo linguaggio dichiarativo di non sem-
plice comprensione, adottato da SNMP ed usato anche per altre applicazioni, come
crittografia e CMIP protocol).
Da notare che il MIB di un dispositivo SNMP è solitamente fisso; viene pro-
gettato e implementato dalla casa produttrice del device e in genere non può essere
aggiunta nessuna funzione o modificata una già esistente. Per questo motivo quando
si parla di estendibilità SNMP ci si riferisce al software che amministra il protocollo
SNMP, infatti è il software che può essere facilmente compilato o ricompilato per
interfacciarsi con le funzioni aggiuntive del dispositivo di rete.
Standard SNMP
32
2.5 MIB
Per usare efficacemente SNMP, gli utenti devono conoscere SNMP
Management Information Base (MIB), che definisce tutti i valori che il protocollo è
in grado di leggere o di settare. Per diventare esperto in SNMP, un manager
network deve per forza approfondire la sua conoscenza del MIB.
SNMP MIB è organizzato con una struttura ad albero, molto simile a quella
usata dai pc per organizzare i files in directory come si vede in Figura.
Come si vede dalla figura la cartella radice (root) non ha nome, poi seguono le tre
cartelle principali in cui sono contenuti tutti i sottoalberi che contengono le defini-
zioni di tutti gli standard tra cui anche Internet che è contenuto in una sottocartella
di ISO (International Organization for Standardization), il nostro interesse infatti
cade sul contenuto del sottoalbero Internet.
Figura 2.8 Albero MIB – Root and Subtree
MIB
33
L’insieme di standardizzazioni che riguardano Internet possono essere suddivise in
quattro rami principali (come si vede nella Figura 2.9):
• i rami “directory” e “experimental” sono sostanzialmente privi di valori e og-
getti che abbiano un significato rilevante;
• il ramo “management" è molto importante per il nostro studio e contiene tutti
gli standard degli oggetti supportati da tutti i dispositivi della rete (o perlome-
no la grande maggioranza);
• il ramo "private" invece contiene le definizioni degli standard per gli oggetti
SNMP creati dai vari produttori e implementati sui propri dispositivi.
La struttura ad albero descritta è una parte integrante dello standard SNMP,
comunque le parti su cui porremo l’attenzione sono le “foglie” (leaf) di questo albe-
ro, ossia gli standard che realmente definiscono le funzioni a disposizione dell’am-
ministratore di rete.
Figura 2.9 Albero MIB - Leaf
MIB
34
2.5.1 Classificazione MIB
Generalmente, gli oggetti SNMP possono essere divisi in due categorie simili
ma con piccole sostanziali differenze che riflettono l'organizzazione in una struttura
ad albero[12]:
1. Discrete MIB Objects. Gli oggetti “discreti” SNMP contengono solamente
una parte precisa e ben definita dei dati utili alla gestione. Questi oggetti sono
spesso distinti dai Table Objects (descritti sotto) aggiungendo un'estensione
“.0”(dot-zero) ai loro nomi (se l'estensione “.0” viene omessa da un nome di
un oggetto SNMP, è sempre considerata implicita).
2. Table MIB Objects. Gli oggetti SNMP definiti “table”(tabella) contengono
parti multiple di dati o valori per la gestione. Questa categoria di oggetti si
distingue dagli oggetti “discrete” aggiungendo “.” (dot-extension) ai loro no-
mi seguito da un numero che distingua unicamente il valore particolare a cui
si fa riferimento.
La dot-extension si riferisce in certa letteratura al numero dell’istanza dell’og-
getto SNMP. Nel caso degli oggetti "discrete", questo numero sarà zero, mentre nel
caso degli oggetti “table”, questo numero sarà l'indice nella tabella SNMP.
2.5.1.1 Discrete MIB Objects
Molti oggetti SNMP sono discreti, questo significa che l'operatore deve sol-
tanto conoscere il nome dell’oggetto e nessun’altra informazione. Gli oggetti discre-
ti rappresentano spesso dei valori standard di un dispositivo, particolarmente utili
per ricavare informazioni dalla rete al fine di monitorare e soprattutto confrontare le
prestazioni dei dispositivi di vari produttori. Se l'estensione (numero dell’istanza)
dell’oggetto non è specificata, esso viene presupposto come “0” (dot-zero).
MIB
35
2.5.1.2 Table MIB Objects
Le tabelle SNMP sono dei tipi speciali di oggetti SNMP, che permettono di
raggruppare una serie di dati che un dispositivo deve supportare. Le tabelle vengono
distinte dagli oggetti discreti, in quanto possono svilupparsi senza limiti. Per esem-
pio, SNMP definisce l'oggetto “ifDescr” (come oggetto standard SNMP) che indica
la descrizione testuale di ogni interfaccia supportata dal dispositivo in questione;
visto che i vari dispositivi della rete possono essere configurati con più di un'inter-
faccia, questo oggetto è ovvio che non può essere rappresentato con un singolo va-
lore ma solo con un insieme di valori come un array.
Per convenzione gli oggetti SNMP sono sempre raggruppati in una “Entry
Directory”, all'interno della quale ogni oggetto viene definito con il suffisso
“Table” (per esempio l'oggetto “ifDescr” descritto precedentemente si trova nella
directory “ifEntry” contenuta a sua volta nella directory “ifTable”).
Il protocollo prevede parecchi vincoli sugli oggetti SNMP come vedremo nel-
l’elenco che segue:
1. Ogni oggetto dell’”Entry Directory” di una tabella deve contenere lo stesso
numero di elementi come gli altri oggetti gli altri oggetti contenuti nella stessa
“Entry Directory”, dove il numero delle istanze di tutti i valori è lo stesso. Gli
oggetti della tabella si possono considerare come insiemi omogenei di dati.
2. Nella creazione di un nuovo oggetto Entry, SNMP richiede che un valore sia
associato con ogni tabella Entry in un singolo messaggio SNMP (PDU). Ciò
significa che per creare una riga in una tabella, tramite il comando SET, un
valore deve essere specificato per ogni elemento della riga.
3. Se si vuole cancellare una riga della tabella, SNMP richiede che almeno un
oggetto che abbia un elemento di controllo che sia in grado di realizzare la
cancellazione desiderata. Questo procedura è necessaria solo quando si can-
cella una riga e non quando si cancella una tabella SNMP.
MIB
36
2.6 Tipologie di oggetti MIB
Gli oggetti MIB sono caratterizzati da specifici tipi di valori e il protocollo è
molto rigido nella definizione di questi “primitive types”:
• Text Type MIB Objects. SNMP definisce un tipo “DisplayString” che può
contenere qualsiasi tipo di informazione testuale (solitamente con un massimo
di 256 caratteri). Il testo può contenere solo i caratteri stampabili. Gli esempi
di questo tipo di oggetto includono il “sysDescr” e i valori “ifDescr”. Questo
tipo di oggetto è abbastanza comune come oggetto MIB.
• Counter Type MIB Objects. SNMP definisce contatore, quella tipologia di
valori che possono essere solo incrementati. Il contatore è il tipo più diffuso di
oggetto MIB standard ed include oggetti come “ipInReceives”,
“ipOutRequests” e “snmpInPkts”. Il contatore può raggiungere un valore mas-