Qu'est-ce que SNMP ? Obtenez des informations en temps réel sur les performances du réseau (2026)

Le SNMP (Simple Network Management Protocol) est le protocole standard utilisé par les équipes informatiques pour surveiller et gérer les équipements réseau. 

Un système central (le gestionnaire) demande à des dispositifs (des agents) des données telles que la charge du processeur, l'utilisation de la mémoire ou le trafic des interfaces, et les dispositifs répondent avec des valeurs structurées extraites d'une base de données locale appelée la MIB. 

Il fonctionne sur le port UDP 161 pour les requêtes et sur le port 162 pour les alertes ; il est compatible avec la quasi-totalité des routeurs, commutateurs, serveurs, onduleurs et baies de stockage, et existe en trois versions (v1, v2c et v3). Seule la version v3 offre un chiffrement et une authentification adéquats.

Dans ce guide, nous allons vous expliquer en détail le fonctionnement du protocole SNMP de bout en bout, le rôle de chacun de ses composants, comment choisir la version la plus adaptée, comment le configurer et le sécuriser, comment résoudre les problèmes éventuels, ainsi que ses limites.

Qu'est-ce que le SNMP ?

SNMP est un protocole standard qui permet à un système de surveillance (gestionnaire SNMP) de collecter des données de santé et de performance à partir d'équipements réseau en utilisant un format de message partagé. Des équipements exécutant différents systèmes d'exploitation (u Commutateur Cisco, un serveur Linux, un onduleur APC) répondent tous aux requêtes SNMP en utilisant le même protocole, bien que les données spécifiques exposées varient selon l'appareil. Un seul outil peut surveiller l'ensemble de l'environnement.

Ce nom est trompeur. Le protocole SNMP n'est pas toujours simple à utiliser ; son champ d'application va bien au-delà des équipements réseau, et dans la plupart des déploiements concrets, les équipes l'utilisent davantage à des fins de surveillance qu'à des fins de gestion active. 

Nous utilisons principalement le protocole SNMP pour collecter des données sur les périphériques : charge du processeur, utilisation de la mémoire, trafic sur les interfaces, température, état des ventilateurs, autonomie de la batterie d'un onduleur et état de santé des disques d'une baie de stockage. La quasi-totalité des équipements réseau le prennent en charge, tout comme la plupart des systèmes d'exploitation pour serveurs, de nombreux périphériques de stockage et certains logiciels d'application.

Pourquoi le SNMP est important

Le protocole SNMP est important parce qu'il s'agit d'un moyen économique et largement pris en charge pour savoir si votre infrastructure fonctionne avant que vos utilisateurs ne le sachent. 

Sans cela, quelqu'un doit surveiller des tableaux de bord, d'autres outils de surveillance ou attendre des réclamations. Avec cela, un système peut interroger des milliers d'appareils et alerter en cas de problèmes automatiquement.

Composants SNMP : Gestionnaire, Agent, MIB et OID

SNMP comprend quatre composants principaux :

1. Le gestionnaire demande des données et reçoit des alertes
2. L'agent répond et peut également envoyer des alertes
3. La MIB définit quelles données existent sur chaque appareil
4. L'OID est l'adresse unique d'un élément de données donné au sein de la MIB.

Comment ces composants s'emboîtent

Un gestionnaire interroge un agent sur le port UDP 161 (par défaut). L'agent recherche l'OID demandé dans sa MIB locale et renvoie la valeur. Le même agent peut également envoyer des alertes non sollicitées (traps) au gestionnaire sur le port UDP 162 lorsqu'un seuil est dépassé ou qu'un état change.

Le Gestionnaire (Station de Gestion de Réseau)

Le gestionnaire est tout système capable d'envoyer des requêtes SNMP et de recevoir des alertes (traps/informs). Il peut s'agir d'une simple machine Linux exécutant la commande snmpwalk depuis la ligne de commande, d'un outil simple tel que What’s Up Gold, ou d'une plateforme complète comme LogicMonitor, où nos collecteurs émettent les requêtes et où notre back-end SaaS stocke, analyse et génère des alertes à partir des données. 

Tout ce qui initie des requêtes SNMP est considéré comme un gestionnaire. Un seul appareil peut exécuter à la fois un gestionnaire et un agent.

L'Agent

L'agent est le logiciel installé sur l'appareil surveillé qui remplit deux fonctions : il répond aux requêtes du gestionnaire et envoie des alertes (traps ou messages d'information) lorsque des événements configurés se produisent. 

Sur les routeurs, les commutateurs et les pare-feu, l'agent est intégré au micrologiciel. Sur les serveurs à usage général (Linux, Fenêtres, Solaris, AIX, FreeBSD), il suffit d'en installer un. Sous Linux, le choix par défaut est net-snmp, qui s'exécute sous la forme du démon snmpd.

La MIB (Base d'information de gestion)

Le MIB est une base de données structurée, définie dans des fichiers en texte brut, qui décrit, selon une structure arborescente, toutes les données qu’un périphérique peut transmettre. 

Les MIB standard couvrent les éléments que chaque appareil doit exposer : les compteurs d'interface, le nom du système et le temps de fonctionnement. Les MIB constructeur couvrent les données spécifiques à l'appareil, telles que l'autonomie restante d'un onduleur APC ou la température d'une carte de ligne Cisco spécifique. 

Un appareil annonce des données en implémentant les MIB que son fournisseur définit.

L'OID (Identificateur d'objet)

Un OID est l'adresse numérique d'un objet géré au sein de l'arborescence MIB. Chaque chiffre de l'OID désigne un nœud, et le chemin complet, séparé par des points, identifie exactement une valeur que l'agent peut renvoyer.

Prenez .1.3.6.1.2.1.1.1.0 comme exemple. 

Cela signifie toujours sysDescr, une description textuelle du système. Le plus souvent, les OID avec lesquels vous travaillerez commencent soit par .1.3.6.1.2.1 pour les objets MIB-2 standard, soit par .1.3.6.1.4.1 pour les OID de fournisseurs privés.

Cisco possède .1.3.6.1.4.1.9, donc chaque objet spécifique à Cisco est rattaché à cette branche. L'IANA gère le registre complet des préfixes de fournisseurs sur iana.org/assignments/enterprise-numbers.

OIDs scalaires vs tabulaires

Il existe deux types d'OID :

1. Les OID scalaires renvoient une seule valeur parce qu'il n'y a qu'une seule de ces choses. sysDescr est scalaire parce qu'un appareil possède une seule description. 
2. Les OIDs tabulaires renvoient des valeurs d'une table, où chaque OID représente une colonne et l'index identifie la ligne. 

Les interfaces sont tabulaires : un routeur possède de nombreuses interfaces, chacune ayant sa propre description, son propre compteur d'octets et son propre nombre d'erreurs. Les OID tabulaires se terminent par un index qui identifie la ligne, tel que .1.3.6.1.2.1.2.2.1.10.3 pour le compteur d'octets d'entrée sur l'index d'interface 3.

Voici un exemple rapide utilisant snmpwalk :

$ snmpwalk -v2c -c Secret 127.0.0.1 .1.3.6.1.2.1.1.1.0

SNMPv2-MIB::sysDescr.0 = STRING : Linux demo1.logicmonitor.net 2.6.32-358.6.2.el6 x86_64

Exécutez la même requête sur un commutateur Cisco, et vous obtiendrez la chaîne de version IOS au lieu de la chaîne du noyau Linux. Même OID, agent différent, réponse appropriée.

Comment fonctionne SNMP : le flux de bout en bout

SNMP fonctionne en quatre étapes : 

1. Le manager envoie une demande
2. L'agent lit sa MIB
3. L'agent répond avec la valeur
4. L'agent envoie une trappe non sollicitée lorsqu'un changement se produit (optionnel)

Tout fonctionne principalement en UDP.

Étape par étape

1. Demande : Le gestionnaire envoie un message GET, GETNEXT ou GETBULK à l'agent sur le port UDP 161, indique l'OID souhaité et fournit une chaîne de communauté (v1/v2c) ou des identifiants d'utilisateur (v3).

2. Rechercher : L'agent vérifie les informations d'identification, puis recherche l'OID dans les objets MIB qu'il implémente et récupère la valeur correspondante auprès du périphérique.

3. Réponse : L'agent renvoie un paquet de RÉPONSE avec la valeur, du port UDP 161 vers le gestionnaire. Les jauges (comme la température) reviennent tellesquelles. Les compteurs (comme les octets entrants) reviennent sous forme de totaux cumulés bruts, et le gestionnaire convertit deux échantillons en un taux.

4. Piège (optionnel) : Si vous avez configuré l'agent pour cela, un franchissement de seuil ou un changement d'état pousse l'agent à envoyer une TRAP ou un INFORM au gestionnaire sur le port UDP 162, sans attendre d'être interrogé.

Une plate-forme de surveillance répète les étapes 1 à 3 toutes les 30 à 300 secondes par appareil, stocke les valeurs, calcule les taux et les ratios, et déclenche des alertes lorsque les valeurs dépassent des seuils. 

La plupart des plateformes utilisent les pièges comme signal secondaire, et non principal, pour des raisons que nous abordons ci-dessous.

Commandes SNMP et types de PDU

Le protocole SNMP définit sept types de messages, appelés PDU. Cinq proviennent du gestionnaire pour récupérer ou modifier des données, et deux proviennent de l'agent pour signaler des événements. 

Chaque échange SNMP utilise l'un d'entre eux.

Ports et protocoles SNMP

Le SNMP utilise deux ports UDP : le 161 pour l'interrogation et le 162 pour les notifications (traps). 

Le protocole SNMP fonctionne généralement sur UDP (ports 161 et 162), bien qu'il puisse également fonctionner sur TCP (ce qui est rare) ou TLS/DTLS dans certaines implémentations.

Considérations relatives aux pare-feu et aux ACL

Si l'interrogation SNMP cesse de fonctionner, nous vérifions d'abord le pare-feu parce que le SNMP fonctionne sur UDP, et les pertes de paquets silencieuses peuvent ressembler exactement à un équipement hors service ou à un agent défectueux. Une règle de pare-feu est généralement l'élément le plus simple à éliminer avant de toucher à quoi que ce soit d'autre. 

L'IP source de votre responsable doit atteindre le port UDP 161 sur l'appareil, car c'est là que les agents SNMP écoutent les requêtes. Les traps nécessitent la règle inverse : l'appareil doit atteindre le port UDP 162 sur le responsable, car c'est l'agent qui initie ce trafic, et non le responsable.

Voici une petite liste de vérification concernant les problèmes liés au pare-feu :

• Autoriser le trafic entrant UDP sur le port 161 sur l'appareil depuis l'adresse IP ou le sous-réseau du gestionnaire.
• Autorisez le trafic entrant UDP sur le port 162 vers le gestionnaire depuis tous les périphériques qui envoient des traps. Cette liste est généralement bien plus longue que la liste de contrôle d'accès (ACL) de sondage.
• N'oubliez pas que UDP est sans connexion. Un paquet de retour doit correspondre à une règle de pare-feu en soi, en particulier sur les pare-feu sans état, car le suivi d'état pour UDP est plus faible que pour TCP.
• Pour un transport chiffré, ouvrez plutôt les ports UDP 10161 et 10162. La plupart des déploiements n’utilisent pas TLS/DTLS, mais recourent plutôt à Secure v3 avec chiffrement au niveau du protocole.

Versions SNMP : v1, v2c et v3

Trois versions du protocole SNMP sont utilisées en production. Nous recommandons d'utiliser SNMPv3 si l'appareil le prend en charge, SNMPv2c à défaut, et la version 1 uniquement sur les équipements anciens qui n'acceptent aucune autre version.

Voici un aperçu des trois versions du protocole SNMP : 

SNMPv1 : la version originale 

Il est facile à configurer, car il utilise une chaîne de communauté en texte clair comme unique identifiant. La limite fatale réside dans les compteurs 32 bits. Une interface de 1 Gbit/s peut saturer un compteur d'octets 32 bits en 34 secondes, de sorte que des interrogations d'une minute ne permettent pas de savoir si 10 octets ont transité ou 4 294 967 306. 

Si vous utilisez toujours la v1 quelque part, prévoyez de la remplacer.

SNMPv2c

v2c est v1 avec des compteurs 64 bits et quelques nouveaux types de messages comme GETBULK. La sécurité repose toujours sur une chaîne de communauté en texte clair, elle n'est donc acceptable que sur les réseaux où vous faites confiance à toute personne pouvant accéder à l'appareil. 

La plupart des matériels prennent en charge v2c, souvent activé par défaut. Quelques appareils plus anciens nécessitent son activation explicite. Ne l'activez que si v3 n'est pas disponible.

SNMPv3

v3 ajoute une véritable sécurité à l'ensemble des fonctionnalités de v2c. Il prend en charge l'authentification (généralement SHA), le chiffrement (généralement AES), ou les deux. 

La configuration est plus complexe. Au lieu d'une seule chaîne de communauté, vous configurez des utilisateurs, des protocoles d'authentification, des clés de chiffrement et des vues. Le compromis en vaut la peine sur tout réseau où une personne non autorisée pourrait intercepter le trafic ou usurper des paquets.

Quelle version de SNMP devez-vous utiliser ?

Nous recommandons SNMPv3 avec authentification et chiffrement activés par défaut. N'utilisez la v2c qu'au sein d'un segment de réseau entièrement de confiance où les listes de contrôle d'accès (ACL) restreignent les hôtes autorisés à interroger. N'utilisez la v1 que lorsqu'un appareil ne prend littéralement en charge aucune version plus récente, et remplacez cet appareil dès que possible.

Interrogations vs Trappes : Quand utiliser l'une ou l'autre

Le questionnement consiste pour le manager à poser des questions selon un calendrier. Les traps consistent pour l'agent à fournir des informations de son propre chef lorsqu'un événement se produit. 

Nous vous recommandons de traiter le sondage comme votre source de données principale et les pièges comme un signal secondaire, et non l'inverse.

Pourquoi les pièges seuls sont risqués

Une trappe est un unique paquet UDP que l'appareil envoie au moment exact où quelque chose ne va pas. C'est le moment où le paquet a le moins de chances d'arriver. 

Supposons qu'une alimentation vienne de basculer et qu'une liaison montante oscille. Si ce paquet est perdu, vous ne recevrez aucune notification et vous ne saurez jamais qu'une notification était censée se produire. 

Le sondage détecte cela. Un sondage échoué est lui-même détectable, de sorte que votre gestionnaire vous avertit qu'un appareil a cessé de répondre.

Pourquoi les pièges sont toujours utiles

Pour les événements qui se produisent entre les scrutins et qui comptent rapidement (un port passant en mode admin-down, un voisin BGP se réinitialisant, une alimentation redondante basculant), les traps vous offrent une notification quasi en temps réel. 

Utilisez-les comme un système d'alerte précoce en plus des sondages, et non à la place. Activez les messages INFORM lorsque vos appareils le prennent en charge, car INFORM nécessite un accusé de réception et une nouvelle tentative.

Ce que les sondages vous apportent et que les pièges ne vous donnent pas

Les sondages vous donnent du contexte. 

Un trap peut vous indiquer que l'utilisation du processeur a dépassé la valeur 80% si des alertes basées sur des seuils sont configurées sur le dispositif. En revanche, l'interrogation régulière vous permet de savoir si l'utilisation du processeur augmente progressivement depuis une semaine ou si elle a connu un pic au cours des cinq dernières minutes. 

Cette différence détermine si vous réveillez quelqu'un ou si vous planifiez une correction pour demain. Nous constatons constamment ce schéma dans les environnements clients : le franchissement d'un même seuil signifie deux choses différentes selon la courbe de tendance qui le sous-tend.

Risques de sécurité SNMP et bonnes pratiques

Le protocole SNMP constitue une surface d'attaque courante, car il a été conçu à la fin des années 1980, à une époque où l'on partait du principe que la plupart des réseaux étaient fiables. 

Trois faiblesses reviennent sans cesse dans SNMP : 

1. v1 et v2c envoient les informations d'identification en clair, de sorte que quiconque peut capturer un seul paquet entre le gestionnaire et l'appareil peut lire la chaîne de communauté et la réutiliser. 
2. Les chaînes de caractères par défaut des communautés (“ public ” et “ private ”) sont toujours actives sur des millions d'appareils, car les fabricants les livrent activées et les administrateurs oublient de les modifier. Cela signifie que les attaquants peuvent souvent se passer complètement de l'étape consistant à deviner les identifiants. 
3. Les pirates exploitent les répondeurs SNMP ouverts pour amplifier le trafic DDoS, car une simple requête GETBULK peut déclencher une réponse jusqu’à 100 fois plus volumineuse, transformant ainsi votre appareil en une arme dirigée contre quelqu’un d’autre. 

Pour y remédier, considérez chaque déploiement SNMP comme un élément qu’il faut sécuriser, et non comme un élément sécurisé par défaut.

Liste de contrôle défensive

Appliquez ces bonnes pratiques sur tous les appareils compatibles SNMP :

• Ne laissez jamais de chaînes de communauté par défaut en place. Modifiez “ public ” et “ private ” ou supprimez-les.
• Utilisez SNMPv3 avec authPriv (authentification et chiffrement) partout où l'appareil le prend en charge.
• Restreindre SNMP avec des ACL à des IP de gestionnaires spécifiques, et non à de larges sous-réseaux.
• Placez le trafic de gestion sur un VLAN dédié ou un VRF de gestion, et non sur le même segment que le trafic utilisateur.
• Désactivez complètement SNMP sur les appareils que vous n'avez pas besoin de surveiller.
• Désactivez SET sauf si vous avez une raison spécifique de l'activer.
• Bloquez les ports UDP 161 et 162 à la périphérie du réseau. Le protocole SNMP ne doit jamais être accessible depuis l'Internet public.
• Faites pivoter les informations d'identification SNMPv3 selon le même calendrier que vos autres informations d'identification privilégiées.
• Vérifiez quels OID sont exposés par le périphérique. La plupart des périphériques permettent de restreindre les vues, de sorte que l'agent ne renvoie que le sous-ensemble de la MIB dont votre gestionnaire a réellement besoin.

Ce que signifie réellement le “ support SNMP ”

“L’expression ” prise en charge SNMP » signifie qu’un périphérique est capable de répondre à des requêtes SNMP, sans toutefois préciser de quelles requêtes il s’agit ni quelle quantité de données utiles est renvoyée. La couverture va d’une simple chaîne de caractères indiquant la version à des milliers de métriques spécifiques au fabricant ; cette mention ne suffit donc pas à elle seule à déterminer si un périphérique mérite d’être surveillé.

Les MIB standard couvrent l'utilisation des interfaces, les paquets par seconde, le processeur, la mémoire et les statistiques TCP. 

Cela suffit souvent pour une surveillance de base d’un routeur ou d’un commutateur. Mais cela ne suffit pas pour un onduleur (pour lequel il faut connaître l'autonomie de la batterie, le temps de fonctionnement sur batterie et l'état du bloc-batterie) ou une baie de stockage (pour laquelle il faut connaître l'état des disques, la capacité disponible et la latence par LUN). Ces indicateurs n'existent que dans les MIB spécifiques aux fabricants.

Avoir la MIB du fournisseur n'aide pas automatiquement non plus. 

La MIB d'APC compte plus de 4 500 objets, dont la plupart n'ont aucune utilité dans le cadre des opérations quotidiennes : l'un d'entre eux indique par exemple “ l'adresse physique du redresseur sur le bus ”. Tous les appareils APC ne prennent pas en charge l'ensemble des objets, car ils ne prennent en charge que des sous-ensembles de la MIB complète. 

Les indicateurs qui vous intéressent réellement sont dispersés dans l'arborescence, et pour les trouver, il faut soit lire attentivement la documentation du fournisseur, soit utiliser un outil de surveillance qui connaît déjà les OID pertinents pour chaque modèle.

Ce que signifie le “ support SNMP ” dans un système de surveillance

Un système de surveillance compatible SNMP n'est pas forcément efficace pour surveiller les périphériques SNMP. Le véritable critère réside dans l'ampleur du travail lié aux OID que le système effectue à votre place. 

Trois capacités séparent les deux :

1. Découverte automatique Un bon système identifie le périphérique, sélectionne les OID adaptés à ce modèle et effectue une nouvelle vérification lorsque la configuration change. Il suffit d'activer le PoE pour que la MIB PoE puisse être interrogée sans que personne n'ait à modifier la configuration.
2. Interprétation correcte des données : Le protocole SNMP renvoie des indicateurs, des compteurs, des chaînes de caractères et des images bitmap. Les compteurs doivent être convertis en débits en calculant la différence entre les échantillons et en divisant le résultat par l'intervalle ; les compteurs 64 bits ne passent à zéro que bien moins fréquemment que les compteurs 32 bits. Le système doit gérer tout cela de manière transparente.
3. Seuils d'alerte par défaut raisonnables : Des alertes prédéfinies pour les problèmes qui affectent réellement la production — erreurs d'interface, saturation du processeur, disque plein, onduleur fonctionnant sur batterie — devraient déjà être en place. De plus, la configuration de seuils personnalisés devrait se faire en quelques instants, et non pas prendre une semaine.

Outre ces trois fonctionnalités, d'autres fonctionnalités utiles sont proposées, notamment la création de graphiques, un routage flexible des alertes, la détection automatique des périphériques, des cartes de topologie de couche 2 et de couche 3, ainsi que la prise en charge d'autres protocoles (WMI, JMX, API des éditeurs) lorsque le protocole SNMP ne suffit pas. 

Un système qui consolide SNMP avec ces autres sources est bien plus utile qu'un système qui ne prend en charge que SNMP, ce qui est le principe sur lequel nous avons bâti notre propre plateforme.

Installer SNMP sur Linux

Pour installer SNMP sous Linux, suivez ces quatre étapes : 

1. Installez le paquet
2. Configurer l'agent
3. Démarrer le service
4. Vérifiez qu'il répond 

Sur Red Hat ou CentOS, l'ensemble du processus prend environ une minute sur un seul hôte. D'autres distributions utilisent le même paquet net-snmp avec des commandes de gestionnaire de paquets différentes.

Étape 1 : Installer le paquet net-snmp

Installez l'agent et les utilitaires en ligne de commande avec votre gestionnaire de paquets. Le paquet d'utilitaires vous fournit `snmpwalk`, `snmpget` et d'autres outils dont vous aurez besoin pour les tests.

yum install net-snmp net-snmp-utils

Sur Debian ou Ubuntu, l'équivalent est apt install snmpd snmp. Sur les systèmes Red Hat plus récents, utilisez dnf au lieu de yum.

Étape 2 : Configurer l'agent

L'agent lit sa configuration à partir de /etc/snmp/snmpd.conf. Pour un hôte situé derrière un pare-feu et non exposé à Internet, la configuration fonctionnelle la plus simple se résume à une seule ligne :

rocommunity MaCommunauté

Cela permet à tout appareil connaissant la chaîne de communauté MyCommunity d'exécuter des requêtes en lecture seule à partir de n'importe quelle adresse IP, à moins que des contrôles d'accès ne soient ajoutés. Les opérations d'écriture (SET) restent désactivées, ce qui est souhaitable pour presque tous les cas de production.

Remplacez MyCommunity par un terme qui n'est ni un mot du dictionnaire ni une valeur par défaut. Les termes “ public ” et “ private ” faisant l'objet de scans constants, ne les utilisez jamais.

Pour les configurations plus strictes, snmpd.conf permet également de limiter les IP qui peuvent interroger l'agent, d'activer l'authentification et le chiffrement SNMPv3, et de restreindre les OIDs auxquels l'agent répondra. 

Étape 3 : Démarrer le service et l'activer au démarrage

Démarrez l'agent maintenant et indiquez au système de le lancer à chaque démarrage :

chkconfig snmpd on

service snmpd restart

Sur les systèmes utilisant systemd (la plupart des distributions Linux modernes), l'équivalent est :

systemctl enable snmpd

systemctl restart snmpd

Étape 4 : Vérifier que l'agent répond

Testez l'agent à partir du même hôte avant de dépanner quoi que ce soit sur le réseau. Une requête locale réussie signifie que l'agent est en cours d'exécution et que la configuration est valide pour l'accès local :

snmpwalk -v2c -c MyCommunity 127.0.0.1 .1.3.6.1.2.1.1.1.0

Vous devriez recevoir une ligne commençant par SNMPv2-MIB::sysDescr.0 = STRING: suivi de votre description du système. Si vous comprenez cela, l'agent fonctionne. Si ce n'est pas le cas, passez à la liste de contrôle de dépannage de la section suivante.

Si les requêtes échouent :

Traitez ceux-ci dans l'ordre :

• Pare-feu local : iptables, firewalld ou nftables doit autoriser le trafic UDP 161 entrant. Vérifiez avec iptables -L -n ou l'équivalent.
• Pare-feu réseau : Tout ce qui se trouve entre le gestionnaire et le serveur doit également autoriser le trafic UDP sur le port 161.
• Paquets arrivant à tous : Exécutez tcpdump -i any port 161 sur le serveur et effectuez une requête depuis le gestionnaire. Si rien ne s'affiche, il s'agit d'un problème de réseau.
• hosts.allow / hosts.deny : Certaines versions de net-snmp utilisent tcpwrappers. Ajoutez snmpd: ALL à /etc/hosts.allow pour tester.
• Chaîne de communauté Confirmez que le gestionnaire utilise la chaîne exacte de la configuration de l'agent.

Résoudre les problèmes liés au SNMP : une liste de contrôle structurée

Lorsque le protocole SNMP ne fonctionne pas, le problème provient presque toujours de l'un des quatre éléments suivants : le port, les identifiants, l'agent ou la liste de contrôle d'accès (ACL). 

Vérifiez-les dans cet ordre. Ne sautez pas d'étapes.

1. Le port est-il accessible ?

• Depuis le gestionnaire, lancez la commande nmap -sU -p 161. Un résultat “ open ” ou “ open|filtered ” signifie que le port est accessible, mais que cela n'est pas confirmé de manière définitive..
• S'il est fermé, vérifiez les pare-feu entre le gestionnaire et l'appareil, ainsi que toute ACL sur l'appareil lui-même.

2. Les identifiants sont-ils corrects ?

• Pour v1/v2c, vérifiez la chaîne de communauté caractère par caractère. Les espaces de fin et la casse sont importants. 
• Pour la v3, vérifiez le nom d'utilisateur, le protocole d'authentification (MD5 ou SHA), la clé d'authentification, le protocole de confidentialité (DES ou AES) et la clé de confidentialité. Un seul champ erroné fait échouer l'ensemble de l'échange.

3. L'agent est-il en cours d'exécution et répond-il ?

• Sous Linux, exécutez la commande « systemctl status snmpd » ou « service snmpd status ».
• Sous Cisco IOS, exécutez la commande “ show snmp ” pour afficher le nombre de paquets. Une augmentation du nombre de « paquets perdus dans la file d'attente d'entrée » indique une surcharge de l'agent.
• Exécutez la commande `tcpdump -i any -n port 161` sur l'appareil. Si des requêtes arrivent mais qu'aucune réponse n'est renvoyée, le problème provient probablement de la configuration de l'agent, des identifiants ou des contrôles d'accès.

4. L'ACL autorise-t-il ce gestionnaire ?

• Cisco: vérifiez la liste ACL mentionnée dans la communauté snmp-server ou le groupe snmp-server.
• Linux net-snmp: le rocommunity La directive accepte une restriction de source, par exemple : rocommunity MyCommunity 10.0.0.0/24.

Comment exécuter SNMP à grande échelle dans de grands environnements

Pour faire évoluer le protocole SNMP :

• Définissez les intervalles d'interrogation en fonction de la métrique : La valeur par défaut courante est de 60 secondes. Réduisez la fréquence de mise à jour des compteurs d'interface à 30 secondes lorsque la capacité de l'appareil le permet, car les pics de courte durée sont importants. Pour les valeurs qui évoluent lentement, comme la capacité du disque, optez pour un intervalle de 300 secondes. Des intervalles plus courts sollicitent davantage l'appareil et le collecteur ; veillez donc à ne pas effectuer d'interrogations plus fréquentes que nécessaire.
• Placez les capteurs à proximité des appareils qu'ils surveillent : Les requêtes effectuées via une liaison WAN entraînent une latence à chaque échange et rendent la transmission des traps plus instable.
• Requêtes par lots avec GETBULK : Utilisez GETBULK (à partir de la version 2c) avec une valeur de répétition raisonnable, généralement comprise entre 10 et 20, afin de réduire le nombre de requêtes d'un ordre de grandeur.
• Renouveler les identifiants via la gestion de la configuration : Des outils tels qu'Ansible, Chef, Puppet ou Salt vous permettent de déployer des chaînes de caractères de la communauté ou des clés SNMPv3 sur l'ensemble du parc sans avoir à vous connecter individuellement à chaque appareil.
• Échelonnez les sondages sur toute la durée de l'intervalle : Répartissez les requêtes de manière uniforme au lieu de les envoyer toutes à la seconde zéro de chaque minute. Un afflux massif de requêtes SNMP entraîne une perte de paquets et des pics d'utilisation du processeur sur les appareils de petite taille ou aux ressources limitées.

Cas d'utilisation de SNMP

Le protocole SNMP intervient dans cinq domaines d'activité communs à la plupart des environnements informatiques : la surveillance des performances, les alertes en cas de panne, la planification des capacités, le dépannage et la mise en évidence de la conformité. 

Chacune utilise les mêmes données sous-jacentes, mais la manière dont ces données sont exploitées diffère.

• Surveillance des performances : Collectez à intervalles réguliers des indicateurs relatifs au processeur, à la mémoire, au trafic des interfaces et à la latence, puis représentez-les sous forme de graphiques et analysez leurs tendances.
• Alertes de panne : Déclencher des alertes lorsqu'un seuil est dépassé, qu'un processus plante, qu'une alimentation électrique tombe en panne ou qu'une interface présente des fluctuations.
• Planification de la capacité : Utilisez les données SNMP collectées sur plusieurs semaines et plusieurs mois pour prévoir quand les liaisons montantes, le processeur ou l'espace de stockage seront saturés.
• Dépannage : Accéder à un périphérique pendant un incident pour vérifier les compteurs en temps réel (erreurs d'interface, taille de la table de routage, pools de mémoire) sans ouvrir de session CLI.
• Conformité : Les données SNMP historiques répondent aux questions des auditeurs concernant la disponibilité, les fenêtres de changement et l'utilisation des ressources qui n'auraient autrement aucune trace.

Limites du protocole SNMP

Les faiblesses de SNMP se divisent en trois catégories : les failles de sécurité, les coûts de mise à l'échelle et les lacunes de couverture. Savoir à quelle catégorie appartient un problème indique s'il faut le résoudre, le contourner ou associer SNMP à autre chose.

Failles de sécurité

Deux limitations se situent au niveau du protocole et affectent l'intégrité des données que vous collectez :

• Sécurité par défaut faible v1 et v2c n'ont pas de chiffrement et s'authentifient avec une chaîne partagée en texte clair. v3 résout ce problème, mais nécessite une configuration plus minutieuse.
• Perte de paquets UDP : SNMP fonctionne sur UDP. Les requêtes et les traps peuvent disparaître silencieusement en cas de congestion, ce qui donne une fausse impression de couverture.

Coûts de mise à l'échelle

Deux limites apparaissent lorsque vous déployez SNMP sur des milliers d'appareils :

• Surcharge d'interrogation : Des dizaines de milliers de petites requêtes UDP par minute s'accumulent. Sur les appareils aux ressources limitées (commutateurs d'entrée de gamme, équipements IoT), SNMP lui-même peut consommer des cycles CPU significatifs.
• Particularités de l'indexation des tables : Les index des interfaces peuvent changer après un redémarrage sur certains appareils. Un système de surveillance qui met en cache les index finit par interroger les mauvaises lignes jusqu'à ce qu'il relance la découverte.

Lacunes de couverture

Trois limitations décrivent ce que SNMP ne peut pas voir, soit en raison d'incohérances entre fournisseurs, soit parce que la pile moderne a évolué :

• Mises en œuvre inégales des fournisseurs : Il est rare que deux appareils de marques différentes appartenant à la même catégorie fournissent les mêmes indicateurs. Certains fournissent toutes les informations. D'autres, pratiquement aucune.
• Incohérence des OID : Les MIB des fournisseurs utilisent des structures différentes pour les mêmes données. Le portage d'un modèle de surveillance d'un fournisseur à un autre se fait rarement sans heurts.
• Visibilité limitée sur l'infrastructure moderne : Les conteneurs, les fonctions « serverless » et les services cloud n'exposent pratiquement jamais le protocole SNMP. Les piles techniques modernes associent le SNMP à la télémétrie en continu (gNMI, OpenTelemetry), aux API des éditeurs et à l'ingestion des journaux.

Défis liés aux fournisseurs SNMP et aux MIB

Voici les défis que nous voyons le plus souvent, à peu près dans l'ordre des dégâts que chacun cause :

• Soutien nominal seulement : Certains appareils implémentent les MIB standard mais renvoient des zéros ou des valeurs statiques. L'agent répond, mais les données ne sont pas réelles. C'est le mode de défaillance le plus difficile à détecter car rien ne semble cassé.
• OIDs qui changent entre les versions de firmware : Un fournisseur peut déprécier un OID dans une version mineure. La surveillance configurée pour cet ancien OID cesse silencieusement de renvoyer des données après une mise à niveau. Nous avons vu cela briser les tableaux de bord des clients plus d'une fois.
• Fichiers MIB non publiés : Certains fournisseurs cachent les fichiers MIB derrière des portails de support. Sans la MIB, vous naviguez dans les OID à l'aveugle. Des valeurs reviennent, mais rien ne vous indique ce qu'elles signifient.
• Contexte manquant : Un OID d'utilisation du processeur peut rapporter une chose différente selon les fournisseurs (moyenne d'une minute, moyenne de cinq minutes, instantanée) sans indiquer laquelle. Les seuils définis pour un fournisseur peuvent être erronés pour un autre.
• Indicateurs dans différentes branches : Les taux d'erreur des interfaces se trouvent dans la norme IF-MIB sur la plupart des équipements, mais dans des branches privées de constructeurs sur d'autres. Vous avez besoin d'une logique de découverte spécifique à l'équipement pour les trouver.
• Instabilité de l'indice : Les valeurs d'ifIndex peuvent être réattribuées lors d'un redémarrage. Certains fournisseurs proposent ifAlias ou une MIB d'index persistant comme solution de contournement, mais pas tous.

Pour éviter ces difficultés, validez ce que le protocole SNMP renvoie réellement sur chaque classe d'équipements de votre environnement avant de vous fier à ces données. 

Vérifiez par sondage les valeurs des compteurs par rapport à d'autres sources (sortie CLI, NetFlow, métriques applicatives) sur au moins un équipement par modèle.

Du support SNMP à la vraie visibilité

Le protocole SNMP reste la référence universelle pour la surveillance des infrastructures. Presque tous les équipements réseau et systèmes d'exploitation de serveurs peuvent l'utiliser. Pour surveiller les routeurs, les commutateurs, les pare-feu, les onduleurs et les serveurs traditionnels, rien ne le remplace.

Mais le support des protocoles n'est que le point de départ. Le véritable travail consiste à déterminer quels OIDs comptent, à les collecter de manière cohérente sur tous les types d'appareils et à transformer ces données en alertes et en tendances sur lesquelles votre équipe peut compter.

LogicMonitor est conçu pour réduire cette charge de travail. Il vous aide à surveiller l'infrastructure compatible SNMP avec moins de configuration manuelle, une meilleure couverture des appareils et un chemin plus clair des métriques brutes à l'action.

FAQ