L’acronyme SNMP signifie « Simple Network Management Protocol. » Il s’agit d’un protocole destiné au transfert d’informations de gestion sur des réseaux, et plus précisément les LAN, selon la version choisie.
L’utilité de SNMP dans le domaine de l’administration réseau tient à ce qu’il permet de collecter des informations relatives aux appareils connectés à un réseau de façon standardisée et sur un large éventail d’appareils et de types de logiciels.
Rares sont les administrateurs réseau qui décident faire l’impasse sur ce protocole. Au contraire, la plupart d’entre eux y recourent en toute confiance parce que la quasi-totalité des appareils de toutes les marques prend en charge SNMP, ce qui leur permet d’utiliser cette technologie pour superviser tout leur parc comme il se doit.
Versions
Il existe à l’heure actuelle trois grandes versions de SNMP. La première a été mise au point en peu de temps à la fin des années 1980, à l’époque où les administrateurs réseau se plaignaient de l’absence d’outils de gestion adaptés capables de fonctionner avec le matériel de n’importe quel fabricant.
La v1 du protocole SNMP a été définie en 1988 et reposait sur le Simple Gateway Monitoring Protocol (formalisé dans le RFC 1028). À l’époque, elle fut adoptée et utilisée par un grand nombre d’utilisateurs. Elle compte encore des adeptes près de 30 ans plus tard, ce qui constitue une éternité dans le monde informatique. SNMP v1 fournit des fonctionnalités élémentaires d’interrogation de données et s’avère plutôt simple à utiliser. Elle ne sollicite que peu de bande passante, car elle n’intègre pas d’algorithmes de chiffrement. Aussi, le recours à la v1 de SNMP doit, pour des raisons de sécurité, se cantonner aux réseaux locaux. Sa principale limite tient à ce que son architecture repose sur des compteurs à 32 bits, ce qui est insuffisant pour les réseaux modernes, où les données représentent des giga-octets si ce n’est plus.
Les utilisateurs qui désirent administrer des réseaux sans fil doivent recourir au protocole CMISE/CMIP.
La v2 de SNMP assure une prise en charge des compteurs à 64 bits, mais elle pèche de nouveau par l’absence de chiffrement des données stratégiques lors de leur transmission, ce qui constitue un défaut de sécurité. Quand les utilisateurs tombent sur la SNMP v2, c’est généralement de la v2c que les fabricants ou fournisseurs de réseau parlent, ce « c » correspondant à communauté. SNMP v2 compte deux variantes, SNMP v2p et SNMP v2u, mais celles-ci ne sont utilisées que dans des rares occasions.
Définie en 2002, SNMP v3 reprend à son compte tous les points forts de la v2c et leur ajoute des mécanismes de sécurité comme des comptes utilisateur, un système d’authentification, ou encore la possibilité de crypter des packages de données. Une amélioration de la sécurité qui fait de SNMP v3 la meilleure option pour ceux qui veulent protéger leurs données, mais qui complique aussi sa configuration, et surtout la gestion des utilisateurs. La v3 sollicite bien plus de puissance de calcul, ce qui vaut particulièrement pour les intervalles de supervision les plus courts, qui génèrent un grand nombre de messages SNMP.
SNMP v3 prévoit trois niveaux de sécurité distincts :
- NoAuthNoPriv – Correspond à « No Authentication, No Privacy », c’est-à-dire qu’aucune authentification n’est requise, et que les messages ne sont pas protégés par chiffrement. Pour des raisons évidentes, ce niveau de sécurité doit se cantonner aux réseaux fermés et sécurisés.
- AuthNoPriv, c’est-à-dire « Authentication, No Privacy ». En d’autres termes, les messages doivent être authentifiés pour donner lieu à des actions. En revanche, ils ne sont pas cryptés lors de leur transmission. En théorie, une personne malveillante pourrait toujours intercepter les données transitant entre agent et manager lors des transmissions autorisées, mais il serait incapable d’y ajouter les requêtes Get ou Set de son choix.
- AuthPriv, c’est-à-dire « Authentication & Privacy ». C’est l’implémentation la plus sécurisée de SNMPv3. Les messages SNMP doivent être authentifiés et toutes les données sont cryptées lors de leur transmission. Cela empêche d’éventuelles personnes malveillantes d’envoyer leurs propres requêtes Get ou Set et de visionner les données générées par des requêtes autorisées.
En règle générale, on trouve sur un réseau au moins un ordinateur ou un serveur sur lequel va s’exécuter le logiciel de supervision. Il s’agit de l’entité de gestion. Un réseau ordinaire compte également quelques-uns, voire beaucoup ou même énormément de périphériques de tous types, des switches aux routeurs, en passant par les stations de travail, baies de serveurs, imprimantes, machines à café, ou tout autre élément méritant d’être supervisé. Ce sont les périphériques gérés.
Les messages SNMP sont échangés entre les « managers » et les « agents ». En règle générale, le manager SNMP du réseau est installé sur l’entité de gestion, tandis que les agents SNMP sont installés sur les périphériques gérés.
Le transfert de messages SNMP fonctionne de manière analogue à une communication entre un client et un serveur, à l’aide de technologies pull et push. La technologie pull (ou poll) est le type de communication le plus répandu. Dans ce modèle, un client, comme le logiciel de gestion réseau installé sur l’entité de gestion, transmet une requête afin de solliciter une réponse auprès d’un serveur ou d’un périphérique géré. Son pendant, la technologie push, permet au périphérique géré de « parler » et d’envoyer un message SNMP à la suite d’un événement.
Selon la terminologie SNMP, par exemple, une requête GET émanant d’un manager SNMP (client) obéit au modèle pull, là où un trap SNMP est « poussé » par un agent SNMP (serveur) sans avoir fait l’objet d’une requête préalable.
Les différents types de messages SNMP
Il existe différents types de messages SNMP qui permettent de mettre en place un mécanisme de supervision réseau via SNMP :
- GetRequest – c’est le message SNMP qu’un manager SNMP est le plus souvent amené à utiliser pour demander des données. L’appareil ciblé renvoie la valeur demandée sous la forme d’un message de type Response.
- GetNextRequest – Le manager SNMP peut envoyer un message de ce type pour déterminer les informations que l’appareil peut envoyer. En commençant par l’OID 0, le manager peut continuer à requérir les données immédiatement consécutives, ce jusqu’à ce qu’il n’y ait plus des données « suivantes ». Les utilisateurs peuvent ainsi accéder à toutes les informations disponibles concernant un périphérique donné, même s’ils n’avaient pas nécessairement connaissance de l’existence du système ou de l’appareil qui répond.
- GetBulkRequest – Apparue avec l’introduction de la v2 de SNMP, cette requête est une version nouvelle et optimisée de GetNextRequest. La réponse sollicitée contient autant de données que la requête l’autorise. Il s’agit avant tout d’un moyen de regrouper plusieurs requêtes GetNextRequest, ce qui permet aux utilisateurs de créer une liste recensant l’intégralité des données et des paramètres disponibles.
- SetRequest – Il s’agit d’une commande initiée par le manager afin de définir ou modifier via SNMP la valeur d’un paramètre sur l’appareil ou système qui sert d’agent. Ce type de message sert également à gérer ou à modifier des paramètres de configuration ou d’autres réglages. Attention à ne pas commettre d’erreur en la matière, une requête SetRequest peut, si elle est mal formulée, provoquer de sérieux dégâts sur la configuration des systèmes et du réseau.
- Response – La response est le message qu’un appareil agent envoie après avoir reçu une Requête de la part du manager. Quand il fait suite à une requête de type GetRequest type, le paquet contient les données ou valeurs sollicitées. Dans le cas d’une requête SetRequest, le paquet répond en transmettant la nouvelle valeur et confirme ainsi que la requête SetRequest a bel et bien abouti.
- Trap(v2) – Un trap est envoyé (ou « poussé ») par l’agent SNMP sans avoir été demandé par le manager. Au lieu de cela, des traps sont envoyés dans des situations précises, comme en cas d’erreur, ou de franchissement d’un seuil de tolérance prédéfini. Si les utilisateurs veulent tirer parti des traps à des fins de supervision, ce qui une excellente idée pour qui veut être proactif sur ce plan, il leur faudra probablement configurer préalablement ces traps par le biais du manager SNMP.
- InformRequest – Ce type de message a été introduit sur SNMP v2 pour donner au manager la possibilité d’accuser réception du message trap émanant d’un agent. Certains agents sont configurés pour continuer d‘envoyer un trap jusqu’à réception d’un message de type Inform.
- Report – Les messages de type sont uniquement disponibles sur SNMP v3. Ils permettent à un manager SNMP de déterminer la nature du problème qui a été détecté par l’agent SNMP distant. En fonction du type d’erreur mis au jour, le moteur SNMP peut essayer d’envoyer une version corrigée du message SNMP. Si cela s’avère impossible, il peut signaler l’erreur à l’application au nom de laquelle la requête SNMP infructueuse avait été envoyée. [RFC3412]
Transfert des messages SNMP
Le Simple Network Management Protocol fait partie de la suite TCP/IP et se situe dans la couche Application (couche 7) du modèle OSI.
SNMP se sert du protocole UDP (User Datagram Protocol) pour transférer des messages. Pour que la supervision fonctionne, les paquets UDP doivent pouvoir circuler de l’agent au manager. Par défaut, cela se fait sur un réseau local, mais il faut aussi configurer le routeur pour permettre à ces paquets de traverser des réseaux étendus.
Les agents SNMP reçoivent des requêtes UDP sur le port 161. Celles qui émanent d’un manager SNMP peuvent être envoyées depuis n’importe quel port. Généralement, il s’agit toutefois du port 161. Les agents envoient des traps via le port 162. Le manager SNMP reçoit aussi des traps sur le port 162.
OID
OID est un acronyme correspondant à Object Identifier, c’est-à-dire identifiant d’objet. Les OID permettent d’identifier de manière unique chacun des objets gérés qui sont définis dans des fichiers MIB.
Exemple:
Sur une imprimante, on surveillera généralement l’état des cartouches, et parfois le nombre de fichiers imprimés. Sur un switch, on s’intéressera au trafic entrant et sortant, ainsi qu’au taux de paquets perdus ou au nombre de paquets destinés à une adresse de diffusion.
La hiérarchie des objets (OID) est d’habitude représentée sous la forme d’une arborescence à plusieurs niveaux allant des racines aux feuilles isolées. Chaque OID a une adresse qui coïncide avec les niveaux de l’arborescence des OID.
Illustration :
Voici à quoi ressemble la structure d’un OID :
Iso(1).org(3).dod(6).internet(1).private(4).transition(868).products(2).chassis(4)
.card(1).slotCps(2)-cpsSlotSummary(1).cpsModuleTable(1).cpsModuleEntry(1)
.cpsModuleModel(3).3562.3
ou tout simplement :
1.3.6.1.4.868.2.4.1.2.1.1.1.3.3562.3
Les identifiants d’objets MIB de niveau élevé ou général sont attribués par divers organismes de normalisation comme ISO. Les fabricants définissent des OID pour leurs propres produits dans des ramifications privées de l’arborescence d’OID.
Les objets administrés peuvent prendre une forme scalaire ou tabulaire. Les objets scalaires définissent une seule instance d’objet, alors que les objets tabulaires définissent plusieurs instances liées d’objets, et celles-ci sont regroupées dans des tables MIB.
MIB
Une MIB (Management Information Base, c’est-à-dire base d’information pour la gestion du réseau) est un format indépendant de définition des informations de gestion. En d’autres termes, les fichiers MIB contiennent des OID de manière organisée. Dans une MIB, tous les objets ont leur propre définition qui détermine ses propriétés sur l’appareil à gérer. On accède aux objets à l’aide du protocole SNMP.
Pourquoi les identifiants d’objets et les fichiers MIB sont nécessaires
Qu’il s’agisse de l’utilisation de mémoire d’un serveur, du trafic que reçoit un commutateur ou des fichiers présents dans la file d’attente d’une imprimante, chacune des informations que le protocole SNMP permet d’extraire est traitée individuellement grâce à son OID. C’est cette propriété qui explique la nécessité du recours aux OID. Ces derniers aident les administrateurs à identifier et superviser les objets présents sur leur réseau, et donc à donner tout son sens à la supervision réseau.
Pour que l’entité de gestion puisse communiquer correctement avec un périphérique géré via le réseau, les deux doivent savoir quels OID sont disponibles.
C’est la raison pour laquelle les fichiers MIB ont été créés et pour laquelle les administrateurs système en ont besoin. Chaque objet destiné à être supervisé sur un périphérique doit être stipulé par la/les MIB de ce dernier. Ainsi, les administrateurs doivent s’assurer que tous les fichiers MIB nécessaires sont bien stockés sur les appareils-agents SNMP, ainsi que sur le système de l’entité de gestion. Un fichier MIB se reconnait à son extension « .my » ou « .mib ».
Si vous désirez creuser davantage le sujet, nous vous invitons à lire l’article SNMP Explained: What You Must Know About Monitoring via MIBs and OIDs (en anglais uniquement).
Les fabricants de périphériques fournissent d’ordinaire les fichiers MIB nécessaires avec leurs produits dès lors qu’ils sont compatibles avec SNMP. En fonction de la solution de supervision que l’on utilise, on peut être obligé de convertir ces fichiers MIB pour en produire des versions spéciales.
Le SMI, raison de l’universalité de SNMP
Le caractère universel de SNMP tient à plusieurs facteurs. Le SMI (Structure of Management Information) fournit une syntaxe standardisée et communément acceptée pour les différents types de données et leur transfert. Si vous souhaitez creuser davantage le sujet et comprendre pourquoi SMI est également indissociable des OID et des fichiers MIB, nous vous invitons à consulter cet article.
Pourquoi se servir de SNMP ? Eh bien, le Simple Network Management Protocol, comme son nom l’indique, est destiné à la gestion des réseaux. Pour gérer un réseau, l’administrateur a besoin d’obtenir des informations à son sujet. C’est là que réside l’intérêt principal de SNMP. Il collecte toutes les données provenant de différents appareils et les met en perspective, ce qui permet à l’utilisateur de suivre l’évolution des problèmes, de faire des choix à l’aune de données précises, et de prendre le contrôle des opérations si nécessaire. C’est là toute la raison d’être de la gestion réseau. Et c’est la raison pour laquelle les administrateurs système ont tout intérêt à se servir de SNMP pour superviser leurs réseaux.
Mais le protocole présente d’autres avantages. Le recours à un outil de supervision adapté, tel que PRTG, permet également aux administrateurs réseau d’exploiter pleinement les données obtenues via SNMP et leur donne la possibilité de superviser et de gérer leurs réseaux en temps opportun et de façon proactive.
De la nécessité de s’organiser correctement
Il est souvent très compliqué de garder le fil de la grande quantité de périphériques réseau que les réseaux modernes abritent. Dans l’idéal, une solution de supervision doit faciliter le travail de l’administrateur en lui proposant des solutions pour structurer et regrouper facilement des appareils et en présentant une vue d’ensemble claire, qui permet d’entrer dans les détails chaque fois que cela est nécessaire pour contrôler l’état de santé du système.
Alertes & notifications
À l’aide d’outils de supervision, les administrateurs système savent précisément où il convient d’intervenir en cas de problème, et ont parfois même le luxe d’en avoir connaissance avant que ledit problème ne se concrétise. Sachant qu’il est crucial pour tout administrateur d’être informé des soucis le plus rapidement possible, les outils de supervision se doivent de proposer autant de modes d’alertes que possible : envoi d’un e-mail, d’une notification Push, ou d’un SMS (ce qui permet d’assurer ses arrières au cas où la connexion internet planterait, par exemple), exécution d’un logiciel, ou même transmission d’alertes sur une montre connectée.
Fonctionnalités de reporting & statistiques
La supervision réseau va alimenter une base de données dédiée d’une foule d’informations. Ces chiffres éloquents vous permettront de créer des rapports et d’établir des statistiques. L’analyse vous permettra non seulement de mieux connaître les caractéristiques de vos réseaux, mais aussi d’étayer votre argumentaire quand viendra l’heure de réclamer des ressources auprès de votre directeur financier ou du directoire. L’aspect visuel des tableaux de bord vous aidera par ailleurs à obtenir de meilleurs résultats.
Avoir une longueur d’avance
L’analyse des données vous dévoilera les tendances de chacun de vos réseaux et vous aidera à anticiper. Résultats des courses, vous gagnerez en fiabilité, en vitesse, et en efficacité.
Une grande simplicité d’installation
La configuration d’un système de supervision sur un réseau étendu peut être très fastidieuse et nécessiter beaucoup de temps. Les outils de supervision automatisent et accélèrent cette étape en mettant notamment à la disposition des utilisateurs des fonctionnalités flexibles de détection automatique des éléments présents sur le réseau, ou des templates prédéfinis pour les dispositifs d’infrastructure réseau les plus répandus. Et devinez quoi ? Il y a de grandes chances que ces technologies utilisent, elles aussi, le protocole SNMP !
Comment PRTG peut-il vous aider à superviser votre réseau ?
SNMP se compose de trois éléments principaux que sont les périphériques gérés, les agents et la station d’administration réseau (NMS).
Un périphérique géré est un nœud qui est doté d’un agent SNMP et qui se trouve sur un réseau géré. Cette catégorie englobe toutes sortes d’appareils, des routeurs aux serveurs d’accès, en passant par les switches, hubs, ordinateurs hôtes, téléphones IP et autres imprimantes.
Un agent est un module logiciel qui réside au sein d’un appareil et tourne sans interruption. Il utilise le protocole SNMP pour rapporter des informations aux systèmes de gestion. Une station d’administration réseau fait fonctionner le protocole de gestion réseau et les applications de supervision qui fournissent l’essentiel des capacités de calcul et de mémoire nécessaires pour observer le réseau. Un réseau SNMP peut compter plusieurs stations d’administration réseau.
- Version illimitée de PRTG pour 30 jours
- Après 30 jours, PRTG revient à la version gratuite
- Ou, vous pouvez évoluer vers une licence payante