Puerto que pierde tramas

En resumen: un rx-overflow en un puerto cuyos intervalos con desborde llevan una fracción pequeña de la capacidad del enlace es una ráfaga, no una carga. Aquí era un emisor de 2,5 Gbit/s soltando ráfagas hacia un puerto de 1 Gbit/s, con los intervalos que desbordaban al 0,36 % del enlace. Ni una MTU menor ni el control de flujo de Ethernet lo pararon; marcar el ritmo del emisor por debajo de lo que puede vaciar el destino más lento sí, de 5 399 desbordes por hora a ninguno en los 39 minutos medidos.

Cuando Port errors in the window está en rojo (está verde en 0 y roja por encima), las secciones de abajo van de ese único número al puerto, al error y a si el puerto pierde tramas porque está ocupado o porque quien envía lo hace a ráfagas, que es lo que decide el arreglo. Las lecturas son un fallo real del RB5009 de referencia, encontrado el 2026-09-19 y arreglado esa misma tarde.

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.4 · 2026-09-19 · ether1, el puerto de 2,5 GbE del NAS, en intervalos de contador de 10 s; las cifras de antes son las tres horas previas al arreglo y las de después los 39 minutos siguientes, con la misma carga

Encontrar el puerto

La tesela suma todos los errores tipificados del MAC de todos los puertos. A propósito no dice cuál: abre Interface traffic y lee Port errors per bin, que dibuja una fila por cada par (puerto, tipo de error) que tuvo un error en la ventana y nada por los que no. En un router sano dice no port errors in this window.

En el equipo de referencia dibujó exactamente una fila: ether1 rx overflow.

Ese nombre es la primera mitad del diagnóstico. rx-overflow es el FIFO de recepción llenándose más rápido de lo que el chip puede drenarlo: tramas que llegaron bien y se descartaron por no tener dónde ponerlas. No es un fallo de cableado. rx-fcs-error, rx-fragment y los contadores de colisión sí lo son, y te mandan a otro sitio completamente: el cable, el dúplex, el puerto.

Carga o ráfaga

De esto depende el arreglo, y los contadores lo responden. Coge el volumen recibido en los intervalos de 10 segundos que desbordaron y compáralo con lo que el enlace podría haber llevado. En el equipo de referencia el intervalo mediano con desborde llevó 8,96 Mbit/s en un enlace de 2,5 Gbit/s: el 0,36 % de su capacidad.

Un puerto no puede verse superado al 0,36 % de ocupación por carga sostenida. Solo puede verse superado por ráfagas demasiado cortas para que una media de un segundo las muestre: la media era de 3,25 Mbit/s y el segundo más alto en tres horas fue de 70 Mbit/s, mientras el desborde corría a 5 399 por hora, el 0,502 % de cada paquete que enviaba el origen.

Si en cambio los intervalos que desbordan son los que rozan la velocidad de línea, párate aquí: eso es un problema de capacidad y la respuesta es un enlace más rápido o menos tráfico.

Camino del tráfico

Una ráfaga desborda en la entrada porque algo aguas abajo no puede con ella. Los contadores por puerto lo encuentran por correlación: ordena los deltas del desborde contra los deltas de transmisión de cada otro puerto en los mismos intervalos.

En el equipo de referencia el más fuerte fue ether4 con ρ 0,53, un puerto de 1 Gbit/s, y sfp-sfpplus1 con ρ 0,42, que es de 10 Gbit/s pero alimenta a un switch cuyos puertos no lo son. La parte del tráfico que llega a la CPU correlacionó a ρ 0,00, lo que descarta el propio reenvío del router: esas tramas nunca llegaron a la CPU.

ether4 llevaba además 6 644 tx-queue-drop. Ese es el mismo suceso contado desde el otro extremo, la cola de salida que no drenaba bastante rápido, y encontrar los dos es lo que convierte una correlación en un mecanismo: un origen de 2,5 Gbit/s soltando ráfagas a velocidad de línea contra un destino de 1 Gbit/s.

En el dashboard es Egress queue drops — the router’s own transmit queue, en Interface traffic. mikroscope-egress-queue-drops solo salta tras diez minutos seguidos descartando, así que ráfagas como estas se ven en el panel y, a propósito, no te avisan.

Quince horas de contadores

El 2026-09-15, cuatro días antes del arreglo, los contadores de la capa de la API en el mismo puerto dijeron qué clase de suceso es el desborde. Los contadores de puerto son el único sitio donde aparecen estos desbordamientos. Medido entre las 07:13 y las 22:20 UTC, sobre 4 471 lecturas consecutivas de los contadores cada 10 s en ether1 (2,5 Gbps hacia un NAS, MTU 9000):

• 126 443 sucesos rx-overflow en total, presentes en el 40 % de los intervalos; por intervalo la mediana es 29, el p99 unos 1 036 y el mayor 3 747. En toda la tirada eso es el 0,53 % de los paquetes que envió el NAS.
• Correlación de rangos sobre los deltas de 10 s: 0,85 con la parte de lo que recibe el NAS que el switch reenvió en hardware (rx-bytes menos driver-rx-byte), 0,00 con la parte que mandó a la CPU (driver-rx-byte).
• Hacia dónde iba: ether8 (NGINX, 1 Gbps) se lleva casi todo el volumen y ether4 (Mastodon, 1 Gbps) es el destino más frecuente; la jaula SFP+, ether2, ether3 y el camino de la CPU no muestran nada.
• Las tramas eran grandes: el intervalo de tamaño de trama de 1024 en adelante en ether1 tiene una mediana de 9 331 por intervalo con desbordamiento frente a 1 336 por intervalo sin él.
• La carga no era alta: la mediana de lo que recibe el NAS en un intervalo con desbordamiento son unos 9 Mbit/s de media en 10 s. Ráfagas, no carga sostenida.
• Nada del lado de la CPU: softnet descartó 0, time_squeeze correlaciona 0,04 y las interrupciones de switch0 0,05 con los desbordamientos, con los datos a 10 Hz del agente agrupados en intervalos de 10 s. Ninguna trama de pausa en ether1 en ningún sentido.

Leído en conjunto, encaja con ráfagas a la velocidad de línea de 2,5 Gbps conmutadas dentro del chip hacia puertos de 1 Gbps sin control de flujo en juego. Sin verificar: la semántica exacta de los contadores del chip de conmutación y la cuenta de retransmisiones del propio NAS; los contadores son del puerto, no de la conversación.

La capa del kernel no puede ver nada de esto por construcción. Una trama que el chip de conmutación reenvía en hardware nunca llega a la CPU, así que ningún fichero de /proc del router tiene un número para ella; hacen falta los contadores por puerto, y solo la API los tiene.

Arreglos fallidos

En el equipo de referencia se probaron primero dos arreglos que parecen correctos, y ninguno funcionó.

Una MTU más pequeña. Bajar el origen y el puerto de 9000 a 1500 recortó las peores ráfagas un 91 % y los datos perdidos por trama descartada por seis, y no cambió la frecuencia en absoluto: 0,530 % de los paquetes antes, 0,502 % después. Abarata cada suceso sin hacer que los sucesos sean más raros.

El control de flujo de Ethernet. Negociar pause en ambos sentidos es el mecanismo diseñado justo para esto, y en este hardware no se activó nunca: 41 minutos con el pause negociado, 5 578 desbordes, y rx-pause y tx-pause ambos todavía a 0. Mira esos dos contadores antes de creer que el pause te está ayudando. El chip descarta la trama en vez de pedirle al origen que espere.

Arreglo

Espacia al origen con un shaper cuya tasa esté por debajo de lo que drena el destino más lento. No un AQM: la cola del origen está vacía al 0,36 % de ocupación, así que un AQM no tiene nada que gestionar y le pasa la ráfaga intacta a la NIC. En el origen:

tc qdisc replace dev <iface> root cake bandwidth 900Mbit

En esa línea importan dos cosas. La tasa está por debajo de 1 Gbit/s, así que el destino drena más rápido de lo que el origen envía y el búfer del chip nunca crece. Y cake parte los super-segmentos de GSO, que es lo que el origen le estaba entregando a su NIC para ponerlo en el cable seguido y a velocidad de línea.

El resultado en el equipo de referencia, con el mismo volumen de tráfico: el desborde pasó de 1 054–3 681 cada 20 minutos a 0, y el tx-queue-drop de ether4 a 0 con él. El coste fue nada medible: el segundo más alto de salida observado fue de 70 Mbit/s contra un tope de 900.

El almacén InfluxDB de referencia siguió contando después de los 39 minutos que cubren esas cifras. En lo que quedaba de ese día, el desborde de ether1 se paró en los diez minutos anteriores a las 15:30 UTC, siguió a cero dos horas y luego volvió de pocos en pocos, con un ritmo de recepción muy parecido. No quedó registrado si el shaper siguió puesto el resto del día, así que esas horas no dicen nada, ni a favor ni en contra, de si aguanta.

Firma

Un fallo real, no provocado · 2026-09-19

• Port errors in the window en rojo, y Port errors per bin dibujando una fila: un rx overflow en un puerto y nada más.
• Los intervalos que desbordan llevan una fracción pequeña de la capacidad del enlace: una ráfaga, no carga.
• La transmisión de un puerto más lento correlaciona con el desborde, y lleva tx-queue-drop propios.
• rx-pause y tx-pause se quedan en 0 diga lo que diga el control de flujo negociado.

No medido, luego no afirmado

Que el shaper aguante. El cero de arriba son 39 minutos con la carga de una tarde, no de un día, y la tasa se eligió contra un destino de 1 Gbit/s en vez de derivarse. No se ha probado si ese mismo tope sigue valiendo cuando algo detrás del puerto de 10 Gbit/s quiera más de 900 Mbit. La semántica exacta de los contadores del chip es de MikroTik y no se ha contrastado con su documentación.

Véase también

• Interface traffic: los paneles que lee esta página.
• Capa de la API de RouterOS: de dónde salen los contadores por puerto, y por qué el agente no los ve.
• Reglas de alerta: la regla que salta con esto, y lo que no puede distinguir.