Capitolo 1

(1)

Capitolo 1

1.1 Network Management

Un sistema di Network Management è composto da un insieme di componenti hardware e software che permettono di monitorare e controllare le risorse della rete [1].

Gli elementi principali che caratterizzano l’architettura di un sistema di controllo e gestione della rete sono due: il manager e l’agent. Entrambi utilizzano e condividono un software di gestione (network management entity) che deve essere in grado di svolgere determinate funzioni quali:

1) raccogliere statistiche sull’attività di tutta la rete 2) memorizzare all’interno di database queste informazioni

3) rispondere a determinati comandi mandati dal centro di controllo della rete - cambiare un parametro (es. un timer utilizzato in un protocollo di

(2)

- generare traffico artificiale per eseguire un test, etc

Il ruolo di Manager deve essere ricoperto almeno da un host all’interno del Network Management system ed ha il compito di inviare richieste e comandi agli altri host presenti nella rete. Oltre al network management entity, il Manager deve avere un software denominato network management application (NMA).

L’NMA mette a disposizione, tramite un’apposita interfaccia, le funzioni necessarie per gestire la rete .

Gli agents sono rappresentati da tutti i restanti nodi della rete che fanno parte del network management system ed hanno il compito di rispondere (qualora sia possibile ) alle richieste fatte dal manager.

Il software di gestione, per poter eseguire tutte le sue funzioni, deve avere accesso ad una base di informazioni per la gestione (MIB). La MIB di un agent contiene le informazioni che riflettono la configurazione e il comportamento di questo nodo, oltre ad una serie di parametri che possono essere utilizzati per poter controllare le operazioni su di esso. La MIB di un manager include anche delle specifiche informazioni riguardanti tutti gli agents sotto il suo controllo.

Un network management system può essere organizzato secondo varie architetture: 1) centralizzata, in cui vi è una singola stazione di controllo che consente al

manager di controllare l’intera configurazione, bilanciando e ottimizzando l’utilizzo delle risorse di rete (Fig 1.1)

(3)

NMA Comm _Comm Comm OS Comm NME OS Manager Agent (router)

NME Appl NME Appl

NME Appl OS OS Agent (server) Agent (workstation) Network Network

NMA = Network Management Application NME = Network Management Entity Appl = Application

Comm = sotware di comunicazione OS = software di comunicazione

Figura 1.1: architettura centralizzata di un network management system

2) distribuita, in cui più manager controllano e monitorano diverse zone della rete (Fig 1.2).

Questo tipo di strategia offre un gran numero di vanataggi quali, ad esempio:

- Il traffico generato dal Network Management System è minimizzato poiché la maggior parte del traffico è confinato nelle zone locali

- Aumenta la scalabilità del sistema: per incrementare la capacità di gestione basta aggiungere un nuovo manager nella zona desiderata

(4)

- L’utilizzo di più stazioni di controllo permette una maggiore affidabilità del sistema, in quanto il guasto di una singola stazione non influenza le zone monitorate dagli altri manager

Pc Workstation network network network network Pc Management clients MIB MIB Management Management Server Server Server Router proxy Host

Figura 1.2: architettura distribuita di un network management system

I management client forniscono all’utente l’accesso ai servizi di gestione e a seconda del livello di autorizzazione, un client può accedere ad uno o più management server, i quali contengono le MIB e anche un set di applicazioni di management.

Quando sia il manager che l’agent condividono il medesimo software dedicato alla gestione della rete , si parla di gestione diretta.

Quando invece, un componente della configurazione non supporta il software necessario al network management allora la gestione viene effettuata tramite PROXY (Fig 1.3). In questo caso un manager che desidera controllare questo componente oppure ottenere informazioni, comunica con il proxy-agent, che traduce la richiesta del manager in una

(5)

forma appropriata per il nodo da monitorare, permettendo così un’effetiva comunicazione tra quest’ultimo e il manager.

IP SNMP

processo gestore

Stazione di

gestione Stazione gestita _{dal proxy}

DATALINK IP UDP SNMP processo agente funzione di conversione processo di gestione architettura dei protocolli utilizzata dal dispositivo mediante il proxy architettura dei protocolli utilizzata dal dispositivo mediante il proxy Network

Network Network_Network

UDP

PHYSICAL PHYSICAL PHYSICAL PHYSICAL

DATALINK DATALINK DATALINK

Figura 1.3: gestione effettuta tramite Proxy

1.2 Network Monitoring

Con questo termine, si indica la funzione del network management system dedicata all’osservazione ed all’analisi dello stato e del comportamento di un end-system, o più in generale di una sottoporzione della rete.

(6)

Per prima cosa definiamo le informazioni che vengono scambiate tra il manager e l’agent, ed il modo in cui una stazione di controllo le può ottenere, cercando di rendere quest’ultima procedura più efficiente possibile.

Le informazioni riguardanti le risorse di rete sono divise in tre categorie:

- Statiche: sono tutte le informazioni che cambiano raramente, come alcune caratteristiche di configurazione di un sistema (es. numeri di identificazione delle interfacce di un router)

- Dinamiche: sono le informazioni legate agli eventi della rete, come il numero di pacchetti trasmessi il numero di errori rilevati su una certa interfaccia.

- Statistiche: sono i valori “medi” ricavati dalle informazioni dinamiche (es: media dei pacchetti trasmessi per unità di tempo )

Le tecniche utilizzate per rendere disponibili al manager le informazioni raccolte negli agent sono due:

1) POLLING: Questa tecnica è quella che viene maggiormente utilizzata nella gestione di reti tramite SNMP ed è quella che verrà prevalentemente utilizzata all’interno di questa tesi. Essa si basa su un’interazione di tipo richiesta/risposta: il manager invia un messaggio all’agent nel quale vengono richiesti i valori di alcuni elementi informativi, ed esso risponde inviando i valori contenuti nelle proprie MIB (Fig 1.4).

2) Event Reporting: Questa tecnica prevede che l’agent periodicamente invii al manager messaggi informativi sul proprio stato, senza che sia stata fatta alcuna richiesta da parte della stazione di controllo. L’invio di questo tipo di messaggio può anche non essere periodico, infatti l’agent potrebbe “avvisare” il

(7)

manager di un avvenuto errore, non appena venisse notata un’anomalia, come un guasto (fault) o un cambiamento di stato.

Figura 1.4: Polling e Event Reporting

La differenza più evidente tra le due tecniche sta nel ruolo che ricoprono agent e manager; infatti, mentre nel polling il manager ricopre un ruolo attivo (invia le richieste), nell’event reporting il suo ruolo è semplicemente quello di “ascoltatore”, e l’elemento attivo è rappresentato dall’agent.

La scelta di uno dei due metodi per ottenere le informazioni deve essere fatta alla luce delle esigenze particolari di ogni sistema: entrambi i metodi presentano infatti aspetti negativi e positivi relativamente al tipo di rete da monitorare e relativamente al tipo di informazioni che un utente vuole raccogliere. Per questo motivo, un network management system, impiega entrambi i metodi e privilegia l’uno rispetto all’altro a seconda di certi fattori, quali il tempo di ritardo nella notifica di un evento al manager, la robustezza in situazioni critiche etc..

Il network monitoring può essere analizzato facendo riferimento ai tre aspetti fondamentali che lo compongono :

- gestione delle prestazioni - gestione dei fault

- gestione dell’accounting

• GESTIONE DELLE PRESTAZIONI

Quest’area del network monitoring si occupa della capacità da parte del sistema di gestione di misurare le prestazioni della rete in base a determinate funzioni quali :

(8)

- analisi delle prestazioni: per mezzo di determinati software sono organizzati e resi disponibili tutti i dati

- generazione artificiale di traffico: permette di osservare la rete in condizioni di traffico controllato

La parte principale della gestione delle prestazioni è essenzialmente la costruzione di indici che misurino in qualche modo le prestazioni del sistema. La loro analisi porta il manager a conoscere le performance di una rete e, quindi, ad apportare opportune modifiche (laddove sia possibile), nel momento in cui i valori riscontrati non risultino soddisfacenti.

La scelta degli indici deve rispettare due proprietà cardine, che permettono al network monitoring di essere efficiente:

- non ambiguità: gli indici devono poter essere sempre interpretati correttamente

- breve tempo di calcolo: il calcolo degli indici non deve essere troppo lungo, in modo tale che il risultato finale possa essere effettivamente usato per il controllo dell’evoluzione del sistema

Gli indicatori possono essere divisi in due gruppi:

- orientati al servizio (service oriented): che tengono conto se il servizio offerto all’utente risulta essere soddisfacente.

- orientati all’efficienza (efficiency-oriented) .

Da un’analisi più dettagliata, come potremo osservare nel quinto capitolo di questa tesi possiamo definire gli indicatori più significativi

- accessibilità (service-oriented): rappresenta la percentuale di tempo che un componente o un‘ applicazione risulta accessibile all’utente; dipende dall’affidabilità dei componenti della rete (intesa come la probabilità che un particolare componente esegua una funzione per un dato periodo di tempo sotto specifiche condizioni) e dall’organizzazione stessa del sistema.

(9)

- accuratezza (service-oriented): rappresenta la percentuale di tempo in cui non si verificano errori nella trasmissione delle informazioni.

- Throughput (efficiency-oriented): rappresenta la velocità con la quale avvengono particolari eventi come il trasferimento di file;

- Utilizzazione (efficiency-oriented): rappresenta la percentuale di capacità teorica di una risorsa effettivamente utilizzata. Quest’indicatore viene utilizzato per la ricerca (preferibilmente per la prevenzione) dei così detti “colli di bottiglia” della rete, ovvero quei punti dove quest’ultima risulta congestionata.

• GESTIONE DEI FAULT

La gestione dei possibili guasti, ha come obbiettivo principale quello di identificare gli errori il più velocemente possibile e di individuarne la causa per poter adottare le giuste contromisure.Oltre che localizzare ed isolare un fault (errore di collegamento, errore di trasporto , errore di applicazione ), la gestione dei guasti ha la funzione di prevenire il verificarsi di un errore: proprio per questo, viene introdotto il concetto di soglia di allarme, che rappresenta il valore massimo o minimo di una variabile monitorata che non deve essere mai superato.

Il manager qualora sia superata la soglia di allarme agisce in modo da “contenere” l’evoluzione del guasto.

• GESTIONE DELL’ACCOUNTING

Lo scopo principale della gestione dell’accounting è quello di fornire al manager la conoscenza dell’utilizzo delle risorse di rete da parte degli utenti, in modo che nessuno di questi possa abusare del suo privilegio di accesso alle risorse.

(10)

1.3 Network Control

Un Network Management System deve provvedere non soltanto al monitoraggio della configurazione di rete, ma deve anche controllarla, modificando alcuni parametri di un componente della rete, in modo che esso reagisca secondo uno schema predefinito di azioni noto al manager. Può essere diviso in due principali aspetti:

- la gestione della configurazione: l’attuazione di tutte le modifiche che si rendono necessarie in seguito ad eventuali cambiamenti interni alla rete (ad esempio, come bypassare un determinato guasto su un link, etc…) - la gestione della sicurezza: la protezione da fornire ad ogni risorsa di

rete, nei confronti di eventuali attacchi da parti esterne alla rete, in maniera tale che le informazioni di un sistema siano accessibili in lettura solo per chi possiede l’autorizzazione per farlo (segretezza), i dati, l’hardware e il software possano essere modificati solo da chi è autorizzato, e infine l’accesso a queste risorse sia possibile solo per chi è autorizzato.

1.4 Simple Network Management Protocol

Le management station e le agent station, comunicano tra loro tramite un protocollo di Network Management chiamato SNMP.

Questo particolare protocollo, dello strato applicativo, facilita lo scambio di informazioni di gestione tra i vari elementi presenti nella rete. Esso permette quindi all’ amministratore della rete di individuare e risolvere problemi e conoscere inoltre, istante per istante, lo stato dei vari nodi. I nodi gestiti possono essere router, switch, bridge, hub, host o qualsiasi altro dispositivo capace di comunicare le proprie

(11)

informazioni di sistema. Questi hanno installato al loro interno un agent SNMP che raccoglie e memorizza varie informazioni di gestione. Le operazioni che sono supportate possono permettere ad un manager di ottenere e modificare determinati valori degli oggetti (MIB) all’interno degli agent.

Figura 1.5: architettura del messaggio SNMP

Nella figura (Fig 1.5) in alto come possiamo osservare, è illustrato il “percorso” di un messaggio SNMP attraverso la pila OSI.

Ogni dispositivo conserva al suo interno una o più variabili, dette oggetti, che descrivono il suo stato. L’insieme di tutti questi oggetti è contenuto all’interno di una struttura dati chiamata MIB (Management Information Base ). La struttura di una MIB deve rispettare determinate proprietà che sono definite in accordo con le regole dello SMI ( Structure of a Management information) [2] (RFC 1155). Lo SMI provvede a standardizzare il modo di rappresentazione delle MIB attraverso:

- tecniche standard per la definizione di una particolare MIB

- tecniche standard per definire singole variabili, specificando la sintassi e i valori assumibili che questi oggetti possono assumere

(12)

-

tecniche di encoding per questi oggetti

1.5 Structure of Management Information

Una base di informazioni di gestione (MIB) può essere pensata come un grande “deposito” contenente vari oggetti da gestire, ognuno dei quali è riferito ad una particolare risorsa di rete (Fig 1.6).

root

ITU-T (0) ISO (1) Joint ISO/ITU-T (2)

Standard (0) Iso Member body (2) ISO identified Organizzaton(3) Dod (6)

Internet (1)

directory(1) experimental (3) management (2)

private (4) security (5) snmpv2 (6) mail (7) Mib-2 (1)

System (1) Address tr(3) Icmp (5) udp (7) cmot (9) snmp (11) Interface (2) Ip (4) tcp (6) egp (8) transmission (10)

(13)

Come si può osservare dalla figura, gli oggetti all’interno di una MIB, sono organizzati secondo una struttura ad albero (tree structure), i cui nodi vengono identificati sia da un nome che da un numero intero positivo; in questo modo è possibile identificare qualsiasi nodo e qualsiasi foglia dell’albero attraverso una sequenza di nomi (object name) o di numeri (object identifier) che specificano il percorso dalla radice al punto interessato. E’ facile osservare che l’identificativo di un determinato oggetto deve essere necessariamente unico, per questo motivo in un sottoalbero (sub-tree) non possono esserci più oggetti ai quali viene associato il solito numero intero. Partendo dalla radice, possiamo individuare tre nodi :

- L’international Organization for Standardization (ISO), a cui è associato il numero (1)

- Il Telecomunication Standardization Sector of the International Telecomunication Union (ITU-T), numero (0)

- Il Joint ISO / ITU- T (2), che mette a comune i due organismi citati.

Sotto uno dei rami dell‘ISO, in particolare quello relativo all’ISO identified organization (3), si possono trovare le entry per gli standard pubblicati dalle organizzazioni dei vari paesi membri dell’ISO; uno di questi è rappresentato dal dod (6) (US DEPARTEMENT OF DEFENSE), dal quale deriva il nodo internet (object identifier = 1.3.6.1)

Al di sotto del nodo internet troviamo sette nodi tra cui i più importanti per l’analisi di rete sono:

- management: questo sottoalbero contiene le definizioni delle MIB approvate dall’ IAB (Internal Activities Board). Osserviamo che attualmente esistono due versioni: la MIB-1 definita nella RFC 1156; e la MIB-2 definita nella RFC 1213. Entrambe sono identificate dallo stesso object identifier = 1.3.6.1.2.1.

(14)

- experimental: utilizzato per identificare oggetti che non sono ancora standard

- private: utilizzato per identificare gli oggetti creati dai vendors (quali Juniper, Cisco, IBM etc..) per gestire specifiche variabili presenti in un loro prodotto. In questa tesi le MIB private rappresentano un ruolo chiave per poter analizzare il router M-10 Juniper, in quanto contengono moltissime informazioni sul protocollo Class of Service.

1.5.1 MIB –II

La MIB-II rappresenta, la seconda versione della base di informazioni di gestione e il suo sottoramo è suddiviso in più gruppi, ognuno dei quali presenta diverse informazioni per la gestione e l’analisi della rete. In particolare i valori che possiamo trovare al di sotto del ramo MIB-II sono:

- system: include informazioni generali sul sistema (ad esempio, la locazione fisica di un nodo, chi è il suo amministratore, etc..)

- interfaces: contiene informazioni generali riguardanti le varie interfacce fisiche che collegano il sistema alla rete.

- ip: contiene informazioni riguardanti le operazioni e l’implementazione dell’IP sul nodo.

- icmp: presenta informazioni sull’implementazione dell’ ICMP (internet Control Message Protocol )

- tcp: permette di visualizzare le informazioni relative al TCP su un determinato nodo

- udp: contiene informazioni sull’implementazione dell’UDP.

- transmission: Comprende tutte le informazioni che riguardano i mezzi di trasmissione associati ad ogni interfaccia del sistema

(15)

- snmp: Informazione riguardanti implementazione ed esecuzione di SNMP in quel sistema.

1.6 Funzionamento del protocollo SNMP

Per poter “sfogliare” le Mib disponibili su un determinato nodo della rete, e quindi far comunicare tra loro manager e agent, è necessario come detto utilizzare il protocollo SNMP. Con l’aumentare della complessità della rete, il numero di manager e di agenti cresce, ed aumenta quindi anche la complessità delle relazioni tra le varie entità. Per questo motivo ogni agent deve proteggere e regolare l’accesso alle proprie MIB. Vi sono quindi due aspetti che caratterizzano questo tipo di controllo:

• l’authentication service: ogni stazione da gestire limita l’accesso alle proprie MIB solo ad alcuni manager autorizzari

• l’access policy: ogni agent fornisce ai vari manager differenti privilegi di accesso alle informazioni di gestione.

La versione dell’SNMP[ RFC 1157], introduce una prima protezione nella comunicazione, introducendo il concetto di community.

Una SNMP community definisce sia il metodo di autenticazione sia la politica di controllo degli accessi. Ad ogni community viene assegnato un nominativo unico (community name) che sarà noto a tutte le stazioni (manager ed agent) coinvolte in quella particolare relazione. Quindi, il community name svolge il ruolo di parola chiave nella comunicazione tra le varie stazioni di servizio, garantendo una limitata autenticazione nella richiesta di informazioni. Il community name sarà presente in ogni messaggio SNMP inviato e verrà considerato valido nel momento in cui siano compatibili il nominativo di comunità della

(16)

stazione trasmittente ed il nominativo di comunità della stazione ricevente. Ogni agent può definire più comunità associate ad un particolare sottoinsieme di MIB (SNMP MIB view) caratterizzate da una particolare modalità di accesso: o di solo lettura, o di lettura e scrittura.

1.6.1 Formato di un messaggio SNMP

Ogni messaggio SNMP(Fig 1.7), comprende oltre alla versione dello standard protocollo (SNMP v1, SNMP v2 , SNMP v3) ed al Community Name, uno dei cinque tipi di PROTOCOL DATA UNITS (PDU) che permettono di implementare la diverse operazioni previste, e sono:

- GetRequest - GetNextRequest - SetRequest - GetResponse - Trap

(17)

Name 1 Value 1 Name 2 …. …. ….. …. Name N Variable Bindings

PDU TYPE Request Id Error Error Variable Bindings Status Index

SNMP PDU

SNMP MESSAGE

Version Community Name SNMP PDU

Figura 1.7: Formato messaggio SNMP In particolare il messaggio SNMP è costituito dai seguenti campi:

- version: specifica la versione del formato SNMP

- community: contiene il nominativo della comunità

- request id: fornisce ad ogni particolare richiesta un unico identificativo

- error status: è utilizzato per indicare che è avvenuto un errore mentre veniva inviata o

ricevuta una richiesta SNMP : i possibili valori assumibili sono cinque : noError(0), tooBig(1), noSuchName(2), badvalue(3), readonly (4), genErr (5)

- error index: identifica quale variabile nel campo Variable Bindings è errata quando il

valore ricevuto nell’error status è diverso da zero.

- variable bindings: è una lista di vari nomi di oggetti con i rispettivi valori

- enterprise: identifica il sottosistema che ha generato un messaggio di tipo trap

- agent addr: contiene l’indirizzo IP dell’agent che ha mandato un messaggio di tipo

trap

- generic trap:specifica il tipo di messaggio trap generato

(18)

- time-stamp: è il tempo trascorso tra l’ultima reinizzializzazione dell’entità che ha

generato il messaggio trap ed il messaggio stesso.

Le operazioni che devono essere compiute in successione da un SNMP entità per poter trasmettere uno dei cinque possibili tipi di PDU sono le seguenti:

In primo luogo è importante definire la notazione con cui la PDU viene costruita, e questa è definita ASN.1 che può essere osservata nell’RFC 1157.

Tramite questa notazione è possibile quindi, descrivere e visualizzare vari tipi di informazioni che un manager può richiedere; uno studio più approfondito dell’ASN.1 può essere osservato nel capitolo 3 di questo lavoro di tesi.

Dopo aver costruito la PDU, essa è passata, insieme agli indirizzi di sorgente e di destinazione ed un community name, ad un servizio di autenticazione. Quest’ultimo quindi compie determinate operazioni (es: inserimento di un codice di autenticazione) e fornisce il risultato ottenuto, che verrà inserito nel messaggio SNMP che conterrà inoltre sia la versione che il nominativo della comunità. Infine il messaggio verrà codificato usando le regole base di cifratura e passato ad un servizio di trasporto.

Per quanto riguarda la ricezione di un messaggio SNMP, verrà inizialmente effettuato un controllo della sintassi e della versione del messaggio ricevuto, che può essere scartato qualora siano riscontrati errori, in seguito sarà passata ad un servizio di autenticazione sia la porzione relativa all PDU, sia l’indirizzo di sorgente e di destinazione.

1.6.1.1 GetRequestPDU

Questo tipo di PDU viene inoltrata da una stazione di controllo ad un agent per ottenere il valore di una o più variabili contenute all’interno della MIB della stazione in gestione (Fig 1.8). I nomi delle variabili interessate da questo tipo di procedura sono specificate all’interno del campo variablebindings.

(19)

La stazione ricevente risponde inviando un messaggio di risposta chiamato GetResponsePDU, contenente sia lo stesso campo request-id presente nella GetRequestPDU inoltrata, che il campo variablebindings, all’interno del quale sono inseriti i valori delle variabili richieste. Quando una di queste variabili, non può essere fornita al manager, nessun valore delle variabili richieste viene restituito; per questo motivo l’operazione GetRequestPDU, viene definita atomica.

GET PDU request-id 0 0 request-id Response PDU variablebindings variablebindings Tipo di

PDU Error-status Error-index

Figura 1.8: PDU della GetRequest e della GetResponse Le condizioni di errore che possono verificarsi sono le seguenti:

- il nome di un oggetto incluso nel campo variablebindings non corrisponde ad alcun object identifier all’interno dell’ SNMP MIB view. In questo caso, la PDU di risposta ha un error-status contenente il valore

noSuchName, ed un valore all’interno del campo error-index indicherà

(20)

- La dimensione della PDU di riposta risulta essere maggiore di una limitazione locale, in questo caso il campo error-status è impostato al valore toobig.

- La stazione ricevente non è capace di soddisfare tutte le richieste del manager per un motivo non contemplato dai quattro tipi di errore specifici possibili, in questo caso l’error-status contiene il valore genErr.

1.6.1.2 GetNextRequestPDU

Questo tipo di PDU ha il solito formato della GetRequestPDU e si differenzia da quest’ultima solo per il fatto che, per ogni variabile presente nella “lista” variablebindings viene restituito il valore dell’elemento successivo nella MIB (Fig 1.9).

Figura 1.9: PDU della GetNextRequestPDU

Attraverso l’utilizzo di questa PDU, il manager può scoprire qual è la struttura di una MIB, senza doverla conoscere a priori, ed inoltre, può ottenere tutti i valori all’interno di una tabella, nonostante non conosca nulla a riguardo di essa, incluso il numero di righe che la compongono. Il manager, infatti, si accorge della fine di una tabella, nel momento in cui i nomi degli oggetti inclusi nella lista della PDU di riposta risultano essere differenti da quelli richiesti.

Anche l’operazione GetNextRequest, così come la GetRequest, viene definita atomica, ovvero vengono restituiti tutti i valori contenuti nel campo variablebindings , oppure, qualora si sia verificata una condizione di errore, nessuno di essi.

(21)

Questa PDU, viene utilizzata dalla stazione di controllo, per assegnare un valore ad un elemento della MIB di un agent (Fig 1.10). Per svolgere questa operazione, il campo

variablebindings contiene i nomi ed i relativi valori delle variabili che il manager vuole

impostare.

La stazione ricevente risponde con una GetResponse PDU contenente anche in questo caso, lo stesso request-id della PDU di richiesta.

Nel caso in cui tutte le variabili vengano impostate correttamente ai valori voluti dal manager, il campo variablebindings conterrà i nomi delle variabili ed il rispettivo valore modificato, altrimenti, se uno dei valori non può essere variato, allora nessuno di essi può essere aggiornato, ed il campo variablebindings non contiene alcun valore.

Figura 1.10: PDU della SetRequest

Le possibili condizioni di errore sono le stesse delle altre PDU già descritte, con l’aggiunta del valore badvalue, a cui viene impostato il campo error-status della PDU di risposta nel caso in cui venga riscontrata un’inconsistenza tra il nome della variabile ed il relativo valore.

SET

PDU request-id 0 0 variablebindings

Tipo di

PDU Error-status Error-index

SET

PDU request-id 0 0 variablebindings

Tipo di

(22)

1.6.1.4 Trap PDU

Un messaggio di tipo Trap, viene inviato dall’agent per avvisare il manager del verificarsi di una condizione anomala (Fig 1.11). Questo tipo di notifica è definita asincrona per sottolineare la non periodicità

di tali messaggi. Come già accennato, il servizio di trasporto dei messaggi SNMP è basato su di un protocollo non orientato alla connessione, è quindi possibile che un messaggio venga perso; ciò risulta disastroso per la notifica di errori o guasti. Per questo motivo ad

una tecnica del tipo event reporting (come per esempio un messaggio di tipo Trap), viene affiancata una procedura periodica di polling, che risulta ovviamente più affidabile.

Figura 1.11: PDU della Trap Il campo generic-trap può assumere uno dei seguenti valori:

- coldstart(0): l’agent si sta inizializzando

- warmstart(1): l’agent si sta reinizializzando

- linkDown(2): un’interfaccia, di cui segue l’identificativo, è stata

disattivata

- linkUp(3): un’interfaccia è stata attivata

- authenticationFailure(4): il messaggio ricevuto è stato inviato da un

manager con il campo community non valido

- egpNeighborLoss(5): un host EGP è stato disattivato (segue il suo

indirizzo IP)

Trap

PDU enterprise