4. Specifica del protocollo
Il protocollo di gestione di rete è un protocollo applicativo mediante il quale le variabili della MIB di un agent possono essere ispezionate o modificate.
La comunicazione tra entità di protocollo è realizzata mediante lo scambio di messaggi, ciascuno dei quali è interamente e indipendentemente rappresentato all'interno di un singolo datagramma UDP usando le basic encoding rules di ASN.1 (come discusso nel Paragrafo 3.2.2). Un messaggio è costituito da un identificatore di versione, un nome di community SNMP e un'unità di dati di protocollo (PDU). Un'entità di protocollo riceve i messaggi sulla porta UDP 161 dell'host con cui è associata per tutti i messaggi, tranne quelli che riportano trap (cioè tutti i messaggi tranne quelli che contengono la Trap-PDU). I messaggi che riportano trap dovrebbero essere ricevuti sulla porta UDP 162 per ulteriore elaborazione. Un'implementazione di questo protocollo non deve necessariamente accettare messaggi la cui lunghezza supera i 484 ottetti. Tuttavia, si raccomanda che le implementazioni supportino datagrammi più grandi ove possibile.
È obbligatorio che tutte le implementazioni dell'SNMP supportino le cinque PDU: GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU e Trap-PDU.
RFC1157-SNMP DEFINITIONS ::= BEGIN
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
-- protocol data units
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 commonly used
-- data types will be defined later
END
4.1. Elementi di procedura
Questa sezione descrive le azioni di un'entità di protocollo che implementa l'SNMP. Si noti, tuttavia, che essa non intende vincolare l'architettura interna di alcuna implementazione conforme.
Nel testo che segue si utilizza il termine indirizzo di trasporto. Nel caso dell'UDP, un indirizzo di trasporto è costituito da un indirizzo IP insieme a una porta UDP. Altri servizi di trasporto possono essere utilizzati per supportare l'SNMP. In questi casi, la definizione di un indirizzo di trasporto dovrebbe essere formulata di conseguenza.
Le azioni di livello superiore di un'entità di protocollo che genera un messaggio sono le seguenti:
-
Costruisce innanzitutto la PDU appropriata, ad esempio la GetRequest-PDU, come oggetto ASN.1.
-
Passa poi questo oggetto ASN.1, insieme a un nome di community, il suo indirizzo di trasporto sorgente e l'indirizzo di trasporto di destinazione, al servizio che implementa lo schema di autenticazione desiderato. Questo servizio di autenticazione restituisce un altro oggetto ASN.1.
-
L'entità di protocollo costruisce quindi un oggetto Message ASN.1, usando il nome di community e l'oggetto ASN.1 risultante.
-
Questo nuovo oggetto ASN.1 viene quindi serializzato, usando le basic encoding rules di ASN.1, e poi inviato tramite un servizio di trasporto all'entità di protocollo peer.
Analogamente, le azioni di livello superiore di un'entità di protocollo che riceve un messaggio sono le seguenti:
-
Esegue un'analisi sintattica rudimentale del datagramma in arrivo per costruire un oggetto ASN.1 corrispondente a un oggetto Message ASN.1. Se l'analisi fallisce, scarta il datagramma e non esegue ulteriori azioni.
-
Verifica poi il numero di versione del messaggio SNMP. Se vi è una discrepanza, scarta il datagramma e non esegue ulteriori azioni.
-
L'entità di protocollo passa quindi il nome di community e i dati utente trovati nell'oggetto Message ASN.1, insieme agli indirizzi di trasporto sorgente e di destinazione del datagramma, al servizio che implementa lo schema di autenticazione desiderato. Questa entità restituisce un altro oggetto ASN.1, oppure segnala un fallimento di autenticazione. In quest'ultimo caso, l'entità di protocollo registra questo fallimento, (possibilmente) genera una trap e scarta il datagramma, senza eseguire ulteriori azioni.
-
L'entità di protocollo esegue quindi un'analisi sintattica rudimentale sull'oggetto ASN.1 restituito dal servizio di autenticazione per costruire un oggetto ASN.1 corrispondente a un oggetto PDUs ASN.1. Se l'analisi fallisce, scarta il datagramma e non esegue ulteriori azioni. In caso contrario, usando la community SNMP denominata, viene selezionato il profilo appropriato e la PDU viene elaborata di conseguenza. Se, in seguito a questa elaborazione, viene restituito un messaggio, l'indirizzo di trasporto sorgente da cui viene inviato il messaggio di risposta deve essere identico all'indirizzo di trasporto di destinazione a cui è stato inviato il messaggio di richiesta originale.
4.1.1. Costrutti comuni
Prima di introdurre i sei tipi di PDU del protocollo, è opportuno considerare alcuni dei costrutti ASN.1 usati frequentemente:
-- request/response information
RequestID ::=
INTEGER
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
ErrorIndex ::=
INTEGER
-- variable bindings
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
I RequestID sono usati per distinguere tra richieste in sospeso. Mediante l'uso del RequestID, un'entità applicativa SNMP può correlare le risposte in arrivo con le richieste in sospeso. Nei casi in cui si utilizzi un servizio di datagramma non affidabile, il RequestID fornisce anche un semplice mezzo per identificare i messaggi duplicati dalla rete.
Un'istanza non nulla di ErrorStatus è usata per indicare che si è verificata un'eccezione durante l'elaborazione di una richiesta. In questi casi, ErrorIndex può fornire informazioni aggiuntive indicando quale variabile in un elenco ha causato l'eccezione.
Il termine variabile si riferisce a un'istanza di un oggetto gestito. Un variable binding, o VarBind, si riferisce all'accoppiamento del nome di una variabile con il valore della variabile. Un VarBindList è un semplice elenco di nomi di variabile e valori corrispondenti. Alcune PDU riguardano solo il nome di una variabile e non il suo valore (ad esempio la GetRequest-PDU). In questo caso, la parte relativa al valore del binding viene ignorata dall'entità di protocollo. Tuttavia, la parte relativa al valore deve comunque avere sintassi e codifica ASN.1 valide. Si raccomanda di usare il valore ASN.1 NULL per la parte relativa al valore di tali binding.
4.1.2. La GetRequest-PDU
The form of the GetRequest-PDU is:
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
La GetRequest-PDU è generata da un'entità di protocollo solo su richiesta della sua entità applicativa SNMP.
Al ricevimento della GetRequest-PDU, l'entità di protocollo ricevente risponde secondo qualsiasi regola applicabile nell'elenco seguente:
-
Se, per qualsiasi oggetto nominato nel campo variable-bindings, il nome dell'oggetto non corrisponde esattamente al nome di qualche oggetto disponibile per le operazioni get nella vista MIB pertinente, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è noSuchName e il valore del campo error-index è l'indice di detta componente del nome dell'oggetto nel messaggio ricevuto.
-
Se, per qualsiasi oggetto nominato nel campo variable-bindings, l'oggetto è di tipo aggregato (come definito nella SMI), l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è noSuchName e il valore del campo error-index è l'indice di detta componente del nome dell'oggetto nel messaggio ricevuto.
-
Se la dimensione della GetResponse-PDU generata come descritto di seguito supererebbe un limite locale, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è tooBig e il valore del campo error-index è zero.
-
Se, per qualsiasi oggetto nominato nel campo variable-bindings, il valore dell'oggetto non può essere recuperato per motivi non contemplati da alcuna delle regole precedenti, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è genErr e il valore del campo error-index è l'indice di detta componente del nome dell'oggetto nel messaggio ricevuto.
Se nessuna delle regole precedenti si applica, l'entità di protocollo ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU in modo che, per ciascun oggetto nominato nel campo variable-bindings del messaggio ricevuto, la componente corrispondente della GetResponse-PDU rappresenti il nome e il valore di quella variabile. Il valore del campo error-status della GetResponse-PDU è noError e il valore del campo error-index è zero. Il valore del campo request-id della GetResponse-PDU è quello del messaggio ricevuto.
4.1.3. La GetNextRequest-PDU
La forma della GetNextRequest-PDU è identica a quella della GetRequest-PDU, salvo per l'indicazione del tipo di PDU. Nel linguaggio ASN.1:
GetNextRequest-PDU ::=
[1]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
La GetNextRequest-PDU è generata da un'entità di protocollo solo su richiesta della sua entità applicativa SNMP.
Al ricevimento della GetNextRequest-PDU, l'entità di protocollo ricevente risponde secondo qualsiasi regola applicabile nell'elenco seguente:
-
Se, per qualsiasi nome di oggetto nel campo variable-bindings, quel nome non precede lessicograficamente il nome di qualche oggetto disponibile per le operazioni get nella vista MIB pertinente, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è noSuchName e il valore del campo error-index è l'indice di detta componente del nome dell'oggetto nel messaggio ricevuto.
-
Se la dimensione della GetResponse-PDU generata come descritto di seguito supererebbe un limite locale, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è tooBig e il valore del campo error-index è zero.
-
Se, per qualsiasi oggetto nominato nel campo variable-bindings, il valore del successore lessicografico dell'oggetto nominato non può essere recuperato per motivi non contemplati da alcuna delle regole precedenti, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è genErr e il valore del campo error-index è l'indice di detta componente del nome dell'oggetto nel messaggio ricevuto.
Se nessuna delle regole precedenti si applica, l'entità di protocollo ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU in modo che, per ciascun nome nel campo variable-bindings del messaggio ricevuto, la componente corrispondente della GetResponse-PDU rappresenti il nome e il valore di quell'oggetto il cui nome è, nell'ordinamento lessicografico dei nomi di tutti gli oggetti disponibili per le operazioni get nella vista MIB pertinente, insieme al valore del campo name della componente data, il successore immediato di quel valore. Il valore del campo error-status della GetResponse-PDU è noError e il valore del campo errorindex è zero. Il valore del campo request-id della GetResponse-PDU è quello del messaggio ricevuto.
4.1.3.1. Esempio di attraversamento di tabella
Un uso importante della GetNextRequest-PDU è l'attraversamento delle tabelle concettuali di informazioni all'interno della MIB. La semantica di questo tipo di messaggio SNMP, insieme ai meccanismi specifici del protocollo per identificare le singole istanze dei tipi di oggetto nella MIB, consente l'accesso a oggetti correlati nella MIB come se essi godessero di un'organizzazione tabellare.
Mediante lo scambio SNMP abbozzato di seguito, un'entità applicativa SNMP potrebbe estrarre l'indirizzo di destinazione e il gateway di next hop per ciascuna voce nella tabella di routing di un particolare elemento di rete. Supponiamo che questa tabella di routing abbia tre voci:
Destination NextHop Metric
10.0.0.99 89.1.1.42 5
9.1.2.3 99.0.0.3 3
10.0.0.51 89.1.1.42 5
La stazione di gestione invia all'agent SNMP una GetNextRequest-PDU contenente i valori OBJECT IDENTIFIER indicati come nomi delle variabili richieste:
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
L'agent SNMP risponde con una GetResponse-PDU:
GetResponse (( ipRouteDest.9.1.2.3 = "9.1.2.3" ),
( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
( ipRouteMetric1.9.1.2.3 = 3 ))
La stazione di gestione prosegue con:
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
L'agent SNMP risponde:
GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.51 = 5 ))
La stazione di gestione prosegue con:
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
L'agent SNMP risponde:
GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
( ipRouteMetric1.10.0.0.99 = 5 ))
La stazione di gestione prosegue con:
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
Poiché non vi sono ulteriori voci nella tabella, l'agent SNMP restituisce gli oggetti che seguono nell'ordinamento lessicografico dei nomi di oggetto noti. Questa risposta segnala alla stazione di gestione la fine della tabella di routing.
4.1.4. La GetResponse-PDU
La forma della GetResponse-PDU è identica a quella della GetRequest-PDU, salvo per l'indicazione del tipo di PDU. Nel linguaggio ASN.1:
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
La GetResponse-PDU è generata da un'entità di protocollo solo al ricevimento della GetRequest-PDU, della GetNextRequest-PDU o della SetRequest-PDU, come descritto altrove in questo documento.
Al ricevimento della GetResponse-PDU, l'entità di protocollo ricevente presenta il suo contenuto alla propria entità applicativa SNMP.
4.1.5. La SetRequest-PDU
La forma della SetRequest-PDU è identica a quella della GetRequest-PDU, salvo per l'indicazione del tipo di PDU. Nel linguaggio ASN.1:
SetRequest-PDU ::=
[3]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
La SetRequest-PDU è generata da un'entità di protocollo solo su richiesta della sua entità applicativa SNMP.
Al ricevimento della SetRequest-PDU, l'entità ricevente risponde secondo qualsiasi regola applicabile nell'elenco seguente:
-
Se, per qualsiasi oggetto nominato nel campo variable-bindings, l'oggetto non è disponibile per le operazioni set nella vista MIB pertinente, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è noSuchName e il valore del campo error-index è l'indice di detta componente del nome dell'oggetto nel messaggio ricevuto.
-
Se, per qualsiasi oggetto nominato nel campo variable-bindings, il contenuto del campo value non manifesta, secondo il linguaggio ASN.1, un tipo, una lunghezza e un valore coerenti con quelli richiesti per la variabile, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è badValue e il valore del campo error-index è l'indice di detto nome dell'oggetto nel messaggio ricevuto.
-
Se la dimensione del messaggio di tipo Get Response generato come descritto di seguito supererebbe un limite locale, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è tooBig e il valore del campo error-index è zero.
-
Se, per qualsiasi oggetto nominato nel campo variable-bindings, il valore dell'oggetto nominato non può essere modificato per motivi non contemplati da alcuna delle regole precedenti, l'entità ricevente invia all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status è genErr e il valore del campo error-index è l'indice di detta componente del nome dell'oggetto nel messaggio ricevuto.
Se nessuna delle regole precedenti si applica, allora per ciascun oggetto nominato nel campo variable-bindings del messaggio ricevuto, il valore corrispondente viene assegnato alla variabile. Ogni assegnazione di variabile specificata dalla SetRequest-PDU dovrebbe essere effettuata come se fosse impostata simultaneamente rispetto a tutte le altre assegnazioni specificate nello stesso messaggio.
L'entità ricevente invia quindi all'originatore del messaggio ricevuto la GetResponse-PDU di forma identica, salvo che il valore del campo error-status del messaggio generato è noError e il valore del campo error-index è zero.
4.1.6. La Trap-PDU
La forma della Trap-PDU è:
Trap-PDU ::=
[4]
IMPLICIT SEQUENCE {
enterprise -- type of object generating
-- trap, see sysObjectID in [5]
OBJECT IDENTIFIER,
agent-addr -- address of object generating
NetworkAddress, -- trap
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
INTEGER, -- if generic-trap is not
-- enterpriseSpecific
time-stamp -- time elapsed between the last
TimeTicks, -- (re)initialization of the network
-- entity and the generation of the
trap
variable-bindings -- "interesting" information
VarBindList
}
La Trap-PDU è generata da un'entità di protocollo solo su richiesta dell'entità applicativa SNMP. Il modo in cui un'entità applicativa SNMP seleziona gli indirizzi di destinazione delle entità applicative SNMP è specifico dell'implementazione.
Al ricevimento della Trap-PDU, l'entità di protocollo ricevente presenta il suo contenuto alla propria entità applicativa SNMP.
Il significato della componente variable-bindings della Trap-PDU è specifico dell'implementazione.
Le interpretazioni del valore del campo generic-trap sono:
4.1.6.1. La trap coldStart
Una trap coldStart(0) significa che l'entità di protocollo mittente si sta reinizializzando in modo tale che la configurazione dell'agent o l'implementazione dell'entità di protocollo possa essere modificata.
4.1.6.2. La trap warmStart
Una trap warmStart(1) significa che l'entità di protocollo mittente si sta reinizializzando in modo tale che né la configurazione dell'agent né l'implementazione dell'entità di protocollo venga modificata.
4.1.6.3. La trap linkDown
Una trap linkDown(2) significa che l'entità di protocollo mittente riconosce un guasto in uno dei collegamenti di comunicazione rappresentati nella configurazione dell'agent.
La Trap-PDU di tipo linkDown contiene, come primo elemento delle sue variable-bindings, il nome e il valore dell'istanza ifIndex per l'interfaccia interessata.
4.1.6.4. La trap linkUp
Una trap linkUp(3) significa che l'entità di protocollo mittente riconosce che uno dei collegamenti di comunicazione rappresentati nella configurazione dell'agent è diventato attivo.
La Trap-PDU di tipo linkUp contiene, come primo elemento delle sue variable-bindings, il nome e il valore dell'istanza ifIndex per l'interfaccia interessata.
4.1.6.5. La trap authenticationFailure
Una trap authenticationFailure(4) significa che l'entità di protocollo mittente è il destinatario di un messaggio di protocollo non autenticato correttamente. Sebbene le implementazioni dell'SNMP debbano essere in grado di generare questa trap, esse devono anche essere in grado di sopprimere l'emissione di tali trap tramite un meccanismo specifico dell'implementazione.
4.1.6.6. La trap egpNeighborLoss
Una trap egpNeighborLoss(5) significa che un vicino EGP, per il quale l'entità di protocollo mittente era un peer EGP, è stato marcato come inattivo e la relazione di peering non sussiste più.
La Trap-PDU di tipo egpNeighborLoss contiene, come primo elemento delle sue variable-bindings, il nome e il valore dell'istanza egpNeighAddr per il vicino interessato.
4.1.6.7. La trap enterpriseSpecific
Una trap enterpriseSpecific(6) significa che l'entità di protocollo mittente riconosce che si è verificato un evento specifico dell'enterprise. Il campo specific-trap identifica la particolare trap che si è verificata.