4. Spécification du protocole
Le protocole de gestion de réseau est un protocole d'application grâce auquel les variables de la MIB d'un agent peuvent être inspectées ou modifiées.
La communication entre entités de protocole s'accomplit par l'échange de messages, dont chacun est entièrement et indépendamment représenté dans un seul datagramme UDP à l'aide des règles d'encodage de base d'ASN.1 (comme discuté à la section 3.2.2). Un message se compose d'un identificateur de version, d'un nom de communauté SNMP et d'une unité de données de protocole (PDU). Une entité de protocole reçoit les messages au port UDP 161 sur l'hôte auquel elle est associée pour tous les messages, sauf ceux qui signalent des traps (c'est-à-dire tous les messages sauf ceux qui contiennent la PDU Trap). Les messages qui signalent des traps doivent être reçus sur le port UDP 162 pour un traitement ultérieur. Une implémentation de ce protocole n'a pas besoin d'accepter les messages dont la longueur dépasse 484 octets. Toutefois, il est recommandé que les implémentations prennent en charge des datagrammes plus grands lorsque cela est possible.
Il est obligatoire que toutes les implémentations du SNMP prennent en charge les cinq PDUs : GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU et 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. Éléments de procédure
Cette section décrit les actions d'une entité de protocole mettant en œuvre le SNMP. Notez toutefois qu'elle n'a pas pour but de contraindre l'architecture interne d'une implémentation conforme.
Dans le texte qui suit, le terme adresse de transport est utilisé. Dans le cas de l'UDP, une adresse de transport se compose d'une adresse IP accompagnée d'un port UDP. D'autres services de transport peuvent être utilisés pour prendre en charge le SNMP. Dans ces cas, la définition d'une adresse de transport doit être faite en conséquence.
Les actions de niveau supérieur d'une entité de protocole qui génère un message sont les suivantes :
-
Elle construit d'abord la PDU appropriée, par exemple la GetRequest-PDU, en tant qu'objet ASN.1.
-
Elle transmet ensuite cet objet ASN.1, accompagné d'un nom de communauté, de son adresse de transport source et de l'adresse de transport de destination, au service qui met en œuvre le schéma d'authentification souhaité. Ce service d'authentification renvoie un autre objet ASN.1.
-
L'entité de protocole construit ensuite un objet ASN.1 Message, en utilisant le nom de communauté et l'objet ASN.1 résultant.
-
Ce nouvel objet ASN.1 est ensuite sérialisé, à l'aide des règles d'encodage de base d'ASN.1, puis envoyé à l'aide d'un service de transport à l'entité de protocole paire.
De même, les actions de niveau supérieur d'une entité de protocole qui reçoit un message sont les suivantes :
-
Elle effectue une analyse rudimentaire du datagramme entrant pour construire un objet ASN.1 correspondant à un objet ASN.1 Message. Si l'analyse échoue, elle rejette le datagramme et n'effectue aucune autre action.
-
Elle vérifie ensuite le numéro de version du message SNMP. En cas de non-concordance, elle rejette le datagramme et n'effectue aucune autre action.
-
L'entité de protocole transmet ensuite le nom de communauté et les données utilisateur trouvés dans l'objet ASN.1 Message, ainsi que les adresses de transport source et de destination du datagramme, au service qui met en œuvre le schéma d'authentification souhaité. Cette entité renvoie un autre objet ASN.1, ou signale un échec d'authentification. Dans ce dernier cas, l'entité de protocole consigne cet échec, génère (éventuellement) un trap, puis rejette le datagramme et n'effectue aucune autre action.
-
L'entité de protocole effectue ensuite une analyse rudimentaire de l'objet ASN.1 renvoyé par le service d'authentification pour construire un objet ASN.1 correspondant à un objet ASN.1 PDUs. Si l'analyse échoue, elle rejette le datagramme et n'effectue aucune autre action. Sinon, à l'aide de la communauté SNMP nommée, le profil approprié est sélectionné, et la PDU est traitée en conséquence. Si, à l'issue de ce traitement, un message est renvoyé, alors l'adresse de transport source depuis laquelle le message de réponse est envoyé doit être identique à l'adresse de transport de destination à laquelle le message de demande d'origine a été envoyé.
4.1.1. Constructions communes
Avant d'introduire les six types de PDU du protocole, il convient d'examiner quelques-unes des constructions ASN.1 fréquemment utilisées :
-- 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
Les RequestIDs servent à distinguer les demandes en cours. Grâce au RequestID, une entité d'application SNMP peut mettre en correspondance les réponses entrantes avec les demandes en cours. Dans les cas où un service de datagrammes non fiable est utilisé, le RequestID fournit également un moyen simple d'identifier les messages dupliqués par le réseau.
Une instance non nulle d'ErrorStatus est utilisée pour indiquer qu'une exception s'est produite lors du traitement d'une demande. Dans ces cas, ErrorIndex peut fournir des informations supplémentaires en indiquant quelle variable d'une liste a provoqué l'exception.
Le terme variable désigne une instance d'un objet géré. Une liaison de variable, ou VarBind, désigne l'appariement du nom d'une variable avec la valeur de cette variable. Une VarBindList est une liste simple de noms de variables et des valeurs correspondantes. Certaines PDUs ne concernent que le nom d'une variable et non sa valeur (par exemple la GetRequest-PDU). Dans ce cas, la partie valeur de la liaison est ignorée par l'entité de protocole. Toutefois, la partie valeur doit tout de même avoir une syntaxe et un encodage ASN.1 valides. Il est recommandé d'utiliser la valeur ASN.1 NULL pour la partie valeur de ces liaisons.
4.1.2. La PDU GetRequest
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 est générée par une entité de protocole uniquement à la demande de son entité d'application SNMP.
À la réception de la GetRequest-PDU, l'entité de protocole réceptrice répond selon toute règle applicable de la liste ci-dessous :
-
Si, pour un objet quelconque nommé dans le champ variable-bindings, le nom de l'objet ne correspond pas exactement au nom d'un objet disponible pour les opérations get dans la vue MIB pertinente, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est noSuchName et que la valeur du champ error-index est l'index de ladite composante de nom d'objet dans le message reçu.
-
Si, pour un objet quelconque nommé dans le champ variable-bindings, l'objet est d'un type agrégé (tel que défini dans le SMI), alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est noSuchName et que la valeur du champ error-index est l'index de ladite composante de nom d'objet dans le message reçu.
-
Si la taille de la GetResponse-PDU générée comme décrit ci-dessous devait dépasser une limitation locale, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est tooBig et que la valeur du champ error-index est zéro.
-
Si, pour un objet quelconque nommé dans le champ variable-bindings, la valeur de l'objet ne peut pas être récupérée pour des raisons non couvertes par l'une quelconque des règles précédentes, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est genErr et que la valeur du champ error-index est l'index de ladite composante de nom d'objet dans le message reçu.
Si aucune des règles précédentes ne s'applique, alors l'entité de protocole réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de telle sorte que, pour chaque objet nommé dans le champ variable-bindings du message reçu, la composante correspondante de la GetResponse-PDU représente le nom et la valeur de cette variable. La valeur du champ error-status de la GetResponse-PDU est noError et la valeur du champ error-index est zéro. La valeur du champ request-id de la GetResponse-PDU est celle du message reçu.
4.1.3. La PDU GetNextRequest
La forme de la GetNextRequest-PDU est identique à celle de la GetRequest-PDU, hormis l'indication du type de PDU. Dans le langage 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 est générée par une entité de protocole uniquement à la demande de son entité d'application SNMP.
À la réception de la GetNextRequest-PDU, l'entité de protocole réceptrice répond selon toute règle applicable de la liste ci-dessous :
-
Si, pour un nom d'objet quelconque du champ variable-bindings, ce nom ne précède pas lexicographiquement le nom d'un objet disponible pour les opérations get dans la vue MIB pertinente, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est noSuchName et que la valeur du champ error-index est l'index de ladite composante de nom d'objet dans le message reçu.
-
Si la taille de la GetResponse-PDU générée comme décrit ci-dessous devait dépasser une limitation locale, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est tooBig et que la valeur du champ error-index est zéro.
-
Si, pour un objet quelconque nommé dans le champ variable-bindings, la valeur du successeur lexicographique de l'objet nommé ne peut pas être récupérée pour des raisons non couvertes par l'une quelconque des règles précédentes, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est genErr et que la valeur du champ error-index est l'index de ladite composante de nom d'objet dans le message reçu.
Si aucune des règles précédentes ne s'applique, alors l'entité de protocole réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de telle sorte que, pour chaque nom du champ variable-bindings du message reçu, la composante correspondante de la GetResponse-PDU représente le nom et la valeur de cet objet dont le nom est, dans l'ordre lexicographique des noms de tous les objets disponibles pour les opérations get dans la vue MIB pertinente, conjointement avec la valeur du champ name de la composante donnée, le successeur immédiat de cette valeur. La valeur du champ error-status de la GetResponse-PDU est noError et la valeur du champ errorindex est zéro. La valeur du champ request-id de la GetResponse-PDU est celle du message reçu.
4.1.3.1. Exemple de parcours de table
Un usage important de la GetNextRequest-PDU est le parcours des tables conceptuelles d'informations au sein de la MIB. La sémantique de ce type de message SNMP, conjointement avec les mécanismes propres au protocole permettant d'identifier les instances individuelles des types d'objets de la MIB, permet d'accéder aux objets apparentés de la MIB comme s'ils bénéficiaient d'une organisation tabulaire.
Par l'échange SNMP esquissé ci-dessous, une entité d'application SNMP pourrait extraire l'adresse de destination et la passerelle de prochain saut pour chaque entrée de la table de routage d'un élément de réseau particulier. Supposons que cette table de routage comporte trois entrées :
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 station de gestion envoie à l'agent SNMP une GetNextRequest-PDU contenant les valeurs d'OBJECT IDENTIFIER indiquées comme noms de variables demandés :
GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
L'agent SNMP répond par une 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 station de gestion poursuit avec :
GetNextRequest ( ipRouteDest.9.1.2.3,
ipRouteNextHop.9.1.2.3,
ipRouteMetric1.9.1.2.3 )
L'agent SNMP répond :
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 station de gestion poursuit avec :
GetNextRequest ( ipRouteDest.10.0.0.51,
ipRouteNextHop.10.0.0.51,
ipRouteMetric1.10.0.0.51 )
L'agent SNMP répond :
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 station de gestion poursuit avec :
GetNextRequest ( ipRouteDest.10.0.0.99,
ipRouteNextHop.10.0.0.99,
ipRouteMetric1.10.0.0.99 )
Comme il n'y a plus d'autres entrées dans la table, l'agent SNMP renvoie les objets qui suivent dans l'ordre lexicographique des noms d'objets connus. Cette réponse signale la fin de la table de routage à la station de gestion.
4.1.4. La PDU GetResponse
La forme de la GetResponse-PDU est identique à celle de la GetRequest-PDU, hormis l'indication du type de PDU. Dans le langage ASN.1 :
GetResponse-PDU ::=
[2]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
La GetResponse-PDU est générée par une entité de protocole uniquement à la réception de la GetRequest-PDU, de la GetNextRequest-PDU ou de la SetRequest-PDU, comme décrit ailleurs dans ce document.
À la réception de la GetResponse-PDU, l'entité de protocole réceptrice présente son contenu à son entité d'application SNMP.
4.1.5. La PDU SetRequest
La forme de la SetRequest-PDU est identique à celle de la GetRequest-PDU, hormis l'indication du type de PDU. Dans le langage 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 est générée par une entité de protocole uniquement à la demande de son entité d'application SNMP.
À la réception de la SetRequest-PDU, l'entité réceptrice répond selon toute règle applicable de la liste ci-dessous :
-
Si, pour un objet quelconque nommé dans le champ variable-bindings, l'objet n'est pas disponible pour les opérations set dans la vue MIB pertinente, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est noSuchName et que la valeur du champ error-index est l'index de ladite composante de nom d'objet dans le message reçu.
-
Si, pour un objet quelconque nommé dans le champ variable-bindings, le contenu du champ value ne présente pas, selon le langage ASN.1, un type, une longueur et une valeur cohérents avec ceux requis pour la variable, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est badValue et que la valeur du champ error-index est l'index dudit nom d'objet dans le message reçu.
-
Si la taille du message de type Get Response généré comme décrit ci-dessous devait dépasser une limitation locale, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est tooBig et que la valeur du champ error-index est zéro.
-
Si, pour un objet quelconque nommé dans le champ variable-bindings, la valeur de l'objet nommé ne peut pas être modifiée pour des raisons non couvertes par l'une quelconque des règles précédentes, alors l'entité réceptrice envoie à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est genErr et que la valeur du champ error-index est l'index de ladite composante de nom d'objet dans le message reçu.
Si aucune des règles précédentes ne s'applique, alors pour chaque objet nommé dans le champ variable-bindings du message reçu, la valeur correspondante est affectée à la variable. Chaque affectation de variable spécifiée par la SetRequest-PDU devrait être effectuée comme si elle était définie simultanément par rapport à toutes les autres affectations spécifiées dans le même message.
L'entité réceptrice envoie ensuite à l'émetteur du message reçu la GetResponse-PDU de forme identique, sauf que la valeur du champ error-status du message généré est noError et que la valeur du champ error-index est zéro.
4.1.6. La PDU Trap
La forme de la Trap-PDU est :
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 est générée par une entité de protocole uniquement à la demande de l'entité d'application SNMP. La manière dont une entité d'application SNMP sélectionne les adresses de destination des entités d'application SNMP dépend de l'implémentation.
À la réception de la Trap-PDU, l'entité de protocole réceptrice présente son contenu à son entité d'application SNMP.
La signification de la composante variable-bindings de la Trap-PDU dépend de l'implémentation.
Les interprétations de la valeur du champ generic-trap sont les suivantes :
4.1.6.1. Le trap coldStart
Un trap coldStart(0) signifie que l'entité de protocole émettrice se réinitialise de telle sorte que la configuration de l'agent ou la mise en œuvre de l'entité de protocole puisse être modifiée.
4.1.6.2. Le trap warmStart
Un trap warmStart(1) signifie que l'entité de protocole émettrice se réinitialise de telle sorte que ni la configuration de l'agent ni la mise en œuvre de l'entité de protocole ne soit modifiée.
4.1.6.3. Le trap linkDown
Un trap linkDown(2) signifie que l'entité de protocole émettrice reconnaît une défaillance dans l'une des liaisons de communication représentées dans la configuration de l'agent.
La Trap-PDU de type linkDown contient, comme premier élément de ses variable-bindings, le nom et la valeur de l'instance ifIndex pour l'interface affectée.
4.1.6.4. Le trap linkUp
Un trap linkUp(3) signifie que l'entité de protocole émettrice reconnaît que l'une des liaisons de communication représentées dans la configuration de l'agent est devenue opérationnelle.
La Trap-PDU de type linkUp contient, comme premier élément de ses variable-bindings, le nom et la valeur de l'instance ifIndex pour l'interface affectée.
4.1.6.5. Le trap authenticationFailure
Un trap authenticationFailure(4) signifie que l'entité de protocole émettrice est le destinataire d'un message de protocole qui n'est pas correctement authentifié. Bien que les implémentations du SNMP doivent être capables de générer ce trap, elles doivent aussi être capables de supprimer l'émission de tels traps par un mécanisme propre à l'implémentation.
4.1.6.6. Le trap egpNeighborLoss
Un trap egpNeighborLoss(5) signifie qu'un voisin EGP pour lequel l'entité de protocole émettrice était un pair EGP a été marqué comme indisponible et que la relation de pair n'existe plus.
La Trap-PDU de type egpNeighborLoss contient, comme premier élément de ses variable-bindings, le nom et la valeur de l'instance egpNeighAddr pour le voisin affecté.
4.1.6.7. Le trap enterpriseSpecific
Un trap enterpriseSpecific(6) signifie que l'entité de protocole émettrice reconnaît qu'un événement propre à une entreprise s'est produit. Le champ specific-trap identifie le trap particulier qui s'est produit.