SNMP

9 SS

Dans les sections précédentes, nous nous sommes principalement intéressés aux approches académiques. Dans le monde industriel, plusieurs solutions ont été développées, pour supporter l'administration et la reconfiguration des applications et des équipements. Nous illustrons dans la suite, les fondements et les principes de base de ces solutions.

9.1 SNMP

SNMP (Simple Network Managment Protocol) [CF+90] est un standard utilisé dans l'administration des équipements réseaux, comme les ponts, les concentrateurs et les routeurs. Sa première version a été développée en 1988. Elle a été suivie par deux autres versions, respectivement en 1993 et 1999, pour introduire des améliorations et corriger des problèmes de sécurité. SNMP est basé sur le modèle Manager/Agent. Ce modèle regroupe plusieurs éléments : le manager (station d'administration), les agents, les bases de données de gestion (MIB), les objets administrés et le protocole réseau qui assure la communication entre les différents éléments. Chaque équipement nécessite d'être modélisé sous la forme d'un objet administrable. Cet objet contient un ensemble d'attributs, caractérisant l'équipement, et pouvant être consultés et modifiés.

9.1.1 Architecture du système

SNMP est un protocole réseau qui permet aux équipements matériels, d'être administrés à distance, à partir d'une station d'administration, souvent appelée le manager. La Figure 30 montre l'architecture d'administration SNMP. Trois éléments principaux peuvent être distingués dans cette architecture : le manager, les agents et la MIB.

9.1.1.1 Le manager

Le manager joue le rôle d'interface entre les applications d'administration, et les équipements réseau à administrer. Il permet ainsi, comme le montre la Figure 31, de recevoir les requêtes des applications d'administration, et de les envoyer sur le réseau. Le manager maintient une base de données de gestion. Cette base sera décrite par la suite.

9.1.1.2 Les agents

Un agent joue le rôle d'interface entre le manager, et un ou plusieurs objets administrables. Il est responsable de répondre aux requêtes envoyées par les applications d’administration, et de gérer les événements éventuels qui peuvent se produire sur les équipements réseau contrôlés.

9.1.1.3 La MIB

Pour administrer un équipement, ses caractéristiques doivent être représentées et stockées, sous un format compréhensible, à la fois par le manager et par les agents. Ces caractéristiques peuvent concerner des aspects matériels, comme la vitesse d'un ventilateur, par exemple. Elles peuvent aussi concerner des aspects applicatifs, comme les tables de routage. Les données, modélisant les caractéristiques des équipements, sont stockées dans une structure appelée la MIB.

Comme nous avons expliqué, les équipements à administrer, sont modélisés sous forme d'objets administrables. C'est justement la MIB qui organise et qui stocke ces objets. La MIB est organisée hiérarchiquement, de la même façon que l'arborescence des domaines Internet. Elle contient une partie commune à tous les agents SNMP, une partie commune à tous les agents SNMP d'un même type de matériel et une partie spécifique à chaque constructeur. Elle peut contenir des valeurs simples ou des tableaux de valeurs.

9.1.2 Le protocole de communication

Il définit l'ensemble des commandes qui permettent aux applications d'administration, de communiquer avec les agents. La Figure 31 montre le lien entre une application d'administration, et un agent SNMP. Elle illustre les différentes couches de communication, sur lesquelles SNMP est basé.

Figure 31. Protocole de communication

Le protocole de communication, entre le manager et les agents, se résume à cinq commandes. Ces commandes sont expliquées dans le Tableau 2.

Commande Action

get-request Le Manager SNMP demande une information à un agent, l'agent répond avec une requête de type get-reponse.

get-next-request Le Manager SNMP demande l'information suivante à l'agent.

set-request Le Manager SNMP demande à un agent de mettre à jour une information dans la MIB. L'équipement associé doit réagir en fonction de la modification.

get-reponse L'agent SNMP répond à une requête de type get-request ou

set-request.

trap L'agent SNMP envoie une alerte au manager, pour l'informer d'une situation particulière concernant l'appareil.

Tableau 2. Commandes du protocole SNMP

En résumé, les commandes get-request, get-next-request et set-request sont toutes émises par le manager, à destination d'un agent, et attendent toutes une réponse de type get-response, de la part de l'agent. La commande trap représente une alerte. Elle est toujours émise par l'agent à destination du manager, et n'attend pas de réponse.

9.1.3 Discussion

SNMP est l'un des protocoles, les plus utilisés pour d'administration des équipements réseau. Il n'est pas figé pour un nombre particulier d'équipements. Il peut être étendu pour administrer toutes sortes d'appareils. Son succès vient particulièrement de sa simplicité. Comme nous l'avons expliqué, son architecture est basée sur peu d'éléments, et le nombre de commandes qu'il supporte est très réduit, ce qui simplifie son utilisation.

L'idée fondamentale derrière SNMP, est de modéliser les équipements à administrer, sous forme d'objets administrables, pour pouvoir les interroger et les modifier. Toutes les modifications appliquées à ces objets, se traduisent par des actions sur les équipements modélisés.

SNMP en tant que tel, n'est pas approprié à l'administration des applications pour différentes raisons. D'un coté, le nombre de commandes qui peuvent être échangées entre une application d'administration et une application administrée, est réduit et figé. D'un autre coté, la sémantique même des commandes ne suffit pas à administrer des applications complexes. Les commandes sont limitées uniquement à consulter et à modifier les valeurs des attributs.

Cependant, SNMP permet de confirmer plusieurs idées :

Les entités à administrer ou à reconfigurer, doivent être modélisées dans un format bien spécifique. Ce format, compréhensible par le système de reconfiguration, permet à ce dernier d'interagir avec les entités modélisées.

Lors de la modélisation, seules les propriétés qui peuvent être intéressantes pour la reconfiguration, doivent être prises en compte. Il est alors nécessaire d'abstraire les entités à administrer, et de décider quelle propriété doit être modélisée.

Il faut séparer le système de reconfiguration des applications à reconfigurer. Ceci permet d'identifier clairement les responsabilités de chaque partie. Pour assurer le lien entre les différentes parties, un protocole d'interaction doit également être clairement exprimé.