Início / Notas técnicas / Porta Ethernet fisicamente DOWN

Porta Ethernet fisicamente DOWN: diagnóstico de cabo, óptica e hardware

current state : DOWN não diz nada sobre o motivo. Pode ser um desligamento humano, uma falha de hardware, um cabo ou fibra ruins, um óptico incompatível, ou a sala onde o switch está — seis causas raiz diferentes, cada uma com sua própria verificação e sua própria solução. Esta é a ordem que as separa rápido, com os comandos display exatos e números reais de potência óptica.

By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026

Um DOWN físico tem seis causas raiz diferentes, não uma

A tentação é recorrer à mesma solução toda vez — reconectar o cabo, trocar o módulo. Isso funciona com frequência suficiente para ser perigoso, porque também esconde qual das seis causas estava realmente em jogo.

Uma interface Ethernet permanece Up sob a condição mais básica que um switch precisa cumprir: poder enviar e receber quadros. Quando não consegue, a luz indicadora apaga, current state mostra DOWN, e uma entrada de log como linkDown_active dispara. A partir daí, as causas possíveis se dividem claramente em seis ramos — alguém a desligou ou disparou um mecanismo de proteção, o próprio hardware do dispositivo falhou, o cabo ou a fibra em si está com defeito, o óptico e a fibra com que está emparelhado não combinam, o método de conexão estava errado, ou o ambiente ao redor do equipamento é o problema. Cada ramo tem seu próprio comando de diagnóstico, e adivinhar qual se aplica desperdiça exatamente o tipo de tempo que esta nota pretende economizar.

A seguir está a verificação para cada um dos seis ramos com os comandos exatos a executar, quatro casos de campo reais extraídos de registros de manutenção reais, e as respostas de perguntas frequentes que surgem sempre que uma porta se recusa a subir.

Seis ramos, uma árvore de decisão

Comece com display interface e deixe o campo current state e qualquer motivo de ERROR DOWN levá-lo para o ramo certo — não um palpite.

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

Na prática, os ramos 3 (meio), 4 (uso) e 6 (o próprio óptico) se sobrepõem bastante — uma leitura de potência óptica fora do limite pode significar uma fibra ruim, um módulo incompatível, ou um transceptor falhando, e display interface transceiver verbose é o comando que ajuda a distingui-los. É por isso que a verificação óptica recebe seu próprio passo a passo detalhado abaixo.

Percorrendo cada ramo

Cinco verificações, cinco comandos diferentes — e a tabela de motivos de ERROR DOWN que evita que você adivinhe no ramo 1.

Ramo 1 — Fatores humanos: desligamento e mecanismos de proteção

Se current state mostrar Administratively down, alguém (ou algo) mandou a porta parar — a questão é quem, e undo shutdown pode nem ser a resposta certa.

Execute display interface e leia current state literalmente. Administratively down significa que um comando shutdown está ativo — execute undo shutdown se isso genuinamente não for intencional.
Se current state mostrar em vez disso ERROR DOWN (down-cause), o dispositivo desligou a porta sozinho em resposta a um evento desencadeador específico — o valor de down-cause nomeia exatamente qual: bpdu-protection (um BPDU chegou em uma porta de borda com proteção BPDU habilitada), storm-control (a taxa de broadcast/multicast/unicast desconhecido excedeu o limite alto configurado com a ação error-down), loopback-detect (a porta recebeu de volta seu próprio quadro de detecção de loopback), mac-address-flapping, link-flap (oscilação repetida Up/Down disparou o limite de proteção contra flapping), crc-statistics, e várias causas específicas de stack/M-LAG.
Na view diagnose, display system internal device port interface-name mostra uma tabela Port enable related check — qualquer linha em que IsPass não seja YES explica por que a porta realmente não consegue subir, até se shutdown está configurado, se o dispositivo está em meio a uma atualização, ou se a instância do motor de encaminhamento está up.
Recupere manualmente com shutdown e depois undo shutdown, ou reinicie a interface — ou configure error-down auto-recovery cause down-cause interval interval-value para que a causa específica se resolva sozinha depois que a condição de falha passar.

<HUAWEI> display logbuffer | include DOWN
Sep 19 2022 08:51:53 HUAWEI %%01IFNET/2/linkDown_active(l):CID=0x807a0427-
alarmID=0x08520003;The interface status changes. (ifName=10GE1/0/1, AdminStatus=UP,
OperStatus=DOWN, Reason=Interface physical link is down, mainIfname=10GE1/0/1)

<HUAWEI> display interface 10GE 1/0/1
10GE1/0/1 current state : DOWN (ifindex: 11)
Line protocol current state : DOWN

[HUAWEI-diagnose] display system internal device port 10ge1/0/1
Port enable related check:
--------------------------------------------------------------------------------
DevType     AttrName        AttrValue    ExpectValue    IsPass
--------------------------------------------------------------------------------
port        isshut          0x1          == 1           YES
port        portlfeisup     0x1          == 1           YES
port        triggerShut     0x1          == 1           YES
port        phyportisshut   0x1          == 1           YES
--------------------------------------------------------------------------------
// any row where IsPass is not YES tells you exactly why the port won't come Up

[HUAWEI] interface 10ge1/0/1
[HUAWEI-10GE1/0/1] error-down auto-recovery cause link-flap interval 300

Ramo 2 — Falhas de hardware do dispositivo

Se é um lote de portas ou apenas uma indica se deve suspeitar da placa ou apenas daquela porta.

Execute display interface brief para ver todas as interfaces de uma vez. Várias portas caindo para DOWN juntas, todas conectadas a dispositivos remotos diferentes, aponta para uma falha de placa local ou a própria instabilidade dos dispositivos remotos (um peer em meio a um failover, hibernação, ou reinício); uma única porta caindo para DOWN aponta especificamente para aquela porta.
Para uma porta única suspeita, primeiro verifique se os contatos metálicos do slot físico estão dobrados ou desalinhados, depois execute loopback internal nessa interface. Se current state voltar a UP sob loopback interno, o caminho interno da porta está bom e não há falha de hardware; se permanecer DOWN, há um problema de hardware interno genuíno.
Para uma falha em lote em uma placa com peers remotos por outro lado saudáveis, execute reset slot slot-id para reiniciar a placa; se a falha persistir, a placa precisa ser substituída. Para uma falha em lote onde os dispositivos peer estão eles mesmos oscilando (failover, reinício), muitas vezes é um comportamento transitório normal que se resolve assim que o peer se estabiliza — mas confirme primeiro que o peer não está reiniciando por causa de seu próprio problema de loop ou ataque.

<HUAWEI> display interface brief
Interface         PHY     Protocol InUti OutUti inErrors outErrors
10GE1/0/1          up     down      0.01% 0.01%        0      0
10GE1/0/3          down     down        0%   0%        0      0

<HUAWEI> system-view
[HUAWEI] interface 10ge1/0/1
[HUAWEI-10GE1/0/1] loopback internal
Info: Ensure that the port is not in default VLAN 1 to prevent traffic loops.
[HUAWEI-10GE1/0/1] display this interface
10GE1/0/1 current state : UP (ifindex: 23)
// came UP under internal loopback -- no hardware fault, problem is external

Ramo 3 — Meio de transmissão: cabo de cobre ou fibra

O cobre e a fibra falham de formas diferentes e precisam de ferramentas diferentes — virtual-cable-test para um, limites de potência óptica para o outro.

Para cobre: confirme que as duas pontas usam o mesmo cabo, que os jumpers do painel de conexão estão corretos, e que o comprimento do cabo está abaixo do limite padrão Ethernet de 100 m — as portas GE precisam de pelo menos Cat5e para negociar a 1000 M.
Execute virtual-cable-test na interface. Pair state Ok nos quatro pares significa que o cabeamento em si está bom; Open ou Short em qualquer par significa que é hora de trocar o cabo.
Para fibra: confirme primeiro que o transceptor é certificado pela Huawei — o alarme de um óptico não certificado aparece diretamente no log, e sua confiabilidade sob garantia não é garantida.
Execute display interface transceiver verbose e compare Current RX Power / Current TX Power com os próprios campos Default RX/TX Power High/Low Threshold do módulo. Uma leitura dentro de ambos os limites e Voltage/Bias Current diferente de zero descarta o óptico como a falha.

<HUAWEI> system-view
[HUAWEI] interface 10ge1/0/1
[HUAWEI-10GE1/0/1] virtual-cable-test
Warning: The command will stop service for a while, Continue?[Y/N] y
Pair A state: Ok
Pair B state: Ok
Pair C state: Ok
Pair D state: Ok
// any pair reporting Open or Short instead of Ok -> replace the cable

<HUAWEI> display interface 10ge1/0/2 transceiver verbose
Diagnostic information:
   Voltage (V)                    :3.27
   Bias Current (mA)              :89.76
   Bias High Threshold (mA)       :130.00
   Bias Low Threshold (mA)        :1.00
   Current RX Power (dBm)         :-3.26
   Default RX Power High Threshold (dBm) :-0.50
   Default RX Power Low Threshold (dBm)  :-23.98
   Current TX Power (dBm)         :0.71
   Default TX Power High Threshold (dBm) :5.90
   Default TX Power Low Threshold (dBm)  :-5.90
// current Rx/Tx readings sitting inside their thresholds -> the optic is not the fault

Ramo 4 — Método de conexão: óptico, tipo de fibra ou cabeamento incompatível

Um transceptor perfeitamente bom e uma fibra perfeitamente boa ainda podem se recusar a linkar se forem o par errado um para o outro.

Execute display device para confirmar a placa/slot exato em questão, depois verifique o tipo de transceptor contra a interface e contra a fibra com que está emparelhado — ópticos monomodo precisam de fibra monomodo, multimodo precisa de multimodo; misturá-los é um erro comum na instalação.
Execute display interface transceiver nos dois lados e compare Transceiver Type, Wavelength e Transfer Distance lado a lado — eles precisam ser compatíveis nos dois lados, não apenas individualmente válidos.
Confirme que o par de fibras está realmente cruzado: o TX de uma ponta precisa se conectar ao RX da outra e vice-versa. Isso parece óbvio até que um painel de conexão entre em cena e o trajeto físico seja mais longo que o diagrama do quadro branco.
Para ópticos bidirecionais de fibra única (BiDi) especificamente, as duas pontas precisam usar comprimentos de onda complementares — uma ponta TX1310/RX1490, a outra TX1490/RX1310 — não o mesmo par de comprimentos de onda nos dois lados.

<HUAWEI> display interface 10ge1/0/2 transceiver
10GE1/0/2 transceiver information:
Common information:
 Transceiver Type          :10GBASE_USR
 Connector Type            :LC
 Wavelength (nm)           :850
 Transfer Distance (m)     :20(62.5um/125um OM1) 50(50um/125um OM2)
Alarm information:
 Non-Huawei-certified transceiver
// compare Transceiver Type / Wavelength / Transfer Distance against the far end,
// not just against the local interface spec

Ramo 5 — Fatores ambientais

Só vale a pena verificar depois que os quatro primeiros ramos voltarem limpos — mas quando chega aqui, geralmente essa é a resposta.

Verifique a temperatura e umidade da sala de equipamentos em relação à faixa de operação nominal do equipamento — normalmente 0-45°C e 5%-95% de umidade relativa, sem condensação. Leituras persistentes fora dessa faixa apontam para o HVAC ou desumidificação, não para a porta em si.
Verifique o roteamento de cabos: cabeamento de energia e cabeamento de dados correndo em paralelo sem separação é uma fonte comum de interferência, e também pode significar desgaste físico onde as bandejas de cabos flexionam ou atritam com o tempo.

Quatro casos de campo

Cada um parecia idêntico à primeira vista — uma porta travada em DOWN — e cada um acabou sendo um ramo diferente da árvore acima.

1. Um transceptor não certificado sobrevive a um reinício no modo errado

SINTOMAApós uma perda de energia não planejada e reinício, várias interfaces permaneceram fisicamente DOWN sem nenhuma mudança de configuração no histórico recente, e os dispositivos peer não mostraram nenhum reinício ou failover próprio.

CAUSAdisplay interface mostrava a porta ainda em Port Mode: COMMON FIBER embora o engenheiro no local tenha confirmado que essa interface na verdade usava uma porta Combo cabeada para cobre. display interface transceiver verbose confirmou que o óptico instalado não tinha identificação de fabricante HUAWEI — um transceptor não certificado. Depois do reinício, a porta falhou em detectar corretamente qual meio físico estava realmente presente e ficou travada reportando modo fibra em vez de mudar para modo cobre, então nunca subiu.

SOLUÇÃOReencaixar o óptico não resolveu. Substituí-lo por um transceptor certificado pela Huawei resolveu — Port Mode mostrou corretamente COMMON COPPER depois e a interface subiu imediatamente. Ópticos não certificados não são validados contra o próprio comportamento do firmware do dispositivo, e esse tipo de falha de detecção de modo em caso extremo é exatamente o risco que a certificação pretende descartar.

<HUAWEI> display interface 10ge1/0/2
10GE1/0/2 current state : DOWN
Port Mode: COMMON FIBER//should have been COMMON COPPER for this build

<HUAWEI> display interface 10ge1/0/2 transceiver verbose
Vendor Name                     :*********
Alarm information: Non-Huawei-certified transceiver

// after replacing with a certified transceiver:
<HUAWEI> display interface 10ge1/0/2
10GE1/0/2 current state : UP
Port Mode: COMMON COPPER//correct mode, port came Up

2. A distância de fibra multimodo excede o que a OM3 consegue transportar de forma confiável

SINTOMAUm link óptico 10GE rodando 210 metros em fibra multimodo e ópticos multimodo oscilava física e repetidamente entre Up e Down, com entradas de log de estado de link correspondentes nos dois lados e nenhuma incompatibilidade de configuração em lugar nenhum.

CAUSAdisplay interface transceiver verbose confirmou que o transceptor era certificado pela Huawei com a potência de recepção e transmissão ambas dentro de seus limites — o óptico em si não era a falha. O campo Transfer Distance no transceptor mostrava classificações de suporte multimodo que variam por grau de fibra: aproximadamente 300m em fibra OM3 mas 400m em OM4. A 210 metros o link estava dentro do alcance da OM4 mas empurrando o limite do que a fibra realmente instalada (multimodo não-OM4) conseguia transportar de forma confiável, e a dispersão cromática nessa distância era suficiente para causar perda de link intermitente.

SOLUÇÃOCombine ópticos multimodo especificamente com fibra de grau OM4 quando o trajeto se aproximar de 300m ou mais, em vez de assumir que qualquer combinação multimodo-multimodo está automaticamente correta — a regra de correspondência (óptico monomodo com fibra monomodo, multimodo com multimodo) é necessária mas não suficiente quando a distância aumenta. Substituir a fibra por OM4 resolveu a oscilação.

<HUAWEI> display interface 10ge1/0/1 transceiver verbose
Transceiver Type:10GBASE_SR_SFP
Transfer Distance(m):300(50um/125um OM3),400(50um/125um OM4)//OM4 carries furthest
Vendor Name:HUAWEI// certified optic, ruled out as the fault
Current RX Power (dBm)  :-2.45//within threshold
Current TX Power (dBm)  :-1.86//within threshold
// optic and power both clean -> look at fiber grade vs. the 210m run length

3. A autonegociação entre fabricantes falha em cobre

SINTOMAUm link de cobre para um equipamento de outro fabricante não subia, enquanto o mesmo cabeamento físico e porta funcionavam corretamente quando reconectados temporariamente a outro dispositivo do mesmo fabricante.

CAUSAdisplay interface mostrava a porta em si saudável — fisicamente UP internamente, velocidade e duplex corretos, Negotiation: ENABLE — sem nada na configuração ou cabeamento que explicasse a falha contra esse peer específico. Implementações de autonegociação não são idênticas em todos os fabricantes, e esse emparelhamento simplesmente não concordou em parâmetros durante a negociação, mesmo que a configuração de cada lado fosse individualmente válida.

SOLUÇÃOConfigure negotiation disable na interface do lado Huawei para forçar o modo sem autonegociação. O peer subiu imediatamente. Se desativar apenas a autonegociação não for suficiente em um caso semelhante, continue definindo explicitamente speed para corresponder ao peer, já que uma porta não negociada também precisa ter sua taxa configurada em vez de assumida.

<HUAWEI> display interface 10ge 1/0/1
10GE1/0/1 current state : UP
Duplex: FULL,Negotiation: ENABLE//auto-negotiation is on, but the peer still won't link

<HUAWEI> system-view
[HUAWEI] interface 10ge 1/0/1
[HUAWEI-10GE1/0/1] negotiation disable
// peer interface came Up immediately after switching off auto-negotiation

4. Um cabo falhando se manifesta como erros de CRC crescentes, não uma porta DOWN

SINTOMAA porta em si permaneceu fisicamente UP o tempo todo, mas o contador de erros CRC da interface continuava subindo a cada verificação — uma falha de combustão mais lenta que um DOWN total, mas que degrada a vazão da mesma forma.

CAUSAUm cabo degradado — desgaste interno, um conector marginal, ou dano físico ao longo do trajeto — corrompe uma fração dos quadros em trânsito sem derrubar o link de vez. Cada quadro corrompido falha em sua sequência de verificação de quadro e incrementa o contador de CRC, o que é um sinal precoce confiável de um problema de camada física mesmo enquanto a porta mostra Up.

SOLUÇÃOTrate primeiro um contador de CRC crescente como um sintoma de camada física, antes de olhar para qualquer outro lugar. Substituir o cabo resolveu este caso; vale a pena executar virtual-cable-test em qualquer interface com uma contagem de CRC crescente mesmo que current state ainda mostre UP.

<HUAWEI> display this interface
10GE1/0/1 current state : UP
CRC          :4782,Giants           :0
// port shows UP, but CRC count keeps growing on repeated checks ->
// treat as a physical-layer / cable fault even without a DOWN state

Cinco perguntas que surgem constantemente

Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.

Como eu realmente verifico a potência de recepção e transmissão de um módulo óptico?

Execute display interface transceiver verbose para o bloco de diagnóstico completo, ou display interface transceiver brief apenas para os números de potência. Current RX Power e Current TX Power são as leituras que importam; compare-as com os próprios campos Default RX/TX Power High/Low Threshold daquele mesmo módulo, que viajam com o transceptor em vez de serem um número fixo para todos os módulos.

Ambas as pontas são portas GE com autonegociação ativada — por que não negociam para velocidade gigabit?

1000BASE-T exige cabeamento Cat5e ou melhor com os quatro pares de fios internos saudáveis para que o link negocie em gigabit. Um par degradado, um conector solto, ou um cabo abaixo da especificação muitas vezes ainda negocia — só que cai para 100M em vez de 1000M. Execute virtual-cable-test para verificar diretamente a saúde dos pares, e configure speed auto explicitamente se quiser forçar uma tentativa de renegociação.

Por que um link bidirecional de fibra única (BiDi) não sobe mesmo com ópticos BiDi instalados nas duas pontas?

Ópticos BiDi precisam ser usados em pares complementares, não idênticos — uma ponta precisa de um módulo TX1310/RX1490 e a outra precisa de TX1490/RX1310. Dois módulos com a mesma atribuição de comprimento de onda nas duas pontas nunca vão linkar não importa quão saudável esteja a fibra, já que ambos estão transmitindo e escutando no mesmo comprimento de onda em vez de comprimentos opostos.

Uma porta 10GE pode usar um módulo óptico 1GE, ou o inverso?

Uma porta óptica 10GE pode aceitar um módulo 1GE e vai rodar em 1GE — a porta em si é capaz da taxa mais baixa. O inverso não funciona: uma interface óptica classificada como 1GE não pode ser forçada a rodar um módulo classificado como 10GE, já que a interface física e a taxa SerDes não são construídas para isso. Sempre combine a velocidade nominal do módulo com o que a porta física realmente foi projetada para rodar.

Uma porta fica oscilando entre Up e Down a cada poucos minutos — isso é hardware, cabo, ou outra coisa?

Verifique primeiro a causa de ERROR DOWN se o log mostrar uma — a proteção de link-flap disparando repetidamente é em si diagnóstica de uma camada física instável por baixo, não uma falha separada. Se não houver causa de ERROR DOWN, verifique o CRC e outros contadores de erro (um cabo falhando degrada antes de falhar de vez), depois a potência óptica se for um link de fibra, e só trate como uma falha de hardware depois que tanto o cabeamento quanto a óptica saírem limpos sob loopback internal.

Limites honestos desta nota

Limites honestos desta nota

Esta nota se baseia no modelo de classificação de falhas de interface física do switch Huawei série S e seus comandos display interface / display interface transceiver / virtual-cable-test, além dos casos de campo por trás deles. Se o seu switch for de outro fabricante, os comandos exatos mudam, mas a ordem de diagnóstico de seis ramos — humano/proteção, hardware, meio, uso/incompatibilidade, ambiente, e o próprio óptico — se aplica diretamente. Não cobre em profundidade falhas de divisão/combinação de interface ou cenários de perda de pacotes em estado Up; esses estão em uma seção relacionada do mesmo manual fonte e merecem seu próprio tratamento separado.

Uma porta que não sobe e você já esgotou as coisas óbvias para tentar?

Envie-nos a saída de display interface e display interface transceiver verbose, e ajudamos você a identificar em qual dos seis ramos você realmente está.

WhatsApp com um engenheiro →