Meraki retire SNMPv1 : comment garder un œil sur son réseau ?

SNMPv1, c'est le vieux câble qu'on oublie derrière la baie. Il fonctionne encore, personne ne veut y toucher, et un jour une mise à jour rappelle qu'il était toujours là.

Cisco Meraki va retirer SNMPv1 du polling direct de ses bornes, switches et appliances à partir des firmwares MR 27.2, MS 27.2 et MX 27.2.

Pas de panique : SNMP ne disparaît pas. En revanche, c'est le bon moment pour vérifier ce que votre supervision interroge vraiment et pour arrêter de faire reposer le monitoring sur un protocole ancien.

Dans Meraki, il existe deux façons très différentes de faire du SNMP. C'est là que les choses se compliquent un peu.

La première consiste à interroger le cloud Meraki sur snmp.meraki.com. Elle se règle dans Organization > Configure > Settings > SNMP.

La seconde consiste à interroger directement chaque équipement sur son adresse locale. Elle se règle dans Network-wide > Configure > General > Reporting.

C'est ce deuxième cas qui perd SNMPv1 avec les firmwares 27.2.

Si votre outil parle uniquement au Dashboard, il n'est donc pas concerné de la même façon. S'il interroge les switches, les MX ou les bornes une par une, il faut regarder sa configuration maintenant.

Le piège classique ? Une organisation a souvent plusieurs collecteurs. Le NMS interroge les switches, un script récupère quelques OID et un autre outil attend des traps. Un seul écran Meraki ne raconte pas toute l'histoire.

SNMPv1 est simple, compatible et connu de tous. C'est aussi son problème : on le retrouve encore dans des configurations que plus personne ne possède vraiment.

Sa chaîne de communauté circule sans chiffrement. Elle n'offre ni identité solide, ni confidentialité, ni protection adaptée à un réseau moderne.

SNMPv2c fonctionne mieux, mais garde le même défaut : la communauté reste en clair. Il améliore le protocole, pas sa sécurité.

SNMPv3 ajoute l'authentification, l'intégrité et le chiffrement. Meraki recommande SHA et AES128. Pour le polling local, les équipements utilisent SHA1 avec DES ou AES128 ; choisissez AES128.

Attention aux exceptions matérielles. DES disparaît sur les switches sous IOS XE 17.18.2 ou plus récent. Campus Gateway impose SNMPv3 avec AES128 à partir de MCG 32.2.1.

Ce n'est pas la cryptographie la plus moderne du marché, mais c'est un vrai progrès par rapport à une communauté envoyée en clair.

Le mauvais réflexe serait de passer directement le firmware en 27.2 et d'attendre de voir quels graphiques deviennent vides.

Commencez par chercher partout où SNMPv1 peut se cacher :

Pour chaque usage, notez la cible interrogée, la version SNMP, les OID utiles, la fréquence de collecte et la personne qui utilise réellement les données.

Ne copiez pas les communautés et secrets dans le fichier de suivi. Il suffit de savoir où ils sont gérés et qui peut les remplacer.

Le vrai test n'est pas « le serveur répond ». Il faut retrouver les mêmes informations utiles après la migration et détecter rapidement une absence de données.

Si votre NMS prend en charge SNMPv3, la direction est simple : créez un utilisateur dédié, activez l'authentification, choisissez AES128 et limitez les sources autorisées.

Pour le polling du Dashboard, Meraki recommande aussi SNMPv3 avec SHA et AES128. Les restrictions d'adresses IP sont obligatoires en v2c et restent une bonne idée en v3.

Pour le polling local, testez chaque famille de matériel. Une configuration qui marche sur un MS ne garantit pas que le modèle MX ou MR du collecteur attend les mêmes OID.

Votre outil ne sait faire que du v2c ? Utilisez-le comme sas de migration. Isolez le réseau de management, limitez les accès aux sondes et planifiez déjà sa sortie.

Évitez surtout d'exposer SNMP directement sur Internet. Si une sonde distante doit joindre un équipement, préférez un VPN ou un chemin d'administration privé.

SNMP est pratique pour remplir des graphiques et suivre des compteurs. Il ne sait pas tout faire, et Meraki propose plusieurs autres chemins.

L'idée n'est pas d'activer tous les canaux pour chaque événement. Il faut donner un rôle à chacun et garder un deuxième chemin pour les incidents vraiment critiques.

Le polling pose régulièrement une question. Le trap part quand un événement se produit. Les deux se complètent.

Chez Meraki, les traps partent du cloud. Le récepteur doit donc être joignable sur une adresse publique. Derrière un NAT, il faudra prévoir la redirection de port adaptée.

Le réglage se trouve dans Network-wide > Configure > Alerts. Un bouton de test permet de vérifier la réception, ce qui évite de découvrir un problème le jour de l'incident.

Petit détail utile : avec le destinataire snmp, Meraki envoie le trap et l'e-mail associé. Les traps ne sont pas proposés pour toutes les alertes, notamment celles de Systems Manager.

Un trap peut se perdre. Gardez un polling de contrôle et retestez la chaîne après un changement de pare-feu, de NAT ou de collecteur.

Les alertes natives du Dashboard couvrent beaucoup de cas : équipement hors ligne, tunnel AutoVPN, température, alimentation, échec DHCP, point d'accès rogue, capteur hors seuil ou certificat APNS proche de l'expiration.

Pour démarrer vite, l'e-mail reste imbattable. Mais il faut vérifier qui reçoit quoi.

L'option « tous les administrateurs réseau » inclut les administrateurs complets et en lecture seule du réseau. Elle n'ajoute pas automatiquement les administrateurs de l'organisation.

Les comptes SAML sans adresse enregistrée dans le Dashboard ne recevront rien. Pensez aussi à autoriser les expéditeurs Meraki dans les filtres de messagerie.

Un e-mail peut arriver avec environ dix minutes de retard, car Meraki regroupe certains événements. Plusieurs alertes sont aussi limitées à 25 envois par période de dix minutes, par type et par réseau.

L'application mobile est pratique pour l'astreinte. Le réglage push reste toutefois personnel à chaque téléphone. Le fait qu'un administrateur soit notifié ne signifie pas que toute l'équipe l'est.

Autre subtilité : Allow notifications coupe tous les canaux de l'événement. Si vous le désactivez, vous perdez aussi e-mails, push et webhooks. Receive push notification ne concerne que le téléphone.

Le push reste un canal de confort. Une session expirée, une permission coupée ou un téléphone sans réseau suffit à le rendre silencieux.

Le webhook devient intéressant lorsqu'une alerte doit créer un ticket, prévenir un canal, enrichir un incident ou lancer une automatisation.

Meraki envoie un message JSON vers une URL HTTPS publique. Le certificat doit être reconnu publiquement ; un certificat autosigné ne suffit pas.

Ajoutez un secret partagé et validez-le côté récepteur. Sans ce contrôle, n'importe qui connaissant l'URL pourrait tenter de vous envoyer de faux événements.

Le message contient notamment alertId, occurredAt, sentAt et les identifiants du réseau et de l'organisation. Utilisez-les pour dédupliquer, mesurer le délai et rattacher l'alerte au bon site.

Meraki annonce un envoi moyen en moins de 90 secondes. Certaines alertes prennent plus de temps lorsqu'elles attendent un seuil ou regroupent plusieurs événements.

Le récepteur doit répondre en HTTP 2xx. Après plus de 100 échecs sur 24 heures, il peut être désactivé automatiquement et les administrateurs de l'organisation sont prévenus.

Surveillez donc le webhook lui-même. Un test périodique et une alerte sur l'absence de réception valent mieux qu'une automatisation silencieusement cassée.

Syslog sert à conserver des événements et des flux hors du Dashboard. Les MX peuvent envoyer Event Log, IDS Alerts, URLs et Flows. Les bornes MR couvrent les mêmes rôles sauf IDS Alerts ; les switches MS envoient les événements.

Les flows peuvent vite remplir un disque. Dimensionnez le stockage et fixez une durée de conservation avant d'activer la collecte partout.

Le chiffrement TLS du transport Syslog est annoncé pour plus tard. En attendant, protégez le chemin réseau et le collecteur. Notre guide sur la rétention des logs Meraki creuse le sujet.

L'API Dashboard répond à un autre besoin. Elle récupère inventaires, états, statistiques et événements à l'échelle d'un réseau ou d'une organisation.

Elle complète très bien un webhook : l'événement arrive, puis l'intégration appelle l'API pour récupérer l'état actuel et ajouter du contexte au ticket.

Il faut simplement gérer les clés, les droits et les limites de requêtes avec sérieux. Nous abordons aussi ce sujet dans notre article sur les agents IA Meraki et Catalyst Center.

Pour un réseau multi-sites, nous partons généralement sur quatre couches simples.

Ce montage évite deux travers : le mur de notifications que plus personne ne lit et l'alerte unique dont personne ne vérifie la livraison.

Voici un chemin simple pour avancer sans couper les graphiques du jour au lendemain.

Rester sur un ancien firmware peut donner quelques semaines de répit à un outil bloqué. Ce n'est pas une stratégie durable : vous finirez aussi par repousser les correctifs et les évolutions du produit.

La fin de SNMPv1 n'est pas seulement une contrainte de firmware. C'est une occasion de poser une question très simple : si un site tombe demain matin, comment l'équipe l'apprend-elle ?

Un graphique vide n'est pas une alerte. Un e-mail n'est pas un historique. Un webhook n'est utile que si son récepteur fonctionne. Et un Dashboard vert ne prouve pas que votre propre chaîne de monitoring va bien.

SNMP mesure, Syslog conserve, l'API apporte le contexte, le webhook déclenche et le push attire l'attention. Le bon dispositif assemble ces briques sans les confondre.