Inicio / Notas técnicas / Resolución de problemas de pérdida de paquetes

Pérdida de paquetes en red: diagnóstico de óptica, errores CRC y Discard

La pérdida de paquetes casi siempre proviene de uno de estos tres lugares: un módulo óptico que emite una señal degradada, un error de capa física de entrada que la interfaz cuenta como CRC, Giants o Runts, o un Discard de salida por una ráfaga de tráfico que el puerto no pudo encolar a tiempo. Este es el orden para distinguirlos, los campos exactos de display interface que los diferencian, y cómo leer los umbrales de diagnóstico óptico sin adivinar una cifra en dBm 'normal'.

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

«Es solo pérdida de paquetes» no es un diagnóstico

La pérdida de paquetes en un switch es un síntoma con una lista corta y repetible de causas — no una falla única que perseguir a ciegas.

La pérdida de paquetes se manifiesta del lado del usuario mucho antes de que alguien toque un comando display: páginas web que cargan lento o solo parcialmente, videollamadas convertidas en un mosaico de bloques, clientes de mensajería instantánea que se desconectan y reconectan, descargas arrastrándose, un simple ping a la puerta de enlace que expira, o una sesión de gestión colgada al iniciar sesión. Cualquiera de estos basta para sospechar que hay pérdida de paquetes en algún punto de la ruta — pero ese 'algún punto' todavía debe reducirse a una interfaz y un contador concretos antes de arreglar nada.

Una vez reducido a una interfaz de switch concreta, la pérdida de paquetes proviene de exactamente tres lugares: un módulo óptico que emite una señal degradada, un error de capa física de entrada que la propia interfaz cuenta y etiqueta, o una cola de salida que no pudo absorber una ráfaga de tráfico. A continuación, un árbol de decisión para distinguirlos, los comandos y campos exactos para cada uno, cinco trampas que convierten un contador de aspecto limpio en un diagnóstico erróneo, y cinco respuestas de preguntas frecuentes extraídas de casos reales de campo.

Los tres lugares de donde realmente proviene la pérdida de paquetes

Antes de que cualquiera de las tres fuentes importe, la interfaz misma debe estar realmente activa (Up) — de lo contrario, está leyendo un árbol de fallas completamente distinto.

Ubicar primero el síntoma en este árbol indica qué sección leer realmente a continuación, en lugar de revisar las tres en el orden que se le ocurra.

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

Evaluando cada fuente por turno

Misma interfaz, tres preguntas independientes — el campo que responde a cada una es distinto, y ninguno sustituye a los demás.

Fuente 1 — Errores de bits del módulo óptico

Una potencia óptica que parece 'más o menos normal' no es lo mismo que una potencia óptica dentro de los umbrales propios de este módulo específico — el bloque de diagnóstico le indica cuál de los dos está viendo.

Ejecute primero display interface transceiver en la interfaz y revise el bloque Alarm information. Un LOS Alarm significa que el extremo remoto no está enviando ninguna señal — verifique con display this si el puerto de cualquiera de los extremos está apagado antes de suponer que el módulo mismo está averiado.
Ejecute display interface transceiver verbose y lea el bloque Diagnostic information: Current RX Power y Current TX Power, cada uno comparado contra los propios campos Default RX/TX Power High/Low Threshold de ese mismo módulo — no una cifra en dBm 'normal' memorizada, ya que distintos tipos de módulo reportan distintos umbrales.
Si Current RX Power está por debajo del Low Threshold propio del módulo, el extremo local está recibiendo una señal demasiado débil — verifique la distancia de transmisión contra el alcance nominal del módulo, luego revise el enlace de fibra en sí por pérdida excesiva en el conector o una curvatura demasiado cerrada antes de suponer que el módulo está averiado.
Si Current RX Power está por encima del High Threshold propio del módulo, suele tratarse de un módulo de largo alcance usado en un tramo demasiado corto, por lo que la señal nunca se atenuó de forma natural — agregue un atenuador óptico para proteger el módulo en lugar de reemplazarlo.
Si Current TX Power está fuera de sus propios umbrales en cualquier dirección, eso apunta al módulo local mismo: una potencia TX baja sugiere un transmisor fallando que se reflejará como un RX bajo en el peer; una potencia TX alta arriesga quemar con el tiempo el receptor del peer y exige cambiar el 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

Fuente 2 — Errores físicos de entrada (CRC / Giants / Runts)

El bloque Input de display interface descompone una queja genérica de 'paquetes con error' en contadores con nombre propio — cada uno apunta a una solución distinta.

Ejecute display interface en la interfaz afectada mientras el tráfico de negocio realmente fluye, y lea Total Error junto con los contadores individuales CRC, Giants, Jabbers, Fragments, Runts, DropEvents, Alignments y Symbols — todos estos son contadores de entrada, lo que significa que la falla está del lado emisor o en el medio físico que trae el tráfico, no en la cola de salida propia de este puerto.
Si el tipo de error es CRC y el conteo es pequeño en relación con el tráfico total, verifique si el conector en cualquiera de los extremos está flojo o si el medio de transmisión — fibra, cobre, módulo — está físicamente dañado; reasiente o reemplace lo dañado, luego ejecute restart en la interfaz.
Si el tipo de error es Runts, verifique la longitud de trama que el peer realmente está enviando. Si es genuinamente menor a 64 bytes, hay que corregir la configuración propia del peer; si la longitud de trama es normal, reinicie en su lugar la interfaz local.
Si el tipo de error es Giants, compare la longitud de trama recibida contra el propio campo The Maximum Frame Length de display interface en esta interfaz. Si el peer envía tramas más largas que ese valor, auméntelo localmente con jumboframe enable value1; si el límite local ya está en su tope, haga que el peer reduzca su propio MTU con mtu mtu en su lugar.

<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

Fuente 3 — Discard de salida (congestión)

Discard vive en el bloque Output, no en el bloque Input — significa que la propia cola de salida de este puerto no pudo seguir el ritmo, no que algo aguas arriba esté dañado.

Ejecute display interface (o display this desde la vista de interfaz) y verifique si Discard está creciendo durante la ventana real en que se reportó el impacto en el negocio — un Discard distinto de cero de hace semanas no explica una queja que ocurre ahora mismo.
En las tarjetas que lo soportan, ejecute display qos queue statistics interface para la interfaz afectada y lea las columnas Passed / Dropped / Drop Rate por cola — la congestión en un puerto programado con QoS es por cola, por lo que una cola puede estar descartando mucho mientras otra pasa limpiamente.
Habilite el modo de ráfaga mejorado para la gestión de buffers de la interfaz y observe si Discard sigue subiendo — esto apunta específicamente a los microbursts, picos de tráfico que duran milisegundos y que un promedio de sondeo de varios segundos nunca muestra como un problema de ancho de banda.
Si Discard sigue subiendo, dé forma o limite la tasa del tráfico que realmente está causando la ráfaga en su cola de origen, mueva el tráfico sensible a la latencia a una cola de mayor prioridad, o aumente el ancho de banda disponible — una velocidad de interfaz más rápida, o agregación de enlaces entre más de un puerto físico.
Si aún no queda claro si una lentitud intermitente es realmente congestión, capture el tráfico y léalo en el IO Graph de Wireshark con el eje X en milisegundos y el eje Y en bits — esto muestra el pico de tasa instantánea que un promedio de contador de dispositivo de 300 segundos oculta por completo.

<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 trampas que convierten un contador de aspecto normal en un diagnóstico erróneo

Cada contador anterior es real y preciso — así es como aun así se malinterpreta.

1. Una potencia óptica dentro de rango aún así genera alarmas — no existe una cifra en dBm 'normal' universal

SÍNTOMAdisplay interface transceiver verbose muestra una advertencia RxPower High o RxPower Low aunque la lectura cruda parezca un número pequeño sin nada de particular.

CAUSALos umbrales los reporta el propio módulo — Default RX/TX Power High/Low Threshold — y difieren según el tipo de módulo y el alcance nominal, no es un valor fijo que se pueda memorizar entre modelos. Un módulo de largo alcance en un enlace corto se lee 'demasiado alto' contra su propio umbral, aunque el mismo número sería intrascendente en otro módulo.

SOLUCIÓNCompare siempre Current RX/TX Power contra los propios campos de umbral de ese módulo exacto en el mismo bloque de salida, nunca contra una cifra en dBm memorizada; agregue un atenuador óptico cuando se despliegue un módulo de largo alcance en un tramo corto.

2. CRC y Discard pueden parecer idénticos en un panel — son direcciones opuestas

SÍNTOMAUn panel de tráfico muestra un porcentaje de pérdida plano, y nadie ha verificado realmente en qué dirección está el conteo.

CAUSACRC, Giants y Runts son contadores de entrada — la falla está del lado emisor o en el medio físico que trae el tráfico. Discard es un contador de salida — la falla es la propia cola de salida de este puerto sobresuscrita. Perseguir un reemplazo de cable para un problema de Discard, o un cambio de shaping de cola para un problema de CRC, no arregla nada.

SOLUCIÓNLea los bloques Input y Output de display interface como dos preguntas separadas antes de decidir cuál de las fuentes anteriores aplica realmente.

3. Un conteo de Discard de hace semanas no explica la queja de hoy

SÍNTOMADiscard es distinto de cero, así que la congestión se culpa por defecto, aunque el problema del usuario esté ocurriendo justo ahora.

CAUSADiscard es acumulativo desde la última vez que se limpió el contador; una única ráfaga que ocurrió una vez, semanas antes, deja un conteo permanente distinto de cero que no tiene nada que ver con el ticket actual.

SOLUCIÓNObserve si Discard sigue subiendo durante la ventana real de impacto en el negocio, o revise display qos queue statistics interface para un Drop Rate por cola en vivo en lugar de confiar solo en el total acumulado.

4. Un bucle o un ataque produce exactamente el mismo síntoma que una congestión ordinaria

SÍNTOMADiscard y el uso de CPU suben juntos, y ninguna cantidad de shaping o ajuste de colas hace bajar Discard.

CAUSAUn bucle de capa 2 que causa flapping de MAC, o un ataque activo — ARP, ICMP, tormenta de broadcast — inunda el puerto con tráfico que un shaping legítimo nunca fue pensado para absorber, porque ese tráfico simplemente no debería estar en el puerto.

SOLUCIÓNVerifique display trapbuffer en busca de un trap de bucle y display mac-address flapping antes de asumir congestión; verifique display cpu-defend statistics all y display cpu-usage antes de dedicar tiempo a optimizar colas que nunca fueron el verdadero cuello de botella.

5. Giants solo aparece cuando alguien cambia el MTU del otro lado

SÍNTOMAAparece un contador Giants tras meses de funcionamiento limpio, sin ningún cambio de configuración en el switch local.

CAUSAEl propio The Maximum Frame Length de esta interfaz no cambió — pero el MTU del dispositivo peer sí, y ahora está enviando tramas más largas de lo que este puerto acepta, lo cual se registra aquí como Giants de entrada y se descarta.

SOLUCIÓNCompare la longitud de trama recibida con The Maximum Frame Length de display interface; auméntela localmente con jumboframe enable value1, o haga que el peer reduzca su MTU con mtu mtu — según cuál de los dos lados realmente deba cambiar.

Cinco preguntas que surgen constantemente

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

¿CRC o Discard — cuál revisar primero?

Técnicamente, ninguno — verifique primero display interface brief, porque un puerto que está Down o en ERROR DOWN hace que CRC y Discard sean irrelevantes; vea nuestra nota sobre puerto Ethernet físicamente down para ese árbol de fallas separado. Una vez confirmado que el puerto está Up, trate los errores de entrada y el Discard de salida como dos preguntas independientes, no una — un puerto puede tener uno, ambos, o ninguno.

El módulo óptico no muestra ninguna Alarm information — ¿puedo descartar por completo la óptica?

No del todo. Alarm information solo señala condiciones que el propio módulo trata como anormales, como LOS o RX LOL. Todavía vale la pena leer todo el bloque Diagnostic information y comparar Current RX/TX Power contra los propios campos de umbral del módulo — una lectura cercana a, pero sin superar, un umbral aún puede correlacionarse con errores intermitentes, sobre todo a medida que la temperatura cambia durante el día.

¿Por qué display qos queue statistics interface muestra descartes en algunas colas y no en otras?

Porque la congestión en un puerto programado con QoS es por cola, no por puerto. Una cola de baja prioridad puede estar descartando mucho mientras una cola de alta prioridad que lleva voz o control pasa limpiamente — eso es justo lo que la programación por prioridad fue configurada para hacer. Verifique en qué cola está realmente clasificado el tráfico afectado antes de concluir que todo el puerto está sobresuscrito.

Reemplacé el cable y CRC bajó a cero, pero los usuarios siguen reportando lentitud — ¿qué queda?

Vuelva a revisar Discard en la misma interfaz; un problema de capa física y un problema de congestión pueden coexistir en el mismo enlace ascendente ocupado, y arreglar uno no toca el otro. Si ambos vuelven limpios, pase a las comprobaciones de bucle y ataque — display trapbuffer para flapping de MAC, display cpu-defend statistics all para tráfico de ataque — antes de suponer que el problema se movió a otra parte de la ruta.

¿Hay alguna forma de demostrar que una lentitud intermitente es congestión cuando Discard nunca parece moverse?

Sí. Los contadores del lado del dispositivo promedian en intervalos de sondeo de varios segundos, por lo que un microburst genuino puede saturar una cola y descartar paquetes entre sondeos sin registrarse nunca como Discard. Capturar el tráfico y leerlo en el IO Graph de Wireshark, con el eje X en milisegundos y el eje Y en bits, muestra el pico de tasa instantánea que un promedio de 300 segundos oculta por completo.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se basa en el modelo de clasificación de fallas de los switches Huawei serie S para pérdida de paquetes de red y los comandos display interface / display interface transceiver verbose / display qos queue statistics detrás de él, además de los casos de campo documentados junto a ellos. Si su switch es de otro fabricante, los comandos cambian pero la lógica de las tres fuentes — óptica, errores de entrada, congestión de salida — se traslada directamente. Deliberadamente mantiene breves la detección de bucles, el rastreo de ataques y la limitación de tasa CPCAR, ya que cada uno de ellos es un tema lo bastante grande como para merecer su propia nota; trate la trampa anterior como el indicador para revisarlos, no como el procedimiento completo.

¿Aún no está seguro de cuál de los tres es?

Envíenos la salida de display interface del puerto afectado — los bloques Input y Output — y le ayudaremos a determinar de qué fuente proviene realmente.

WhatsApp con un ingeniero →