# Puerto que pierde tramas

Un puerto MikroTik que cuenta rx-overflow: distinguir carga de microrráfaga con los contadores del puerto, qué no lo arregló y el ritmo del emisor que sí.

Source: https://jmrplens.github.io/mikroscope/es/playbooks/port-errors/

**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:

```sh
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.

_El desbordamiento de recepción de ether1, antes y después de pararse_ — Cada diez minutos, del 2026-09-19 11:10 al 2026-09-20 00:00 UTC, del almacén InfluxDB de referencia (RB5009UG+S+, RouterOS 7.24.4, Linux 5.6.3): los incrementos de los contadores rx-overflow y de paquetes recibidos de ether1, leídos por la capa de la API una mediana de 56 veces cada diez minutos. Todos los tramos de diez minutos desde las 11:10 hasta las 15:30 desbordaron, 24 550 en las 4 h 20 min anteriores a las 15:30; las dos horas siguientes no tuvieron ninguno, y las 8 h 30 min posteriores enteras, 131. El puerto recibió una mediana de 313 paquetes por segundo antes y 286 después.

## 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](https://jmrplens.github.io/mikroscope/es/dashboards/#tráfico-por-interfaz): los paneles que lee esta página.
- [Capa de la API de RouterOS](https://jmrplens.github.io/mikroscope/es/sinks/api-tier/): de dónde salen los contadores por
  puerto, y por qué el agente no los ve.
- [Reglas de alerta](https://jmrplens.github.io/mikroscope/es/dashboards/alerts/): la regla que salta con esto, y lo que no
  puede distinguir.