1 LABORATORIO DI INFORMATICA Network Management 6. Protocollo SNMPv2 e modello operazionale Claudio Salati Copyright © 2001 by Claudio Salati ALMA MATER

1

LABORATORIO DI INFORMATICANetwork Management

6. Protocollo SNMPv2 e modello operazionale

Claudio Salati

Copyright © 2001 by Claudio Salati

ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA

FACOLTA' DI INGEGNERIA - SEDE DI CESENA

2

SNMPv2 Abstract Syntax

-- SNMPv2 PDUs

GetRequest-PDU ::= [0] IMPLICIT PDU

GetNextRequest-PDU ::= [1] IMPLICIT PDU

Response-PDU ::= [2] IMPLICIT PDU

SetRequest-PDU ::= [3] IMPLICIT PDU

GetBulkRequest-PDU ::= [5] IMPLICIT BulkPDU

InformRequest-PDU ::= [6] IMPLICIT PDU

SNMPv2-Trap-PDU ::= [7] IMPLICIT PDU

-- N.B.: l’operazione invocata e’ identificata dal tipo del PDU

-- i parametri dell’operazione sono contenuti nei campi del PDU

3


-- Generic PDU

PDU ::= SEQUENCE { request-id Integer32, error-status Error-status, -- sometimes

ignored error-index INTEGER (0..max-bindings),

-- sometimes ignored variable-bindings VarBindList

-- values are sometimes ignored

}

-- vedi lezione 3 per la sintassi astratta completa di SNMPv2-- in particolare:

-- VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind

4

CAMPI del PDU generico SNMPv2

• request-id • identificatore univoco di una richiesta (un manager non puo'

avere due richieste aperte con lo stesso valore di request-id). • In un PDU di risposta il campo deve contenere lo stesso

valore della richiesta corrispondente, cosi' da consentire il match richiesta-risposta.

• Infatti un manager puo' inviare una nuova richiesta senza attendere la risposta a quella precedente, e non e' garantito alcun ordine nelle risposte.

• error-status • questo campo e' sempre nullo nei PDU di richiesta.• Se nel PDU di risposta il campo e' !=0, cio' indica che si e'

incontrato un errore nel processamento della richiesta corrispondente, e che di conseguenza i campi value dei variable-bindings non riportano valori significativi.

5

CAMPI del PDU generico SNMPv2

• error-index • questo campo e' sempre nullo nei PDU di richiesta.• Nel PDU di risposta puo' essere !=0 solo se error-status e' !

=0. • Se error-index e' !=0, il suo valore indica quale VarBind della

lista variable-bindings della richiesta corrispondente ha causato l'errore.

• Notare che gli elementi di variable-bindings si considerano indiciati a partire da 1.

• variable-bindings lista di coppie {oggetto (istanza), valore }, in cui la parte valore puo' essere o meno significativa, e puo' assumere diversi significati a seconda del particolare PDU in cui compare.

Campi non significativi se in un particolare PDU un campo risulta essere non significativo, il ricevitore e' tenuto ad ignorarne il valore.

6


-- variable binding VarBind ::= SEQUENCE { name ObjectName, CHOICE { value ObjectSyntax, unSpecified NULL, -- in retrieval requests -- exceptions in responses: noSuchObject [0] IMPLICIT NULL, noSuchInstance [1] IMPLICIT NULL, endOfMibView [2] IMPLICIT NULL } }

7

VARIABLE-BINDING

Il secondo campo di un VarBind puo' assumere tre forme:

• valuequando contiene il valore dell'object-instance (o cui si vuole settare l'object-instance) indicato nel primo campo (name).

• unSpecified nel PDU di request di una delle operazioni di get, quando il manager deve solo indicare il nome dell'object-instance al cui valore e' interessato.

• noSuchObject, noSuchInstance, endOfMibViewin un response PDU in cui si descrive una condizione di eccezione riscontrata durante il tentativo di applicazione dell'operazione richiesta (in realta', una delle operazioni di read) all'object-instance indicato dal campo name.Sono previste tre diverse situazioni (e quindi risposte) di eccezione.

8

RISPOSTA di ECCEZIONE

• Puo' essere generata solo a fronte di una delle operazioni di read.

• Consente al manager di ottenere quanta piu' informazione possibile da un agent anche a fronte di una richiesta parzialmente non soddisfacibile

• I campi error-status e error-index sono nulli

• error-status=noError

• In realta' error-index e' non significativo

• La presenza di eccezioni non e' causa di una risposta di errore

• sono previsti tre codici di eccezione, che si applicano individualmente per ogni VarBind del campo variable-bindings

in una stessa risposta possono coesistere VarBind di successo e VarBind di eccezione, e VarBind di eccezione diversi tra loro

9

CODICI di ECCEZIONE

• codici di eccezione previsti:

• noSuchObject

indica che l'operazione di get sta cercando di accedere una istanza di un object-type non supportato dall'agent.

• noSuchInstance

indica che l'operazione di get sta cercando di accedere una istanza non esistente nella MIB view dell'operazione

• endOfMibView

indica che in una operazione di get-next o similare si e' esaurita la scansione degli object-instance nella MIB view dell'operazione

10

Processamento di VarBind.name 1

• il campo VarBind.name e' di tipo ObjectName, quindi un OBJECT IDENTIFIER

quando vuole individuare una precisa variabile della MIB il manager costruisce il valore del campo name di un VarBind di variable-bindigs concatenando:

• un prefisso, costituito dall'identificativo OBJECT IDENTIFIER dell'object-type della variabile che vuole accedere

• un suffisso che identifica la particolare istanza che vuole accedere di quell'object-type

• e.g.:

• OBJECT IDENTIFIER dell'object-type = t1.t2. ... .tn prefisso di VarBind.name = t1.t2. ... .tn

• sub-identificatore dell'object-instance = .i1. ... .im suffisso di VarBind.name = .i1. ... .im

VarBind.name = t1.t2. ... .tn.i1. ... .im

11


lato agent

• Quando l'agent processa VarBind.name cerca di riconoscervi un prefisso che sia uguale all'identificativo OBJECT IDENTIFIER di uno degli object-type che supporta

• in base alle MIB-schema supportate

• e ai suoi statement di agent-capability

• se non ci riesce (consideriamo una operazione di get)

(non esiste in VarBind.name alcun prefisso che sia uguale all'identificativo OBJECT IDENTIFIER di uno degli object-type che l'agent supporta)

si riconosce la situazione di eccezione noSuchObject

(continua alla pagina successiva)

12


lato agent (continua dalla pagina precedente)

• se ci riesce (consideriamo sempre una operazione di get)

(esiste in VarBind.name un prefisso che e' uguale all'identificativo OBJECT IDENTIFIER di uno degli object-type che l'agent supporta)

l'agent determina di conseguenza la parte suffisso di VarBind.name, e questa deve identificare nella MIB-istanza una particolare istanza dell'object-type identificato dal prefisso

• se il suffisso identifica effettivamente una istanza esistente allora si e' in una situazione corretta

• se il suffisso non corrisponde a quello di alcuna istanza esistente dell'object-type, allora si riconosce la situazione di eccezione noSuchInstance

13


-- Generic PDU: Error-status

Error-status ::= INTEGER { noError(0), tooBig(1), noSuchName(2), -- for proxy compatibility badValue(3), -- for proxy compatibility readOnly(4), -- for proxy compatibility genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18)

}

14

RISPOSTA di ERRORE

• Puo' essere generata a fronte di qualunque richiesta del manager.

• Il campo error-status e' non nullo.

• A seconda del tipo di errore il campo error-index puo' essere

• nullo (e quindi non significativo) o

• non nullo (e quindi significativo) .

• Il campo variable-bindings e' uguale allo stesso campo del corrispondente PDU di richiesta o e' comunque non significativo

15

RISPOSTA di ERRORE

• I codici di errore da 1 a 5 sono comuni a SNMPv1

• i codici tooBig(1) e genErr(5) sono utilizzati anche in SNMPv2

• i codici da 2 a 4 sono utilizzati solo nei proxy di interworking SNMPv2-SNMPv1e sono riconosciuti per compatibilita' anche da manager SNMPv2

• Molti dei codici di errore sono utilizzabili solo in risposta ad operazioni di set.

• Due codici di errore (tooBig(1) e genErr(5)) possono pero' applicarsi a qualunque operazione invocata da un manager.

16

RISPOSTA di ERRORE

• Codici di errore di uso generale:

• tooBig

ogni messaggio SNMP deve essere contenuto in un singolo PDU UDP.

Quindi la sua dimensione massima e' limitata dalla dimensione massima del PDU UDP

Se un agent si trova a dover generare una risposta che eccede questa dimensione, la marca come errata e riduce il numero dei VarBind presenti nel campo variable-bindings fino ad ottenere una risposta abbastanza piccola (o addirittura ritorna una lista vuota).

• genErr

e' un codice di errore piglia-tutto che si usa solo quando nessun altro codice risulta appropriato.

Viene generalmente utilizzato a fronte di errori di processamento interni al sistema gestito.

17

OPERAZIONE get

• nel campo variable-bindings del PDU di request il manager indica la lista degli object-instance dei quali vuole conoscere il valore

(campo name di ciascun VarBind. Il secondo campo di ogni VarBind ha valore unSpecified NULL)

• In assenza di errore e di eccezioni

• il secondo campo di un VarBind (che e' unspecified NULL nel PDU di richiesta) assume nel PDU di risposta la forma value, e riporta il valore dell‘

• object-instance indicato dal primo campo (campo name, che e’ invariato rispetto al PDU di request).

• In risposta, l'operazione ammette, sui singoli VarBind, le eccezioni• noSuchObject e • noSuchInstance.

18

OPERAZIONE get: errori

• In una risposta di errore (campo error-status!=noError) il campo variable-bindings e’ identico a quello del corrispondente PDU di request.

• L'operazione ammette solo i codici di errore tooBig e genErr

• genErr indica il fallimento nell'acquisizione del valore di un object-instance presente nella MIB:

in questo caso il campo error-index e’ significativo e indica per quale VarBind (e quindi per quale object-instance) del PDU di request si e’ verificata la condizione di errore

• nel caso di errore tooBig il campo error-index non e’ significativo

19

OPERAZIONE get-next

• Nel campo variable-bindings del PDU di request il manager indica una lista di OBJECT IDENTIFIER

(campo name di ciascun VarBind. Il secondo campo di ogni VarBind ha valore unSpecified NULL).

• In questo caso pero’ gli object-instance ai cui valori il manager e’ interessato non sono quelli indicati dai valori OBJECT IDENTIFIER

(che possono anche non nominare alcun object-instance)

ma quelli che, nell’ordinamento lessicografico degli OBJECT IDENTIFIER delle object-stance della MIB-istanza, hanno nome immediatamente successivo a ciascuno degli OBJECT IDENTIFIER di variable-bindings.

• Nel PDU di risposta il campo variable-bindings lista nell’ordine, in ciascun VarBind, l’object-instance identificato (campo name) ed il suo valore (secondo campo del VarBind nella forma value).

20

OPERAZIONE get-next: eccezioni

• Se nella MIB dell’agent (in realta’ nella MIB view associata al manager) non c’e’ nessun object-instance successivo ad un OBJECT IDENTIFIER della request, nel PDU di risposta viene generata una eccezione di endOfMibView:

• Il campo name riporta lo stesso OBJECT IDENTIFIER del corrispondente VarBind del PDU di request

• Il secondo campo del VarBind assume la forma endOfMibView NULL

• e’ evidente che le eccezioni noSuchObject e noSuchInstance, significative per l’operazione get, in questo caso non sono significative

21

OPERAZIONE get-next: errori


• L'operazione ammette i codici di errore tooBig e genErr

• genErr indica il fallimento nell'acquisizione del valore di un object-instance presente nella MIB:

in questo caso il campo error-index e’ significativo e indica per quale VarBind (e quindi per quale OBJECT IDENTIFIER) del PDU di request si e’ verificata la condizione di errore

• nel caso di errore tooBig il campo error-index non e’ significativo

22

OPERAZIONE get-next: APPLICAZIONI

• Permette al manager di leggere tutta la MIB (istanza) dell’agent senza conoscere niente a priori di essa (MIB schema).

objectId = 1.3.6.1; // internetobjectValue = unSpecified; // unSpecified NULLwhile (getNext( { {&objectId, &objectValue} } ) != endOfMibView) {

// add info in manager’s view…// scan next object objectValue = unSpecified; // unSpecified NULL

}

• Nella stessa maniera il manager puo’ leggere una conceptual table scandendone in parallelo tutte le colonne

• La prima interrogazione riporta in variable-bindings (campo name) gli OBJECT IDENTIFIER degli object-type colonna della tabella.

• Il ciclo termina quando getNext non ritorna piu’ istanze degli object-type colonna della tabella (o ritorna eccezione).

23

OPERAZIONE get-bulk

• L’utilizzo dell’operazione get-next per l’acquisizione di grandi quantita’ di dati (come in SNMPv1) si e’ rivelato poco efficiente, nonostante lo sviluppo di algoritmi ottimizzati (e.g. RFC 1187).

• Per affrontare il problema SNMPv2 introduce una nuova operazione, che offre una soluzione sfruttando al meglio la dimensione del PDU di trasporto UDP.

(massimizzando cosi’ la quantita’ di informazione ritornata dall’agent al manager ad ogni interazione)

• Per fare cio’ SNMPv2 definisce anche un PDU ad hoc (GetBulkRequest-PDU), con il vincolo che esso sia strutturalmente uguale al normale PDU SNMPv2.

24

GetBulkRequest-PDU

BulkPDU ::= SEQUENCE {

-- must be identical in structure to PDU

request-id Integer32,

non-repeaters INTEGER (0..max-bindings),

max-repetitions INTEGER (0..max-bindings),

variable-bindings VarBindList

-- values are ignored

}

25

GetBulkRequest-PDU

• non-repeaters

I primi non-repeaters VarBind di variable-bindings sono interpretati come in una operazione get-next, e quindi ciascuno di essi chiede all’agent di ritornare il valore di un object-instance

• max-repetitions• Per ciascuno dei rimanenti (N – non-repeaters) VarBind di

variable-bindings (N e’ la sua cardinalita’) l’agent e’ richiesto di ritornare al manager il valore di max-repetitions istanze successive di oggetti in ordine lessicografico.

• L’ordine di generazione dei VarBind di risposta prevede che ad ogni iterazione venga fornito il valore di una istanza per ciascuno dei repeaters

E’ come se get-bulk ritornasse il risultato di un ciclo di max-repetitions operazioni get-next eseguite a partire dagli ultimi (N – non-repeaters) VarBind di variable-bindings, e nel quale il risultato di una iterazione fosse usato come input per la iterazione successiva

26

OPERAZIONE get-bulk

• Essendo introdotta per ragioni di efficienza (e non per necessita' logica), questa operazione tiene anche conto del fatto che molti manager tendono a chiedere agli agent di marcare le risposte con un time-stamp

in pratica, in ogni operazione di lettura i manager chiedono il valore dell'object-instance sysUpTime.0

cio' e' fatto ad esempio per stimare il round-trip delay delle comunicazioni sistema di gestione - sistema gestito

• Per questo motivo risulta utile nell'operazione get-bulk la possibilita' di lettura di non-repeaters

per cui di norma risulta non-repeaters1, e il primo VarBind di variable-bindings ha campo name = sysUpTime

27

get-bulk: RISPOSTA

• In una request ben conformata e’ • non-repeaters N,

e di conseguenza• #VarBind nel campo variable-bindings nella risposta =

non-repeaters + (N – non-repeaters) * max-repetitions

• pero’

• Se non-repeaters N l’operazione viene interpretata come una normale get-next di tutti e soli i VarBind di variable-bindings

• Se la dimensione del PDU di risposta risulta eccessiva, esso viene troncato a contenere un numero intero di VarBind (in linea di principio, il numero massimo consentito dalla dimensione massima di un PDU SNMP)

• Il PDU di risposta e’ troncato anche in caso di condizione eccezionale endOfMibView per tutti i VarBind scanditi in una iterazione.

28

get-bulk: RISPOSTA• L’agent e’ comunque autorizzato a limitare il numero delle

ripetizioni sui VarBind repeaters per suoi insindacabili motivi:

basta che completi almeno una iterazione su di essi

• E’ prevista la risposta di errore genErr, nella quale il campo variable-bindings e’ identico a quello della richiesta e error-index (significativo) indica per quale VarBind si e’ riscontrata la condizione anomala.

• E’ evidente che per l’operazione di get-bulk una risposta di errore tooBig non e’ significativa

Risultato

la lettura di tabelle di grandi dimensione usando l’operazione get-bulk risulta piu’ veloce di un ordine di grandezza rispetto a quando la si fa utilizzando l’operazione get-next

29

OPERAZIONE set

• questa operazione consente al manager di chiedere all'agent di • modificare il valore degli• creare (quando non esistono gia') gli

object-instance indicati nel campo variable-bindings del PDU di request che gli invia, assegnando loro il valore del campo value del relativo VarBind

• come effetto collaterale delle operazioni eseguite su richiesta del manager, l'agent puo' decidere di effettuare sulla MIB altre modifiche. Esempio:se il manager chiede all'agent di creare alcuni oggetti colonna in una nuova riga di una tabella, e l'agent accetta la richiesta, esso potrebbe creare tutti gli object-instance colonna della riga

• SNMPv2 assegna all’operazione set una semantica atomica:• o l'operazione richiesta dal manager e' applicata con

successo a tutti gli object-instance indicati• o essa non e' applicata a nessuno.

30

OPERAZIONE set: semantica atomica

La semantica dell'operazione set e' descritta da RFC 1905 in termini di esecuzione logica secondo il protocollo di 2-phase commit.

Fase 1:• tutti i VarBind del parametro variable-bindings del PDU di richiesta

sono analizzati e validati.• tutte le risorse del sistema gestito necessarie per l'esecuzione

dell'operazione sono riservate dall'agent.• Se tutto cio' non avviene con successo l'esecuzione

dell'operazione e' terminata con errore (abortita senza alcun effetto).

Fase 2:• le modifiche alla MIB e alla configurazione del sistema gestito

implicate dall'operazione sono effettivamente eseguite.• Le modifiche alla MIB avvengono logicamente tutte

simultaneamente (come parte di una singola transazione)

31

OPERAZIONE set: errori

• data la semantica atomica dell'operazione, in caso di risposta di errore la MIB dell'agent non e' stata modificata.


• L'operazione ammette diversi codici di errore:

per alcuni di questi codici il campo error-index e’ significativo e indica per quale VarBind (e quindi per quale object-instance) del PDU di request si e’ verificata la condizione di errore

• Naturalmente sono previsti anche i codici di errore di uso generale • tooBig (per il quale error-index non e' significativo) e • genErr (per il quale error-index e' significativo) .

L'operazione set non prevede ritorni con eccezioni

32

OPERAZIONE set: errori specifici1

noAccess

• l'object-instance (gia' esistente o da creare) non appartiene alla MIB view dell'operazione

• il campo error-index del PDU di risposta e' significativo

• questo errore e' legato alla illegalita' della richiesta da parte del particolare manager che la ha generata.

• e' una condizione di errore persistente

• Da RFC 1905: If the variable binding's name specifies an existing or non-existent variable to which this request is/would be denied access because it is/would not be in the appropriate MIB view, then the value of the Response-PDU's error-status field is set to 'noAccess', and the value of its error-index field is set to the index of the failed variable binding.

33

OPERAZIONE set: errori specifici 2

notWritable

• l'object-instance indicato non e' modificabile o creabile


• questo errore e' indicativo di una condizione permanente, e non puo' essere recuperato ripetendo la richiesta

• Da RFC 1905: Otherwise, if there are no variables which share the same OBJECT IDENTIFIER prefix as the variable binding's name, and which are able to be created or modified no matter what new value is specified, then the value of the Response-PDU's error-status field is set to 'notWritable', and the value of its error-index field is set to the index of the failed variable binding.

• Da RFC 1905: Otherwise, if the variable binding's name specifies a variable which exists but can not be modified no matter what new value is specified, then the value of the Response-PDU's error-status field is set to 'notWritable', and the value of its error-index field is set to the index of the failed variable binding.

34


wrongType

• l'object-instance e il valore indicati nel VarBind non sono di tipo compatibile tra loro


• questo errore e' indicativo di un errore di protocollo nel colloquio manageragent

• Da RFC 1905: Otherwise, if the variable binding's value field specifies, according to the ASN.1 language, a type which is inconsistent with that required for all variables which share the same OBJECT IDENTIFIER prefix as the variable binding's name, then the value of the Response-PDU's error-status field is set to 'wrongType', and the value of its error-index field is set to the index of the failed variable binding.

35


wrongLength

• la lunghezza del valore indicato nel VarBind non e' compatibile con il tipo dell'object-instance



• Da RFC 1905: Otherwise, if the variable binding's value field specifies, according to the ASN.1 language, a length which is inconsistent with that required for all variables which share the same OBJECT IDENTIFIER prefix as the variable binding's name, then the value of the Response-PDU's error-status field is set to 'wrongLength', and the value of its error-index field is set to the index of the failed variable binding.

36


wrongEncoding

• la codifica BER del valore del VarBind e' scorretta.



• Da RFC 1905: Otherwise, if the variable binding's value field contains an ASN.1 encoding which is inconsistent with that field's ASN.1 tag, then the value of the Response-PDU's error-status field is set to 'wrongEncoding', and the value of its error-index field is set to the index of the failed variable binding. (Note that not all implementation strategies will generate this error.)

37


wrongValue

• il valore indicato nel VarBind non appartiene al range ammissibile per il tipo dell'object-instance



• Da RFC 1905: Otherwise, if the variable binding's value field specifies a value which could under no circumstances be assigned to the variable, then the value of the Response-PDU's error-status field is set to 'wrongValue', and the value of its error-index field is set to the index of the failed variable binding.

38


noCreation

• l'object-instance indicato nel VarBind non esiste e non e' creabile dall'agent


• questo errore e' indicativo di una condizione permanente, e non puo' essere recuperato ripetendo la richiesta

• Da RFC 1905: Otherwise, if the variable binding's name specifies a variable which does not exist and could not ever be created (even though some variables sharing the same OBJECT IDENTIFIER prefix might under some circumstances be able to be created), then the value of the Response-PDU's error-status field is set to 'noCreation', and the value of its error-index field is set to the index of the failed variable binding.

39


inconsistentName

• l'object-instance indicato nel VarBind non esiste e non e' creabile dall'agent perche' il suo nome e' in conflitto con il valore di altri object-instance della MIB


• questo errore e' indicativo di una situazione contingente

• Da RFC 1905: Otherwise, if the variable binding's name specifies a variable which does not exist but can not be created under the present circumstances (even though it could be created under other circumstances), then the value of the Response-PDU's error-status field is set to 'inconsistentName', and the value of its error-index field is set to the index of the failed variable binding.

40


inconsistentValue

• il valore indicato nel VarBind e' in conflitto con il valore di altri object-instance della MIB



• Da RFC 1905: Otherwise, if the variable binding's value field specifies a value that could under other circumstances be held by the variable, but is presently inconsistent or otherwise unable to be assigned to the variable, then the value of the Response-PDU's error-status field is set to `inconsistentValue', and the value of its error-index field is set to the index of the failed variable binding.

41


resourceUnavailable

• l'agent non ha potuto riservare le risorse necessarie a consentire l'esecuzione dell'operazione relativamente ad un certo VarBind



• Da RFC 1905: When, during the above steps, the assignment of the value specified by the variable binding's value field to the specified variable requires the allocation of a resource which is presently unavailable, then the value of the Response-PDU's error-status field is set to 'resourceUnavailable', and the value of its error-index field is set to the index of the failed variable binding.

42

OPERAZIONE set: errori specifici

Tutti gli errori descritti fino a qui sono diagnosticati dall'agent durante la prima fase del 2-phase commit.

Il fatto che nessuno di queste condizioni di errore si verifichi per alcuno dei VarBind del parametro variable-bindings dovrebbe garantire all'agent la possibilita' di portare a termine con successo e in modo atomico la seconda fase del 2-phase commit.

Per trattare il caso in cui, nonostante tutto, cio' non risultasse possibile SNMPv2 introduce due nuovi codici di errore.

In questo caso inoltre, l'agent deve impegnarsi per disfare (undo) tutte le modifiche che aveva eseguito prima di incontrare la condizione di blocco

43

OPERAZIONE set: errori della fase 2 del 2-phase commit

commitFailed

• l'agent non ha potuto portare a termine con successo la seconda fase del 2-phase commit perche' non e' riuscito a eseguire la modifica alla MIB e allo stato del sistema gestito indicata da un certo VarBind della richiesta.

• Tuttavia, l'agent e' riuscito ad eseguire correttamente l'undo delle modifiche prcedentemente operate, cosi' che l'operazione e' terminata senza che lo stato del sistema gestito risulti alterato.

• il campo error-index del PDU di risposta e' significativo e identifica il VarBind per il quale non si e' potuta completare l'operazione di set

44

OPERAZIONE set: errori della fase 2 del 2-phase commit

undoFailed

• l'agent non solo non ha potuto portare a termine con successo la seconda fase del 2-phase commit ma non e' nemmeno riuscito ad eseguire correttamente l'undo delle modifiche operate prima di incontrare la condizione di blocco, cosi' che l'operazione e' terminata avendo modificato in modo parziale lo stato del sistema gestito.

• il campo error-index del PDU di risposta e' non significativo e ha valore 0

l'esistenza di questa condizione di errore deve servire esclusivamente a gestire situazioni eccezionali, e non rappresenta una licenza agli agent per non implementare la semantica atomica dell'operazione set.

45

OPERAZIONE set: PDU di risposta

• Secondo RFC 1905 il campo variable-bindings del PDU di risposta di una operazione di set deve sempre essere uguale al campo variable-bindings del corrispondenet PDU di chiamata.

• Unica eccezione a questa regola, se la dimensione del PDU di risposta eccede la massima dimensione trattabile dall'agent

in questo caso viene generata una risposta con codice di errore tooBig e campo variable-bindings con valore {}

• la regola si applica anche quando la semantica di un object-type prevede che il valore trasportato nel VarBind di chiamata non sia quello che l'object-instance assume in seguito all'esecuzione con successo dell'operazione set

e' il caso di object-instance di tipo TestAndIncr.

notare che la clausola DESCRIPTION della textual-convention ripete esplicitamente la regola di generazione della risposta all'operazione di set indicata in RFC 1905

46

OPERAZIONE set - sincronizzazione

• La semantica atomica dell'operazione di set puo' essere utilizzata per sincronizzare

• successive operazioni di uno stesso manager.

• operazioni di diversi manager

• E' sufficiente inserire nella lista degli object-instance da modificare l'istanza di snmpSetSerialNo (RFC 1907) di tipo ASN.1 TestAndIncr (RFC 1903).

• Solo se il valore indicato nel relativo VarBind e' opportuno la set di questo oggetto, e quindi la set nel suo insieme, puo' avere successo.

• Utilizzando questa tecnica un manager puo' assicurarsi che una set venga eseguito solo se una set precedente ha avuto successo

(e nessuna altra set da parte di altri manager e’ intervenuta nel frattempo)

47

MANIPOLAZIONE DI RIGHE DI TABELLE

• L'operazione set consente anche la creazione e la cancellazione di righe di tabelle.

• La semantica della manipolazione di righe di tabelle e' descritta dalla textual-convention RowStatus (RFC 1903).

• Una istanza di RowStatus puo' comparire come colonna di una tabella.

• nelle MIB SNMPv2 una colonna RowStatus dovrebbe essere presente in tutte quelle tabelle di cui il manager puo' gestire dinamicamente le righe, e.g.

• tabella ifRcvAddressTable di RFC 2233, MIB delle interfacce

• tabella ipCidrRouteTable di RFC 2096 "IP Forwarding Table MIB"

48

RowStatus (RFC 1903) 1

RowStatus ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION

"The RowStatus textual convention is used to manage the creation and deletion of conceptual rows, and is used as the value of the SYNTAX clause for the status column of a conceptual row (as described in Section 7.1.12.1 of RFC 1902.)The status column has six defined values:

• active, which indicates that the conceptual row is available for use by the managed device;

• notInService, which indicates that the conceptual row exists in the agent, but is unavailable for use by the managed device;

• notReady, which indicates that the conceptual row exists in the agent, but is missing information necessary in order to be available for use by the managed device;

49


• createAndGo, which is supplied by a management station wishing to create a new instance of a conceptual row and to have its status automatically set to active, making it available for use by the managed device;

• createAndWait, which is supplied by a management station wishing to create a new instance of a conceptual row (but not make it available for use by the managed device);

• destroy, which is supplied by a management station wishing to delete all of the instances associated with an existing conceptual row.

Whereas five of the six values (all except notReady) may be specified in a management protocol set operation, only three values will be returned in response to a management protocol retrieval operation: notReady, notInService or active.

50


When queried, an existing conceptual row has only three states:

• it is either available for use by the managed device the status column has value active; la riga e’ correttamente inizializzata e il suo valore influenza il

comportamento del sistema gestito

• it is not available for use by the managed device, though the agent has sufficient information to make it so the status column has value notInService; or, la riga e’ correttamente inizializzata ma il suo valore non

influenza il comportamento del sistema gestito

• it is not available for use by the managed device, and an attempt to make it so would fail because the agent has insufficient information the state column has value notReady la riga non e’ adeguatamente (creata e) inizializzata e quindi il

valore delle sue colonne non puo’ influenzare il comportamento del sistema gestito

Also note that whenever any elements of a row exist, the RowStatus column must also exist.

51


This textual convention may be used for a MIB table, irrespective of whether the values of that table's conceptual rows are able to be modified while it is active, or whether its conceptual rows must be taken out of service in order to be modified.It is the responsibility of the DESCRIPTION clause of the status column to specify whether the status column must not be active in order for the value of some other column of the same conceptual row to be modified. If such a specification is made, affected columns may be changed by an SNMP set PDU (only) if the RowStatus would not be equal to active either immediately before or after processing the PDU. In other words, if the PDU also contained a VarBind that would change the RowStatus value, the column in question may be changed if the RowStatus was not equal to active as the PDU was received, or if the varbind sets the status to a value other than active.

52


SYNTAX INTEGER { -- the following two values are states: -- these values may be read or written active (1), notInService (2),

-- the following value is a state: -- this value may be read, but not written notReady (3),

-- the following three values are -- actions: these values may be written, -- but are never read createAndGo (4), createAndWait (5), destroy (6) }

53

SELEZIONE INDICI PER NUOVA RIGA1

• In ogni tabella e' sempre definito e presente un insieme di colonne il cui valore ne identifica univocamente ciascuna riga

• una colonna indice puo' essere semanticamente significativa, e.g.

• colonna ipAdEntAddr nella tabella di ipAddrTable di RFC 2011

• colonne ipCidrRouteDest, ipCidrRouteMask, ipCidrRouteTos, ipCidrRouteNextHop della tabella ipCidrRouteTable di RFC 2096

• una colonna indice puo' essere utilizzata solo per questo scopo, e.g.

• colonna ifIndex nella tabella delle interfacce ifTable di RFC 2233

• N.B. le tabelle ipAddrTable e ifTable non hanno una colonna RowStatus: infatti il manager non puo' creare e distruggere righe in queste tabelle, solo l'agent puo' decidere autonomamente di farlo

54

SELEZIONE INDICI PER NUOVA RIGA2

• dovendo creare una nuova riga in una tabella occorre individuare un insieme univoco di indici che la identifichino.

• Non esistono regole fisse su come questo insieme puo'/deve essere individuato:

• in alcuni casi l'indice e' noto semanticamente a priori (e.g. ipAdEntAddr nella tabella di ipAddrEntry di RFC 2011)

• oppure ci puo' essere un oggetto scalare associato alla tabella che mantiene l'indice della prima riga non esistente

• oppure si possono scandire tutte le righe esistenti della tabella, e cosi' identificare un valore di indice disponibile

• oppure si puo' operare per tentativi attraverso un generatore pseudo-random

• notare che in generale non e' mai necessario settare (inizializzare) esplicitamente il valore delle colonne indice: l'agent le puo' sempre settare spontaneamente in base all'indice dello/gli oggetto/i colonna che vengono esplicitamente inizializzati in set-creazione

55

COLUMN REQUIREMENTS 1

• Ovviamente si possono settare in creazione solo colonne con MAX-ACCESS read-create, tuttavia

PROBLEMA

• Un agent puo' non implementare tutte le colonne di una tabella!

• Un agent puo' porre restrizioni implementative al livello di MAX-ACCESS definito in una MIB

• Se applico l'operazione set ad una colonna non supportata l'operazione fallisce!

DOMANDA

• Quali colonne possono/devono essere inizializzate dal manager durante la procedura di creazione di una riga?

• Ovviamente perche' un oggetto colonna possa/debba essere inizializzato occorre che il suo MAX-ACCESS sia read-create!

• Questo insieme di colonne e’ indicato come column requirements della riga/tabella

56

COLUMN REQUIREMENTS 2

SOLUZIONI

1. Il manager consulta gli statement di AGENT-CAPABILITIES del particolare agent

1. sub-clausola CREATION-REQUIRES

2. della clausola VARIATION relativa all’oggetto riga della tabella

2. il manager applica un protocollo dinamico di interrogazione dell'agent (lettura della riga della tabella che si sta creando), che gli consente di capire (in base ai valori di eccezione di ritorno) su quali colonne deve/puo' agire

1. per quanto detto questo protocollo dovra' operare solo su oggetti colonna con MAX-ACCESS read-create

57

MODALITA' DI CREAZIONE DI UNA RIGA

(cfr. clausola DESCRIPTION della textual-convention RowStatus, RFC 1903)

• Esistono due modalita' di creazione di una riga da parte del manager:

1. creazione e attivazione contestuale della nuova riga set a createAndGo della colonna RowStatus

2. creazione della riga senza renderla attiva set a createAndWait della colonna RowStatus

• un agent puo' non supportare la seconda modalita', ma in questo caso

• deve supportare la prima modalita'

• e questa deve essere effettivamente utilizzabile (vedi seguito)

• Quando un agent riceve una richiesta di creazione di una riga esso deve comunque verificarne la correttezza dei parametri rispetto alla definizione della MIB e ad eventuali proprie restrizioni implementative.

58

CREAZIONE E ATTIVAZIONE CONTESTUALE1

createAndGo• perche' l'operazione abbia successo il manager deve fornire un

valore iniziale per tutte le colonne per cui cio' e' necessario (column requirements della tabella per l'agent in considerazione)

• N.B.: un singolo PDU SNMP deve essere abbastanza grande per contenere il valore di inzializzazione di tutte le colonne necessarie! Se cio' non e’ possibile e' necessario utilizzare la seconda

modalita' di creazione (createAndWait)

• Quali sono i column requirement? Ad es., protocollo di get! (RFC 1903). Vedi pagina successiva

• Identificati i column requirements il manager genera la richiesta di set di creazione della riga desiderata fornendo nel parametro variable-bindings tutta l'informazione individuata come necessaria Nella richiesta di set il VarBind relativo alla colonna di stato

riporta ovviamente il valore createAndGo

59

CREAZIONE E ATTIVAZIONE CONTESTUALE Protocollo di get per determinare i column requirement

• il manager applica un'operazione get di tutte le colonne della riga (inesistente) che ha deciso di creare

• se l'operazione ha un ritorno di successo, cio' significa che qualche altro manager ha gia' creato la riga. Consideriamo quindi solo il

• caso di ritorno di eccezione su tutti i VarBind della richiesta.• se ad un VarBind della richiesta e' associata in risposta

l'eccezione noSuchInstance l'agent supporta l'object-type colonna relativo. Se il MAX-ACCESS dell'object-type e' read-create il manager dovrebbe inizializzare il valore della colonna alla creazione della riga (non dovrebbe fare conto su una inizializzazione di default da parte dell'agent).

• se ad un VarBind della richiesta e' associata in risposta l'eccezione noSuchObject l'agent non supporta l'object-type colonna relativo, e quindi il manager non deve cercare di inizializzarlo nella set di creazione della riga.

60


createAndGo

• Se l'agent ha abbastanza informazioni per farlo

• parametro variable-bindings della richiesta di set di creazione

• valori di default (eventualmente dipendenti dalla implementazione)

allora:

1. crea la riga (tutti gli oggetti colonna relativi),

2. la fa transitare in stato active, e

3. genera un ritorno di successo verso il manager

• Notare che l'agent e' obbligato a fornire un valore di default almeno per tutte le colonne che implementa come read-only

• Se l'agent non ha sufficienti informazioni dalla richiesta di set, la rifiuta con il codice di errore inconsistentValue

61


createAndGo• Notare che il manager potrebbe avere fornito anche troppa

informazione rispetto alle agent-capabilities dell'agent:

• se l'agent non supporta il modo d'accesso read-create previsto da una MIB per un oggetto colonna, esso rifiutera' la creazione della riga

• il campo error-index del PDU di risposta indichera’ quale e' l'oggetto colonna per il quale il problema si e' presentato

• a questo punto il manager dovra’ decidere se

• rinunciare alla creazione della riga perche' il valore di inizializzazione dell'oggetto colonna in questione e' essenziale per la semantica della riga creata

• accettare di creare la riga senza specificare il valore iniziale dell'oggetto colonna, affidandosi quindi per la sua inizializzazione al valore default che l'agent deve ovviamente fornire

62

CREAZIONE SENZA ATTIVAZIONE CONTESTUALE1

createAndWait• In linea di principio la riga puo' venire creata settando al valore

createAndWait la sola colonna di RowStatus

• in caso di successo la riga transita

• in stato notInService se tutte le colonne (necessarie) della riga sono state create e hanno un valore iniziale accettabile.

• in stato notReady se alcune colonne (necessarie) mancano di un valore iniziale accettabile (e non sono quindi state create).

• Questa modalita' di creazione consente di creare una riga anche quando non e' possibile fornire in un unico PDU SNMP un valore di inizializzazione per tutte le colonne per cui cio' e' necessario.

In questo caso la riga e' creata in stato notReady

• Consente anche al manager di esaminare a priori i valori di default impostati da un agent (decidendo se accettarli o modificarli con una set successiva)

63

CREAZIONE SENZA ATTIVAZIONE CONTESTUALE 2

createAndWait

la procedura di creazione e successiva attivazione si sviluppa in 5 fasi

1. selezione degli indici per la nuova riga che si vuole creare.

2. creazione della riga in stato notReady o notInService tramite • set esplicito della sua colonna RowStatus al valore

createAndWait, • conseguente set implicito delle sue colonne indice, e • inizializzazione default, quando possibile, delle altre colonne

3. se necessario (riga in stato notReady), • determinazione dei column requirements della riga• inizializzazione delle colonne identificate

• a questo punto la riga e' comunque in stato notInService

4. set esplicito al valore voluto di colonne inizializzate dall'agent con un valore default non accettabile

5. attivazione della riga (set ad active della sua colonna di stato)

64

CREAZIONE SENZA ATTIVAZIONE CONTESTUALE Protocollo di get per determinare i column requirements

• il manager applica un'operazione get di tutte le colonne della riga appena creata

• se per un VarBind della richiesta e' ritornato un valore, l'agent implementa l'object-type colonna ed e' stato capace di inizializzarlo. Se la colonna e' read-create il manager potra' cambiarne il valore con una set esplicita prima di attivare la riga.

• se ad un VarBind della richiesta e' associata in risposta l'eccezione noSuchInstance l'agent supporta l'object-type colonna relativo, ma non e' stato in grado di inizializzarlo.Se il MAX-ACCESS dell'object-type e' read-create il manager deve inizializzare esplicitamente il valore della colonna tramite set per fare transitare la riga dallo stato corrente di notReady a quello di notInService.

• se ad un VarBind della richiesta e' associata in risposta l'eccezione noSuchObject l'agent non supporta l'object-type colonna relativo, e quindi il manager non deve cercare di inizializzarlo.

65


createAndWait

Manager: set colonna di stato della riga desiderata a createAndWait

Agent: se non accetta la richiesta ritorna wrongValue, altrimenti crea la riga (in stato notInService o notReady a seconda che abbia o meno abbastanza informazioni per rendere la riga attiva: cio' si riflette nel fatto di avere o meno adeguatamente inizializzato tutte le colonne della riga che sono supportate ) e ritorna noError.

Manager: determina i column requirement e li soddisfa tramite opportune set, fino a che il valore della colonna RowStatus della nuova riga diventa notInService.In questa fase il manager puo' anche modificare il valore di colonne gia' inizializzate.

Agent: risponde alle set del manager. Quando ha abbastanza informanzioni da rendere la riga attiva le assegna lo stato notInService.

Continua alla pagina successiva

66


createAndWaitManager: set della colonna di stato al valore active.

Agent: se la riga e' in stato notInService la fa transitare in stato active e ritorna noError, altrimenti la lascia in stato notReady e ritorna inconsistentValue

cosa succede se il manager non termina il protocollo di attivazione e lascia la riga in stato notInService o notReady?

L'agent e' tenuto a monitorare la cosa e ad applicare una procedura di garbage collection

la clausola DESCRIPTION della colonna di stato dovrebbe indicare per quanto tempo al massimo una riga puo' rimanere in stato notInService o notReady, discriminando eventualmente i due casi.

Notare che la clausola si applica anche quando una riga gia' attiva e' posta dal manager in stato notInService!

se la clausola DESCRIPTION non da' indicazioni RFC 1903 indica un tempo massimo default di 5 min.

67

Creazione di riga con colonna rowStatus di DEFAULT

• il manager non e' tenuto, in una set-create, ad inizializzare tutte le colonne della riga: di conseguenza, l'agent puo' supplire valori di default per le colonne non inizializzate dal manager.

• Tra le colonne che possono non essere inizializzate dal manger c'e' quella di RowStatus.

In questo caso l'agent puo' comportarsi in diversi modi, ritornando:• inconsistentName: because the agent does not choose to

create such an instance when the corresponding RowStatus instance does not exist, or

• inconsistentValue: if the supplied value is inconsistent with the state of some other MIB object's value, or

• noError: because the agent chooses to create the instance.

In quest'ultimo caso la colonna di RowStatus della riga deve comunque essere creata e puo' assumere valore notInService o notReady a seconda della completezza dell'inizializzazione.

(in caso di successo l'operazione e' analoga a createAndWait)

68

Confronto fra le modalita' di creazione1

da W. Stallings: libro citato in bibliografia.

In base ai requisiti secondo i quali le due operazioni sono state progettate.

• modalita' createAndWait:

• consente di gestire righe piu' grandi di un PDU• createAndWait : si'• createAndGo : no

• consente al manager di imparare quali siano gli eventuali oggetti colonna non implementati da un agent (o impementati in modo limitato)

• createAndWait : si'• createAndGo : si'

• consente al manager di imparare quali siano gli oggetti colonna non accessibili


69


• consente di coordinare tentativi contemporanei di diversi manager di creare una stessa riga di una tabella


• consente all'agent di diagnosticare la necessita' di generare una risposta di errore tooBig prima di iniziare a eseguire la set


• consente di gestire il caso di righe che contengano sia colonne read-only che colonne read-create


• consente di non dovere tenere conto di relazioni di riga: "the agent should not have to take into account any semantic relationship between rows while performing row creation and deletion".


70


• non richiede l'introduzione di un nuovo tipo di PDU• createAndWait : si'• createAndGo : si'

• consente di creare una nuova riga con una transazione composta di una sola operazione

• createAndWait : no• createAndGo : no

• consente al manager di accettare consapevolmente oggetti creati con valore di deafult dall'agent

• createAndWait : si'• createAndGo : no

• consente al manager di verificare oggetti creati con valore di deafult dall'agent , e se del caso di modificare il loro valore

• createAndWait : si'• createAndGo : no

71


• consente al manger di scegliere liberamente il valore degli indici della riga da creare quando questi non siano vincolati dalla loro semantica


• consente al manager di selezionare i valori di indici da utilizzare nel contesto stesso dell'operazione di set-create, e non prima di invocare la set stessa

• createAndWait : no• createAndGo : no

72

CANCELLAZIONE DI UNA RIGA

• Una riga puo' essere cancellata dal manager settandone la colonna di stato a destroy.

• Questa operazione ha successo qualunque sia lo stato corrente della riga (compreso il caso in cui la riga non esiste!)

73

Creazione/cancellazione di riga: PDU di risposta 1

• Per creare una riga il manager invia una richiesta di set della colonna di status a uno dei valori createAndGo o createAndWait:

di conseguenza la colonna di status, in caso di successo dell' operazione, assume uno dei valori active, notReady o notInService.

• Analogamente, per cancellare una riga il manager invia una richiesta di set della colonna di status al valore destroy:

di conseguenza la colonna di status e tutto il resto della riga, in caso di successo dell'operazione, vengono distrutti (la colonna di status, non esistendo piu', non ha piu' un valore).

• Quale e' il valore del VarBind relativo alla colonna di status nel PDU di risposta?

• Uguale a quello del PDU di richiesta corrispondente?

• Uguale a quello assunto dalla colonna di status a seguito della operazione set?

74

Creazione/cancellazione di riga: PDU di risposta 2

• Come gia' detto,

il protocollo SNMP specifica che il campo variable-bindings del PDU di risposta di una operazione di set deve sempre essere uguale al campo variable-bindings del corrispondenet PDU di chiamata

• Questo e' vero anche quando il valore assunto dall'oggetto che ha subito la operazione set e' diverso da quello indicato dal PDU di richiesta.

• Cosi' specifica il protocollo e cosi' si comporta ad esempio l'agent UCD-SNMP

• Tuttavia W. Stallings nel suo libro (citando S. Waldbusser) descrive una risposta in cui il campo value del VarBind della colonna di status assume lo stesso valore della colonna di status a valle dell'operazione set

Prudentemente, quindi, un manager dovrebbe essere pronto ad accettare tutte e due le risposte!

75

DISATTIVAZIONE DI UNA RIGA

• Il manager puo' anche controllare, tramite operazioni di set del suo RowStatus, lo stato di una riga.

• In particolare puo' anche disattivarla (set della colonna di stato al valore notInService)

• se l'agent non supporta la disattivazione della riga, l'operazione viene rifiutata con l'errore wrongValue

• una riga non attiva non ha alcun effetto sulla configurazione dell'apparato.

• Una riga puo' dovere essere disattivata quando se ne vogliono modificare molte colonne, e una singola operazione di set eccede la dimensione del PDU SNMP.

• La clausola DESCRIPTION della colonna rowStatus di una tabella deve indicare per quanto tempo una riga puo’ rimanere in stato notInService prima di essere automaticamente distrutta dall’agent.

76

DIAGRAMMA DI STATO DI UNA RIGA (da RFC 1903)

status colum set action

A: doesn't exist

B: not ready C: not in service

D: active

status column to createAndGo

noError D or

inconsistentValue

inconsistentValue inconsistentValue inconsistentValue

status column to createAndWait

noError (note 1) or

wrongValue

inconsistentValue inconsistentValue inconsistentValue

status column to active

inconsistentValue inconsistentValue

or (note 2) D

noError

D

noError

D

status column to notInService

inconsistentValue inconsistentValue

or (note 3) C

noError

C

noError C or

wrongValue

status column to destroy

noError

A

noError

A

noError

A

noError

A

any other column to some value

(note 4) noError (note 1) noError

C (note 5)

D

Vedi note alla pagina successiva

77

DIAGRAMMA DI STATO DI UNA RIGA: NOTE (da RFC 1903)

1) goto B or C, depending on information available to the agent.

2) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, then return noError and goto D.

3) if other variable bindings included in the same PDU, provide values for all columns which are missing but required, then return noError and goto C.

4) at the discretion of the agent, the return value may be either:• inconsistentName: because the agent does not choose to create such an

instance when the corresponding RowStatus instance does not exist, or• inconsistentValue: if the supplied value is inconsistent with the state of some

other MIB object's value, or• noError: because the agent chooses to create the instance.

If noError is returned, then the instance of the status column must also be created, and the new state is B or C, depending on the information available to the agent. If inconsistentName or inconsistentValue is returned, the row remains in state A.

5) depending on the MIB definition for the column/table, either noError or inconsistentValue may be returned.

NOTE: Other processing of the set request may result in response other than noError being returned, e.g., wrongValue, noCreation, etc.

78

OPERAZIONE trap

• Una notifica spontanea agentmanager

• unica interazione non confermata prevista da SNMP

• trasportata dal PDU SNMPv2-Trap-PDU (di struttua identica a quella di tutti gli altri PDUs ad eccezione di GetBulkRequest)

• i campi di SNMPv2-Trap-PDU hanno hanno i seguenti valori:

• request-id: identificatore univoco delle richieste da agent a manager. E' ovviamente scorrelato dal valore di request-id delle richieste da manager ad agent.

• error-status e' non significativo, settato a 0 dall'agent e ignorato dal manager

• error-index e' non significativo, settato a 0 dall'agent e ignorato dal manager

continua alla prossima pagina

79

OPERAZIONE trap

• i campi di SNMPv2-Trap-PDU hanno hanno i seguenti valori (continua):

• variable-bindings:

• i primi due VarBind riportano nell'ordine • il valore di sysUpTime.0• il valore di snmpTrapOID.0, cioe' l'object-identifier della

notifica che viene comunicata tramite la trap

• di seguito sono riportati nell'ordine i valori delle istanze di object-type indicate dalla definizione della notifica

• la clausola OBJECTS lista gli object-type• la clausola DESCRIPTION, in caso di object-type

colonna, deve consentire di individuare la particolare istanza (in caso di oggetti semplici l'istanza ha object-identifier object-type.0)

• di seguito ancora, l'agent puo' aggiungere il valore di altri object-instance a suo piacimento

80

INTERAZIONE MANAGER-AGENT

• Da RFC 1905

For all types of request in this protocol, the receiver is required under normal circumstances, to generate and transmit a response to the originator of the request.

Whether or not a request should be retransmitted if no corresponding response is received in an appropriate time interval, is at the discretion of the application originating the request.

This will normally depend on the urgency of the request. However, such an application needs to act responsibly in respect to the frequency and duration of re-transmissions.

• Motivi per una mancanza di risposta (entro il timeout fissato)• la rete ha perso il PDU di richiesta o quello di risposta• l'agent non e' attivo• l'agent non ha inviato risposta (come specificato anche dal

protocollo)• il timeout era troppo corto

81

INTERAZIONE MANAGER-AGENT: TIMEOUT1

• il recupero degli errori tramite ritrasmissione presenta in realta' diversi punti aperti:

• l'operazione ripetuta e' idempotente o la sua ripetizione puo' creare problemi?

• come deve comportarsi l'agent a fronte di un PDU ripetuto?

E se fosse un duplicato generato da un intruso non autorizzato?

• se il problema era solo un timeout troppo corto, l'arrivo ritardato della risposta alla prima richiesta dopo la sua ritrasmissione non puo' provocare confusione?

E.g. nella stima del round-trip delay?

• In realta' SNMPv2 non da' indicazioni precise su come il manager deve gestire il timeout di una risposta.

82


Da RFC 1905:

• The value of the request-id field in a Response-PDU takes the value of the request-id field in the request PDU to which it is a response.

• By use of the request-id value, a SNMPv2 application can distinguish the (potentially multiple) outstanding requests, and thereby correlate incoming responses with outstanding requests.

• In cases where an unreliable datagram service is used, the request-id also provides a simple means of identifying messages duplicated by the network.

• Use of the same request-id on a retransmission of a request allows the response to either the original transmission or the retransmission to satisfy the request.

• However, in order to calculate the round trip time for transmission and processing of a request-response transaction, the SNMPv2 application needs to use a different request-id value on a retransmitted request.

• The latter strategy is recommended for use in the majority of situations.

83


• RFC 1905 non da' nemmeno nessuna indicazione su come trattare una condizione di time-out a livello di applicazione.

• Un problema e' ad esempio che la rete potrebbe non solo perdere ma anche duplicare un PDU SNMP.

• Fortunatamente, le interazioni manager-agent sono di norma idempotenti.

• Inoltre, la textual-convention di TestAndIncr puo' essere utilizzata per risolvere alcuni di questi problemi.

• M.T. Rose: "for some objects, a set shouldn't be re-transmitted, just because a response was not received, without issuing an intervening get to test whether or not the original set operation took effect.

Although one should include snmpSetSerialNo in the set to ensure that the operation is performed at most once, it's still a good idea to issue a get to find out what happens when a response isn't received."

Documents

1 LABORATORIO DI INFORMATICA Network Management 6. Protocollo SNMPv2 e modello operazionale Claudio Salati Copyright © 2001 by Claudio Salati ALMA MATER