El gráfico de tasa promedio de un conmutador puede verse perfectamente plano mientras un puerto descarta silenciosamente paquetes por una ráfaga que duró un solo milisegundo. Esto es cómo reconocer el síntoma, capturar y leer la ráfaga real, recorrer un caso real donde el registro de fallas apuntaba a la causa equivocada, y las medidas de mitigación que realmente funcionan una vez que se confirma de qué se trata.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
He visto un gráfico de utilización promedio de cinco minutos por debajo del 30% mientras ese mismo puerto perdía paquetes silenciosamente — la herramienta simplemente no estaba mirando la escala de tiempo correcta.
Las plataformas de gestión de red y las herramientas de monitoreo de rendimiento suelen calcular la utilización en varios segundos a unos pocos minutos. A esa resolución, la curva de tráfico de un puerto parece suave y sin nada destacable. Pero un segundo es un lapso enorme para una interfaz que mueve paquetes a velocidad de línea multigigabit — al acercarse a granularidad de milisegundos, el mismo tráfico resulta habitualmente dentado, con picos que alcanzan muchas veces su propio promedio. Cuando el pico es lo bastante severo como para desbordar el búfer del conmutador, eso es una microrráfaga, y produce descartes que nunca aparecen como un problema de utilización sostenida.
A continuación, cómo se ve realmente una microrráfaga, el orden de comprobación a seguir sin adivinar, un caso real de campo donde los registros de clasificación de fallas apuntaban directamente a la causa equivocada, y las medidas de mitigación que funcionan una vez confirmado el problema.
Las microrráfagas duran de 1 a 100 milisegundos y pueden alcanzar picos de decenas o cientos de veces la tasa promedio — a veces por encima del ancho de banda propio del puerto.
Una microrráfaga es una ráfaga de tráfico muy corta y muy densa en un puerto — típicamente de 1 a 100 ms — que alcanza una tasa instantánea muy por encima del promedio medido, y en el peor caso, por encima del ancho de banda físico del propio puerto. No es un fallo del monitoreo perderla a resolución de 5 minutos; es un desajuste de resolución. El tráfico bajo una curva macro de aspecto plano suele ser una curva micro dentada, y cuando los dientes son lo bastante grandes, esa es la ráfaga.
Las etiquetas del diagrama se mantienen en inglés por claridad técnica.
Tres condiciones se combinan para crear la mayoría de las microrráfagas: comportamiento a ráfagas de la aplicación (patrones de solicitud/respuesta, tráfico sensible a la latencia intentando enviar lo más rápido posible), más ancho de banda de entrada que de salida en la misma ruta de reenvío (una tubería grande alimentando a una pequeña, o varios puertos de igual velocidad convergiendo en uno), y el clásico patrón dentado de TCP bajo evitación de congestión (arranque lento y luego reducción a la mitad). Ninguna de las tres requiere una mala configuración — son comportamientos normales de tráfico que chocan con un búfer demasiado pequeño para ese instante.
Los contadores de descarte y las alarmas de QoS indican que probablemente ocurrió una microrráfaga; la captura por espejo y las funciones de detección propias del conmutador indican qué tan grande y con qué frecuencia.
Cualquiera de los síntomas siguientes significa “probablemente ocurrió una microrráfaga aquí”, no una confirmación — las comprobaciones siguientes son las que realmente la confirman.
<HUAWEI>display interface 10GE1/0/1
10GE1/0/1 current state : UP (ifindex: 8)
Line protocol current state : UP
Last 300 seconds input rate: 225 bits/sec, 0 packets/sec
Last 300 seconds output rate: 2075 bits/sec, 1 packets/sec
Input peak rate 2387819 bits/sec, Record time: 2025-11-26 16:11:22+08:00
Output peak rate 1277476 bits/sec, Record time: 2025-11-26 15:51:14+08:00
Input:
Discard: 0, Frames: --
Output:
Discard: 89, Buffers Purged: 0
// average rate looks trivial -- but 89 egress discards already happenedLos descartes en el lado de salida, no en el de entrada, son la firma distintiva de una microrráfaga y no de un problema de CRC o de capa física.
<HUAWEI>display qos queue statistics interface 10GE1/0/1
Queue CIR/PIR Passed Pass Rate Dropped Drop Rate Drop Time
(% or kbps) (Packets/Bytes) (pps/bps) (Packets/Bytes) (pps/bps)
----------------------------------------------------------------------------------------------
6 0 21 0 0 0 -
10000000 6930 88 0 0
----------------------------------------------------------------------------------------------
7 0 255 0 0 0 -
10000000 31365 492 0 0Un gráfico de E/S de 1 milisegundo es la granularidad que realmente necesita una microrráfaga para hacerse visible — el intervalo predeterminado de varios segundos solo muestra la misma curva plana que ya dio la plataforma de monitoreo.
Dos funciones integradas logran esto sin necesidad de captura por espejo — ninguna está disponible en todos los modelos de conmutador, así que verifique el soporte de su hardware antes de asumir que está presente.
[HUAWEI] interface 100GE 1/0/1
[HUAWEI-100GE1/0/1] qos buffer-monitoring percent low 60 high 90
<HUAWEI> display qos buffer-monitoring result interface 100GE 1/0/1
Queue Time BufferUsage(Bytes) Percent(%)
----------------------------------------------------------------
0 2015-11-11 14:36:15.208 1602016 100
// a saved record here confirms a microburst occurred, and precisely when
[HUAWEI] qos micro-burst detection enhanced enable
[HUAWEI] interface 100GE 1/0/1
[HUAWEI-100GE1/0/1] qos micro-burst detection enableUn cliente de red de campus con una pila S12700E-8 reportó tiempos de espera intermitentes de los clientes a través del conmutador central — los pings largos nunca se perdían, los pings con paquetes grandes tampoco, solo el tráfico real de aplicaciones se veía afectado. Los registros mostraban una alarma de relación de cambio de tasa de salida en un puerto GigabitEthernet, junto con un registro “Packets are discarded for congestion” que, en esta versión de software, se leía exactamente como congestión entre tarjetas. Eliminar una gran pila de configuración de espejado de puerto alivió el síntoma pero no lo resolvió. display qos micro-burst statistics en la interfaz con pérdidas mostró tráfico muy lejos del techo real de reenvío de la plataforma — así que no debería haber sido congestión entre tarjetas en absoluto. Espejar esa misma interfaz mostró una captura dentada con una ventana de un milisegundo que alcanzaba aproximadamente 8-9 megabits — alrededor de 8Gb/s — en un puerto de velocidad Gigabit; una captura de paquetes adicional en la misma interfaz sorprendió a un host específico enviando varios paquetes de gran tamaño dentro de ese mismo milisegundo. La lección: en esta plataforma y versión, la congestión ordinaria a nivel de puerto se registra con la misma redacción que la congestión entre tarjetas, lo que desvía el diagnóstico hacia “el plano de reenvío no puede con tanto tráfico” cuando la causa real es un solo puerto recibiendo un golpe instantáneo muy por encima de su propio ancho de banda. Juzgue combinando señales — utilización de ancho de banda de la interfaz, qos micro-burst statistics y captura por espejo — nunca solo por la redacción del registro.
Una vez confirmado que realmente ocurre una ráfaga, estas son las malas interpretaciones que hacen buscar en el lugar equivocado.
SYMPTOMLos descartes están aumentando, pero el dispositivo nunca generó ninguna alarma sobre el uso del búfer — así que se asume que los búferes están bien y que el contador de descarte debe estar midiendo otra cosa.
CAUSELeer la ocupación del búfer requiere sondeo de CPU, la misma restricción que limita la frecuencia de muestreo de la utilización misma. Sondear con la agresividad suficiente para captar un evento a escala de milisegundos elevaría el uso de CPU lo suficiente como para ralentizar todo el dispositivo, así que el conmutador deliberadamente no intenta alarmar sobre el estado del búfer a esa resolución.
FIXTrate los contadores de descarte, la captura por espejo y la función dedicada de detección de microrráfagas como los sustitutos previstos de una alarma de búfer que nunca llegará — no la espere.
SYMPTOMEl gráfico de utilización del puerto nunca supera el 20-30%, por lo que se descarta de plano cualquier teoría de pérdida de paquetes relacionada con ráfagas.
CAUSELa utilización promedio y la tasa instantánea de ráfaga no son la misma medida, del mismo modo que la velocidad y la aceleración no son lo mismo. Una NIC transmite a su tasa física completa o nada en absoluto — nunca a una tasa fraccionaria — así que un puerto que promedia 20-30% puede seguir funcionando al 100% de la tasa de línea durante unos milisegundos, y luego quedar inactivo.
FIXNunca descarte una microrráfaga basándose únicamente en la utilización promedio — recurra directamente a una captura por espejo a escala de milisegundos o a la función de detección integrada.
SYMPTOMEl conmutador es el dispositivo que registra los descartes, así que se lo trata como lo que está averiado.
CAUSEAparte de una pequeña cantidad de tráfico de protocolo, los conmutadores no generan el tráfico que desborda sus propios búferes — lo generan los hosts finales. Lo que el conmutador puede hacer es amplificar una ráfaga: varios puertos de igual velocidad enviando a uno solo, o una relación de convergencia desfavorable, apilan los picos de varias ráfagas justo en el momento en que colisionan en el puerto de salida compartido.
FIXRastree la fuente del tráfico y la relación de convergencia en el diseño de la red, no solo la interfaz que resultó registrar el descarte.
SYMPTOMLa aplicación se describe con tráfico impredecible y de baja intensidad, por lo que una ráfaga seria parece poco plausible.
CAUSELa tarjeta de red de un servidor transmite a su tasa física de enlace completa siempre que tiene algo en cola, y luego queda inactiva esperando a la capa de aplicación. Promediado en el tiempo puede parecer un 20-30% de utilización, pero a nivel de microsegundos es en realidad 100% o 0%, nunca intermedio — que es precisamente de lo que está hecha una microrráfaga.
FIXNo use “la aplicación no está tan ocupada” como razón para omitir una captura a escala de milisegundos — es exactamente el patrón de tráfico más propenso a producir una.
SYMPTOMUna captura por espejo en una interfaz cargada de más de 10Gbps muestra pérdidas o resultados inconsistentes de una ejecución a otra, aunque la configuración de la captura parezca correcta.
CAUSEUna captura basada en PC solo es fiable hasta aproximadamente 1Gbps de tasa de interfaz, y una basada en servidor hasta aproximadamente 10Gbps; más allá de eso, la propia herramienta de captura se convierte en el cuello de botella y empieza a perder o representar mal los paquetes — justo lo que se intenta observar.
FIXPor encima de aproximadamente 10Gbps, o para cualquier ventana de monitoreo sostenido, use un dispositivo dedicado de terceros para captura y análisis en lugar de una PC o servidor de propósito general ejecutando Wireshark.
En el orden aproximado en que vale la pena probarlas — primero lo más económico y con menos efectos secundarios.
[HUAWEI-GigabitEthernet0/0/1] qos burst-mode enhanced
[HUAWEI] traffic classifier c_latency
[HUAWEI-classifier-c_latency] if-match dscp af41
[HUAWEI] traffic behavior b_latency
[HUAWEI-behavior-b_latency] remark local-precedence 6
[HUAWEI] traffic policy p_edge
[HUAWEI-trafficpolicy-p_edge] classifier c_latency behavior b_latency
[HUAWEI-GigabitEthernet0/0/2] traffic-policy p_edge inbound
[HUAWEI-GigabitEthernet0/0/1] qos queue 3 shaping cir 500 mbps pir 800 mbps
// shaping adds latency -- reach for it after the other options, not beforeExtraídas directamente del campo — las que vale la pena tener respondidas de antemano.
No. La congestión ordinaria y sostenida también aparece en el gráfico de tasa promedio — que es exactamente lo que el monitoreo de rutina, incluidas las comprobaciones de nuestra nota de revisión de salud de conmutadores de centro de datos, está diseñado para detectar. Una microrráfaga es específicamente una ráfaga tan corta — de 1 a 100 milisegundos — que es invisible en la resolución normal de monitoreo, aunque igual desborde el búfer del puerto en ese instante.
Porque leer la ocupación del búfer requiere sondeo de CPU, y sondear con la agresividad suficiente para captar un evento a escala de milisegundos elevaría el uso de CPU lo bastante como para ralentizar todo el dispositivo. Por eso exactamente existen los contadores de descarte, la captura por espejo y la función dedicada de detección de microrráfagas como sustitutos de una alarma que no va a llegar.
Si solo necesita confirmar que ocurrió una ráfaga y aproximadamente cuándo, el buffer-monitoring del monitoreo de congestión es más ligero y compatible con más modelos. Si necesita la tasa y duración reales para la planificación de capacidad, el modo mejorado de detección de microrráfagas ofrece cifras reales por interfaz a resolución de 1ms — al costo de funcionar solo en una interfaz a la vez.
Sí, y esta es la interpretación errónea más común de los datos. La utilización promedio y la tasa instantánea de ráfaga no son la misma medida, del mismo modo que la velocidad y la aceleración no son lo mismo. Un puerto que promedia 20-30% puede seguir funcionando al 100% de la tasa de línea durante unos milisegundos, porque así es literalmente como transmite una tarjeta de red — a tasa física completa o nada.
En el orden aproximado en que ayudan sin efectos secundarios: añada ancho de banda de salida en el enlace cuello de botella; evite patrones de tráfico de muchos a uno en el diseño; habilite qos burst-mode enhanced para que los puertos ocupados puedan tomar más del búfer dinámico compartido; separe el tráfico sensible a la latencia en una cola de mayor prioridad para que no sea el que se descarte; y recurra al conformado de salida solo al final, ya que corrige el descarte añadiendo latencia de reenvío, lo cual es una contrapartida en sí misma.
Esta nota se basa en el modelo de búfer/QoS de los conmutadores de campus y chasis Huawei serie S — display interface, display qos queue statistics, qos buffer-monitoring, qos micro-burst detection — y el caso de campo detrás de ella. Si su plataforma es de otro fabricante, los comandos exactos cambian, pero el concepto subyacente se traslada directamente: el monitoreo de tasa promedio pasa por alto las ráfagas de milisegundos por diseño, y confirmar una requiere captura por espejo o una función de detección dedicada. No cubre en profundidad la absorción de ráfagas en fabrics sin pérdidas leaf-spine de centro de datos (PFC, ECN) — ese es el tema de la solución de almacenamiento sin pérdidas enlazada.
Cuéntenos qué interfaz, el contador de descarte, y si ya intentó una captura por espejo, y le ayudamos a interpretarla.