4. PROTOCOL SPECIFICATION
RFC1157-SNMP DEFINITIONS ::= BEGIN
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., get, set, getnext
ANY -- implementation-specific;
-- e.g., BindingList for
-- bind request
}
-- PDUs
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
-- the individual PDUs and their syntax
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- sometimes ignored
ErrorStatus,
error-index -- sometimes ignored
ErrorIndex,
variable-bindings -- values are ignored
VarBindList
}
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object
-- generating
-- trap
OBJECT IDENTIFIER,
agent-addr -- address of object
-- generating trap
NetworkAddress,
generic-trap -- generic trap type
INTEGER {
coldStart(0),
warmStart(1),
linkDown(2),
linkUp(3),
authenticationFailure(4),
egpNeighborLoss(5),
enterpriseSpecific(6)
},
specific-trap -- specific code, present
-- even if generic-trap
-- is not equal to 6
INTEGER,
time-stamp -- time elapsed between
-- agent start-up and
-- trap generation
TimeTicks,
variable-bindings -- "interesting" info
VarBindList
}
RequestID ::=
INTEGER
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4),
genErr(5)
}
ErrorIndex ::=
INTEGER
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
END
4.1. Elements of Procedure
I messaggi SNMP sono inviati alla ben nota porta (UDP porta 161) sull'elemento di destinazione. Un'entità SNMP (sia un agent che un manager) riceve i messaggi su questa porta. Le richieste di gestione sono ricevute dall'agente e i trap di gestione sono ricevuti dal manager. La ben nota porta per i trap è la UDP porta 162.
Quando una stazione di gestione invia una richiesta a un agent, deve copiare lo stato dei valori "ben noti" nei corrispondenti campi della richiesta. L'agente che riceve la richiesta controllerà il nome della community nel messaggio e, se l'autenticazione fallisce, può facoltativamente inviare un trap di autenticazione.
L'entità di protocollo SNMP che agisce nel ruolo di agent deve essere pronta a accettare, sulla porta ben nota, messaggi con una lunghezza massima accettabile di 484 ottetti e dovrebbe essere pronta ad accettare messaggi di almeno 1024 ottetti.
L'entità di protocollo SNMP che agisce nel ruolo di manager deve essere pronta a accettare, sulla porta ben nota per i trap, messaggi con una lunghezza massima accettabile di 484 ottetti e dovrebbe essere pronta ad accettare messaggi di almeno 1024 ottetti.
4.1.1. The Request/Response Operations
Quanto segue descrive la procedura per generare ed elaborare le operazioni get-request, get-next-request, get-response e set-request.
4.1.1.1. Generating a Retrieval Request
Nel generare una richiesta di recupero, l'entità SNMP richiedente (tipicamente un manager) seleziona un valore per il campo request-id. Questo valore, insieme agli indirizzi di trasporto sorgente e destinazione, consente all'entità di protocollo richiedente di abbinare le risposte in arrivo alle richieste pendenti. I campi error-status e error-index sono impostati a zero. Il campo variable-bindings è impostato sull'elenco delle variabili i cui valori sono desiderati.
4.1.1.2. Receiving a Retrieval Request
Al ricevimento di una richiesta di recupero, l'entità SNMP ricevente (tipicamente un agent) determina la dimensione della risposta. Se la dimensione della PDU get-response che sarebbe generata supera la lunghezza massima accettabile per il trasporto sorgente, l'entità ricevente invia una PDU get-response con error-status di tooBig, error-index di zero e il campo valore di tutte le variabili legate impostato a null.
Altrimenti, per ciascun oggetto nel campo variable-bindings, l'entità ricevente:
-
recupera il valore dell'oggetto denominato, nel caso in cui il nome dell'oggetto corrisponda a un'istanza effettiva dell'oggetto e tale oggetto sia accessibile; oppure
-
non trova l'oggetto denominato, nel caso in cui il nome non corrisponda a un'istanza effettiva dell'oggetto; oppure
-
trova che l'oggetto denominato esiste, ma che l'accesso all'oggetto è proibito.
Nel primo caso, il nome e il valore dell'oggetto sono inclusi nel campo variable-bindings della PDU get-response. Nel secondo caso, il nome dell'oggetto è incluso, insieme a un'indicazione che l'oggetto non esiste (cioè, il campo valore della legatura è impostato a null, ma il tipo non lo è). Nel terzo caso, il nome dell'oggetto è incluso, insieme a un'indicazione che l'oggetto denominato esiste, ma non è accessibile. L'entità ricevente imposta quindi il campo error-status della PDU get-response a noError e il campo error-index a zero.
Se un oggetto nominato nel campo variable-bindings non esiste, l'entità ricevente imposta il campo error-status a noSuchName e il campo error-index all'indice dell'oggetto fallito nell'elenco variable-bindings. Se un oggetto nominato nel campo variable-bindings esiste ma non è accessibile, l'entità ricevente imposta il campo error-status a readOnly e il campo error-index all'indice dell'oggetto fallito. In entrambi i casi, il campo valore di tutte le legature è impostato a null.
4.1.1.3. Generating a Set Request
Nel generare un set-request, l'entità SNMP richiedente (tipicamente un manager) seleziona un valore per il campo request-id. I campi error-status e error-index sono impostati a zero. Il campo variable-bindings è impostato sull'elenco delle variabili i cui valori devono essere modificati.
4.1.1.4. Receiving a Set Request
Al ricevimento di un set-request, l'entità SNMP ricevente (tipicamente un agent) convalida innanzitutto l'operazione nel suo complesso. Verifica che tutti gli oggetti nominati nel campo variable-bindings esistano e siano accessibili e che il tipo e la lunghezza di ciascun valore siano coerenti con la definizione dell'oggetto. Se una verifica fallisce, l'agente non modifica i valori di alcuna delle variabili e restituisce una PDU get-response con l'opportuno error-status (noSuchName o badValue) e error-index impostato all'indice della variabile fallita.
Se tutte le verifiche hanno successo, l'agente esegue l'operazione set, modificando i valori delle variabili nominate. Invia quindi una PDU get-response con error-status di noError e error-index di zero e include i nuovi valori nel campo variable-bindings.
Se si verifica un errore durante l'operazione set, l'agente invia una PDU get-response con error-status di genErr e error-index impostato all'indice della variabile in cui è stato rilevato l'errore.
4.1.1.5. Receiving a Get Response
Quando una get-response è ricevuta dall'entità SNMP richiedente (tipicamente un manager), questa abbina il messaggio a una richiesta pendente utilizzando il request-id e l'indirizzo di trasporto sorgente. Elabora quindi il campo variable-bindings secondo i campi error-status e error-index. Se error-status è noError, i valori sono assegnati alle corrispondenti variabili locali. Altrimenti, il manager adotta l'azione appropriata all'errore indicato.
4.1.2. The GetNextRequest-PDU
La semantica della PDU get-next-request è simile a quella della PDU get-request, tranne per il fatto che la variabile nominata nel campo variable-bindings della richiesta è quella il cui nome è lessicograficamente successivo (nella vista MIB) alla variabile nominata. Le PDU get-next-request e get-response forniscono un mezzo per "attraversare" la MIB, recuperando i valori di una sequenza di variabili senza conoscerne i nomi esatti in anticipo.
4.1.3. The Trap Operation
I trap sono notifiche asincrone inviate da un agent a un manager. L'agente genera una PDU trap quando si verifica un evento significativo, come un avvio a freddo o a caldo, la caduta o l'attivazione di un collegamento, un errore di autenticazione o la perdita di un vicino EGP. La PDU trap contiene i campi enterprise, agent-addr, generic-trap, specific-trap, time-stamp e variable-bindings. Poiché i trap non sono confermati, l'agente non si aspetta alcuna risposta dal manager.
Return: RFC 1157 Home