Inicio / Notas técnicas / Recuperación de acceso de emergencia

Bloqueado fuera de su router: recuperación de emergencia cuando Telnet, SSH y Console fallan todos

Telnet está caído, SSH se niega, y ahora Console tampoco responde — eso no es una contraseña olvidada, es un dispositivo al que no se puede llegar por ningún canal de gestión mientras se supone que sigue transportando tráfico. Esta es la forma de averiguar por qué, capa por capa, la ruta de recuperación en el peor de los casos, y qué asegurar después para que no vuelva a pasar.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué "ni siquiera me pide contraseña" es un problema distinto de "olvidé la contraseña"

Una contraseña olvidada todavía le da un prompt de inicio de sesión. Aquí se trata del caso en que ni siquiera llega hasta ahí, en ningún canal, mientras el dispositivo está en funcionamiento.

Si el inicio de sesión remoto por Telnet o STelnet falla, la primera reacción estándar es probar con Console en su lugar, y revisar la configuración relacionada con Telnet/STelnet que pudiera ser la causa. Esta nota trata sobre lo que queda cuando Console también falla: en ese punto no es posible ninguna operación de línea de comandos por ningún canal normal, y lo que hace falta es una clasificación de emergencia capa por capa, no una corrección de configuración.

Si al menos un canal todavía le muestra un prompt de usuario/contraseña, no necesita esta nota — consulte en su lugar Recuperación de contraseña del router, que cubre las tres rutas de recuperación habituales.

Lea esto antes de hacer cualquier otra cosa
  • Cada paso siguiente supone que el tráfico de negocio del dispositivo ya está interrumpido, de modo que actuar no causará más daño del que ya se ha producido.
  • Si el servicio en realidad NO está interrumpido — el dispositivo sigue transportando tráfico, simplemente no puede gestionarlo — no realice ninguno de los pasos siguientes. En su lugar, recopile la información de la falla y contacte de inmediato a su distribuidor o a la línea de soporte postventa de Huawei.

Baje por la pila capa por capa, no de forma dispersa

Seis capas, desde la conexión física hasta la CPU que se supone debe responder a su inicio de sesión — revíselas en orden, de la menos disruptiva a la más disruptiva.

Las tres primeras capas son comprobaciones puramente de hardware y del lado del terminal, que nunca tocan la configuración del dispositivo ni interrumpen nada más. Las tres siguientes son causas lógicas que explican específicamente por qué Telnet/SSH puede fallar mientras Console sigue funcionando. El peor caso — una falla de la placa de control principal — está al final porque es el único que cuesta una acción que afecta el servicio, encima de la interrupción que ya tiene.

No Channel Answers — Work Down, Least to Most Disruptive Layer 1 · Physical Port & Console Cablecheck the cable and the Console port itself for damage or a bad seat Layer 2 · Power Supply Systemswitch on · Input LED · Output/STATUS LED · swap the power module Layer 3 · Serial Baud Rate / Terminal Parametersdefault 9600bps, 8 data bits, 1 stop bit, no parity, no flow control Layer 4 · VTY Exhaustion (Telnet/SSH only)from Console: display users, free a stale VTY, or raise maximum-vty Layer 5 · ACL Misconfiguration on VTYfrom Console: display acl, check the inbound ACL bound to user-interface vty Layer 6 · CPU Overload Starves the Management Planefrom Console: display cpu-usage, identify and stop the offending task Worst Case · MPU Fault → Reseat / Replace, Then Device Resetonly after every layer above checks out clean, and business is already down If a layer checks out clean, move down to the next one -- don't jump straight to the hardware layer. Layers 4-6 need Console access to check -- they only apply while Console still works and only Telnet/SSH fail.

Las etiquetas del diagrama se mantienen en inglés por claridad técnica.

Recorriendo cada capa

Las tres primeras capas no cuestan nada extra si resultan estar bien — las últimas tres le dicen exactamente por qué específicamente Telnet/SSH es el que falla.

Capa 1 — Puerto físico y cable de Console

  1. Inspeccione el cable de Console y el puerto de Console mismo en busca de daños visibles o mala conexión antes de suponer que algo más profundo está mal.

Capa 2 — Sistema de alimentación

Si todos los indicadores del dispositivo están apagados y los ventiladores no giran, aquí es donde hay que mirar primero, antes de tocar cualquier otra cosa.

  1. Compruebe que el interruptor del dispositivo o del módulo de alimentación esté realmente encendido — con varios módulos de alimentación, confirme que al menos uno esté encendido y suministrando energía con normalidad.
  2. Compruebe el indicador Input del módulo de alimentación. Si no está encendido, el lado de entrada es anómalo — haga que un electricista inspeccione la alimentación de la sala/rack/gabinete y la restablezca.
  3. Compruebe el indicador Output o STATUS del módulo de alimentación. Si no está encendido, el lado de salida es anómalo — intente reemplazar el módulo de alimentación.

Capa 3 — Velocidad en baudios y parámetros del terminal

Esta es, con diferencia, la falsa alarma más común — un desajuste de parámetros del terminal se ve exactamente igual que un puerto Console muerto.

  1. Compruebe si los parámetros de comunicación del terminal serie realmente coinciden con los del puerto Console del dispositivo. Por defecto, el puerto Console usa 9600bps, 8 bits de datos, 1 bit de parada, sin paridad y sin control de flujo — si el terminal está configurado de otra forma, corrija el terminal, no el dispositivo.

Capa 4 — Agotamiento de VTY (Telnet/SSH se niega, Console sigue bien)

Esta capa y las dos siguientes solo tienen sentido una vez confirmado que Console funciona — son comprobaciones estándar de VRP para saber por qué específicamente los canales remotos se niegan, ejecutadas desde esa sesión de Console.

  1. Desde Console, ejecute display users para ver todas las líneas VTY actualmente ocupadas. Si todas las líneas VTY configuradas ya muestran una sesión — incluidas sesiones antiguas e inactivas que nadie cerró — eso solo basta para que cada nuevo intento de Telnet/SSH falle directamente, sin ningún error informativo en el lado del cliente.
  2. Elimine a la fuerza una sesión obsoleta con free user-interface vty, o, si la carga de gestión realmente necesita más sesiones simultáneas, aumente el límite con 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

Capa 5 — ACL mal configurada que bloquea el acceso a VTY

  1. Compruebe si hay una ACL de entrada vinculada a las líneas VTY, y, desde Console, muestre las reglas de esa ACL para ver si su propia dirección de origen de gestión ha sido excluida — a menudo por una regla pensada para otra subred, o que quedó de un cambio anterior.
  2. Ajuste la regla problemática, o desvincule temporalmente la ACL de las líneas VTY desde Console mientras se corrige la regla adecuadamente.
<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

Capa 6 — La sobrecarga de CPU deja sin recursos al plano de gestión

  1. Desde Console, ejecute display cpu-usage. Si la utilización se ha mantenido cerca del 100% durante un período sostenido, el proceso que maneja el inicio de sesión Telnet/SSH puede simplemente no ser programado a tiempo para responder, lo que desde fuera se ve exactamente como si el servicio estuviera caído.
  2. Identifique en esa misma salida la tarea que consume la CPU, y deténgala o baje su prioridad desde Console si es seguro hacerlo; si no hay nada que se pueda detener con seguridad, un reload controlado durante la ventana de interrupción ya declarada es el recurso de respaldo.
<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

Peor caso — Falla de la placa de control principal y reinicio del dispositivo

Solo se llega aquí una vez descartadas tanto la alimentación como la comunicación serie — y solo bajo la condición previa de servicio ya interrumpido del aviso anterior.

  1. Una vez descartadas la alimentación y la comunicación serie, la placa de control principal es la causa probable restante. En un dispositivo con dos placas de control principales, intente reasentarlas; con una sola placa, reemplácela por un repuesto.
  2. Si eso todavía no lo resuelve, reinicie el dispositivo apagándolo y volviéndolo a encender.

Controlar el impacto en el negocio mientras trabaja

El orden de las seis capas anteriores no es arbitrario — va de un impacto nulo en el negocio a uno máximo, y ese orden es en sí mismo la estrategia de control del impacto.

  1. Confirme primero, con honestidad, si el negocio está realmente interrumpido. Si no lo está, la acción correcta es detenerse, recopilar la información de la falla y escalar — no seguir trabajando en las capas siguientes.
  2. Trabaje primero las capas 1-3: son puramente diagnósticas sobre el cable, la ruta de alimentación y el lado del terminal, y ninguna arriesga a empeorar la interrupción.
  3. Las capas 4-6 solo aplican una vez confirmado el acceso a Console, y las propias comprobaciones (comandos display) no conllevan riesgo — solo las correcciones (liberar una sesión, cambiar una ACL, detener una tarea) tocan algo en producción, e incluso esas son cambios pequeños y puntuales.
  4. El reasentado/reemplazo de la MPU y un reinicio completo del dispositivo están al final a propósito: son las únicas acciones aquí que pueden causar por sí mismas una interrupción, así que solo entran en juego después de descartar todo lo menos disruptivo y de confirmar la condición previa de servicio ya interrumpido.

Endurecimiento: asegurarse de que esto no vuelva a pasar de la misma manera

Cada uno de estos se remonta directamente a una capa anterior — cada uno cierra una forma específica en que este incidente podría repetirse.

  1. Configure una ruta de gestión de respaldo genuinamente independiente — una segunda conexión de Console a través de un servidor de terminales, o un enlace de gestión fuera de banda — para que una sola falla (un cable defectuoso, una tabla VTY saturada) no pueda tumbar todos los canales a la vez como esta vez.
  2. Limite y monitoree los inicios de sesión VTY: ajuste idle-timeout para que las sesiones obsoletas realmente caduquen, mantenga una ACL solo de gestión vinculada a las líneas VTY, y vigile qué tan cerca está del límite de VTY antes de que se convierta en una emergencia.
  3. Mantenga copias de seguridad de configuración regulares y fuera del dispositivo — si un futuro incidente llega a necesitar el tipo de recuperación con configuración vacía cubierto en nuestra nota de Recuperación de contraseña del router, tener algo listo para restaurar convierte una reconstrucción larga en una subida rápida.
  4. Documente in situ, junto al dispositivo, los parámetros de serie reales del sitio y la asignación de pines del cable de Console — para que la comprobación de baudios de la capa 3 tome treinta segundos durante un incidente real en lugar de convertirse en su propia investigación.
<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

Cinco cosas que hacen perder tiempo durante un bloqueo real

Estos son los detalles que convierten una clasificación de quince minutos en una hora de conjeturas.

Las dos advertencias que hay que leer antes de tocar nada

SÍNTOMAUn ingeniero empieza de inmediato a seguir los pasos de recuperación, sin comprobar antes si el dispositivo realmente sigue transportando tráfico.

CAUSACada paso de esta nota supone que el negocio ya está interrumpido, por lo que actuar no puede empeorar las cosas. Si el negocio en realidad está bien y solo se ve afectado el canal de gestión, las mismas acciones conllevan un riesgo real sin ningún beneficio a cambio.

SOLUCIÓNConfirme con honestidad el impacto en el negocio antes de hacer cualquier otra cosa. Si el tráfico todavía fluye, deténgase, recopile la información de la falla y contacte a su distribuidor o a la línea de soporte postventa de Huawei — no inicie en absoluto la clasificación capa por capa.

Un desajuste de velocidad en baudios se ve exactamente igual que un puerto Console muerto

SÍNTOMAEl cable de Console está conectado, el dispositivo está claramente encendido y funcionando, pero el terminal no muestra nada en absoluto, o muestra caracteres ilegibles.

CAUSALos parámetros de comunicación del emulador de terminal no coinciden con los valores predeterminados del puerto Console del dispositivo (9600bps, 8 bits de datos, 1 bit de parada, sin paridad, sin control de flujo) — un desajuste puramente superficial que parece exactamente una falla de hardware hasta que se comprueba.

SOLUCIÓNCorrija la configuración del terminal a 9600/8/1/ninguna/ninguno y vuelva a intentarlo antes de escalar a una investigación de alimentación o hardware.

Que todos los indicadores estén apagados no siempre es culpa de la alimentación

SÍNTOMANingún indicador encendido en el dispositivo, los ventiladores no giran — el instinto es culpar a la alimentación eléctrica del edificio.

CAUSAHay tres posibilidades distintas y ordenadas: el interruptor del dispositivo o módulo de alimentación simplemente no está encendido; el indicador Input del módulo está apagado, lo que significa que la propia entrada de alimentación es anómala; o el indicador Output/STATUS está apagado mientras Input está bien, lo que significa que el módulo en sí ha fallado aunque la energía llega correctamente.

SOLUCIÓNCompruebe en ese orden — interruptor, luego LED de Input, luego LED de Output/STATUS — ya que cada uno apunta a una solución distinta: encender el interruptor, llamar a un electricista para la alimentación del edificio, o cambiar el propio módulo de alimentación.

Una tabla VTY llena deniega el inicio de sesión sin ningún mensaje de error útil

SÍNTOMALas conexiones Telnet o SSH son rechazadas o simplemente se quedan colgadas, mientras que Console sigue iniciando sesión bien y el dispositivo por lo demás se ve saludable.

CAUSATodas las líneas VTY del dispositivo (5 por defecto, VTY 0-4) ya están ocupadas — a menudo por sesiones que nadie cerró explícitamente, simplemente dejadas inactivas — por lo que no queda ninguna línea disponible para que se conecte una nueva sesión remota.

SOLUCIÓNDesde Console, ejecute display users para confirmar que todas las líneas están ocupadas, elimine a la fuerza una obsoleta con free user-interface vty, y considere ajustar idle-timeout para que esto no vuelva a acumularse silenciosamente.

Reasentar la MPU es un último recurso, no un primer intento

SÍNTOMATodo lo anterior ha resultado estar bien — cable, alimentación, parámetros serie, VTY, ACL, CPU — y todavía no hay forma de entrar por ningún canal.

CAUSADescartadas todas las demás capas, la propia placa de control principal es la causa probable restante — pero es una conclusión a la que se llega por eliminación, no una primera suposición, precisamente porque reasentarla o reemplazarla es en sí misma una acción que afecta el servicio.

SOLUCIÓNIntente esto solo después de agotar las capas 1 a 6, y solo bajo la condición previa confirmada de servicio ya interrumpido — reasiente en un dispositivo con doble MPU, reemplace en uno con una sola MPU, y recurra a un reinicio completo de apagado/encendido si eso todavía no lo resuelve.

Diseños de soluciones relacionadas

Red de sucursales bancarias y financieras: sucursales segmentadas, SD-WAN de área amplia, redundancia de doble enlace y auditoría lista para cumplimientoDonde este tipo de escenario de bloqueo total conlleva las apuestas más altas — sucursales reguladas donde cada minuto de acceso de gestión perdido importa. Solución de red de campus empresarial: cableada + Wi-Fi que simplemente funciona — oficinas, hoteles, escuelasEl borde de campus del día a día donde estas mismas seis capas explican la mayoría de las caídas misteriosas que al final no resultan ser un cable.

Cinco preguntas que surgen constantemente

Sacadas directamente del terreno — las que vale la pena tener respondidas de antemano.

¿En qué se diferencia esto de simplemente olvidar mi contraseña?

Una contraseña olvidada todavía le muestra un prompt de inicio de sesión en al menos un canal — eso es un problema de credenciales con tres rutas de recuperación oficiales, cubiertas en nuestra nota Recuperación de contraseña del router. Esta nota es para cuando ningún canal da ningún prompt, lo que apunta a la conexión física, la configuración del terminal, o los propios recursos del dispositivo, no a una contraseña.

El dispositivo parece seguir transportando tráfico con normalidad, simplemente no puedo gestionarlo — ¿debería igualmente hacer todo esto?

No. Ese es exactamente el caso que cubre la advertencia del principio: si el negocio en realidad no está interrumpido, no realice los pasos de recuperación. En su lugar, recopile la información de la falla y contacte a su distribuidor o a la línea de soporte postventa de Huawei — interrumpir tráfico que funciona para perseguir un problema del plano de gestión no está justificado.

Console está conectado y las luces del dispositivo están encendidas, pero el terminal no muestra nada — ¿qué es lo primero que hay que comprobar?

Los parámetros de comunicación del terminal serie, antes que nada. Un desajuste ahí — el terminal no configurado con los valores predeterminados del dispositivo (9600bps, 8 bits de datos, 1 bit de parada, sin paridad, sin control de flujo) — es la razón más común por la que un puerto Console perfectamente sano parece muerto.

Console funciona bien pero Telnet/SSH sigue negándose a conectar — ¿es esta nota o Recuperación de contraseña del router?

Esta nota — específicamente las capas 4 a 6 (agotamiento de VTY, mala configuración de ACL, sobrecarga de CPU). Ninguno de esos es un problema de credenciales, así que los tres métodos de Recuperación de contraseña del router no aplican; la solución está del lado de VTY/ACL/CPU, ejecutada desde la sesión de Console que todavía tiene.

¿Cuál es el primerísimo cambio de configuración que hay que hacer justo después de este tipo de recuperación?

Respalde de inmediato la configuración actual fuera del dispositivo, antes que nada — luego recorra la lista de endurecimiento anterior: una ruta de gestión de respaldo independiente, límites y monitoreo de VTY más estrictos, y parámetros de serie documentados in situ.

Límites honestos de esta nota

Límites honestos de esta nota

Las capas 1, 2 y el paso de peor caso sobre la placa de control principal siguen la guía oficial de Huawei para el manejo de emergencias de un dispositivo al que no se puede acceder por ningún canal — reproducida aquí exactamente como se documenta, incluida la advertencia de impacto en el negocio al principio. Las capas 4 a 6 (agotamiento de VTY, mala configuración de ACL, sobrecarga de CPU) son práctica de diagnóstico de VRP de Huawei estándar y generalmente aplicable para explicar por qué específicamente Telnet/SSH puede fallar mientras Console sigue funcionando, en lugar de provenir de ese mismo capítulo de manejo de emergencias, cuyo alcance es deliberadamente centrado en el hardware. Esta nota supone routers AR basados en VRP y acceso físico a Console como punto de entrada para cada paso que no sea el reinicio de hardware.

¿Ahora mismo en medio de un bloqueo?

Cuéntenos en qué capa está atascado y si el negocio realmente está interrumpido, y le ayudamos a completar el resto de forma segura.

WhatsApp con un ingeniero →

Lectura relacionada

Recuperación de contraseña del router: comparativa de los métodos Console, Telnet y BootROMLa nota complementaria para el caso mucho más común — una contraseña olvidada, con al menos un canal que todavía da un prompt de inicio de sesión. ¿El túnel VPN IPSec no se establece? Un diagrama de resolución de problemas y las causas más frecuentesMisma disciplina aplicada a una falla distinta — recorra las etapas en orden antes de cambiar la configuración en cualquiera de los extremos. Seguridad del borde de Internet empresarialEl diseño de la puerta de enlace en torno a estos mismos routers de borde para los que se escribe esta nota — zonificación y política de firewall, junto con las preocupaciones del plano de gestión anteriores.
Solo usamos cookies para analítica anónima — sin publicidad ni rastreo entre sitios.Política de privacidad