Início / Notas técnicas / Recuperação de login de emergência

Trancado para fora do seu roteador: recuperação de emergência quando Telnet, SSH e Console falham todos

O Telnet caiu, o SSH recusa, e agora o Console também não responde — isso não é uma senha esquecida, é um dispositivo que não se consegue alcançar por nenhum canal de gerenciamento enquanto ele ainda deveria estar carregando tráfego. Esta é a forma camada por camada de descobrir o porquê, o caminho de recuperação no pior cenário, e o que reforçar depois para que não aconteça de novo.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Por que "nem sequer me pede login" é um problema diferente de "esqueci a senha"

Uma senha esquecida ainda mostra um prompt de login. Aqui trata-se do caso em que você nem chega até esse ponto, em nenhum canal, enquanto o dispositivo está em funcionamento.

Se o login remoto por Telnet ou STelnet falhar, a primeira reação padrão é tentar o Console em vez disso, e verificar a configuração relacionada a Telnet/STelnet que possa estar com problema. Esta nota trata do que resta quando o Console também falha: nesse ponto, nenhuma operação de linha de comando é possível por nenhum canal normal, e o que é preciso é uma triagem de emergência camada por camada, não um ajuste de configuração.

Se pelo menos um canal ainda mostrar um prompt de usuário/senha, você não precisa desta nota — veja em vez disso Recuperação de senha do roteador, que cobre os três caminhos de recuperação comuns.

Leia isto antes de fazer qualquer outra coisa

Cada passo abaixo pressupõe que o tráfego de negócio do dispositivo já está interrompido, de modo que agir não causará dano adicional além do que já aconteceu.
Se o serviço NÃO estiver realmente interrompido — o dispositivo ainda está passando tráfego, você só não consegue gerenciá-lo — não execute nenhum dos passos abaixo. Em vez disso, colete as informações da falha e contate prontamente seu revendedor ou a linha de suporte pós-venda da Huawei.

Desça pela pilha camada por camada, não de forma dispersa

Seis camadas, da conexão física até a CPU que deveria responder ao seu login — verifique-as em ordem, da menos disruptiva para a mais disruptiva.

As três primeiras camadas são verificações puramente de hardware e do lado do terminal, que nunca tocam na configuração do dispositivo nem interrompem mais nada. As três seguintes são causas lógicas que explicam especificamente por que Telnet/SSH pode falhar enquanto o Console ainda funciona. O pior caso — uma falha na placa controladora principal — fica por último porque é o único que custa uma ação que afeta o serviço, além da interrupção que você já tem.

Os rótulos do diagrama permanecem em inglês para clareza técnica.

Percorrendo cada camada

As três primeiras camadas não custam nada a mais se estiverem bem — as três últimas dizem exatamente por que especificamente o Telnet/SSH é que está falhando.

Camada 1 — Porta física e cabo do Console

Inspecione o cabo do Console e a própria porta do Console em busca de danos visíveis ou mau contato antes de supor que algo mais profundo está errado.

Camada 2 — Sistema de alimentação

Se todos os indicadores do dispositivo estiverem apagados e as ventoinhas não estiverem girando, é aqui que se deve olhar primeiro, antes de mexer em qualquer outra coisa.

Verifique se o interruptor do dispositivo ou do módulo de alimentação está realmente ligado — com vários módulos de alimentação, confirme que pelo menos um está ligado e fornecendo energia normalmente.
Verifique o indicador Input do módulo de alimentação. Se não estiver aceso, o lado de entrada está anormal — peça a um eletricista para inspecionar a alimentação da sala/rack/gabinete e restabelecê-la.
Verifique o indicador Output ou STATUS do módulo de alimentação. Se não estiver aceso, o lado de saída está anormal — tente substituir o módulo de alimentação.

Camada 3 — Taxa de transmissão serial e parâmetros do terminal

Esse é, de longe, o alarme falso mais comum — uma incompatibilidade de parâmetros do terminal parece exatamente igual a uma porta de Console morta.

Verifique se os parâmetros de comunicação do terminal serial realmente correspondem aos da porta de Console do dispositivo. Por padrão, a porta de Console usa 9600bps, 8 bits de dados, 1 bit de parada, sem paridade e sem controle de fluxo — se o terminal estiver configurado de forma diferente, corrija o terminal, não o dispositivo.

Camada 4 — Esgotamento de VTY (Telnet/SSH recusa, o Console continua bem)

Esta camada e as duas seguintes só fazem sentido depois de confirmado que o Console funciona — são verificações padrão do VRP para saber por que especificamente os canais remotos recusam, executadas a partir dessa sessão de Console.

No Console, execute display users para ver todas as linhas VTY atualmente ocupadas. Se todas as linhas VTY configuradas já mostrarem uma sessão — incluindo sessões antigas e ociosas que ninguém fechou — isso sozinho já basta para fazer toda nova tentativa de Telnet/SSH falhar de imediato, sem nenhum erro informativo do lado do cliente.
Force o encerramento de uma sessão obsoleta com free user-interface vty, ou, se a carga de gerenciamento realmente precisar de mais sessões simultâneas, aumente o limite com 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

Camada 5 — ACL malconfigurada bloqueando o acesso ao VTY

Verifique se há uma ACL de entrada vinculada às linhas VTY e, no Console, exiba as regras dessa ACL para ver se o seu próprio endereço de origem de gerenciamento foi excluído — muitas vezes por uma regra pensada para outra sub-rede, ou deixada de uma mudança anterior.
Ajuste a regra problemática, ou desvincule temporariamente a ACL das linhas VTY pelo Console enquanto a regra é corrigida adequadamente.

<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

Camada 6 — Sobrecarga de CPU sufoca o plano de gerenciamento

No Console, execute display cpu-usage. Se a utilização ficou presa perto de 100% por um período sustentado, o processo que trata o login Telnet/SSH pode simplesmente não ser agendado a tempo de responder, o que visto de fora parece exatamente como o serviço estar fora do ar.
Identifique na mesma saída a tarefa que está consumindo a CPU, e pare-a ou reduza sua prioridade pelo Console se for seguro fazer isso; se nada puder ser parado com segurança, um reload controlado dentro da janela de interrupção já declarada é o recurso de reserva.

<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

Pior caso — Falha da placa controladora principal e reset do dispositivo

Só se chega aqui depois de descartar tanto a alimentação quanto a comunicação serial — e apenas sob a condição prévia de serviço já interrompido do aviso acima.

Descartadas a alimentação e a comunicação serial, a placa controladora principal é a causa provável restante. Em um dispositivo com duas placas controladoras principais, tente reencaixá-las; com apenas uma placa, substitua-a por uma sobressalente.
Se isso ainda não resolver, redefina o dispositivo desligando-o e ligando-o novamente.

Controlando o impacto no negócio enquanto você trabalha

A ordem das seis camadas acima não é arbitrária — vai de impacto nulo no negócio até máximo, e essa ordenação em si é a estratégia de controle de impacto.

Confirme primeiro, com honestidade, se o negócio está realmente interrompido. Se não estiver, a ação correta é parar, coletar as informações da falha e escalar — não continuar trabalhando nas camadas abaixo.
Trabalhe primeiro as camadas 1-3: são puramente diagnósticas sobre o cabo, o caminho de alimentação e o lado do terminal, e nenhuma delas arrisca piorar a interrupção.
As camadas 4-6 só se aplicam depois de confirmado o acesso ao Console, e as próprias verificações (comandos display) não têm risco — só as correções (liberar uma sessão, mudar uma ACL, parar uma tarefa) tocam em algo ativo, e mesmo essas são mudanças pequenas e pontuais.
O reencaixe/substituição da MPU e um reset completo do dispositivo ficam por último de propósito: são as únicas ações aqui que podem, por si só, causar uma interrupção, então só entram depois de descartado tudo o que é menos disruptivo e confirmada a condição prévia de serviço já interrompido.

Reforço: garantindo que isso não aconteça da mesma forma de novo

Cada um destes se liga diretamente a uma camada acima — cada um fecha uma forma específica de esse incidente se repetir.

Configure um caminho de gerenciamento de backup genuinamente independente — uma segunda conexão de Console por meio de um servidor de terminais, ou um link de gerenciamento fora de banda — para que uma única falha (um cabo ruim, uma tabela VTY saturada) não derrube todos os canais de uma vez como desta vez.
Limite e monitore os logins de VTY: ajuste o idle-timeout para que sessões obsoletas realmente expirem, mantenha uma ACL só de gerenciamento vinculada às linhas VTY, e observe o quão perto você está do limite de VTY antes que isso vire uma emergência.
Mantenha backups de configuração regulares e fora do dispositivo — se um incidente futuro precisar do tipo de recuperação com configuração vazia abordado em nossa nota de Recuperação de senha do roteador, ter algo pronto para restaurar transforma uma reconstrução longa em um upload rápido.
Documente no local, ao lado do dispositivo, os parâmetros seriais reais do site e a pinagem do cabo de Console — para que a verificação de taxa de transmissão da camada 3 leve trinta segundos durante um incidente real, em vez de virar uma investigação própria.

<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 coisas que fazem perder tempo durante um bloqueio real

São esses detalhes que transformam uma triagem de quinze minutos em uma hora de suposições.

Os dois avisos que você precisa ler antes de mexer em qualquer coisa

SINTOMAUm engenheiro começa imediatamente a seguir os passos de recuperação, sem verificar antes se o dispositivo ainda está realmente passando tráfego.

CAUSACada passo desta nota pressupõe que o negócio já está interrompido, então agir não pode piorar as coisas. Se o negócio na verdade está bem e só o canal de gerenciamento foi afetado, as mesmas ações trazem risco real sem nenhum benefício correspondente.

SOLUÇÃOConfirme com honestidade o impacto no negócio antes de fazer qualquer outra coisa. Se o tráfego ainda estiver fluindo, pare, colete as informações da falha e contate seu revendedor ou a linha de suporte pós-venda da Huawei — não comece a triagem camada por camada.

Incompatibilidade de taxa de transmissão parece exatamente igual a uma porta de Console morta

SINTOMAO cabo do Console está conectado, o dispositivo está claramente ligado e funcionando, mas o terminal não mostra nada, ou mostra caracteres embaralhados.

CAUSAOs parâmetros de comunicação do emulador de terminal não correspondem aos padrões da porta de Console do dispositivo (9600bps, 8 bits de dados, 1 bit de parada, sem paridade, sem controle de fluxo) — uma incompatibilidade puramente superficial que parece exatamente uma falha de hardware até você verificar.

SOLUÇÃOCorrija as configurações do terminal para 9600/8/1/nenhuma/nenhum e tente de novo antes de escalar para uma investigação de energia ou hardware.

Todos os indicadores apagados nem sempre é culpa da alimentação

SINTOMANenhum indicador aceso no dispositivo, ventoinhas não giram — o instinto é culpar a alimentação elétrica do prédio.

CAUSAHá três possibilidades distintas e ordenadas: o interruptor do dispositivo ou do módulo de alimentação simplesmente não está ligado; o indicador Input do módulo está apagado, significando que a própria alimentação de entrada está anormal; ou o indicador Output/STATUS está apagado enquanto o Input está bem, significando que o módulo em si falhou mesmo com a energia chegando corretamente.

SOLUÇÃOVerifique nessa ordem — interruptor, depois LED de Input, depois LED de Output/STATUS — já que cada um aponta para uma solução diferente: ligar o interruptor, chamar um eletricista para a alimentação do prédio, ou trocar o próprio módulo de alimentação.

Uma tabela VTY cheia recusa o login sem nenhuma mensagem de erro útil

SINTOMAConexões Telnet ou SSH são recusadas ou simplesmente travam, enquanto o Console continua fazendo login bem e o dispositivo parece saudável no restante.

CAUSATodas as linhas VTY do dispositivo (5 por padrão, VTY 0-4) já estão ocupadas — muitas vezes por sessões que ninguém fechou explicitamente, apenas deixadas ociosas — então não sobra nenhuma linha disponível para uma nova sessão remota se conectar.

SOLUÇÃONo Console, execute display users para confirmar que todas as linhas estão ocupadas, force o encerramento de uma sessão obsoleta com free user-interface vty, e considere ajustar o idle-timeout para que isso não volte a se acumular silenciosamente.

Reencaixar a MPU é o último recurso, não a primeira tentativa

SINTOMATudo acima verificou-se limpo — cabo, alimentação, parâmetros seriais, VTY, ACL, CPU — e ainda não há como entrar por nenhum canal.

CAUSADescartadas todas as outras camadas, a própria placa controladora principal é a causa provável restante — mas essa é uma conclusão alcançada por eliminação, não um primeiro palpite, justamente porque reencaixá-la ou substituí-la é, em si, uma ação que afeta o serviço.

SOLUÇÃOSó tente isso depois de esgotar as camadas 1 a 6, e apenas sob a condição prévia confirmada de serviço já interrompido — reencaixe em um dispositivo com MPU dupla, substitua em um com MPU única, e recorra a um reset completo de desligar/ligar se isso ainda não resolver.

Cinco perguntas que surgem constantemente

Tiradas direto do campo — as que vale a pena já ter resposta pronta.

Em que isso é diferente de simplesmente esquecer minha senha?

Uma senha esquecida ainda mostra um prompt de login em pelo menos um canal — isso é um problema de credenciais com três caminhos oficiais de recuperação, cobertos em nossa nota Recuperação de senha do roteador. Esta nota é para quando nenhum canal dá nenhum prompt, o que aponta para a conexão física, as configurações do terminal, ou os próprios recursos do dispositivo, não uma senha.

O dispositivo ainda parece estar passando tráfego normalmente, eu só não consigo gerenciá-lo — ainda assim devo fazer tudo isso?

Não. Esse é exatamente o caso coberto pelo aviso no topo: se o negócio na verdade não estiver interrompido, não execute os passos de recuperação. Em vez disso, colete as informações da falha e contate seu revendedor ou a linha de suporte pós-venda da Huawei — interromper um tráfego que está funcionando para perseguir um problema no plano de gerenciamento não se justifica.

O Console está conectado e as luzes do dispositivo estão acesas, mas o terminal não mostra nada — qual é a primeiríssima coisa a verificar?

Os parâmetros de comunicação do terminal serial, antes de qualquer outra coisa. Uma incompatibilidade aí — o terminal não configurado com os padrões do dispositivo (9600bps, 8 bits de dados, 1 bit de parada, sem paridade, sem controle de fluxo) — é o motivo mais comum de uma porta de Console perfeitamente saudável parecer morta.

O Console funciona bem, mas o Telnet/SSH ainda recusa a conexão — isso é desta nota ou de Recuperação de senha do roteador?

Esta nota — especificamente as camadas 4 a 6 (esgotamento de VTY, ACL malconfigurada, sobrecarga de CPU). Nenhum desses é um problema de credenciais, então os três métodos de Recuperação de senha do roteador não se aplicam; a correção está do lado de VTY/ACL/CPU, executada a partir da sessão de Console que você ainda tem.

Qual é a primeiríssima mudança de configuração a fazer logo após esse tipo de recuperação?

Faça backup da configuração atual para fora do dispositivo imediatamente, antes de qualquer outra coisa — depois siga a lista de reforço acima: um caminho de gerenciamento de backup independente, limites e monitoramento de VTY mais rígidos, e parâmetros seriais documentados no local.

Limites honestos desta nota

Limites honestos desta nota

As camadas 1, 2 e o passo de pior caso sobre a placa controladora principal seguem a orientação oficial da Huawei para o tratamento de emergência de um dispositivo que não pode ser acessado por nenhum canal — reproduzidas aqui exatamente como documentadas, incluindo o aviso de impacto no negócio no topo. As camadas 4 a 6 (esgotamento de VTY, ACL malconfigurada, sobrecarga de CPU) são prática de diagnóstico padrão e geralmente aplicável do VRP da Huawei para explicar por que especificamente o Telnet/SSH pode falhar enquanto o Console ainda funciona, em vez de virem desse mesmo capítulo de tratamento de emergência, cujo escopo é deliberadamente focado em hardware. Esta nota pressupõe roteadores AR baseados em VRP e acesso físico ao Console como ponto de entrada para cada passo que não seja o reset de hardware.

No meio de um bloqueio agora mesmo?

Conte-nos em qual camada você está travado e se o negócio realmente está interrompido, e ajudamos você a concluir o resto com segurança.

WhatsApp com um engenheiro →