Sur les équipements réseau Cisco fonctionnant sous IOS, tout administrateur est un jour confronté à ce grand classique : vous activez une commande de débogage pour analyser un dysfonctionnement, le trafic circule, mais aucun message n’apparaît à l’écran. Ce comportement est tout à fait normal. Par défaut, le système redirige les événements et les flux de journalisation uniquement vers le port console physique, laissant les lignes virtuelles VTY (Telnet et SSH) totalement muettes.
Pourquoi les traces ne s’affichent-elles pas en SSH ?
Le sous-système de journalisation de Cisco IOS sépare distinctement les flux selon leur destination : la console (logging console), la mémoire tampon interne (logging buffered), un serveur syslog distant (logging host) et les terminaux distants (logging monitor). Pour préserver la bande passante de gestion et éviter de bloquer une session à distance avec un déluge de messages, le moniteur distant est souvent inactif ou configuré avec un niveau de criticité trop haut pour afficher les messages de debug.
De la même manière qu’il est courant de devoir déboguer avec dmesg pour capturer les messages du noyau système, il est indispensable sous Cisco d’indiquer explicitement au routeur ou au commutateur que votre session VTY souhaite recevoir le flux de débogage en direct.
Étape 1 : Activer la réception sur la session courante
La commande indispensable pour recevoir les logs sur votre connexion Telnet ou SSH s’exécute en mode utilisateur privilégié (mode enable) :
Router# terminal monitor
Notez bien que cette commande n’est pas une commande de configuration globale : vous ne devez pas entrer dans configure terminal. Elle ne s’applique qu’à votre session interactive active. Si vous fermez votre client SSH ou si vous devez déconnecter une session en ligne de commande, le réglage est automatiquement désactivé pour la connexion suivante.
Étape 2 : Vérifier les niveaux de logging globaux
Si après avoir exécuté terminal monitor les traces ne s’affichent toujours pas, la configuration globale de l’équipement filtre probablement les messages inférieurs à un certain niveau de sévérité. Passez en mode configuration pour autoriser le niveau de débogage (niveau 7) sur le moniteur :
Router(config)# logging on
Router(config)# logging monitor debugging
Router(config)# exit
Pour analyser les paquets réseau avec précision, pensez également à vérifier que l’horodatage des logs est activé en millisecondes avec la directive service timestamps debug datetime msec.
Lancer un debug ciblé et éviter le crash
Les commandes de debug permettent d’analyser le comportement interne des protocoles en temps réel. Par exemple :
- debug ip ospf events : pour analyser les transitions d’état du protocole OSPF.
- debug ip dhcp server packet : pour tracer les requêtes et offres DHCP traitées par l’équipement.
- debug radius : pour diagnostiquer les échecs d’authentification AAA.
Avertissement : Ne tapez jamais la commande debug all sur un équipement en production. Le processeur du routeur sera immédiatement saturé à 100 % par la génération des messages console, rendant l’équipement injoignable jusqu’à son plantage complet. Si vous perdez totalement le contrôle physique ou l’accès distant suite à une mauvaise manipulation, la seule issue reste souvent de redémarrer le matériel ou de devoir procéder à un reset de mot de passe Cisco pour reprendre la main.
Privilégiez toujours des filtres stricts. Lorsque c’est possible, utilisez le débogage conditionnel (par exemple debug condition interface gigabitethernet 0/1) avant d’activer votre trace.
Arrêter les traces proprement
Dès que votre capture d’informations est terminée, coupez immédiatement l’ensemble des processus de debug pour libérer le processeur et assainir la sortie terminal :
Router# undebug all (ou son raccourci : u all)
Désactivez ensuite la réception des flux sur votre session SSH :
Router# terminal no monitor
Cette rigueur évite de polluer l’affichage lors de vos interventions ultérieures et protège la stabilité globale de l’infrastructure réseau.
