show tech-support : bien utiliser la commande de dépannage Cisco

show tech-support est probablement la commande de diagnostic la plus complète disponible sur un équipement Cisco — et souvent la première chose qu’un support technique (TAC) vous demandera de fournir en cas d’incident.

Ce que fait réellement la commande

show tech-support exécute automatiquement une longue série d’autres commandes show (configuration, interfaces, processus, mémoire, journaux, tables de routage, versions…) et concatène l’ensemble dans une seule sortie. C’est un instantané complet de l’état du système à un moment donné, sans avoir à taper une dizaine de commandes séparées à la main pendant que la situation se dégrade.

Pourquoi ne pas l’exécuter à l’aveugle

La sortie peut atteindre plusieurs milliers de lignes et prendre du temps à générer, en particulier sur un équipement déjà sous forte charge — ce qui peut aggraver temporairement une situation de saturation CPU. Sur un équipement en production en pleine incident, mieux vaut cibler les commandes utiles plutôt que lancer un show tech-support complet sans réflexion préalable, surtout sur un switch d’accès déjà surchargé.

Rediriger la sortie vers un fichier

Plutôt que de faire défiler des milliers de lignes dans un terminal, il est plus pratique de rediriger directement vers un serveur :

Switch# show tech-support | redirect tftp://192.168.1.50/switch-diag.txt

D’autres protocoles sont possibles selon la configuration de l’équipement (FTP, HTTP, ou stockage local sur la mémoire flash du switch), pratique lorsqu’aucun serveur TFTP n’est disponible sur le moment.

Cibler un sous-ensemble utile

Pour un problème précis, il est souvent plus rapide et moins impactant d’utiliser des variantes ciblées :

• show tech-support ospf — pour un problème de routage OSPF
• show tech-support ethernet-switching — pour un problème de commutation

Ces versions filtrées sont plus rapides à générer et plus faciles à analyser, tout en couvrant l’essentiel du contexte utile au diagnostic sans noyer l’information pertinente dans des sections sans rapport avec l’incident en cours.

Bonnes pratiques avant d’ouvrir un dossier support

• Notez l’heure exacte de l’incident, pour croiser avec les horodatages des journaux inclus dans la sortie.
• Conservez systématiquement une copie horodatée : elle sert aussi de référence pour comparer un état « avant/après » en cas de changement de configuration ultérieur.
• Vérifiez que la commande inclut bien la configuration active (show running-config) — c’est souvent la première chose analysée par un support technique.
• Joignez également une description précise du symptôme observé : la sortie brute seule ne remplace jamais un contexte humain clair sur ce qui a été constaté et à quel moment.

Automatiser la collecte sur plusieurs équipements

Sur un parc de plusieurs dizaines de switches, exécuter cette commande manuellement partout devient vite fastidieux. Des outils d’automatisation réseau (scripts, Ansible avec les modules Cisco) permettent de programmer une collecte régulière ou déclenchée par une alerte de supervision, avec archivage centralisé — un vrai gain de temps lors d’un futur incident.

Commandes utiles : application et supervision

Préparer une collecte de logs exploitable (à faire avant l’incident)

Switch(config)# service timestamps log datetime msec
Switch(config)# logging buffered 16384
Switch(config)# logging host 192.168.1.50

Supervision (au moment du diagnostic)

Switch# show tech-support
Switch# show logging
Switch# show processes cpu sorted
Switch# show memory statistics
Switch# show interfaces counters errors

Procédure étape par étape

Comment se comporter, concrètement, le jour où un équipement fait des siennes et où vous devez collecter des informations utiles — sans aggraver la situation.

Étape 1 — Respirer, puis regarder l’ampleur du problème

Un seul port capricieux ne justifie pas un show tech-support complet. Un switch qui devient injoignable, en revanche, oui. Adaptez l’huile de coude à la taille du problème.

Étape 2 — Préparer un point de collecte

Si un serveur TFTP est déjà en place, tant mieux. Sinon, un petit serveur TFTP temporaire sur un poste du réseau suffit largement pour l’occasion.

Étape 3 — Lancer la collecte ciblée en premier

Switch# show tech-support ethernet-switching | redirect tftp://192.168.1.50/switch-diag.txt

Commencez toujours par la version ciblée sur le domaine du problème — plus rapide, plus lisible, et moins susceptible d’aggraver un switch déjà à bout de souffle.

Étape 4 — Si nécessaire, la version complète

Switch# show tech-support | redirect tftp://192.168.1.50/switch-diag-complet.txt

Réservée aux cas où le problème ne se laisse pas facilement catégoriser — ou quand le support Cisco (ou nous) vous la demande explicitement.

Étape 5 — Noter le contexte humain

Heure précise de l’incident, ce qui a été observé, ce qui a changé récemment (mise à jour, câblage, nouvel équipement branché). Un fichier de logs sans contexte, c’est un peu comme une radio sans savoir où ça fait mal.

Étape 6 — Archiver proprement

Renommez le fichier avec la date et le nom de l’équipement (SW-BUREAU-01_2026-08-30.txt, pas nouveau(3)_final_v2.txt) et conservez-le dans un dossier dédié aux incidents. Le jour où le même problème revient six mois plus tard, vous serez ravi de le retrouver en deux clics.

Étape 7 — En cas de dossier support ouvert

Joignez le fichier tel quel, avec votre description du contexte. Un technicien qui reçoit une sortie brute sans explication passe généralement dix minutes à deviner ce qui s’est passé — dix minutes que vous pouvez lui épargner en trois phrases.

Besoin d’aide pour diagnostiquer un incident réseau ? Contactez-nous.