Guide de gestion des équipements réseau : SNMP, TFTP et syslog sans NMS complet

La gestion des commutateurs et des routeurs sans logiciel onéreux repose sur trois protocoles légers. La combinaison du requêtage SNMP sur le port UDP 161, des transferts de fichiers TFTP sous la RFC 1350 et de la collecte syslog sur le port UDP 514 offre une visibilité et une récupération complètes. L'exécution de ces tâches à partir d'un seul utilitaire couvre les opérations quotidiennes sans la surcharge d'une grande plateforme.

À quoi servent concrètement SNMP, TFTP et syslog ?

Chaque protocole répond à une question différente concernant un équipement. Ensemble, ils couvrent la majeure partie de ce que vous faites sur un commutateur ou un routeur entre les installations.

SNMP répond à la question « dans quel état se trouve cet équipement en ce moment même ? » Le protocole Simple Network Management Protocol (SNMP) permet à un gestionnaire de lire les valeurs d'un équipement. Une requête « get » lit une seule valeur, comme le temps d'activité ou le nombre d'erreurs d'une interface. Un « walk » lit chaque valeur sous une branche de l'arborescence, l'une après l'autre. Chaque valeur possède un identifiant d'objet (OID), un numéro séparé par des points tel que 1.3.6.1.2.1.1.3 pour sysUpTime. Une base d'informations de gestion (MIB) est le fichier texte qui donne à ces numéros des noms lisibles par l'homme.

TFTP répond à la question « comment transférer un fichier vers ou depuis cet équipement ? » Le protocole Trivial File Transfer Protocol (TFTP), défini dans la RFC 1350, déplace des fichiers sur le port UDP 69 sans authentification. La plupart des commutateurs et routeurs gérés peuvent copier leur configuration active vers un serveur TFTP. Ils peuvent également télécharger des images de firmware depuis ce dernier.

Syslog répond à la question « que m'a dit cet équipement ? » Les équipements envoient des lignes de journalisation à un récepteur au fur et à mesure que les événements se produisent. Le format actuel est la RFC 5424, et de nombreux équipements réseau envoient encore l'ancien format BSD décrit dans la RFC 3164. Les traps SNMP font le même travail pour les alertes structurées. Un trap linkDown, par exemple, arrive sur le port UDP 162 dès qu'un port tombe en panne.

Rôle de chaque protocole

Tâche	Protocole	Transport et port	Standard	Sécurité intégrée
Interroger l'état de l'équipement à la demande	SNMP get, getnext, getbulk	UDP 161	RFC 3416 (opérations), RFC 3411 à 3418 (SNMPv3)	v2c : chaîne de communauté en texte clair. v3 : authentification et chiffrement (RFC 3414, RFC 3826)
Recevoir des alertes structurées	Trap ou inform SNMP	UDP 162	RFC 3416	Correspond à la version SNMP utilisée
Sauvegarder les configurations, restaurer les configurations, charger le firmware	TFTP	UDP 69, puis un nouveau port par transfert	RFC 1350, options dans RFC 2347 à 2349	Aucune : pas d'authentification, pas de chiffrement
Collecter les journaux des équipements	Syslog	UDP 514, ou TLS sur TCP 6514	RFC 5424, RFC 5426, RFC 5425	UDP : aucune. TLS : chiffrement et authentification du serveur

De quoi avez-vous besoin avant de commencer ?

La configuration est légère, mais cinq éléments déterminent sa réussite dès le premier jour.

• Un réseau de gestion. Placez les interfaces de gestion des équipements sur un VLAN de gestion. Un VLAN est un réseau logique distinct qui fonctionne sur les mêmes commutateurs physiques. Cela permet de séparer le trafic SNMP, TFTP et syslog du trafic des invités et du personnel.
• Un hôte de gestion fixe. Utilisez un ordinateur portable ou un hôte de saut sur ce VLAN avec une adresse statique. Les équipements envoient des journaux et des interruptions à une adresse fixe, de sorte qu'une adresse changeante interrompt silencieusement la collecte.
• Identifiants. Créez un utilisateur SNMPv3 avec authentification et confidentialité là où votre firmware le prend en charge. Si vous devez utiliser v2c, modifiez la chaîne de communauté par défaut et limitez-la à un accès en lecture seule à partir de votre hôte de gestion.
• Synchronisation de l'heure. Dirigez chaque équipement vers la même source NTP. Sans cela, les horodatages syslog de différents équipements ne peuvent pas être alignés lors d'une panne.
• Règles de pare-feu. Autorisez le port UDP 161 de votre hôte vers les équipements. Autorisez les ports UDP 162 et UDP 514 des équipements vers votre hôte. Le TFTP nécessite le port UDP 69 plus les ports suivants décrits ci-dessous.

Comment le modèle de gestion de votre fournisseur modifie le plan

Les plateformes gérées par le cloud conservent la configuration dans leur cloud, de sorte que la sauvegarde TFTP y est moins importante. Le SNMP et le syslog vous offrent toujours une vue locale du comportement des équipements.

Fournisseur	Modèle de gestion	Où réside la configuration	Ce qu'un outil local fait encore
Cisco Meraki	Tableau de bord cloud Meraki	Tableau de bord Meraki	Reçoit le syslog, interroge le SNMP lorsqu'il est activé dans le tableau de bord
HPE Aruba	CLI sur les commutateurs AOS-S et AOS-CX, ou Aruba Central	Sur le commutateur, miroitée dans Central le cas échéant	Interrogation SNMP, syslog, copie de configuration TFTP
Ruckus	CLI sur les commutateurs ICX, ou contrôleur Ruckus et gestion cloud	Sur le commutateur	Interrogation SNMP, syslog, copie de configuration TFTP
Juniper Mist	Cloud Mist gérant les commutateurs Junos EX	Cloud Mist	Interrogation SNMP et syslog depuis Junos
Ubiquiti UniFi	Application UniFi Network	Sauvegardes de l'application UniFi Network	Syslog distant, SNMP lorsqu'il est activé
Cambium	cnMaestro, ou gestion locale sur les commutateurs cnMatrix	cnMaestro ou le commutateur	Interrogation SNMP et syslog
Extreme	CLI sur Switch Engine (EXOS), ou ExtremeCloud IQ	Sur le commutateur	Interrogation SNMP, syslog, copie de configuration TFTP
Fortinet	GUI ou CLI FortiGate et FortiSwitch, ou FortiManager	Sur l'équipement	Interrogation SNMP, syslog, sauvegarde de configuration TFTP depuis la CLI

Les commutateurs Cisco Catalyst fonctionnant sous IOS ou IOS XE n'entrent pas dans le modèle Meraki. Leur configuration réside sur le commutateur et se copie sur un serveur TFTP depuis la CLI.

Comment configurer l'interrogation SNMP, les sauvegardes TFTP et un récepteur syslog ?

Le Netforge Network Multi-Tool intègre un client SNMP, un serveur TFTP et un récepteur syslog. Une seule installation sur votre hôte de gestion couvre les trois étapes ci-dessous. Les mêmes étapes fonctionnent avec des outils autonomes si vous les utilisez déjà.

Étape 1 : exécuter un SNMP walk sans navigateur de MIB

Vous n'avez pas besoin d'un navigateur de MIB pour obtenir des réponses utiles. Une MIB traduit uniquement des chiffres en noms. Parcourez la bonne branche numérique et les valeurs parlent d'elles-mêmes. Commencez par ces quatre branches standard :

• 1.3.6.1.2.1.1 (groupe système). Renvoie sysDescr (chaîne du modèle et du firmware), sysUpTime, sysName et sysLocation. Défini dans la RFC 3418.
• 1.3.6.1.2.1.2.2 (ifTable). Renvoie les descriptions d'interface, le statut opérationnel, les erreurs et les compteurs de trafic 32 bits. Défini dans la RFC 2863.
• 1.3.6.1.2.1.31.1.1 (ifXTable). Renvoie les compteurs haute capacité 64 bits et les alias d'interface que vous avez saisis comme descriptions de port.
• 1.3.6.1.4.1 (branche entreprise privée). Renvoie des valeurs spécifiques au fournisseur sous les numéros d'entreprise attribués par l'IANA. Le numéro de Cisco, par exemple, est le 9.

Dans Netforge, saisissez l'adresse de l'appareil, vos identifiants SNMP et un OID de départ, puis lancez un walk. Chaque résultat s'affiche sous la forme d'un OID, d'un type et d'une valeur. Une STRING sous sysDescr se lit en texte brut. Une valeur Timeticks sous sysUpTime compte les centièmes de seconde depuis le démarrage de l'agent.

Si vous préférez la ligne de commande, le snmpwalk de Net-SNMP fait le même travail :

snmpwalk -v3 -l authPriv -u <user> -a SHA -A <auth-passphrase> -x AES -X <priv-passphrase> <switch-address> 1.3.6.1.2.1.1

Commencez par un périmètre restreint. Un walk depuis la racine sur un grand commutateur central peut renvoyer des dizaines de milliers de lignes et expirer. Parcourez une seule branche, trouvez ce dont vous avez besoin, puis utilisez un get pour cet OID unique la fois suivante.

Lisez le trafic à partir des compteurs 64 bits. Un compteur d'octets 32 bits redémarre à zéro à environ 4,29 milliards d'octets. Sur une liaison à 1 Gbps à plein débit, ce redémarrage se produit environ toutes les 34 secondes. La RFC 2863 exige des compteurs d'octets 64 bits sur les interfaces plus rapides que 20 Mbps pour cette raison précise.

Étape 2 : exécuter un serveur TFTP pour les sauvegardes de configuration des commutateurs

Démarrez le serveur TFTP dans Netforge, choisissez un dossier racine et autorisez l'écriture de fichiers. Envoyez ensuite la configuration de l'appareil vers votre hôte. La commande varie selon le fournisseur :

• Cisco IOS et IOS XE : copy running-config tftp: demande l'adresse du serveur et un nom de fichier.
• HPE Aruba AOS-S : copy running-config tftp suivi de l'adresse du serveur et du nom de fichier.
• Extreme Switch Engine (EXOS) : tftp put avec l'adresse du serveur et les détails du fichier.
• Fortinet FortiGate : execute backup config tftp suivi d'un nom de fichier et de l'adresse du serveur.

Consultez le guide de référence des commandes de votre fournisseur pour connaître la syntaxe exacte de votre version de firmware. Nommez chaque fichier avec le nom d'hôte et la date, afin qu'une restauration ne récupère jamais la configuration du mauvais commutateur. Déplacez les sauvegardes terminées du serveur TFTP vers un stockage sécurisé.

Les chargements de firmware fonctionnent de la même manière en sens inverse. Les images de taille supérieure à environ 32 Mo peuvent échouer sur les serveurs limités à des blocs de 512 octets. Le compteur de blocs 16 bits s'épuise à cette taille. L'option blocksize de la RFC 2348 lève cette limite lorsque les deux extrémités la prennent en charge.

Arrêtez le serveur TFTP lorsque vous avez terminé. Le protocole TFTP ne disposant d'aucune authentification, un serveur actif en permanence constitue un point d'accès libre aux fichiers sur votre réseau de gestion.

Étape 3 : exécuter un récepteur de syslog et de traps SNMP

Pointez l'hôte de journalisation de chaque appareil vers l'adresse de votre hôte de gestion. Définissez ensuite un seuil de gravité. Les gravités syslog vont de 0 (Urgence) à 7 (Débogage). L'envoi de 0 à 5 (Notification) permet de capturer les pannes et les changements d'état sans saturer le récepteur. Ne passez un appareil en mode Débogage que pendant la recherche d'une panne spécifique.

Ajoutez votre hôte en tant que destination de trap SNMP avec les mêmes identifiants que vous utilisez pour le polling. Activez les notifications standard de SNMPv2-MIB et IF-MIB : coldStart, linkDown, linkUp et authenticationFailure. Utilisez les informs au lieu des traps là où l'appareil les prend en charge. Un inform attend un accusé de réception, de sorte qu'une alerte perdue est renvoyée.

Le récepteur syslog Netforge affiche les journaux et les traps dans le même outil que vous utilisez pour le polling et le transfert de fichiers. Cela évite d'avoir à exécuter Kiwi Syslog Server aux côtés de Tftpd64 et d'un navigateur MIB distinct.

Scénario concret : un hôtel de 200 chambres restaure un commutateur défaillant

Situation. Un hôtel de 200 chambres exploitait 14 commutateurs : deux de cœur et 12 d'accès. Un incident électrique a détruit un commutateur d'accès desservant deux étages de clients. Aucune sauvegarde de configuration n'existait. L'ingénieur a reconstruit les VLAN et les paramètres de port à partir de photos et de mémoire, ce qui a pris une journée de travail complète.

Ce qui a été fait. Le responsable informatique a configuré un hôte de gestion avec TFTP, SNMP et syslog dans un seul outil. Chaque configuration de commutateur était transférée vers le TFTP chaque semaine et avant chaque modification. Un SNMP walk mensuel du groupe système enregistrait chaque modèle et version de firmware. Les 14 commutateurs envoyaient syslog et traps au même récepteur.

Résultat. Lorsqu'un deuxième commutateur d'accès est tombé en panne, le modèle de remplacement reçu était identique. L'ingénieur a chargé la configuration de la semaine précédente à partir du serveur TFTP. Les clients de ces étages ont été reconnectés à Internet en moins d'une heure, contre une journée entière la première fois. Les équipes hôtelières qui gèrent des réseaux WiFi pour les clients à grande échelle font face au même schéma dans chaque établissement : voir Hôtels.

Comment vérifier que cela fonctionne ?

Testez chaque protocole par rapport à un résultat connu avant de vous y fier.

• SNMP. Obtenez sysUpTime deux fois, à une minute d'intervalle. La valeur doit augmenter d'environ 6 000 centièmes de seconde. Confirmez que sysName correspond au nom d'hôte attendu.
• Sauvegarde TFTP. Ouvrez le fichier enregistré et lisez-le. Une configuration Cisco IOS se termine par la ligne end, de sorte qu'un fichier tronqué se repère immédiatement. Comparez la taille du fichier avec la sauvegarde précédente.
• Restauration TFTP. Restaurez une sauvegarde sur un commutateur de rechange ou de laboratoire. Une sauvegarde que vous n'avez jamais restaurée est un espoir, pas un plan de reprise d'activité.
• Syslog et traps. Fermez et réactivez un port inutilisé. Vous devriez voir un trap linkDown et un trap linkUp, ainsi que les lignes syslog correspondantes. Leurs horodatages doivent concorder à la seconde près si NTP fonctionne.
• Couverture. Confirmez que chaque appareil de votre inventaire a envoyé au moins une ligne de journal au cours des dernières 24 heures. Un appareil silencieux est généralement un appareil mal configuré.

Qu'est-ce qui ne va pas et comment y remédier ?

La plupart des pannes proviennent des pare-feu, des identifiants ou des interfaces sources. Ce tableau associe les symptômes courants à leurs solutions.

Symptôme	Cause probable	Solution
La requête SNMP expire	La liste d'accès de l'appareil bloque votre hôte, ou le port UDP 161 est filtré	Ajoutez votre hôte à la liste d'accès SNMP et ouvrez le port UDP 161
SNMPv3 échoue avec une erreur d'authentification	Incompatibilité de l'algorithme d'authentification ou de confidentialité	Alignez les paramètres SHA et AES des deux côtés, puis saisissez à nouveau les phrases secrètes
Le Walk renvoie les données système mais rien sous la branche d'entreprise	Le contrôle d'accès basé sur la vue (RFC 3415) limite ce que votre utilisateur peut voir	Élargissez la vue SNMP pour votre utilisateur en lecture seule
Le transfert TFTP démarre, puis se bloque	Le pare-feu ou le NAT bloque le port de suivi depuis lequel le serveur répond	Autorisez la plage de ports de transfert du serveur, ou gardez le TFTP au sein d'un seul VLAN
Écriture TFTP refusée	Le serveur ne créera pas de nouveaux fichiers, ou les autorisations de dossier bloquent les écritures	Autorisez la création de fichiers dans le serveur et vérifiez les autorisations de dossier
Échec du firmware volumineux en cours de route	Limite de bloc de 512 octets atteinte à environ 32 Mo	Activez l'option de taille de bloc, ou utilisez le téléversement SCP ou HTTP du fournisseur
Aucun syslog n'arrive	L'appareil envoie depuis une interface différente, ou le pare-feu de l'hôte bloque le port UDP 514	Définissez l'interface source de journalisation et autorisez le flux UDP 514 entrant
Les journaux apparaissent dans le désordre	Les appareils ne sont pas synchronisés sur le NTP	Configurez la même source NTP sur chaque appareil
Les graphiques d'interface restent plats ou font des bonds	Bouclage du compteur 32 bits	Interrogez ifHCInOctets et ifHCOutOctets à partir d'ifXTable

Combien cela coûte-t-il, et qu'obtenez-vous en retour ?

Le coût réel de la gestion des appareils réside dans le temps d'ingénierie et le temps d'indisponibilité, et non dans le logiciel. Comparez les trois approches courantes sur les axes qui régissent ces deux aspects.

Approche	Outils à installer	Protocoles couverts	Conçu pour	Convient à
Logiciel gratuit à usage unique	Trois : Tftpd64, Kiwi Syslog Server, un navigateur MIB	TFTP et syslog, interruptions SNMP via Kiwi, interrogation SNMP via le navigateur	Tâches ponctuelles, un outil par tâche	Un ingénieur maîtrisant déjà ces trois outils
Multi-outil léger (Netforge Network Multi-Tool)	Un	SNMP get et walk, serveur TFTP, récepteur de syslog et d'interruptions	Interrogation à la demande, transferts et journaux en temps réel	Petits parcs, intervention terrain pour MSP, sites uniques
NMS complet	Une plateforme plus une base de données et un serveur	SNMP, syslog, interruptions, plus découverte, graphiques et routage des alertes	Surveillance continue et historique des tendances à long terme	Parcs de grande taille ou multisites avec équipes d'astreinte

Quand avez-vous besoin d'un NMS complet ?

Un outil léger lit l'état lorsque vous le demandez. Un NMS complet surveille en continu et mémorise. Passez à un NMS complet lorsque l'une de ces conditions est remplie :

• Vous avez besoin de semaines d'historique d'interface pour la planification des capacités.
• Les alertes doivent appeler un ingénieur d'astreinte à 3 heures du matin sans que personne n'ait à surveiller un écran.
• Votre parc s'étend sur des dizaines de sites, comme des gares sur un réseau ferroviaire. Voir Trains.
• Les auditeurs attendent des rapports automatisés plutôt que des fichiers que vous exportez manuellement.

En dessous de cette limite, un NMS complet ajoute un serveur, une base de données et de la maintenance pour des fonctionnalités que vous n'utiliserez pas.

Scénario concret : une chaîne de vente au détail de 40 magasins trouve des défauts de liaison cachés

Situation. Un MSP gérait une chaîne de 40 magasins. Chaque magasin était équipé d'un pare-feu FortiGate et de deux commutateurs. Les équipes des magasins signalaient que les terminaux de paiement se déconnectaient plusieurs fois par semaine. Les visites des ingénieurs ne donnaient rien, car le problème avait disparu avant que quelqu'un n'arrive. Ce qui a été fait. L'MSP a dirigé les syslog et les traps SNMP des 120 appareils vers un seul récepteur via le VPN de site à site existant. Chaque commutateur a envoyé des traps linkDown et linkUp. L'équipe a vérifié le récepteur quotidiennement pendant deux semaines.

Résultat. Les journaux ont montré des battements de liaison répétés sur les ports de liaison montante de trois magasins, correspondant aux heures d'interruption signalées. Le personnel du magasin a remplacé trois cordons de brassage défectueux sous guidage à distance. L'MSP a mis fin aux interventions réactives pour ce défaut, et les trois magasins n'ont plus signalé de déconnexions de terminaux. En savoir plus sur la gestion des réseaux dans le secteur du commerce de détail : Retail.

Conformité et traitement des données

Les journaux d'appareils ont un poids important en matière de conformité. La norme PCI-DSS exige la modification des paramètres d'usine par défaut, et la version 3.2.1 mentionne explicitement les chaînes de communauté SNMP. L'exigence 10.5.1 de la version 4.0 de la norme PCI-DSS impose de conserver les journaux d'audit pendant au moins 12 mois, dont trois mois immédiatement disponibles. Le contrôle 8.15 de l'Annexe A de la norme ISO 27001 couvre la journalisation.

Les lignes de syslog peuvent contenir des adresses IP et MAC, qui peuvent être considérées comme des données personnelles en vertu du GDPR. Définissez une période de rétention et limitez l'accès en lecture aux fichiers du récepteur. Cela est particulièrement important dans les environnements réglementés : voir Healthcare.

La place de Purple

Purple est indépendante du matériel. Notre solution Guest WiFi fonctionne comme un overlay cloud sur Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti, UniFi, Cambium, Extreme Networks et Fortinet, sur plus de 80 000 sites actifs (données Purple). Des commutateurs sains et bien documentés en aval facilitent l'exécution de chaque service overlay. Le Netforge Network Multi-Tool offre à vos ingénieurs la visibilité au niveau des appareils pour garantir cet état.

Questions fréquemment posées

Ai-je besoin d'un NMS complet pour gérer quelques commutateurs ?

Non. Pour un site unique ou un petit parc, l'interrogation SNMP, les sauvegardes TFTP et un récepteur syslog couvrent l'essentiel de la gestion quotidienne. Un NMS complet justifie son coût lorsque vous avez besoin d'une surveillance continue, de plusieurs semaines d'historique de tendances, d'alertes automatiques pour les ingénieurs d'astreinte ou d'une gestion sur des dizaines de sites. En deçà de ce seuil, il ajoute un serveur, une base de données et des frais de maintenance pour des fonctionnalités que vous n'utiliserez pas.

Puis-je effectuer un SNMP walk sans navigateur de MIB ?

Oui. Une MIB ne fait que traduire les OID numériques en noms, vous pouvez donc parcourir directement les branches numériques. Commencez par 1.3.6.1.2.1.1 pour le modèle, le firmware et la durée d'activité, et par 1.3.6.1.2.1.31.1.1 pour les noms d'interfaces et les compteurs de trafic 64 bits. Le Netforge Network Multi-Tool exécute des requêtes get et walk à partir d'un OID de départ. L'outil snmpwalk de Net-SNMP fait de même depuis la ligne de commande.

Le protocole TFTP est-il sûr pour sauvegarder les configurations des commutateurs ?

Oui, si vous le confinez. Le protocole TFTP ne dispose d'aucune authentification ni d'aucun chiffrement selon la RFC 1350, de sorte que toute personne sur le trajet peut lire une configuration en transit. Exécutez le serveur TFTP uniquement sur un VLAN de gestion et uniquement pendant une sauvegarde ou une restauration. Déplacez les fichiers finalisés vers un espace de stockage protégé. Lorsque votre fournisseur prend en charge SCP ou SFTP, utilisez-les pour les sauvegardes planifiées.

Est-ce que cela fonctionnera avec mon matériel Cisco, Aruba ou Fortinet existant ?

Oui. SNMP, TFTP et syslog sont des standards ouverts pris en charge par Cisco IOS, HPE Aruba AOS-S et AOS-CX, Ruckus ICX, Extreme Switch Engine et Fortinet FortiGate. Les plateformes gérées dans le cloud telles que Cisco Meraki, Juniper Mist et Ubiquiti UniFi conservent la configuration dans leur cloud. Sur ces dernières, vous utilisez SNMP et syslog localement et sauvegardez la configuration via la propre plateforme du fournisseur.

Un seul outil peut-il remplacer Tftpd64 et Kiwi Syslog Server ?

Oui. L'outil Netforge Network Multi-Tool inclut un serveur TFTP, un récepteur de requêtes syslog et de traps SNMP, ainsi que les fonctions SNMP get et walk au sein d'une seule application. Cela remplace Tftpd64 pour les transferts de fichiers et Kiwi Syslog Server pour les logs, et élimine le besoin d'un navigateur MIB distinct. Si vous avez besoin d'un stockage de logs à long terme ou d'un routage automatisé des alertes, associez-le à une plateforme de logs ou à un NMS complet.

Les logs d'équipements sont-ils soumis aux normes PCI-DSS et GDPR ?

Oui, dans la plupart des établissements. L'exigence 10.5.1 de la version 4.0 de la norme PCI-DSS impose de conserver les journaux d'audit pendant au moins 12 mois, dont trois mois immédiatement disponibles, pour les systèmes concernés. Les lignes syslog peuvent inclure des adresses IP et MAC, qui peuvent constituer des données personnelles en vertu du GDPR. Définissez une période de rétention, limitez l'accès aux fichiers de logs et documentez ces deux aspects.

Combien de temps prend la configuration pour un petit parc d'équipements ?

La majeure partie de l'effort réside dans la configuration côté équipement plutôt que dans l'outil lui-même. Définir un hôte de journalisation, une destination de trap et un utilisateur SNMPv3 prend quelques minutes par commutateur depuis la CLI. Pour un site de 14 commutateurs, prévoyez une après-midi, y compris les règles de pare-feu et la vérification. Les travaux sur le NTP et le VLAN de gestion, s'ils ne sont pas déjà en place, prennent généralement plus de temps que la configuration de l'outil.