Una inundación de paquetes

Esta página responde a qué aspecto tiene el tráfico que la CPU del router tiene que atender, visto desde dentro de un contenedor que no puede ver las interfaces del router. La inundación se provocó a propósito.

Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · 2026-09-12 · agente a 10 Hz en un contenedor privilegiado efímero

Cómo se provocó

ICMP contra la propia dirección LAN del router, desde un host de la LAN, limitado a 10 s. Es tráfico que la CPU del router tiene que atender, a diferencia del tráfico de LAN a LAN, que el chip del switch reenvía sin que la CPU llegue a verlo:

ping -f -w 10 192.168.0.1     # 67 793 paquetes, ~6.8 kpps, 0 % de pérdida

192.168.0.1 es la dirección LAN del router de referencia; usa la de tu router.

Lo que registró el agente

En tramos de 5 segundos, antes y durante:

   t  busy%  per-core busy%           sirq  squeeze  top IRQ
   2    4.8   3.8   8.0   3.0   4.2     51       50  switch0=5337
   3    5.5   3.9  10.4   3.9   3.9     50       45  switch0=5567
   4    9.6  23.3   2.8   3.3   8.8    149      138  switch0=34922
   5   14.3  24.9  19.6   3.5   9.2    153      136  switch0=33832

Qué leer

Las interrupciones de switch0 pasaron de 5,5 k a 34 k por tramo, una subida de 6×. Es lo más parecido a un contador por interfaz que existe dentro del contenedor: el namespace de red oculta /proc/net/dev, pero la interrupción que levanta la NIC es global. No te dará bytes; te dará el inicio, el final y qué núcleo pagó.
El coste cayó en un solo núcleo (el núcleo 0, al 23–25 %) porque esa IRQ está fijada. Una inundación que satura un núcleo mientras tres están ociosos es una forma habitual y confusa — el total dice 14 %, y el router parece bloqueado.
Los softirqs se triplicaron (de 50 a 150), y time_squeeze subió con ellos. time_squeeze es el que hay que vigilar: cuenta las veces que el manejador de softirq agotó su presupuesto con trabajo aún en cola. Un squeeze que sube con un caudal plano es la firma de un router en su techo de paquetes por segundo.
El tiempo de IRQ hardware no aparece en la columna irq de /proc/stat en este kernel — siempre es 0 (sin IRQ_TIME_ACCOUNTING). Ese trabajo está dentro de system. No leas el campo irq para concluir que el router no tiene carga de interrupciones.

Dónde viven estas señales

Las líneas de interrupción son mikroscope_irq_total{irq,name,cpu} en /metrics, por núcleo, para las fuentes que aparecieron en el top-K de alguna muestra; mikroscope_irq_delivered_total es la suma de todas las fuentes, el denominador para saber qué parte cubre el top-K. En InfluxDB, el reparto por núcleo es mikroscope_irq_cpu, con una etiqueta cpu. Qué línea levanta una NIC y cómo se llama dependen de la placa y de su driver: compara con la etiqueta name o con la tasa, no con switch0 escrito en una consulta.
El squeeze es mikroscope_softnet_total{cpu,kind="time_squeeze"}, junto a kind="processed" y kind="dropped"; los softirqs son mikroscope_softirq_total{cpu,kind}.
El squeeze no tiene un presupuesto entre el que dividirlo: /proc/sys/net/core/* (netdev_budget, netdev_max_backlog) no existe en el namespace del contenedor.

El colector marca una muestra como burst cuando una cola softnet descartó un paquete o hizo más squeezes de los que esa CPU suele hacer (por encima de su percentil 90 móvil y al menos 3), en una muestra cuyo número de paquetes estuvo en su mediana móvil o por debajo — la evidencia del kernel de una ráfaga más corta que el intervalo de muestreo. Lee la forma en reposo para saber por qué la regla no es “cualquier squeeze”.

Tu instrumento forma parte del sistema

Un inciso que lo demuestra: ejecutar /system/routerboard/settings/print por SSH produjo sucesos del kernel propios —

[4] rb_ioctl, cmd: 0x5212, arg: 0x0
[4] rb: RB_GET_CF_INFO

Leer la configuración de RouterOS deja rastro en el log del kernel. Cuando estés correlacionando sucesos con tus propias acciones, recuerda que tu instrumento forma parte del sistema. En este equipo, cada conexión SSH cuesta además un 20–27 % de CPU mientras dura.

La firma

Provocado a propósito · 2026-09-12

Una línea de interrupción que se multiplica varias veces, con un inicio y un final bruscos.
El coste en el único núcleo al que está fijada esa línea, mientras el total del equipo se mantiene modesto.
Los softirqs y time_squeeze subiendo juntos, frente a un squeeze que nunca es cero en reposo.