- Definitions.
- Au moins une station d'administration.
- Des agents administratifs.
- Les MIBs (Management Information Base).
- Un protocole d'administration.
- Des applications spécifiques à l'administration.
- Une interface avec l'administrateur.
- La capacité à pouvoir recupérer des informations des élements administrés.
- Une base de données obtenue à partir des MIB des éléments administrés.
- L'architecture du protocole d'administration.
- Les alarmes.
- Les proxies.
Lors de l'administration réseau, quatre entités sont nécessaires :
Station d'administration : Ce terme désigne le périphérique utilisé par l'administrateur pour gérer son réseau. Celui-ci doit obligatoirement posséder :
Il est également possible pour une station d'administation de déléguer ses pouvoirs, c'està dire de nommer quelques agents administratifs "mixtes" afin de décentraliserl'administration du réseau.
Agent administratif : ce terme désigne l'ensemble des périphériques supportant SNMP.Ces agents peuvent aussi bien être des ordinateurs que des hubs, des routeurs, ou encoretout autre type de périphériques. Ces agents ont pour devoir de répondre aux requêtes de la station d'administration.
Les MIBs : Ces bases de données sont assimilées à des bibliothèques d'objets nousrenseignant sur tous les types de données en rapport avec l'activité du reseau. Nous la détaillerons lors de notre deuxième partie.
Le protocole d'administration : Ce protocole est le plus souvent implémenté sur la couche TCP/IP. Pour notre part, nous étudierons uniquement SNMP qui est un des plus répanduà ce jour.
Figure 1 : Mise en oeuvre de SNMP dans un réseau.
SNMP a été crée pour être une couche utilisant TCP/IP à un niveau supérieur.Le protocole d'administration opère en accord avec UDP (User Datagram Protocol) et IP. A chaque action de la station d'administration, le processus de contrôle accède à la MIB et avertit l'utilisateur par l'intermédiaire d'une interface graphique.
Chaque agent administratif doit lui aussi implémenter SNMP et UDP/IP afinde pouvoir interpréter les requêtes qui permettent à la machine d'administration d'accéder à sa MIB.
SNMP étant relié à UDP qui est un protocole sans connexion, il est lui ausssi sans connexion, c'est pourquoi les connexions entre station d'administration et agents adminisratifs ne sont jamais maintenues.
Il est évident qu'une machine d'administration ne peut constamment demander aux stations surveillées quel est leur état, c'est pourquoi il est possible de demander aux stations d'emmettre de temps en temps (une fois par heure par exemple) un rapport sur son état et pourquoi pas quelques statistiques. Cela permet de soulager la station d'administrationqui n'a plus qu'à écouter ses protégés si elle n'a pas d'autres actions de gestion à faire.
Figure 2 : Gestion des machines ne supportant pas SNMP.
Afin de palier ce problème, le concept de proxy a été développé. Ces proxies suppléent les machines inadaptées car ils connaissent les objets de la MIB nécéssaires pour la gestion du système mandaté.
La communication entre le proxy et la machine suppléée ne peuvent utiliser SNMP pour dialoguer et il faut donc, pour le proxy, s'adapter aux protocoles connus par la seconde machine, c'est ce qui est illustré par la figure 2.
Comme nous l'avons vu au début de ce dossier, chaque noeud possède une MIB qui contient l'ensemble des informations utiles pour gérer un réseau.
- Structure of Management Information (SMI).
- Fournir une méthode standard de définition des structures d'une MIB particulière.
- Fournir une méthode standard de définition d'objets individuels, incluant la syntaxe et les valeurs de chaque objet.
- Fournir une méthode d'encodage standard des valeurs des objets (par exemple, comment coder un compteur au niveau binaire).
- Structure de la MIB.
- ifDefaultTTL(2) : Qui fixe la durée de vie d'un paquet IP par défaut.
- ipInUnknownProtos(7) : Qui est égal au nombre de paquets adressés àla station interressée, et correctement reçus, mais issus d'un protocole inconnu.
- ipInDelivers(9) : Qui correspond au nombre total de trames reçues avec succès.
- etc . . .
- Les types utilisés dans la MIB.
- Les types universels.
- integer : Allant de 0 à 4 294 967 295.
- octet string : Correspond à une suite de 0 à n octets.
- null : Valeur 0, car la valeur 0 ne peut être utilisée, étant réservée pour les erreurs.
- object identifier : Ensemble de valeurs associées aux objets créés.
- sequence, sequence of : Définit une suite ordonnée d'éléments de types divers (resp. ordonnés).
- Les types application.
- networkaddress : Ce type permet d'être utilisé pour tout type d'adresse déjà définies. Cependant il faut noter que seul le type IpAddress existe à ce jour, et n'est codé que sur 32 bits, or l'arrivée d'IPv6 risque de donner le jour à un nouveau type d'adresse sur 48 bits.
- ipaddress : Qui sert à adresser une machine au format IPv4.
- counter : Ce type est un entier non négatif, qui revient à 0 après avoir atteint son maximum, mais qui ne peut pas être décrémenté.
- tt gauge : Entier non négatif qui peut être incrémenté et décrémenté,mais ne peut en aucun cas passer la barre du zéro.
- timeticks : Entier également non négatif qui compte les centièmes de secondes écoulés depuis une époque donnée. La définition d'un objet de ce type correspond à une époque.
- opaque : Type de donnée arbitraire codé comme un objet de type octet string lors de la transmission. Ce type peut être également défini en ASN.1.
- La définition d'objets.
Les MIB ont une partie standard définie pour tout agent de tous les réseaux existants. Pour ce faire, il a été nécessaire de mettre au point une technique standard de définitiondes objets de la MIB. Ce "langage" est appelé SMI et est spécifié dans le RFC 1155 (ouvrage de référence pour la norme SNMP). Toutefois, il faut garder à l'esprit que la MIB est définie par des scalaires et des tableaux à deux dimensions uniquement. Cela permet de rester dans un environnement assez simple, ce qui contraste avec les structures de l'administration OSI.
Pour permettre une standardisation de SNMP et de la MIB, il a fallu implémenter dans SMI la possibilité de :
Figure 3 : Aperçu de la MIB.
Cette arborescence décrite dans la figure 3 présente une partie de la MIB, nous permettant d'accéder à certaines informations comme des statistiques sur les communications IP en cours. En effet par la séquence 1.3.6.1.2.1.4, on aboutit au noeud "ip", permettant ainsi de récupérer des informations comme :
Tous les objets de la MIB sont définis de manière formelle en ASN.1 qui définit ainsi sa structure dans sa totalité, tout en gardant comme objectif la simplicité, ce qui restreint le nombre d'éléments ASN.1 utilisés.
Ce sont le types les plus répandus et les plus utilisés, on peut compter parmi eux :
La classe application de ASN.1 est destinée à la création de types pour des applications particulières.
Les applications SNMP sont donc ammenées à créer leurs propres types :
A travers ASN.1, il est possible de définir ses propres objets, tout en restant dans les normes du RFC 1212 (La suite de RFC 1155), qui précise les définitions de la MIB, donnant ainsi naissance à la MIB-II, plus évoluée que la MIB.
- La pratique.
- Les opérations.
- Get : Utilisé lorsque la station d'administration désire connaître la valeur d'un scalaire d'une station administrée.
- Set : Utilisé lorsque la station d'administration désire modifier la valeur d'un scalaire d'une station administrée.
- Trap : Utilisé lorsqu'une station administrée décide d'envoyer une information à une station d'administration sans que cette dernière l'ait demandée.
- Read only : Permet uniquement la consultation du scalaire.
- Read Write : Permet une lecture ou une écriture du scalaire.
- Dans le cas concret.
- GetRequest qui envoie une requête, demandant la valeur de l'entrée de la MIB passée en paramètre.
- GetNextRequest Permet de faire une requête sur l'entrée de la MIB suivant celle passée en paramètre (dans l'ordre lexicographique).
- SetRequest change l'entrée passée en paramètre par la valeur donnée elle aussi en paramètre.
- GetResponse permet de récupérer une réponse à une requête précedemment émise.
- Les communautés.
- Les communautés.
- L'authentification : Consiste à envoyer avec le message, un mot de passe, correspondant au nom de la communauté, permettant au récepteur de vérifier l'authenticité de ce dernier.
- Politique d'accès : Un agent qui fait partie d'une communauté, ne permet l'accès à sa MIB, qu'à un nombre limité de stations d'administration.
- Le service proxy : Dans le cas de machines gérées par l'intermédiaire d'un proxy, ce dernier connait les objets utilisés pour gérer la machine mandatée, et gère la politique d'accès adéquat.
- La théorie.
- Le format des PDU.
- version : Version de SNMP.
- community : Nom de la communauté (agit comme un motde passe).
- request-id : Utilisé pour différencier les messages.
- error-status : Utilisé pour signaler une erreur (0 si pas d'erreur).
- error-index : Indique la sous-catégorie d'erreur.
- variablebindings : Nom des variables avec leurs valeurs. Rq : Lors d'une opération Get, les valeurs sont NULL.
- enterprise : Type de l'objet générant l'alarme.
- agent-addr : Adresse de l'émetteur de l'alarme.
- generic-trap : Identificateur de l'alarme.
- specific-trap : Identificateur d'alarme spécifique.
- time-stamp : Temps écoulé depuis la dernière réinitialisation de l'entité.
- Emission d'un message.
- Le PDU est construit.
- Est soumis à un service d'authentification où, après étude des adresses de destination, de la source et du nom de la communauté, on choisira ou non la nécessité de crypter le PDU.
- Le message est construit a partir du PDU avec l'ajout du nom de la communauté et la version de SNMP.
- Ce nouvel objet ASN.1, est enfin codé et envoyé au service transport.
- Réception d'un message.
- Le message est reçu et se voit opérer une vérification syntaxique. Si le message est défectueux, il est ignoré.
- Le numéro de version est vérifié, s'il n'est pas conforme, le message est ignoré.
- Le nom d'utilisateur, le PDU, l'adresse source et destination au niveau transport, sont soumis à un service qui se charge de l'authentification.
- Si l'authentification échoue, le service prévient l'entité transport de SNMP, laquelle envoie une alarme et ignore le message.
- Si l'authentification réussit, le service renvoie un PDU de la forme d'un objet ASN.1 qui se conforme à la norme RFC 1157.
- Interaction avec la couche transport.
- Quelques rappels sur UDP
- Les trames UDP sont véhiculées dans les paquets IP comme étant des données.
- Chaque trame possède une adresse source et une adresse destination qui permettent aux protocoles de niveau supérieurs comme SNMP de pouvoir adresser leurs requêtes.
- Le protocole UDP peut utiliser un checksum optionnel qui couvre l'en-tête et le données de la trame. En cas d'erreur, la trame UDP reçue est ignorée.
- Perte d'un PDU
UDP est un protocole qui n'est pas fiable à 100% et la perte de trames est donc possible. Or rien n'empêche UDP de perdre un trame contenant un message SNMP. Dans ce cas, plusieurs cas s'offrent à nous :
- Le paquet perdu est du type Get ou une réponse d'un agent administré. Cela provoque un manque d'information au niveau de la station d'admnistration qui n'est pas important : Voyant la réponse ne pas arriver, la station d'administration peut décider d'elle même de renvoyer sa requête. L'identificateur de requête étant identique, il n'y a pas de risque de recevoir plusieurs réponses dûes à des questions dupliquées.
En cas de non-réponse permanent, cette station peut déclarer ce périphérique muet comme défaillant. - Le paquet perdu est du type Set. Il est alors plus judicieux de faire un Get sur cette entrée afin de savoir si c'est la requête qui a été perdue ou alors sa réponse.
- C'est une alarme qui a été perdue. Comme aucun acquitement n'est nécessaire suite à une alarme, la station d'administration ne sera jamais avertie par le signal. Il est donc nécessaire que la station d'administraton scrute régulièrement l'état de ses agents pour se mettre au courant des éventuels changements pour lesquels il n'aurait pas reçu d'alarme.
- Le paquet perdu est du type Get ou une réponse d'un agent administré. Cela provoque un manque d'information au niveau de la station d'admnistration qui n'est pas important : Voyant la réponse ne pas arriver, la station d'administration peut décider d'elle même de renvoyer sa requête. L'identificateur de requête étant identique, il n'y a pas de risque de recevoir plusieurs réponses dûes à des questions dupliquées.
- Les limitations de SNMP.
- Pour chaque réponse reçue correspond une requête et le transfert de données à travers le réseau s'avère donc assez important, ce qui surcharge ce dernier par rapport à ce qu'il aurait été en cas de non administration.
- Ce protocole n'est pas très pratique pour ramener une grosse quantité de données comme un table de routage par exemple.
- Les alarmes ne sont pas acquitées et un agent n'est jamais sûr de bien avoir averti sa station d'administration.
- L'authentification reste très simple et donc non sécurisée.
- SNMP ne permet pas de "commander" un agent, cette manipulation ne peut se faire qu'en modifiant une entrée de sa MIB.
Exemple : On ne peut demander à une passerelle de terminer une connexion TCP donnée mais on peut modifier la valeur tcpConnState pour que cette connexion soit fermée. - SNMP ne supporte pas la communication de station d'administration à station d'administration. Il est donc impossible à une station d'administration de faire des requêtes à un périphérique administré par une autre station en passant par son intermédiaire.
- SNMPv2.
- Structure of Management Information (SMI) : Les macros permettant de définir des objets ont été étendues, ce qui permet de définir de nouveaux objets. De plus, les documentations associées ont été améliorées.
- Les communications entre machines d'administration. Comme vu précédemment, il est possible pour une machine de se comporter à la fois comme un agent et comme une machine d'administration. De cette manière, il est à présent possible pour une machine d'administration d'un niveau supérieur, de commander un agent par l'intermédiaire de ces machines "mixtes", ce qui est une amélioration non négligeable par rapport à SNMP.
- Les opérations des protocoles. Le plus important changement en ce qui concerne le protocole SNMPv2 est l'ajout de deuxnouveaux PDU:
- GetBulkRequest : Permet à la machine d'administration de récupérer efficacement des blocs de grande taille.
- InformRequest : Permettant à une machine d'administration d'envoyer une alarme à une autre machine d'administration.
Dans cette partie, nous examinerons les différents concepts qui relèvent des opérations du protocole.
Les seules opérations supportées par SNMP sont la modification et la consultation de variables. Plus précisément, trois types d'opérations sont réalisables :
Remarque : Il est impossible d'accéder à une table entière ou même à une colone de cette table, avec une seule action, ce qui simplifie considérablement l'implémentation de SNMP, d'un autre côté, cela limite les capacités de l'administration du réseau.
Nous venons de voir quels type d'opérations étaient réalisables avec le protocole SNMP mais voici plus precisément les commandes utilisées :
GetRequest(1.3.6.1.2.1.6.4) provoque le retour de GetResponse(tcpMaxConn = x ) où x est le résultat de la requête).
SetRequest(1.3.6.1.2.1.6.13.1.1 = 12 ) provoque le retour de GetResponse(tcpConnState = 12).
La notion de communauté est utilisée dans les réseaux administrés à l'aide du protocole SNMP. Elle réunit une machine d'administration et ses administrés. Chaque communauté est identifiée par un nom de communauté:
Nous allons dans cette partie décrire de manière succinte le format des PDU de SNMP, ainsi que les interactions avec les couches inférieures.
Figure 4 : Structure d'un PDU SNMP.
Description des champs :
Pour envoyer un message, l'agent suit la procédure suivante :
La puissance de SNMP à administrer un réseau n'est plus à démontrer mais il faut avouer que ce protocole souffre de quelques defauts :
Il est tout d'abord important de préciser, que certaines de ces déficiences énumérées dans le paragraphe ci-dessus sont paliées par SNMPv2.
SNMPv2 peut tout d'abord supporter une stratégie d'administration de réseau plus centralisée, voir distribuée.
Les principales améliorations de SNMP à SNMPv2 peuvent être classées dans les catégories suivantes:
