Révision rapide : Support technique – CCNA

Ce que vous devez vraiment savoir

Le support technique dans le CCNA ne signifie pas seulement connaître des commandes. Cela signifie savoir aborder un problème réseau avec méthode, en évitant de modifier des configurations au hasard ou de sauter immédiatement à la conclusion la plus pratique.

Dans un réseau réel, un problème peut dépendre des câbles, ports, VLAN, adresses IP, DHCP, DNS, routage, ACL, firewalls, services, configurations incorrectes ou changements récents. Pour cette raison, le troubleshooting doit être ordonné : identifier le problème, collecter les informations, formuler des hypothèses, tester, appliquer une solution, vérifier et documenter.

Le point central est celui-ci : un bon technicien ne devine pas. Il observe, vérifie et procède par élimination.

Concepts clés

• Troubleshooting : processus structuré pour identifier et résoudre un problème.
• Identification du problème : comprendre ce qui ne fonctionne pas et quel impact cela a.
• Collecte d'informations : obtenir des données depuis utilisateurs, dispositifs, logs et outils.
• Hypothèse : cause possible du problème.
• Test : vérification contrôlée d'une hypothèse.
• Vérification : confirmation que la solution a résolu le problème.
• Documentation : enregistrement de la cause, solution et modifications appliquées.
• Approche par couches : analyse par couches OSI/TCP-IP.
• Baseline : état normal du réseau utilisé comme référence.
• Change management : gestion contrôlée des changements.
• Escalation : implication de teams ou niveaux supérieurs lorsque nécessaire.
• Communication : mise à jour claire vers utilisateurs et stakeholders.

Différences à ne pas confondre

Concept	Signification principale
Symptôme	Effet visible du problème
Cause racine	Raison réelle du problème
Hypothèse	Explication possible à vérifier
Test	Vérification contrôlée
Workaround	Solution temporaire
Fix	Correction stable
Vérification	Confirmation du rétablissement
Documentation	Enregistrement du travail effectué
Escalation	Passage au support supérieur
Baseline	Comportement normal attendu

Méthode de troubleshooting

Une méthode simple de troubleshooting peut suivre ces étapes :

1. identifier le problème ;
2. collecter les informations ;
3. établir une théorie sur la cause probable ;
4. tester la théorie ;
5. créer un plan d'action ;
6. appliquer la solution ;
7. vérifier le fonctionnement ;
8. documenter problème, cause et solution.

Cette méthode évite les interventions aléatoires et réduit le risque d'aggraver la situation.

Dans CCNA, vous devez raisonner de manière technique mais ordonnée : comprendre d'abord, modifier ensuite.

Identifier le problème

Avant de résoudre, vous devez bien comprendre ce qui ne fonctionne pas.

Questions utiles :

• qui est concerné ?
• combien d'utilisateurs sont touchés ?
• le problème concerne-t-il un seul host ou plusieurs ?
• le problème est-il local ou distant ?
• quand a-t-il commencé ?
• est-il arrivé après un changement ?
• le problème est-il continu ou intermittent ?
• quels services ne fonctionnent pas ?
• qu'est-ce qui fonctionne encore ?

Exemple : “Internet ne fonctionne pas” est trop générique. Vous devez comprendre s'il s'agit d'un problème DNS, gateway, Wi-Fi, DHCP, routage, firewall ou seulement d'application.

Collecte d'informations

La collecte d'informations inclut les données provenant de :

• utilisateurs ;
• tickets ;
• logs ;
• configurations ;
• commandes show ;
• monitoring ;
• Syslog ;
• SNMP ;
• ping et traceroute ;
• outils physiques ;
• documentation réseau ;
• changements récents.

Une erreur courante consiste à se fier uniquement à la description initiale. Les utilisateurs décrivent le symptôme, pas toujours la cause technique.

Approche par couches

Une approche très utile consiste à raisonner par couches.

Exemples :

• Layer 1 : câbles, ports, alimentation, signal.
• Layer 2 : VLAN, adresses MAC, trunks, STP.
• Layer 3 : IP, gateway, routage.
• Layer 4 : ports TCP/UDP, ACL, firewall.
• Layer 7 : DNS, applications, services.

Si un host ne communique pas, contrôler d'abord Layer 1 et Layer 2 peut éviter de perdre du temps sur le routage ou DNS lorsque le problème est un câble débranché.

Top-down, bottom-up et divide-and-conquer

Il existe différentes manières d'aborder le troubleshooting.

Bottom-up : partir du Layer 1 et monter. Utile lorsque vous suspectez des problèmes physiques ou de connectivité de base.

Top-down : partir de l'application et descendre. Utile lorsque le problème concerne un service spécifique.

Divide-and-conquer : partir d'un point intermédiaire, souvent Layer 3, puis monter ou descendre selon le résultat.

Pour CCNA, vous devez savoir qu'il n'existe pas une seule méthode toujours valable. Le choix dépend du scénario.

Baseline

Une baseline décrit le comportement normal du réseau.

Elle peut inclure :

• utilisation normale de la bande passante ;
• latence moyenne ;
• configurations standard ;
• ports normalement actifs ;
• chemins de routage attendus ;
• CPU et mémoire des dispositifs ;
• logs normaux ;
• nombre attendu d'utilisateurs ou dispositifs.

Sans baseline, il est plus difficile de comprendre si une valeur est normale ou anormale.

Exemple : une latence de 80 ms peut être normale sur un lien géographique, mais anormale dans une LAN.

Change management

Beaucoup de problèmes naissent après un changement.

Exemples :

• nouvelle VLAN ;
• modification ACL ;
• mise à jour firmware ;
• changement gateway ;
• nouvelle configuration DHCP ;
• remplacement switch ;
• modification trunk ;
• mise à jour driver ;
• changement DNS.

Le change management sert à planifier, approuver, documenter et vérifier les changements.

Dans le troubleshooting, une question fondamentale est : “Qu'est-ce qui a changé récemment ?”

Commandes show

Les commandes show sont fondamentales sur les dispositifs Cisco.

Exemples utiles :

• show running-config ;
• show startup-config ;
• show ip interface brief ;
• show interfaces ;
• show vlan brief ;
• show interfaces trunk ;
• show mac address-table ;
• show ip route ;
• show arp ;
• show cdp neighbors ;
• show lldp neighbors ;
• show access-lists ;
• show logging.

Ces commandes permettent d'observer l'état du dispositif sans modifier la configuration.

Debug

Les commandes debug montrent des informations détaillées en temps réel.

Elles sont puissantes mais doivent être utilisées avec attention.

Risques :

• forte consommation CPU ;
• output excessif ;
• impact sur dispositifs en production ;
• difficulté de lecture ;
• risque de dégrader les performances.

Pour CCNA, vous devez retenir que debug peut être utile, mais doit être utilisé seulement lorsque nécessaire et avec prudence, de préférence dans des fenêtres contrôlées ou environnements de laboratoire.

Ping

Ping utilise ICMP pour vérifier la joignabilité.

Il peut aider à tester :

• loopback local ;
• IP du host ;
• default gateway ;
• destination dans la même LAN ;
• destination distante ;
• perte de paquets ;
• latence.

Séquence utile :

• ping 127.0.0.1 ;
• ping sa propre IP ;
• ping gateway ;
• ping IP distante ;
• ping nom DNS.

Cette séquence aide à comprendre où la communication s'interrompt.

Traceroute

Traceroute, ou tracert sous Windows, montre le chemin vers une destination.

Il est utile pour comprendre :

• où le trafic s'arrête ;
• quels routeurs sont traversés ;
• si le chemin est cohérent ;
• si le problème est proche ou distant ;
• s'il manque une route ;
• si un firewall ou routeur ne répond pas.

Attention : certains dispositifs ne répondent pas aux paquets utilisés par traceroute, donc un astérisque ne signifie pas toujours une panne.

Syslog

Syslog permet de collecter les messages de log des dispositifs.

Il peut montrer :

• interfaces up/down ;
• erreurs ;
• connexions réussies ou échouées ;
• modifications de configuration ;
• événements de routage ;
• violations ACL ;
• problèmes hardware ;
• événements de sécurité.

Centraliser Syslog est utile parce que les logs locaux peuvent être perdus après redémarrage ou limités par la mémoire du dispositif.

SNMP

SNMP permet de surveiller les dispositifs réseau.

Il peut collecter des données comme :

• état des interfaces ;
• utilisation de bande passante ;
• CPU ;
• mémoire ;
• erreurs ;
• disponibilité ;
• température ;
• événements via traps.

SNMP est utile pour le monitoring proactif. Vous n'avez pas besoin d'attendre que l'utilisateur signale le problème : le système peut alerter lorsqu'une interface passe down ou qu'un seuil est dépassé.

Testeur de câble

Un testeur de câble vérifie les problèmes physiques sur les câbles.

Il peut aider à identifier :

• câble interrompu ;
• paires inversées ;
• terminaison incorrecte ;
• longueur excessive ;
• court-circuit ;
• problèmes de continuité ;
• câblage non conforme.

Si un port ne monte pas ou présente beaucoup d'erreurs, un testeur physique peut être plus utile que n'importe quelle commande logicielle.

Problèmes Layer 1

Problèmes courants Layer 1 :

• câble débranché ;
• câble endommagé ;
• port éteint ;
• interface administratively down ;
• module SFP incompatible ;
• fibre sale ;
• TX/RX inversés ;
• PoE insuffisant ;
• vitesse ou duplex incorrects ;
• distance maximale dépassée ;
• erreurs CRC.

Symptômes typiques :

• interface down ;
• lien intermittent ;
• beaucoup d'erreurs ;
• throughput faible ;
• perte de paquets.

Problèmes Layer 2

Problèmes courants Layer 2 :

• VLAN incorrecte ;
• trunk non configuré ;
• VLAN non autorisée sur trunk ;
• native VLAN mismatch ;
• table MAC incorrecte ou instable ;
• STP blocking ;
• port security violation ;
• DHCP snooping mal configuré ;
• DAI qui bloque ARP ;
• boucle Layer 2.

Commandes utiles :

• show vlan brief ;
• show interfaces trunk ;
• show mac address-table ;
• show spanning-tree ;
• show port-security ;
• show interfaces status.

Problèmes Layer 3

Problèmes courants Layer 3 :

• IP incorrecte ;
• subnet mask incorrect ;
• gateway manquant ;
• route manquante ;
• route de retour manquante ;
• default route incorrecte ;
• OSPF non adjacent ;
• ACL qui bloque le trafic ;
• NAT non configuré correctement.

Commandes utiles :

• show ip interface brief ;
• show ip route ;
• show arp ;
• ping ;
• traceroute ;
• show access-lists ;
• show ip protocols.

Troubleshooting DHCP

Problèmes DHCP courants :

• serveur DHCP non joignable ;
• pool épuisé ;
• scope incorrect ;
• gateway distribué incorrect ;
• DNS distribué incorrect ;
• ip helper-address manquant ;
• VLAN incorrecte ;
• trunk incorrect ;
• DHCP snooping qui bloque les réponses ;
• client avec ancien lease.

Symptômes :

• host sans IP ;
• adresse APIPA ;
• IP dans le mauvais subnet ;
• gateway ou DNS incorrects.

Troubleshooting DNS

Problèmes DNS courants :

• serveur DNS incorrect ;
• enregistrement manquant ;
• enregistrement incorrect ;
• cache DNS obsolète ;
• firewall qui bloque DNS ;
• serveur DNS non joignable ;
• DHCP qui distribue un DNS incorrect.

Symptôme classique :

• vous atteignez une IP ;
• vous n'atteignez pas un nom.

Dans ce cas, le routage peut fonctionner parfaitement : le problème est la résolution des noms.

Troubleshooting routage

Problèmes de routage courants :

• route absente ;
• default route manquante ;
• route de retour absente ;
• protocole dynamique non fonctionnel ;
• métrique ou administrative distance inattendue ;
• interface down ;
• subnet non annoncé ;
• ACL ou firewall qui bloque le trafic.

Dans le troubleshooting end-to-end, vous devez toujours considérer à la fois le chemin aller et le chemin retour.

ACL et firewalls

ACL et firewalls peuvent bloquer le trafic même si IP et routage sont corrects.

Contrôlez :

• ordre des règles ;
• direction ;
• interface ;
• deny implicite ;
• ports TCP/UDP ;
• adresses source et destination ;
• trafic de retour ;
• logs de blocage.

Une erreur typique est de permettre le trafic dans une direction mais d'oublier le retour ou un service nécessaire comme DNS.

Documentation

La documentation fait partie du troubleshooting.

Elle doit inclure :

• symptôme ;
• impact ;
• cause racine ;
• tests effectués ;
• modifications appliquées ;
• solution finale ;
• éventuel workaround ;
• temps ;
• personnes impliquées ;
• commandes utilisées ;
• recommandations futures.

Documenter évite que le même problème soit résolu depuis zéro à chaque fois.

Communication avec les utilisateurs

Le support technique exige aussi de la communication.

Bonnes pratiques :

• poser des questions claires ;
• ne pas accuser l'utilisateur ;
• expliquer simplement ;
• mettre à jour sur l'état ;
• indiquer des délais réalistes ;
• confirmer la résolution ;
• communiquer les impacts éventuels ;
• documenter dans le ticket.

Un bon technicien n'est pas seulement celui qui résout, mais celui qui maintient la clarté pendant le problème.

Escalation

L'escalation sert lorsque le problème dépasse les compétences, permissions ou responsabilités du premier niveau.

Exemples :

• problème sur équipements core ;
• panne provider ;
• incident de sécurité ;
• configuration non autorisée ;
• problème complexe de routage ;
• besoin d'accès administratif ;
• impact sur beaucoup d'utilisateurs.

Escalader ne signifie pas échouer : cela signifie impliquer le bon niveau.

Vérification finale

Après avoir appliqué une solution, vous devez vérifier.

Exemples :

• ping fonctionne ;
• DNS résout ;
• utilisateurs confirment ;
• interface stable ;
• erreurs n'augmentent pas ;
• service joignable ;
• logs propres ;
• routage correct ;
• ACL ne bloque pas le trafic légitime.

La vérification est importante parce qu'un problème peut sembler résolu mais réapparaître après quelques minutes.

Erreurs fréquentes dans les quiz

• Modifier la configuration sans collecter d'informations.
• Sauter Layer 1.
• Confondre symptôme et cause racine.
• Penser que DNS est toujours un problème Internet.
• Oublier la route de retour.
• Ignorer les changements récents.
• Utiliser debug sans prudence.
• Oublier le deny implicite dans les ACL.
• Ne pas documenter la solution.
• Ne pas vérifier après le fix.
• Ne pas communiquer avec l'utilisateur.
• Ne pas escalader lorsque nécessaire.

Mini scénario d'examen

Un utilisateur signale que “Internet ne fonctionne pas”. Le PC a une IP correcte et réussit à faire ping au gateway et à 8.8.8.8, mais ne parvient pas à ouvrir des sites web par nom.

Le problème le plus probable est DNS, pas la connectivité Internet générale. Le technicien devrait vérifier le serveur DNS configuré, la résolution avec nslookup et la configuration DHCP.

Autre scénario : après une modification d'ACL, beaucoup d'utilisateurs ne parviennent plus à atteindre un service. Le technicien doit contrôler ordre des règles, direction, interface, deny implicite et logs.

Mini checklist avant le quiz

Avant de commencer le quiz, vous devriez savoir expliquer :

• les principales phases du troubleshooting ;
• pourquoi il faut bien identifier le problème ;
• ce que signifie cause racine ;
• comment utiliser une approche par couches ;
• quand utiliser ping et traceroute ;
• à quoi servent show et debug ;
• pourquoi Syslog et SNMP sont utiles ;
• quand utiliser un testeur de câble ;
• comment distinguer les problèmes Layer 1, 2 et 3 ;
• comment reconnaître les problèmes DHCP et DNS ;
• pourquoi ACL et firewalls peuvent bloquer du trafic correct ;
• pourquoi documentation et communication font partie du support technique.