ALMA MATER STUDIORUM - UNIVERSITA' DI BOLOGNA
FACOLTA' DI INGEGNERIA - SEDE DI CESENA
LABORATORIO DI INFORMATICA
Network Management
6. Protocollo SNMPv2 e modello operazionale
Claudio Salati
Copyright © 2001 by Claudio Salati
1
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
2
SNMPv2 Abstract Syntax
-- Generic PDU
PDU ::=
SEQUENCE {
request-id
error-status
error-index
variable-bindings
Integer32,
Error-status, -- sometimes ignored
INTEGER (0..max-bindings),
-- sometimes ignored
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
3
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.
4
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.
5
SNMPv2 Abstract Syntax
-- 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
}
}
6
VARIABLE-BINDING
Il secondo campo di un VarBind puo' assumere tre forme:
•
value
quando 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, endOfMibView
in 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.
7
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
8
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
9
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
10
Processamento di VarBind.name
2
 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)
11
Processamento di VarBind.name
3
 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
12
SNMPv2 Abstract Syntax
-- 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)
}
13
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
14
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 SNMPv2SNMPv1e 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.
15
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.
16
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.
17
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
18
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).
19
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
20
OPERAZIONE get-next: 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 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
21
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;
// internet
objectValue = unSpecified;
// unSpecified NULL
while (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 objecttype colonna della tabella (o ritorna eccezione).
22
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.
23
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
}
24
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 maxrepetitions 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
25
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-repeaters1, e il primo VarBind di
variable-bindings ha campo name = sysUpTime
26
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 variablebindings
•
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.
27
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 getbulk risulta piu’ veloce di un ordine di grandezza rispetto a quando
la si fa utilizzando l’operazione get-next
28
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.
29
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)
30
OPERAZIONE set: errori
•
data la semantica atomica dell'operazione, in caso di risposta di
errore la MIB dell'agent non e' stata modificata.
•
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 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
31
OPERAZIONE set: errori specifici
1
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.
32
OPERAZIONE set: errori specifici
2
notWritable
•
l'object-instance indicato non e' modificabile o creabile
•
il campo error-index del PDU di risposta e' significativo
•
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.
•
33
OPERAZIONE set: errori specifici
3
wrongType
•
l'object-instance e il valore indicati nel VarBind non sono di tipo
compatibile tra loro
•
il campo error-index del PDU di risposta e' significativo
•
questo errore e' indicativo di un errore di protocollo nel colloquio
manageragent
•
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.
34
OPERAZIONE set: errori specifici
4
wrongLength
•
la lunghezza del valore indicato nel VarBind non e' compatibile con
il tipo dell'object-instance
•
il campo error-index del PDU di risposta e' significativo
•
questo errore e' indicativo di un errore di protocollo nel colloquio
manageragent
•
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.
35
OPERAZIONE set: errori specifici
5
wrongEncoding
•
la codifica BER del valore del VarBind e' scorretta.
•
il campo error-index del PDU di risposta e' significativo
•
questo errore e' indicativo di un errore di protocollo nel colloquio
manageragent
•
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.)
36
OPERAZIONE set: errori specifici
6
wrongValue
•
il valore indicato nel VarBind non appartiene al range ammissibile
per il tipo dell'object-instance
•
il campo error-index del PDU di risposta e' significativo
•
questo errore e' indicativo di un errore di protocollo nel colloquio
manageragent
•
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.
37
OPERAZIONE set: errori specifici
7
noCreation
•
l'object-instance indicato nel VarBind non esiste e non e' creabile
dall'agent
•
il campo error-index del PDU di risposta e' significativo
•
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.
38
OPERAZIONE set: errori specifici
8
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
•
il campo error-index del PDU di risposta e' significativo
•
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 errorstatus field is set to 'inconsistentName', and the value of its errorindex field is set to the index of the failed variable binding.
39
OPERAZIONE set: errori specifici
9
inconsistentValue
•
il valore indicato nel VarBind e' in conflitto con il valore di altri
object-instance della MIB
•
il campo error-index del PDU di risposta e' significativo
•
questo errore e' indicativo di una situazione contingente
•
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.
40
OPERAZIONE set: errori specifici
10
resourceUnavailable
•
l'agent non ha potuto riservare le risorse necessarie a consentire
l'esecuzione dell'operazione relativamente ad un certo VarBind
•
il campo error-index del PDU di risposta e' significativo
•
questo errore e' indicativo di una situazione contingente
•
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.
41
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
42
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
43
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.
44
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 textualconvention ripete esplicitamente la regola di generazione
della risposta all'operazione di set indicata in RFC 1905
45
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)
46
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"
47
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;
48
RowStatus (RFC 1903)
2
• 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.
49
RowStatus (RFC 1903)
3
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.
50
RowStatus (RFC 1903)
4
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.
51
RowStatus (RFC 1903)
5
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)
}
52
SELEZIONE INDICI PER NUOVA RIGA
•
1
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
53
SELEZIONE INDICI PER NUOVA RIGA
2
•
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
54
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 MAXACCESS 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
55
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
56
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.
57
CREAZIONE E ATTIVAZIONE CONTESTUALE
1
 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
58
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.
59
CREAZIONE E ATTIVAZIONE CONTESTUALE
2
 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
60
CREAZIONE E ATTIVAZIONE CONTESTUALE
3
 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
61
CREAZIONE SENZA ATTIVAZIONE CONTESTUALE
1
 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)
62
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)
63
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.
64
CREAZIONE SENZA ATTIVAZIONE CONTESTUALE
3
 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
65
CREAZIONE SENZA ATTIVAZIONE CONTESTUALE
4
 createAndWait
Manager: 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.
66
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)
67
Confronto fra le modalita' di creazione
1
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
• createAndWait :
si'
• createAndGo :
si'
68
Confronto fra le modalita' di creazione
2
•
consente di coordinare tentativi contemporanei di diversi manager di
creare una stessa riga di una tabella
• createAndWait :
si'
• createAndGo :
si'
•
consente all'agent di diagnosticare la necessita' di generare una
risposta di errore tooBig prima di iniziare a eseguire la set
• createAndWait :
si'
• createAndGo :
si'
•
consente di gestire il caso di righe che contengano sia colonne readonly che colonne read-create
• createAndWait :
si'
• createAndGo :
si'
•
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".
• createAndWait :
si'
69
• createAndGo :
si'
Confronto fra le modalita' di creazione
3
•
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
70
Confronto fra le modalita' di creazione
4
•
consente al manger di scegliere liberamente il valore degli indici della
riga da creare quando questi non siano vincolati dalla loro semantica
• createAndWait :
si'
• createAndGo :
si'
•
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
71
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!)
72
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?
73
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!
74
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.
75
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
noError (note 1)
noError
C
(note 5)
any other column
to some value
(note 4)
D
Vedi note alla pagina successiva
76
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.
77
OPERAZIONE trap
• Una notifica spontanea agentmanager
• 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
78
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 objectidentifier object-type.0)
• di seguito ancora, l'agent puo' aggiungere il valore di altri
object-instance a suo piacimento
79
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
80
INTERAZIONE MANAGER-AGENT: TIMEOUT
•
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?
1
 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.
81
INTERAZIONE MANAGER-AGENT: TIMEOUT
2
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.
82
INTERAZIONE MANAGER-AGENT: TIMEOUT
3
•
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."
83