Supervision SNMP pour MikroTik

Résumé SNMP est la base de facto pour superviser les routeurs MikroTik — uptime, compteurs d’interfaces, CPU, mémoire, température et état de lien, interrogés par un NMS comme Zabbix, LibreNMS ou PRTG. Ce guide couvre la configuration SNMPv2c et SNMPv3 sur RouterOS, les tests avec snmpwalk, les patterns d’intégration avec un NMS et la checklist de durcissement qui maintient SNMP utile à grande échelle sans devenir un passif de sécurité.

Comment SNMP supervise-t-il les routeurs MikroTik ?

SNMP (Simple Network Management Protocol) est le mécanisme standard pour superviser les équipements réseau. Un NMS interroge l’équipement sur le port UDP 161 pour les OID définis dans des MIB (Management Information Bases), et l’équipement retourne des valeurs standardisées pour l’uptime, les compteurs d’interfaces, la charge CPU, l’usage mémoire, les températures et l’état matériel. Sur MikroTik, activer SNMP prend deux commandes et produit immédiatement de la télémétrie utile — sysUpTimeInstance, ifInOctets, ifOutOctets et le reste de la table SNMP standard sont disponibles pour tout NMS qui pose la question.

SNMP est le côté lecture de la télémétrie réseau ; pour la gestion de configuration, utilisez TR-069, TR-369 (USP) ou des API spécifiques aux équipements. C’est cette séparation propre entre observation et contrôle qui rend sûr d’exposer SNMP à un NMS — lecture seule par conception, standardisé entre fabricants et stable sur des décennies d’exploitation réseau. Pour les protocoles de gestion complémentaires, voyez notre guide TR-369 USP et le guide de supervision SNMP Intelbras.

Choisissez la bonne version de SNMP

Préférez toujours SNMPv3 quand le NMS le supporte. Si vous devez utiliser v1 ou v2c (NMS legacy, contraintes embarquées), restreignez l’accès strictement par IP source et traitez la community string comme un secret public plutôt que comme une vraie credential.

Activez SNMP sur le MikroTik

Le minimum pour faire fonctionner SNMPv2c depuis le terminal :

/snmp set enabled=yes
/snmp community add name=monitor-public addresses=192.0.2.10/32 security=none
/snmp print

Remplacez 192.0.2.10/32 par l’IP source réelle de votre NMS. Ne laissez jamais 0.0.0.0/0 ni la community par défaut public en production — un SNMPv2c exposé est une source récurrente d’exfiltration non autorisée de données dans les audits réels.

Exemple SNMPv3 (recommandé)

Créez un utilisateur avec authentification et confidentialité (chiffrement) :

/snmp user add name=snmpv3user security=authPriv \
    auth-protocol=SHA1 auth-passphrase="AuthPass" \
    priv-protocol=AES priv-passphrase="PrivPass"

Vérifiez :

/snmp print
/snmp user print

Testez la collecte avec snmpwalk

Depuis un hôte Linux qui peut atteindre le routeur sur UDP 161, validez que SNMP répond. SNMPv2c d’abord :

snmpwalk -v2c -c monitor-public 192.168.88.1

SNMPv3 :

snmpwalk -v3 -u snmpv3user -a SHA -A AuthPass -x AES -X PrivPass 192.168.88.1

Sortie attendue : un flot d’OID incluant sysUpTimeInstance, des compteurs d’interfaces comme ifInOctets et ifOutOctets, et le descripteur système. Les timeouts pointent presque toujours vers l’une de trois choses : les credentials (community ou v3) ne correspondent pas, un pare-feu bloque l’UDP 161, ou l’IP source n’est pas dans la liste des adresses autorisées sur le MikroTik.

Intégrez à un NMS

Choisissez un NMS adapté à votre échelle et à votre flux opérationnel.

• Zabbix — le plus puissant pour les gros déploiements personnalisables avec des arbres d’alerte complexes.
• LibreNMS — découverte SNMP plus facile et bons templates prêts à l’emploi pour MikroTik.
• PRTG Network Monitor — commercial, convivial, licence par sondes.

L’onboarding de base est le même partout :

1. Ajoutez l’hôte avec l’IP de management du routeur.
2. Attachez un template SNMP (ou définissez les items pour les OID qui vous intéressent).
3. Configurez les intervalles de polling (60 s pour le trafic, 5 min pour les métriques plus lentes).
4. Créez des triggers et des alertes pour des conditions comme link down, fort taux d’erreurs ou CPU au-dessus du seuil.

Commencez par un petit jeu de métriques essentielles — uptime, débit d’interface, erreurs, CPU — avant d’en ajouter. Le gonflement de la base par un polling indiscriminé est un coût opérationnel bien réel.

Supervisez les équipements derrière le MikroTik

Le MikroTik peut servir de collecteur SNMP local pour les équipements en aval :

/tool snmp-walk address=192.168.88.10 community=public

Utilisez-le pour découvrir des caméras, des switches, des onduleurs ou des équipements PoE sur le LAN et faire remonter leurs métriques au NMS central via le routeur. C’est particulièrement utile quand les équipements en aval sont derrière une couche de pare-feu que le NMS ne peut pas atteindre directement.

Mise à l’échelle : proxys, découverte, automatisation

À l’échelle d’un parc, l’onboarding manuel cesse d’être viable. Utilisez Zabbix Proxy (ou équivalent) pour collecter les métriques depuis des régions distantes, réduisant la latence et centralisant l’agrégation. Activez la découverte SNMP pour que les nouveaux équipements s’ajoutent automatiquement au NMS au lieu d’exiger une création manuelle. Automatisez le provisionnement avec des scripts ou un outil de gestion de configuration — quand un nouveau MikroTik arrive en ligne, il doit être interrogé en quelques minutes, pas en jours.

Bonnes pratiques de sécurité

• Utilisez SNMPv3 dès que le NMS le supporte.
• Limitez l’accès par IP source — seuls le NMS et les proxys doivent interroger les équipements.
• N’utilisez jamais les community strings par défaut (public, private).
• Ne collectez que les métriques dont vous avez réellement besoin. Moins de données interrogées = moins de charge et moins d’exposition.
• Auditez les logs d’usage SNMP et faites tourner les credentials v3 au même rythme que les autres credentials.

Exposer SNMP (surtout v1/v2c) à l’Internet public sans restriction d’origine est un risque de sécurité majeur. Pour un contexte plus large sur la sécurité du plan de management, voyez notre article sur les bonnes pratiques de sécurité Winbox.

Cas d’usage à l’échelle d’un FAI

Avec 500 routeurs MikroTik déployés sur les sites clients, SNMP vous donne l’historique d’uptime et de CPU par équipement, la détection des gros consommateurs de bande passante par client via les compteurs d’interfaces, la détection d’interfaces défaillantes via la hausse des erreurs et discards, et des alertes automatiques vers Slack, Telegram ou e-mail quand des équipements tombent. Les alertes automatiques sur les bons seuils font économiser des heures d’opérations réactives et évitent le type d’escalade qui survient quand les problèmes ne sont découverts que par les réclamations clients.

SNMP face à la télémétrie moderne

SNMP est stable, mature et supporté partout. Les méthodes plus récentes — télémétrie streaming gRPC, NetFlow/IPFIX, OpenConfig — apportent des données plus riches avec moins d’overhead de polling, mais SNMP reste la base d’interopérabilité que parle tout NMS et tout fabricant. La bonne réponse pour la plupart des exploitations est de combiner SNMP pour un polling stable et indépendant du fabricant avec une télémétrie plus récente là où vous avez besoin d’analytique haute résolution ou de détection d’événements sub-seconde.

Passez à la suite

SNMP garde les réseaux observables et les opérateurs sains d’esprit. Activez-le avec soin, préférez SNMPv3, testez avec snmpwalk et branchez-vous à un NMS taillé pour votre échelle. Commencez petit, itérez et automatisez le flux d’onboarding.

Si vous préférez vous épargner totalement le déploiement d’un NMS, MKController combine supervision basée sur SNMP et accès distant sécurisé via les tunnels sortants de NATCloud — visibilité centralisée, onboarding plus simple et sessions distantes vers des parcs MikroTik sans IP publiques ni ports ouverts. Pour des patterns de gestion distante complémentaires, voyez notre guide de gestion via VPS et le guide de gestion distante WireGuard.

Démarrez votre essai gratuit MKController