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
SNMPv2 Abstract Syntax
-- 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
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.
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.
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
}
}
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.
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
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
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
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)
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
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
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.
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.
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.
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
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).
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
Comments