3. Architecture SNMP
Le modèle architectural SNMP suppose implicitement un ensemble de stations de gestion de réseau et d'éléments de réseau. Les stations de gestion de réseau exécutent des applications de gestion qui surveillent et contrôlent les éléments de réseau. Les éléments de réseau sont des dispositifs tels que des hôtes, des passerelles, des serveurs terminaux et analogues, qui possèdent des agents de gestion chargés d'exécuter les fonctions de gestion de réseau demandées par les stations de gestion de réseau. Le Simple Network Management Protocol (SNMP) est utilisé pour communiquer les informations de gestion entre les stations de gestion de réseau et les agents des éléments de réseau.
3.1. Objectifs de l'architecture
Le SNMP minimise explicitement le nombre et la complexité des fonctions de gestion réalisées par l'agent de gestion lui-même. Cet objectif est intéressant à au moins quatre égards :
-
Le coût de développement du logiciel d'agent de gestion nécessaire pour prendre en charge le protocole est réduit d'autant.
-
Le degré de fonction de gestion pris en charge à distance est augmenté d'autant, ce qui permet la pleine utilisation des ressources internet dans la tâche de gestion.
-
Le degré de fonction de gestion pris en charge à distance est augmenté d'autant, ce qui impose le moins de restrictions possible sur la forme et la sophistication des outils de gestion.
-
Des ensembles simplifiés de fonctions de gestion sont facilement compris et utilisés par les développeurs d'outils de gestion de réseau.
Un deuxième objectif du protocole est que le paradigme fonctionnel de surveillance et de contrôle soit suffisamment extensible pour prendre en compte des aspects supplémentaires, éventuellement imprévus, de l'exploitation et de la gestion du réseau.
Un troisième objectif est que l'architecture soit, autant que possible, indépendante de l'architecture et des mécanismes d'hôtes particuliers ou de passerelles particulières.
3.2. Éléments de l'architecture
L'architecture SNMP articule une solution au problème de la gestion de réseau en termes de :
-
la portée des informations de gestion communiquées par le protocole,
-
la représentation des informations de gestion communiquées par le protocole,
-
les opérations sur les informations de gestion prises en charge par le protocole,
-
la forme et la signification des échanges entre entités de gestion,
-
la définition des relations administratives entre entités de gestion, et
-
la forme et la signification des références aux informations de gestion.
3.2.1. Portée des informations de gestion
La portée des informations de gestion communiquées par le fonctionnement du SNMP est exactement celle représentée par les instances de tous les types d'objets non agrégés, qu'ils soient définis dans la MIB standard Internet ou définis ailleurs selon les conventions énoncées dans le SMI standard Internet [5].
La prise en charge des types d'objets agrégés dans la MIB n'est ni exigée pour la conformité au SMI, ni réalisée par le SNMP.
3.2.2. Représentation des informations de gestion
Les informations de gestion communiquées par le fonctionnement du SNMP sont représentées selon le sous-ensemble du langage ASN.1 [9] qui est spécifié pour la définition des types non agrégés dans le SMI.
Le SGMP a adopté la convention d'utiliser un sous-ensemble bien défini du langage ASN.1 [9]. Le SNMP poursuit et étend cette tradition en utilisant un sous-ensemble modérément plus complexe d'ASN.1 pour décrire les objets gérés et pour décrire les unités de données de protocole servant à gérer ces objets. En outre, le souhait de faciliter la transition éventuelle vers des protocoles de gestion de réseau fondés sur l'OSI a conduit à la définition, dans le langage ASN.1, d'une Structure des informations de gestion (SMI) [5] et d'une Base d'informations de gestion (MIB) [6] standard Internet. L'utilisation du langage ASN.1 a été, en partie, encouragée par le succès de l'emploi d'ASN.1 dans des travaux antérieurs, en particulier le SGMP. Les restrictions sur l'utilisation d'ASN.1 qui font partie du SMI contribuent à la simplicité préconisée et validée par l'expérience du SGMP.
Toujours par souci de simplicité, le SNMP n'utilise qu'un sous-ensemble des règles d'encodage de base d'ASN.1 [10]. À savoir, tous les encodages utilisent la forme à longueur définie. En outre, chaque fois que cela est permis, des encodages non constructeurs sont utilisés plutôt que des encodages constructeurs. Cette restriction s'applique à tous les aspects de l'encodage ASN.1, tant pour les unités de données de protocole de niveau supérieur que pour les objets de données qu'elles contiennent.
3.2.3. Opérations prises en charge sur les informations de gestion
Le SNMP modélise toutes les fonctions de l'agent de gestion comme des modifications ou des inspections de variables. Ainsi, une entité de protocole située sur un hôte logiquement distant (éventuellement l'élément de réseau lui-même) interagit avec l'agent de gestion résidant sur l'élément de réseau afin de récupérer (get) ou de modifier (set) des variables. Cette stratégie a au moins deux conséquences positives :
-
Elle a pour effet de limiter à deux le nombre de fonctions de gestion essentielles réalisées par l'agent de gestion : une opération pour affecter une valeur à un paramètre de configuration ou autre paramètre spécifié, et une autre pour récupérer une telle valeur.
-
Un second effet de cette décision est d'éviter d'introduire dans la définition du protocole la prise en charge de commandes de gestion impératives : le nombre de ces commandes ne cesse en pratique d'augmenter, et la sémantique de ces commandes est en général arbitrairement complexe.
La stratégie implicite du SNMP est que la surveillance de l'état du réseau, à tout niveau de détail significatif, s'accomplit principalement par interrogation (polling) des informations appropriées de la part du ou des centres de surveillance. Un nombre limité de messages non sollicités (traps) guide le moment et l'objet de l'interrogation. Limiter le nombre de messages non sollicités est conforme à l'objectif de simplicité et de minimisation du trafic engendré par la fonction de gestion de réseau.
L'exclusion des commandes impératives de l'ensemble des fonctions de gestion explicitement prises en charge ne devrait guère empêcher une quelconque opération souhaitable de l'agent de gestion. Actuellement, la plupart des commandes sont des demandes visant soit à définir la valeur d'un paramètre, soit à récupérer une telle valeur, et la fonction des quelques commandes impératives actuellement prises en charge est facilement prise en compte en mode asynchrone par ce modèle de gestion. Dans ce schéma, une commande impérative pourrait être réalisée par le réglage d'une valeur de paramètre qui déclenche ensuite l'action souhaitée. Par exemple, plutôt que de mettre en œuvre une « commande de redémarrage », cette action pourrait être invoquée en définissant simplement un paramètre indiquant le nombre de secondes avant le redémarrage du système.
3.2.4. Forme et signification des échanges de protocole
La communication des informations de gestion entre entités de gestion est réalisée dans le SNMP par l'échange de messages de protocole. La forme et la signification de ces messages sont définies ci-dessous à la section 4.
Conformément à l'objectif de minimiser la complexité de l'agent de gestion, l'échange de messages SNMP ne requiert qu'un service de datagrammes non fiable, et chaque message est entièrement et indépendamment représenté par un seul datagramme de transport. Bien que ce document spécifie l'échange de messages via le protocole UDP [11], les mécanismes du SNMP conviennent généralement à une grande variété de services de transport.
3.2.5. Définition des relations administratives
L'architecture SNMP admet une variété de relations administratives entre les entités qui participent au protocole. Les entités résidant dans les stations de gestion et les éléments de réseau qui communiquent entre eux à l'aide du SNMP sont appelées entités d'application SNMP. Les processus pairs qui mettent en œuvre le SNMP, et prennent ainsi en charge les entités d'application SNMP, sont appelés entités de protocole.
L'appariement d'un agent SNMP avec un ensemble arbitraire d'entités d'application SNMP est appelé une communauté SNMP. Chaque communauté SNMP est nommée par une chaîne d'octets, appelée nom de communauté de ladite communauté.
Un message SNMP émis par une entité d'application SNMP qui appartient effectivement à la communauté SNMP nommée par le composant communauté dudit message est appelé message SNMP authentique. L'ensemble des règles par lesquelles un message SNMP est identifié comme un message SNMP authentique pour une communauté SNMP particulière est appelé schéma d'authentification. Une mise en œuvre d'une fonction qui identifie les messages SNMP authentiques selon un ou plusieurs schémas d'authentification est appelée service d'authentification.
De toute évidence, une gestion efficace des relations administratives entre entités d'application SNMP requiert des services d'authentification qui (par l'utilisation du chiffrement ou d'autres techniques) sont capables d'identifier les messages SNMP authentiques avec un haut degré de certitude. Certaines implémentations du SNMP peuvent souhaiter ne prendre en charge qu'un service d'authentification trivial qui identifie tous les messages SNMP comme des messages SNMP authentiques.
Pour tout élément de réseau, un sous-ensemble d'objets de la MIB qui se rapportent à cet élément est appelé vue MIB SNMP. Notons que les noms des types d'objets représentés dans une vue MIB SNMP ne doivent pas nécessairement appartenir à une seule sous-arborescence de l'espace de noms des types d'objets.
Un élément de l'ensemble { READ-ONLY, READ-WRITE } est appelé mode d'accès SNMP.
L'appariement d'un mode d'accès SNMP avec une vue MIB SNMP est appelé profil de communauté SNMP. Un profil de communauté SNMP représente des privilèges d'accès spécifiés à des variables dans une vue MIB spécifiée. Pour chaque variable de la vue MIB dans un profil de communauté SNMP donné, l'accès à cette variable est représenté par le profil selon les conventions suivantes :
-
si ladite variable est définie dans la MIB avec « Access: » valant « none », elle n'est disponible comme opérande pour aucun opérateur ;
-
si ladite variable est définie dans la MIB avec « Access: » valant « read-write » ou « write-only » et que le mode d'accès du profil donné est READ-WRITE, cette variable est disponible comme opérande pour les opérations get, set et trap ;
-
sinon, la variable est disponible comme opérande pour les opérations get et trap.
-
Dans les cas où une variable « write-only » est un opérande utilisé pour les opérations get ou trap, la valeur donnée pour la variable dépend de l'implémentation.
L'appariement d'une communauté SNMP avec un profil de communauté SNMP est appelé politique d'accès SNMP. Une politique d'accès représente un profil de communauté spécifié accordé par l'agent SNMP d'une communauté SNMP spécifiée aux autres membres de cette communauté. Toutes les relations administratives entre entités d'application SNMP sont définies architecturalement en termes de politiques d'accès SNMP.
Pour toute politique d'accès SNMP, si l'élément de réseau sur lequel réside l'agent SNMP de la communauté SNMP spécifiée n'est pas celui auquel se rapporte la vue MIB du profil spécifié, alors cette politique est appelée politique d'accès proxy SNMP. L'agent SNMP associé à une politique d'accès proxy est appelé agent proxy SNMP. Bien qu'une définition imprudente des politiques d'accès proxy puisse entraîner des boucles de gestion, une définition prudente des politiques proxy est utile d'au moins deux manières :
-
Elle permet la surveillance et le contrôle d'éléments de réseau qui, autrement, ne sont pas adressables à l'aide du protocole de gestion et du protocole de transport. C'est-à-dire qu'un agent proxy peut fournir une fonction de conversion de protocole permettant à une station de gestion d'appliquer un cadre de gestion cohérent à tous les éléments de réseau, y compris des dispositifs tels que des modems, des multiplexeurs et d'autres dispositifs qui prennent en charge des cadres de gestion différents.
-
Elle protège potentiellement les éléments de réseau contre des politiques de contrôle d'accès élaborées. Par exemple, un agent proxy peut mettre en œuvre un contrôle d'accès sophistiqué grâce auquel divers sous-ensembles de variables de la MIB sont rendus accessibles à différentes stations de gestion sans augmenter la complexité de l'élément de réseau.
À titre d'exemple, la figure 1 illustre la relation entre les stations de gestion, les agents proxy et les agents de gestion. Dans cet exemple, l'agent proxy est envisagé comme un centre d'exploitation réseau Internet (INOC) normal d'un domaine administratif donné, qui entretient une relation de gestion standard avec un ensemble d'agents de gestion.
+------------------+ +----------------+ +----------------+
| Region #1 INOC | |Region #2 INOC | |PC in Region #3 |
| | | | | |
|Domain=Region #1 | |Domain=Region #2| |Domain=Region #3|
|CPU=super-mini-1 | |CPU=super-mini-1| |CPU=Clone-1 |
|PCommunity=pub | |PCommunity=pub | |PCommunity=slate|
| | | | | |
+------------------+ +----------------+ +----------------+
/|\ /|\ /|\
| | |
| | |
| \|/ |
| +-----------------+ |
+-------------->| Region #3 INOC |<-------------+
| |
|Domain=Region #3 |
|CPU=super-mini-2 |
|PCommunity=pub, |
| slate |
|DCommunity=secret|
+-------------->| |<-------------+
| +-----------------+ |
| /|\ |
| | |
| | |
\|/ \|/ \|/
+-----------------+ +-----------------+ +-----------------+
|Domain=Region#3 | |Domain=Region#3 | |Domain=Region#3 |
|CPU=router-1 | |CPU=mainframe-1 | |CPU=modem-1 |
|DCommunity=secret| |DCommunity=secret| |DCommunity=secret|
+-----------------+ +-----------------+ +-----------------+
- Domain: le domaine administratif de l'élément
- PCommunity: le nom d'une communauté utilisant un agent proxy
- DCommunity: le nom d'une communauté directe
Figure 1 : Exemple de configuration de gestion de réseau
3.2.6. Forme et signification des références aux objets gérés
Le SMI exige que la définition d'un protocole de gestion conforme traite :
-
la résolution des références MIB ambiguës,
-
la résolution des références MIB en présence de versions multiples de la MIB, et
-
l'identification d'instances particulières de types d'objets définis dans la MIB.
3.2.6.1. Résolution des références MIB ambiguës
Étant donné que la portée de toute opération SNMP est conceptuellement limitée aux objets pertinents pour un seul élément de réseau, et que toutes les références SNMP à des objets de la MIB se font (implicitement ou explicitement) par des noms de variables uniques, il est impossible qu'une référence SNMP à un type d'objet défini dans la MIB puisse se résoudre en plusieurs instances de ce type.
3.2.6.2. Résolution des références entre versions de MIB
L'instance d'objet à laquelle se réfère toute opération SNMP est exactement celle spécifiée dans la demande d'opération ou (dans le cas d'une opération get-next) son successeur immédiat dans la MIB prise dans son ensemble. En particulier, une référence à un objet dans le cadre d'une version donnée de la MIB standard Internet ne se résout pas en un objet qui ne fait pas partie de ladite version de la MIB standard Internet, sauf dans le cas où l'opération demandée est get-next et où le nom d'objet spécifié est le dernier dans l'ordre lexicographique parmi les noms de tous les objets présentés dans le cadre de ladite version de la MIB standard Internet.
3.2.6.3. Identification des instances d'objets
Les noms de tous les types d'objets de la MIB sont définis explicitement, soit dans la MIB standard Internet, soit dans d'autres documents qui se conforment aux conventions de nommage du SMI. Le SMI exige que les protocoles de gestion conformes définissent des mécanismes pour identifier les instances individuelles de ces types d'objets pour un élément de réseau particulier.
Chaque instance d'un type d'objet défini dans la MIB est identifiée dans les opérations SNMP par un nom unique appelé son « nom de variable ». En général, le nom d'une variable SNMP est un OBJECT IDENTIFIER de la forme x.y, où x est le nom d'un type d'objet non agrégé défini dans la MIB et y est un fragment d'OBJECT IDENTIFIER qui, d'une manière spécifique au type d'objet nommé, identifie l'instance souhaitée.
Cette stratégie de nommage permet la plus pleine exploitation de la sémantique de la PDU GetNextRequest (voir la section 4), car elle attribue des noms aux variables apparentées de manière à ce qu'elles soient contiguës dans l'ordre lexicographique de tous les noms de variables connus dans la MIB.
Le nommage propre au type des instances d'objets est défini ci-dessous pour un certain nombre de classes de types d'objets. Les instances d'un type d'objet auquel aucune des conventions de nommage suivantes ne s'applique sont nommées par des OBJECT IDENTIFIERs de la forme x.0, où x est le nom dudit type d'objet dans la définition de la MIB.
Par exemple, supposons que l'on veuille identifier une instance de la variable sysDescr. La classe d'objet de sysDescr est :
iso org dod internet mgmt mib system sysDescr
1 3 6 1 2 1 1 1
Par conséquent, le type d'objet, x, serait 1.3.6.1.2.1.1.1, auquel est ajouté un sous-identifiant d'instance de 0. C'est-à-dire que 1.3.6.1.2.1.1.1.0 identifie l'unique instance de sysDescr.
3.2.6.3.1. Noms des types d'objets ifTable
Le nom d'une interface de sous-réseau, s, est la valeur d'OBJECT IDENTIFIER de la forme i, où i a la valeur de cette instance du type d'objet ifIndex associée à s.
Pour chaque type d'objet, t, dont le nom défini, n, a pour préfixe ifEntry, une instance, i, de t est nommée par un OBJECT IDENTIFIER de la forme n.s, où s est le nom de l'interface de sous-réseau sur laquelle i représente des informations.
Par exemple, supposons que l'on veuille identifier l'instance de la variable ifType associée à l'interface 2. En conséquence, ifType.2 identifierait l'instance souhaitée.
3.2.6.3.2. Noms des types d'objets atTable
Le nom d'une adresse réseau mise en cache par AT, x, est un OBJECT IDENTIFIER de la forme 1.a.b.c.d, où a.b.c.d est la valeur (dans la notation « pointée » familière) du type d'objet atNetAddress associé à x.
Le nom d'une équivalence de traduction d'adresse e est une valeur d'OBJECT IDENTIFIER de la forme s.w, telle que s est la valeur de cette instance du type d'objet atIndex associée à e et telle que w est le nom de l'adresse réseau mise en cache par AT associée à e.
Pour chaque type d'objet, t, dont le nom défini, n, a pour préfixe atEntry, une instance, i, de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom de l'équivalence de traduction d'adresse sur laquelle i représente des informations.
Par exemple, supposons que l'on veuille trouver l'adresse physique d'une entrée de la table de traduction d'adresses (cache ARP) associée à une adresse IP de 89.1.1.42 et à l'interface 3. En conséquence, atPhysAddress.3.1.89.1.1.42 identifierait l'instance souhaitée.
3.2.6.3.3. Noms des types d'objets ipAddrTable
Le nom d'un élément de réseau adressable par IP, x, est l'OBJECT IDENTIFIER de la forme a.b.c.d tel que a.b.c.d est la valeur (dans la notation « pointée » familière) de cette instance du type d'objet ipAdEntAddr associée à x.
Pour chaque type d'objet, t, dont le nom défini, n, a pour préfixe ipAddrEntry, une instance, i, de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom de l'élément de réseau adressable par IP sur lequel i représente des informations.
Par exemple, supposons que l'on veuille trouver le masque réseau d'une entrée de la table d'interfaces IP associée à une adresse IP de 89.1.1.42. En conséquence, ipAdEntNetMask.89.1.1.42 identifierait l'instance souhaitée.
3.2.6.3.4. Noms des types d'objets ipRoutingTable
Le nom d'une route IP, x, est l'OBJECT IDENTIFIER de la forme a.b.c.d tel que a.b.c.d est la valeur (dans la notation « pointée » familière) de cette instance du type d'objet ipRouteDest associée à x.
Pour chaque type d'objet, t, dont le nom défini, n, a pour préfixe ipRoutingEntry, une instance, i, de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom de la route IP sur laquelle i représente des informations.
Par exemple, supposons que l'on veuille trouver le prochain saut d'une entrée de la table de routage IP associée à la destination 89.1.1.42. En conséquence, ipRouteNextHop.89.1.1.42 identifierait l'instance souhaitée.
3.2.6.3.5. Noms des types d'objets tcpConnTable
Le nom d'une connexion TCP, x, est l'OBJECT IDENTIFIER de la forme a.b.c.d.e.f.g.h.i.j tel que a.b.c.d est la valeur (dans la notation « pointée » familière) de cette instance du type d'objet tcpConnLocalAddress associée à x, tel que f.g.h.i est la valeur (dans la notation « pointée » familière) de cette instance du type d'objet tcpConnRemoteAddress associée à x, tel que e est la valeur de cette instance du type d'objet tcpConnLocalPort associée à x et tel que j est la valeur de cette instance du type d'objet tcpConnRemotePort associée à x.
Pour chaque type d'objet, t, dont le nom défini, n, a pour préfixe tcpConnEntry, une instance, i, de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom de la connexion TCP sur laquelle i représente des informations.
Par exemple, supposons que l'on veuille trouver l'état d'une connexion TCP entre l'adresse locale 89.1.1.42 sur le port TCP 21 et l'adresse distante 10.0.0.51 sur le port TCP 2059. En conséquence, tcpConnState.89.1.1.42.21.10.0.0.51.2059 identifierait l'instance souhaitée.
3.2.6.3.6. Noms des types d'objets egpNeighTable
Le nom d'un voisin EGP, x, est l'OBJECT IDENTIFIER de la forme a.b.c.d tel que a.b.c.d est la valeur (dans la notation « pointée » familière) de cette instance du type d'objet egpNeighAddr associée à x.
Pour chaque type d'objet, t, dont le nom défini, n, a pour préfixe egpNeighEntry, une instance, i, de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom du voisin EGP sur lequel i représente des informations.
Par exemple, supposons que l'on veuille trouver l'état de voisin pour l'adresse IP 89.1.1.42. En conséquence, egpNeighState.89.1.1.42 identifierait l'instance souhaitée.