Início / Notas técnicas / Solução de problemas de perda de pacotes

Perda de pacotes de rede: diagnóstico de óptica, erros de CRC e Discard

A perda de pacotes quase sempre vem de um destes três lugares: um módulo óptico emitindo um sinal degradado, um erro de camada física de entrada que a interface conta como CRC, Giants ou Runts, ou um Discard de saída por uma rajada de tráfego que a porta não conseguiu enfileirar a tempo. Esta é a ordem para distingui-los, os campos exatos do display interface que os diferenciam, e como ler os limiares de diagnóstico óptico sem adivinhar um número em dBm 'normal'.

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

'É só perda de pacotes' não é um diagnóstico

A perda de pacotes em um switch é um sintoma com uma lista curta e repetitiva de causas — não uma falha única para perseguir às cegas.

A perda de pacotes aparece do lado do usuário muito antes de alguém tocar em um comando display: páginas web carregando devagar ou apenas parcialmente, chamadas de vídeo virando um mosaico de blocos, clientes de mensagens instantâneas caindo e reconectando, downloads arrastando, um simples ping ao gateway expirando, ou uma sessão de gerenciamento travada no login. Qualquer um desses já basta para suspeitar de perda de pacotes em algum ponto do caminho — mas esse 'algum ponto' ainda precisa ser reduzido a uma interface e um contador concretos antes de qualquer correção.

Uma vez reduzido a uma interface de switch específica, a perda de pacotes vem de exatamente três lugares: um módulo óptico emitindo um sinal degradado, um erro de camada física de entrada que a própria interface conta e rotula, ou uma fila de saída que não conseguiu absorver uma rajada de tráfego. A seguir está uma árvore de decisão para distingui-los, os comandos e campos exatos para cada um, cinco armadilhas que transformam um contador de aparência limpa em um diagnóstico errado, e cinco respostas de perguntas frequentes tiradas de casos reais de campo.

Os três lugares de onde a perda de pacotes realmente vem

Antes que qualquer uma das três fontes importe, a própria interface precisa estar realmente Up — caso contrário, você está lendo uma árvore de falhas completamente diferente.

Colocar primeiro o sintoma nesta árvore indica qual seção abaixo realmente ler, em vez de verificar as três na ordem que vier à cabeça.

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

Avaliando cada fonte por vez

Mesma interface, três perguntas independentes — o campo que responde a cada uma é diferente, e nenhum substitui os outros.

Fonte 1 — Erros de bits do módulo óptico

Uma potência óptica que parece 'mais ou menos normal' não é o mesmo que uma potência óptica dentro dos próprios limiares deste módulo específico — o bloco de diagnóstico indica qual dos dois você está vendo.

Execute primeiro display interface transceiver na interface e verifique o bloco Alarm information. Um LOS Alarm significa que a extremidade remota não está enviando nenhum sinal — verifique com display this se a porta de qualquer uma das extremidades está desligada antes de supor que o próprio módulo está com defeito.
Execute display interface transceiver verbose e leia o bloco Diagnostic information: Current RX Power e Current TX Power, cada um comparado com os próprios campos Default RX/TX Power High/Low Threshold desse mesmo módulo — não um número em dBm 'normal' memorizado, já que diferentes tipos de módulo reportam limiares diferentes.
Se Current RX Power estiver abaixo do Low Threshold próprio do módulo, a extremidade local está recebendo um sinal fraco demais — verifique a distância de transmissão em relação ao alcance nominal do módulo, depois verifique o próprio link de fibra por perda excessiva no conector ou curvatura apertada demais antes de supor que o módulo está com defeito.
Se Current RX Power estiver acima do High Threshold próprio do módulo, geralmente é um módulo de longo alcance usado em um trecho curto demais, então o sinal nunca atenuou naturalmente — adicione um atenuador óptico para proteger o módulo em vez de substituí-lo.
Se Current TX Power estiver fora de seus próprios limiares em qualquer direção, isso aponta para o próprio módulo local: potência TX baixa sugere um transmissor falhando que aparecerá como RX baixo no peer; potência TX alta arrisca queimar o receptor do peer com o tempo e exige a troca do módulo.

<HUAWEI> display interface 10ge1/0/1 transceiver verbose
... ...
-------------------------------------------------------------------
Warning information:
RxPower High
-------------------------------------------------------------------
Diagnostic information:
Temperature (Celsius)                :41.41
Voltage (V)                          :3.27
Bias Current (mA)                    :89.76|59.89 (Lane0|Lane1)
                                       71.61|63.70 (Lane2|Lane3)
Bias High Threshold (mA)             :130.00
Bias Low Threshold (mA)              :1.00
Current RX Power (dBm)               :-3.23|-3.11 (Lane0|Lane1)
                                       -2.90|-1.09 (Lane2|Lane3)
Default RX Power High Threshold (dBm):-0.50
Default RX Power Low Threshold (dBm) :-23.98
Current TX Power (dBm)               :0.71|1.21 (Lane0|Lane1)
                                       0.99|0.92 (Lane2|Lane3)
Default TX Power High Threshold (dBm):5.90
Default TX Power Low Threshold (dBm) :-5.90
-------------------------------------------------------------------
// compare Current RX/TX Power against THIS module's own threshold fields,
// never against a memorized "normal" dBm number -- different modules differ

Fonte 2 — Erros físicos de entrada (CRC / Giants / Runts)

O bloco Input de display interface decompõe uma queixa genérica de 'pacotes com erro' em contadores nomeados — cada um aponta para uma correção diferente.

Execute display interface na interface afetada enquanto o tráfego de negócio está realmente fluindo, e leia Total Error junto com os contadores individuais CRC, Giants, Jabbers, Fragments, Runts, DropEvents, Alignments e Symbols — todos esses são contadores de entrada, o que significa que a falha está do lado emissor ou no meio físico que traz o tráfego, não na fila de saída própria desta porta.
Se o tipo de erro for CRC e a contagem for pequena em relação ao tráfego total, verifique se o conector em qualquer extremidade está solto ou se o meio de transmissão — fibra, cobre, módulo — está fisicamente danificado; reencaixe ou substitua o que estiver danificado, depois execute restart na interface.
Se o tipo de erro for Runts, verifique o comprimento do quadro que o peer está realmente enviando. Se for genuinamente menor que 64 bytes, a própria configuração do peer precisa ser corrigida; se o comprimento do quadro estiver normal, reinicie a interface local em vez disso.
Se o tipo de erro for Giants, compare o comprimento do quadro recebido com o próprio campo The Maximum Frame Length do display interface nesta interface. Se o peer estiver enviando quadros mais longos que esse valor, aumente-o localmente com jumboframe enable value1; se o limite local já estiver no teto, faça o peer reduzir seu próprio MTU com mtu mtu em vez disso.

<HUAWEI> system-view
[HUAWEI] display interface 10GE1/0/1
... ...
Total Error: 0
CRC: 0, Giants: 0
Jabbers: --, Fragments: 0
Runts: 0, DropEvents: 0
Alignments: 0, Symbols: 0
Output:
Unicast: 0, Multicast: 1438
Broadcast: 0, Jumbo: 0
Discard: 0, Buffers Purged: 0
Pause: 0

<HUAWEI> display interface 10GE1/0/1
10GE1/0/1 current state : UP (ifindex: 45)
Line protocol current state : UP
Description:
Switch Port, PVID : 1, TPID : 8100(Hex), The Maximum Frame Length is 9216
// compare received frame length against The Maximum Frame Length above

[HUAWEI] interface 10GE1/0/1
[HUAWEI-10GE1/0/1] jumboframe enable 9600
// or, on the sending peer instead:
[peer] mtu 1500

Fonte 3 — Discard de saída (congestionamento)

Discard vive no bloco Output, não no bloco Input — significa que a própria fila de saída desta porta não conseguiu acompanhar, não que algo a montante esteja danificado.

Execute display interface (ou display this dentro da view da interface) e verifique se Discard está crescendo durante a janela real em que o impacto no negócio foi relatado — um Discard diferente de zero de semanas atrás não explica uma reclamação que está acontecendo agora.
Em placas que suportam, execute display qos queue statistics interface para a interface afetada e leia as colunas Passed / Dropped / Drop Rate por fila — o congestionamento em uma porta com escalonamento QoS é por fila, então uma fila pode estar descartando muito enquanto outra passa limpa.
Habilite o modo de rajada aprimorado para o gerenciamento de buffer da interface e observe se Discard continua subindo — isso visa especificamente os microbursts, picos de tráfego que duram milissegundos e que uma média de sondagem de vários segundos nunca mostra como um problema de largura de banda.
Se Discard continuar subindo, molde ou limite a taxa do tráfego que realmente está causando a rajada em sua fila de origem, mova o tráfego sensível à latência para uma fila de prioridade mais alta, ou aumente a largura de banda disponível — uma velocidade de interface mais rápida, ou agregação de links entre mais de uma porta física.
Se ainda não estiver claro se uma lentidão intermitente é realmente congestionamento, capture o tráfego e leia-o no IO Graph do Wireshark com o eixo X em milissegundos e o eixo Y em bits — isso mostra o pico de taxa instantânea que uma média de contador do dispositivo de 300 segundos esconde completamente.

<HUAWEI> display interface 10GE1/0/1
... ...
Output:
Unicast: 0, Multicast: 2033
Broadcast: 0, Jumbo: 0
Discard: 0, Buffers Purged: 0
Pause: 0
Input bandwidth utilization threshold : 90.00%
Output bandwidth utilization threshold: 90.00%
Last 300 seconds input utility rate: 0.01%
Last 300 seconds output utility rate: 0.01%

<HUAWEI> display qos queue statistics interface 10GE1/0/1
Queue CIR/PIR   Passed          Pass Rate   Dropped         Drop Rate
      (kbps)     (Packets/Bytes) (pps/bps)  (Packets/Bytes) (pps/bps)
----------------------------------------------------------------------
0     0/200000000  0              0          0               0
----------------------------------------------------------------------
7     0/200000000  1751           0          208369          507
----------------------------------------------------------------------

<HUAWEI> system-view
[HUAWEI] interface 10ge1/0/1
[HUAWEI-10GE1/0/1] qos burst-mode enhanced
[HUAWEI-10GE1/0/1] qos queue 0 shaping cir 200 mbps pir 200 mbps

5 armadilhas que transformam um contador de aparência normal em um diagnóstico errado

Cada contador acima é real e preciso — estas são as formas como ainda assim ele é mal interpretado.

1. Uma potência óptica dentro da faixa ainda dispara alarmes — não existe um número em dBm 'normal' universal

SINTOMAdisplay interface transceiver verbose mostra um aviso RxPower High ou RxPower Low mesmo que a leitura bruta pareça um número pequeno e sem nada de especial.

CAUSAOs limiares são reportados pelo próprio módulo — Default RX/TX Power High/Low Threshold — e diferem por tipo de módulo e alcance nominal, não é um valor fixo que se possa memorizar entre modelos. Um módulo de longo alcance em um link curto lê 'alto demais' em relação ao seu próprio limiar, mesmo que o mesmo número fosse insignificante em outro módulo.

CORREÇÃOCompare sempre Current RX/TX Power com os próprios campos de limiar desse módulo exato no mesmo bloco de saída, nunca com um número em dBm memorizado; adicione um atenuador óptico quando um módulo de longo alcance for implantado em um trecho curto.

2. CRC e Discard podem parecer idênticos em um painel — são direções opostas

SINTOMAUm painel de tráfego mostra uma porcentagem de perda genérica, e ninguém realmente verificou em qual direção está a contagem.

CAUSACRC, Giants e Runts são contadores de entrada — a falha está do lado emissor ou no meio físico que traz o tráfego. Discard é um contador de saída — a falha é a própria fila de saída desta porta sobrecarregada. Perseguir uma troca de cabo para um problema de Discard, ou uma mudança de shaping de fila para um problema de CRC, não resolve nada.

CORREÇÃOLeia os blocos Input e Output do display interface como duas perguntas separadas antes de decidir qual das fontes acima realmente se aplica.

3. Uma contagem de Discard de semanas atrás não explica a reclamação de hoje

SINTOMADiscard é diferente de zero, então o congestionamento é culpado por padrão, mesmo que o problema do usuário esteja acontecendo agora.

CAUSADiscard é cumulativo desde a última vez que o contador foi zerado; uma única rajada que aconteceu uma vez, semanas antes, deixa uma contagem permanente diferente de zero que não tem nada a ver com o chamado atual.

CORREÇÃOObserve se Discard continua subindo durante a janela real de impacto no negócio, ou verifique display qos queue statistics interface para um Drop Rate por fila ao vivo em vez de confiar apenas no total acumulado.

4. Um loop ou um ataque produz exatamente o mesmo sintoma que um congestionamento comum

SINTOMADiscard e uso de CPU sobem juntos, e nenhuma quantidade de shaping ou ajuste de filas faz o Discard baixar.

CAUSAUm loop de camada 2 causando flapping de MAC, ou um ataque ativo — ARP, ICMP, tempestade de broadcast — inunda a porta com tráfego que um shaping legítimo nunca foi feito para absorver, porque esse tráfego simplesmente não deveria estar na porta.

CORREÇÃOVerifique display trapbuffer em busca de um trap de loop e display mac-address flapping antes de presumir congestionamento; verifique display cpu-defend statistics all e display cpu-usage antes de gastar tempo otimizando filas que nunca foram o verdadeiro gargalo.

5. Giants só aparece quando alguém muda o MTU do outro lado

SINTOMAUm contador Giants aparece depois de meses de operação limpa, sem nenhuma mudança de configuração no switch local.

CAUSAO próprio The Maximum Frame Length desta interface não mudou — mas o MTU do dispositivo peer mudou, e agora ele está enviando quadros mais longos do que esta porta aceita, o que é registrado aqui como Giants de entrada e descartado.

CORREÇÃOCompare o comprimento do quadro recebido com The Maximum Frame Length do display interface; aumente-o localmente com jumboframe enable value1, ou faça o peer reduzir seu MTU com mtu mtu — dependendo de qual lado realmente deve mudar.

Cinco perguntas que surgem constantemente

Tiradas diretamente do campo — as que vale a pena ter uma resposta pronta.

CRC ou Discard — qual verificar primeiro?

Tecnicamente, nenhum dos dois — verifique primeiro display interface brief, porque uma porta que está Down ou em ERROR DOWN torna CRC e Discard irrelevantes; veja nossa nota sobre porta Ethernet fisicamente down para essa árvore de falhas separada. Uma vez confirmado que a porta está Up, trate os erros de entrada e o Discard de saída como duas perguntas independentes, não uma — uma porta pode ter um, ambos, ou nenhum.

O módulo óptico não mostra nenhuma Alarm information — posso descartar completamente a óptica?

Não exatamente. Alarm information só sinaliza condições que o próprio módulo trata como anormais, como LOS ou RX LOL. Ainda vale a pena ler todo o bloco Diagnostic information e comparar Current RX/TX Power com os próprios campos de limiar do módulo — uma leitura próxima de um limiar, mas sem ultrapassá-lo, ainda pode se correlacionar com erros intermitentes, especialmente conforme a temperatura muda ao longo do dia.

Por que display qos queue statistics interface mostra descartes em algumas filas e não em outras?

Porque o congestionamento em uma porta com escalonamento QoS é por fila, não por porta. Uma fila de baixa prioridade pode estar descartando muito enquanto uma fila de alta prioridade carregando voz ou controle passa limpa — é exatamente para isso que o escalonamento por prioridade foi configurado. Verifique em qual fila o tráfego afetado está realmente classificado antes de concluir que a porta inteira está sobrecarregada.

Troquei o cabo e o CRC caiu a zero, mas os usuários ainda relatam lentidão — o que falta?

Reverifique o Discard na mesma interface; um problema de camada física e um problema de congestionamento podem coexistir no mesmo uplink ocupado, e corrigir um não afeta o outro. Se ambos voltarem limpos, passe para as verificações de loop e ataque — display trapbuffer para flapping de MAC, display cpu-defend statistics all para tráfego de ataque — antes de supor que o problema se moveu para outro lugar no caminho.

Existe uma forma de provar que uma lentidão intermitente é congestionamento quando o Discard nunca parece se mover?

Sim. Os contadores do lado do dispositivo fazem a média em intervalos de sondagem de vários segundos, então um microburst genuíno pode saturar uma fila e descartar pacotes entre sondagens sem nunca ser registrado como Discard. Capturar o tráfego e lê-lo no IO Graph do Wireshark, com o eixo X em milissegundos e o eixo Y em bits, mostra o pico de taxa instantânea que uma média de 300 segundos esconde completamente.

Limites honestos desta nota

Limites honestos desta nota

Esta nota se baseia no modelo de classificação de falhas dos switches Huawei série S para perda de pacotes de rede e nos comandos display interface / display interface transceiver verbose / display qos queue statistics por trás dele, além dos casos de campo documentados ao lado deles. Se o seu switch for de outro fabricante, os comandos mudam, mas a lógica das três fontes — óptica, erros de entrada, congestionamento de saída — se aplica diretamente. Ela mantém deliberadamente breves a detecção de loop, o rastreamento de ataques e a limitação de taxa CPCAR, já que cada um desses é um tópico grande o suficiente para merecer sua própria nota; trate a armadilha acima como o indicador para verificá-los, não o procedimento completo.

Ainda não tem certeza de qual dos três é?

Envie-nos a saída de display interface da porta afetada — os blocos Input e Output — e ajudamos você a determinar de qual fonte ela realmente vem.

WhatsApp com um engenheiro →