Accueil / Notes techniques / Récupération de connexion d'urgence

Verrouillé hors de votre routeur : récupération d'urgence quand Telnet, SSH et Console échouent tous

Telnet est en panne, SSH refuse, et maintenant Console ne répond plus non plus — ce n'est pas un mot de passe oublié, c'est un appareil injoignable par aucun canal de gestion alors qu'il est censé transporter du trafic. Voici la méthode couche par couche pour comprendre pourquoi, le pire scénario de récupération, et ce qu'il faut verrouiller ensuite pour que cela ne se reproduise pas.

Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026

Pourquoi « ça ne me propose même pas de me connecter » est un problème différent de « j'ai oublié le mot de passe »

Un mot de passe oublié vous donne quand même une invite de connexion. Il s'agit ici du cas où vous n'allez même pas jusque-là, sur aucun canal, alors que l'appareil est en fonctionnement.

Si la connexion distante Telnet ou STelnet échoue, le premier réflexe standard est d'essayer Console à la place, et de vérifier la configuration liée à Telnet/STelnet qui pourrait être en cause. Cette note porte sur ce qu'il reste à faire quand Console échoue aussi : à ce stade, aucune opération en ligne de commande n'est possible par un canal normal, et ce qu'il faut, c'est un triage d'urgence couche par couche plutôt qu'une correction de configuration.

Si au moins un canal vous propose encore une invite nom d'utilisateur/mot de passe, vous n'avez pas besoin de cette note — consultez plutôt Récupération de mot de passe routeur, qui couvre les trois voies de récupération classiques.

À lire avant de faire quoi que ce soit d'autre

Chaque étape ci-dessous suppose que le trafic métier de l'appareil est déjà interrompu, de sorte qu'agir ne causera pas de dommage supplémentaire par rapport à ce qui s'est déjà produit.
Si le service n'est PAS réellement interrompu — l'appareil transporte toujours du trafic, vous ne pouvez simplement pas le gérer — n'effectuez aucune des étapes ci-dessous. Recueillez plutôt les informations sur la panne et contactez rapidement votre revendeur ou l'assistance après-vente Huawei.

Descendez la pile couche par couche, pas en tous sens

Six couches, de la connexion physique jusqu'au CPU censé répondre à votre connexion — vérifiez-les dans l'ordre, de la moins perturbatrice à la plus perturbatrice.

Les trois premières couches sont de pures vérifications matérielles et côté terminal, qui ne touchent jamais à la configuration de l'appareil ni n'interrompent quoi que ce soit de plus. Les trois suivantes sont des causes logiques qui expliquent spécifiquement pourquoi Telnet/SSH peut échouer alors que Console fonctionne encore. Le pire cas — une panne de la carte de contrôle principale — se trouve tout en bas car c'est le seul qui coûte une action impactant le service en plus de la panne déjà en cours.

Les légendes du schéma restent en anglais pour la clarté technique.

Parcourir chaque couche

Les trois premières couches ne coûtent rien de plus si elles se révèlent normales — les trois dernières indiquent précisément pourquoi c'est spécifiquement Telnet/SSH qui échoue.

Couche 1 — Port physique et câble Console

Inspectez le câble Console et le port Console lui-même pour détecter tout dommage visible ou un mauvais contact avant de supposer un problème plus profond.

Couche 2 — Système d'alimentation

Si tous les voyants de l'appareil sont éteints et que les ventilateurs ne tournent pas, c'est ici qu'il faut regarder en premier, avant de toucher à quoi que ce soit d'autre.

Vérifiez que l'interrupteur de l'appareil ou du module d'alimentation est bien activé — avec plusieurs modules d'alimentation, assurez-vous qu'au moins un est activé et alimente normalement.
Vérifiez le voyant Input du module d'alimentation. S'il n'est pas allumé, le côté entrée est anormal — faites inspecter par un électricien l'alimentation de la salle/du rack/de l'armoire et la rétablir.
Vérifiez le voyant Output ou STATUS du module d'alimentation. S'il n'est pas allumé, le côté sortie est anormal — essayez de remplacer le module d'alimentation.

Couche 3 — Débit série et paramètres du terminal

C'est de loin la fausse alerte la plus courante — une incompatibilité de paramètres du terminal ressemble exactement à un port Console mort.

Vérifiez si les paramètres de communication du terminal série correspondent réellement à ceux du port Console de l'appareil. Par défaut, le port Console utilise 9600 bps, 8 bits de données, 1 bit d'arrêt, aucune parité et aucun contrôle de flux — si le terminal est configuré différemment, corrigez le terminal, pas l'appareil.

Couche 4 — Épuisement des VTY (Telnet/SSH refuse, Console fonctionne toujours)

Cette couche et les deux suivantes n'ont de sens qu'une fois Console confirmé fonctionnel — ce sont des vérifications VRP standard pour comprendre pourquoi les canaux distants refusent spécifiquement, exécutées depuis cette session Console.

Depuis Console, exécutez display users pour voir toutes les lignes VTY actuellement occupées. Si toutes les lignes VTY configurées affichent déjà une session — y compris d'anciennes sessions inactives que personne n'a fermées — cela suffit à lui seul à faire échouer d'emblée chaque nouvelle tentative Telnet/SSH, sans erreur informative côté client.
Effacez de force une session obsolète avec free user-interface vty, ou, si la charge de gestion nécessite réellement plus de sessions simultanées, augmentez le plafond avec user-interface maximum-vty.

<Huawei> display users
 User-Intf  Delay     Type  Network Address    AuthenStatus   AuthorcmdFlag
  129 VTY 0  02:14:10  TEL   10.20.4.11         pass
  130 VTY 1  00:41:02  TEL   10.20.4.34         pass
  131 VTY 2  05:02:55  TEL   10.20.4.9          pass
  132 VTY 3  01:10:00  TEL   10.20.4.61         pass
  133 VTY 4  00:03:12  TEL   10.20.4.7          pass
// all 5 VTY lines (0-4) already occupied -- no line left for a new session

<Huawei> free user-interface vty 0
// force-clears the stale session on VTY 0

<Huawei> system-view
[Huawei] user-interface maximum-vty 15
// raises the ceiling above the default of 5 if the workload genuinely needs it

Couche 5 — Mauvaise configuration ACL bloquant l'accès VTY

Vérifiez si une ACL entrante est liée aux lignes VTY, et, depuis Console, affichez les règles de cette ACL pour voir si votre propre adresse source de gestion a été exclue — souvent à cause d'une règle destinée à un autre sous-réseau, ou restante d'un changement passé.
Ajustez la règle fautive, ou déliez temporairement l'ACL des lignes VTY depuis Console pendant que la règle est correctement corrigée.

<Huawei> display current-configuration configuration user-interface
user-interface vty 0 4
 acl 3001 inbound
[Huawei] display acl 3001
Advanced ACL 3001, 1 rule
 rule 5 permit ip source 10.20.4.0 0.0.0.255
// your management source address may not be in this permitted range

<Huawei> system-view
[Huawei] user-interface vty 0 4
[Huawei-ui-vty0-4] undo acl inbound
// temporarily unbind the ACL from the VTY lines while the rule is fixed

Couche 6 — La surcharge CPU affame le plan de gestion

Depuis Console, exécutez display cpu-usage. Si l'utilisation reste bloquée près de 100 % pendant une période prolongée, le processus gérant la connexion Telnet/SSH peut simplement ne pas être ordonnancé à temps pour répondre, ce qui, vu de l'extérieur, ressemble exactement à un service en panne.
Identifiez la tâche consommant le CPU dans cette même sortie, et arrêtez-la ou déprioritisez-la depuis Console si cela peut être fait sans risque ; si rien ne peut être arrêté en toute sécurité, un rechargement contrôlé pendant la fenêtre de panne déjà déclarée est la solution de repli.

<Huawei> display cpu-usage
CPU Usage Stat. Cycle: 60 (Second)
CPU Usage            : 98% Max: 99%
CPU Usage Stat. Time  : 2026-07-19  09:41:20
CPU utilization for five seconds: 98%: one minute: 97%: five minutes: 95%
// pinned near 100% for a sustained period -- the VTY/SSH task may not be scheduled in time to respond

Pire cas — Panne de la carte de contrôle principale et réinitialisation de l'appareil

On n'y arrive qu'une fois l'alimentation et la communication série toutes deux écartées — et seulement sous la condition préalable de service déjà interrompu mentionnée dans l'avertissement ci-dessus.

Une fois l'alimentation et la communication série écartées, la carte de contrôle principale est la cause probable restante. Sur un appareil à deux cartes de contrôle principales, essayez de les réenficher ; avec une seule carte, remplacez-la par une pièce de rechange.
Si cela ne résout toujours pas le problème, réinitialisez l'appareil en l'éteignant puis en le rallumant.

Maîtriser l'impact métier pendant l'intervention

L'ordre des six couches ci-dessus n'est pas arbitraire — il va d'un impact métier nul à maximal, et cet ordonnancement est lui-même la stratégie de maîtrise de l'impact.

Confirmez d'abord, honnêtement, si le service est réellement interrompu. Si ce n'est pas le cas, la bonne action est de s'arrêter, de recueillir les informations sur la panne et d'escalader — pas de continuer à travailler les couches ci-dessous.
Traitez d'abord les couches 1 à 3 : elles sont purement diagnostiques sur le câble, le chemin d'alimentation et le côté terminal, et aucune ne risque d'aggraver la panne.
Les couches 4 à 6 ne s'appliquent qu'une fois l'accès Console confirmé, et les vérifications elles-mêmes (commandes display) ne comportent aucun risque — seules les corrections (libérer une session, modifier une ACL, arrêter une tâche) touchent à quelque chose de vivant, et même celles-ci sont de petits changements ciblés.
Le réenfichage/remplacement de la MPU et une réinitialisation complète de l'appareil sont volontairement en dernier : ce sont les seules actions ici qui peuvent elles-mêmes causer une panne, donc elles n'ont leur place qu'après que tout ce qui est moins perturbateur a été écarté et que la condition préalable de service déjà interrompu est confirmée.

Renforcement : s'assurer que cela ne se reproduise pas de la même façon

Chacun de ces points renvoie directement à une couche ci-dessus — chacun ferme une façon précise dont cet incident pourrait se reproduire.

Mettez en place une voie de gestion de secours réellement indépendante — une seconde connexion Console via un serveur de terminaux, ou une liaison de gestion hors bande — pour qu'une seule panne (un mauvais câble, une table VTY saturée) ne puisse pas faire tomber tous les canaux à la fois comme cette fois.
Limitez et surveillez les connexions VTY : ajustez idle-timeout pour que les sessions obsolètes expirent réellement, gardez une ACL réservée à la gestion liée aux lignes VTY, et surveillez à quel point vous êtes proche du plafond VTY avant que cela ne devienne une urgence.
Conservez des sauvegardes de configuration régulières et hors de l'appareil — si un futur incident nécessite le type de récupération à configuration vide décrit dans notre note Récupération de mot de passe routeur, disposer de quelque chose de prêt à restaurer transforme une longue reconstruction en un simple transfert rapide.
Documentez sur place, à côté de l'appareil, les paramètres série réels du site et le brochage du câble Console — pour que la vérification du débit de la couche 3 prenne trente secondes lors d'un incident réel au lieu de devenir sa propre enquête.

<Huawei> system-view
[Huawei] user-interface vty 0 4
[Huawei-ui-vty0-4] idle-timeout 10
[Huawei-ui-vty0-4] acl 3001 inbound
// tighter idle-timeout plus a management-only ACL bound to VTY

<Huawei> tftp 10.20.4.5 put vrpcfg.zip
// keep a regular, off-box configuration backup

Cinq choses qui font perdre du temps lors d'un verrouillage réel

Ce sont ces détails qui transforment un triage de quinze minutes en une heure de suppositions.

Les deux avertissements à lire avant de toucher à quoi que ce soit

SYMPTÔMEUn ingénieur commence immédiatement à suivre les étapes de récupération, sans vérifier au préalable si l'appareil transporte encore réellement du trafic.

CAUSEChaque étape de cette note suppose que le service est déjà interrompu, donc agir ne peut pas aggraver la situation. Si le service fonctionne réellement bien et que seul le canal de gestion est affecté, les mêmes actions comportent un risque réel sans bénéfice correspondant.

SOLUTIONConfirmez honnêtement l'impact métier avant toute autre chose. Si le trafic circule toujours, arrêtez-vous, recueillez les informations sur la panne et contactez votre revendeur ou l'assistance après-vente Huawei — ne commencez pas du tout le triage couche par couche.

Une incompatibilité de débit ressemble exactement à un port Console mort

SYMPTÔMELe câble Console est connecté, l'appareil est clairement alimenté et en fonctionnement, mais le terminal n'affiche rien du tout, ou affiche des caractères illisibles.

CAUSELes paramètres de communication de l'émulateur de terminal ne correspondent pas aux valeurs par défaut du port Console de l'appareil (9600 bps, 8 bits de données, 1 bit d'arrêt, aucune parité, aucun contrôle de flux) — une incompatibilité purement superficielle qui ressemble exactement à une panne matérielle tant qu'on ne l'a pas vérifiée.

SOLUTIONCorrigez les paramètres du terminal en 9600/8/1/aucune/aucun et réessayez avant d'escalader vers une investigation d'alimentation ou de matériel.

Tous les voyants éteints n'est pas toujours la faute de l'alimentation

SYMPTÔMEAucun voyant allumé sur l'appareil, les ventilateurs ne tournent pas — le réflexe est d'incriminer l'alimentation électrique du bâtiment.

CAUSEIl existe trois possibilités distinctes et ordonnées : l'interrupteur de l'appareil ou du module d'alimentation n'est tout simplement pas activé ; le voyant Input du module est éteint, signifiant que l'alimentation d'entrée elle-même est anormale ; ou le voyant Output/STATUS est éteint alors qu'Input est normal, signifiant que le module lui-même est en panne bien que l'alimentation arrive correctement.

SOLUTIONVérifiez dans cet ordre — interrupteur, puis voyant Input, puis voyant Output/STATUS — car chacun pointe vers une solution différente : activer l'interrupteur, appeler un électricien pour l'alimentation du bâtiment, ou remplacer le module d'alimentation lui-même.

Une table VTY pleine refuse la connexion sans message d'erreur utile

SYMPTÔMELes connexions Telnet ou SSH sont refusées ou restent simplement bloquées, tandis que Console se connecte toujours normalement et que l'appareil semble par ailleurs en bonne santé.

CAUSEToutes les lignes VTY de l'appareil (5 par défaut, VTY 0-4) sont déjà occupées — souvent par des sessions que personne n'a explicitement fermées, simplement laissées inactives — il ne reste donc aucune ligne disponible pour qu'une nouvelle session distante s'y attache.

SOLUTIONDepuis Console, exécutez display users pour confirmer que toutes les lignes sont occupées, effacez de force une session obsolète avec free user-interface vty, et envisagez d'ajuster idle-timeout pour que cela ne se reproduise pas silencieusement.

Réenficher la MPU est un dernier recours, pas un premier essai

SYMPTÔMETout ce qui précède a été vérifié et semble normal — câble, alimentation, paramètres série, VTY, ACL, CPU — et il n'y a toujours aucun moyen d'entrer par aucun canal.

CAUSEUne fois toutes les autres couches écartées, la carte de contrôle principale elle-même est la cause probable restante — mais c'est une conclusion obtenue par élimination, pas une première hypothèse, précisément parce que la réenficher ou la remplacer est elle-même une action impactant le service.

SOLUTIONNe tentez cela qu'après avoir épuisé les couches 1 à 6, et uniquement sous la condition préalable confirmée de service déjà interrompu — réenfichez sur un appareil à double MPU, remplacez sur un appareil à MPU unique, et repliez-vous sur une réinitialisation complète par extinction/rallumage si cela ne résout toujours pas le problème.

Cinq questions qui reviennent constamment

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse toute prête.

En quoi est-ce différent du simple oubli de mon mot de passe ?

Un mot de passe oublié vous montre toujours une invite de connexion sur au moins un canal — c'est un problème d'identifiants avec trois voies de récupération officielles, couvertes dans notre note Récupération de mot de passe routeur. Cette note concerne le cas où aucun canal ne donne d'invite du tout, ce qui pointe vers la connexion physique, les paramètres du terminal, ou les ressources propres de l'appareil, pas un mot de passe.

L'appareil semble toujours transporter le trafic normalement, je n'arrive juste pas à le gérer — dois-je quand même faire tout cela ?

Non. C'est exactement le cas couvert par l'avertissement en haut de page : si le service n'est pas réellement interrompu, n'effectuez pas les étapes de récupération. Recueillez plutôt les informations sur la panne et contactez votre revendeur ou l'assistance après-vente Huawei — interrompre un trafic qui fonctionne pour traquer un problème de plan de gestion n'est pas justifié.

Console est connecté et les voyants de l'appareil sont allumés, mais le terminal n'affiche rien — quelle est la toute première chose à vérifier ?

Les paramètres de communication du terminal série, avant toute autre chose. Une incompatibilité à ce niveau — le terminal non réglé sur les valeurs par défaut de l'appareil (9600 bps, 8 bits de données, 1 bit d'arrêt, aucune parité, aucun contrôle de flux) — est la raison la plus courante pour laquelle un port Console parfaitement sain semble mort.

Console fonctionne bien mais Telnet/SSH refuse toujours de se connecter — est-ce cette note ou Récupération de mot de passe routeur ?

Cette note — plus précisément les couches 4 à 6 (épuisement des VTY, mauvaise configuration ACL, surcharge CPU). Aucun de ces cas n'est un problème d'identifiants, donc les trois méthodes de Récupération de mot de passe routeur ne s'appliquent pas ; la solution se trouve du côté VTY/ACL/CPU, exécutée depuis la session Console dont vous disposez encore.

Quel est le tout premier changement de configuration à effectuer juste après ce type de récupération ?

Sauvegardez immédiatement la configuration actuelle hors de l'appareil, avant toute autre chose — puis parcourez la liste de renforcement ci-dessus : une voie de gestion de secours indépendante, des limites et une surveillance VTY plus strictes, et des paramètres série documentés sur place.

Limites honnêtes de cette note

Limites honnêtes de cette note

Les couches 1, 2 et l'étape de pire cas concernant la carte de contrôle principale suivent les directives officielles de Huawei pour le traitement d'urgence d'un appareil injoignable par aucun canal — reproduites ici exactement telles que documentées, y compris l'avertissement sur l'impact métier en haut de page. Les couches 4 à 6 (épuisement des VTY, mauvaise configuration ACL, surcharge CPU) relèvent d'une pratique de diagnostic VRP Huawei standard et généralement applicable pour comprendre pourquoi Telnet/SSH spécifiquement peut échouer alors que Console fonctionne encore, plutôt que d'être tirées de ce même chapitre de traitement d'urgence, dont la portée est délibérément centrée sur le matériel. Cette note suppose des routeurs AR basés sur VRP et un accès Console physique comme point d'entrée pour chaque étape autre que la réinitialisation matérielle.

En plein verrouillage en ce moment ?

Dites-nous à quelle couche vous êtes bloqué et si le service est réellement interrompu, et nous vous aiderons à traiter le reste en toute sécurité.

WhatsApp avec un ingénieur →