Conntrack sin la API
En resumen: dentro del contenedor del agente, nf_conntrack_count marca 0 por
muy ocupado que esté el router, porque pertenece al namespace de red del
contenedor. El recuento real de conexiones del router son los objetos activos de
la caché de slab nf_conntrack en /proc/slabinfo, legible con
privileged=yes, y su techo, nf_conntrack_max, marca lo mismo desde el
contenedor que desde RouterOS. En cinco días de medias horarias del almacén de
referencia, ese recuento del slab siguió al count-only de la API y quedó
siempre un pequeño porcentaje por encima. El techo y los timeouts se leyeron los
dos el 2026-09-14.
Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · Linux 5.6.3 · · agente a 10 Hz en un contenedor privilegiado efímero
Recuento del namespace
Sección titulada «Recuento del namespace»El namespace de red del propio contenedor informa de nf_conntrack_count = 0 por
muy ocupado que esté el router.
Medido en RB5009UG+S+ · 4 × 1,4 GHz Cortex-A72 · RouterOS 7.24.2 · · privileged=yes no cambia el espacio de nombres de red
Recuento del slab
Sección titulada «Recuento del slab»El asignador slab es global. Con privileged=yes el agente lee /proc/slabinfo
e informa del número de objetos activos de la caché nf_conntrack, que es la
población real de conntrack del router:
slab: {'nf_conntrack': 6240, 'skbuff_head_cache': 1008, 'skbuff_fclone_cache': 400, 'TCP': 327, 'UDP': 180, 'TCPv6': 117, 'UDPv6': 125, 'sock_inode_cache': 645, 'kmalloc-1k': 1152, 'kmalloc-2k': 905}En una muestra es el mapa slab; en /metrics es
mikroscope_. La familia no aparece sin
privileged=yes, porque /proc/slabinfo solo lo puede leer root. Una caché que
el kernel no tiene se omite, no se informa como un 0 permanente: el agente
también pide dst_cache e ip_dst_cache, que no aparecen en la salida de arriba.
/proc/slabinfo es el fichero más caro que analiza el agente, así que se lee con
un suelo de presupuesto de 6 Hz, redondeado a ticks enteros: uno de cada 2 ticks
(5 Hz) a los 10 Hz por defecto, uno de cada 17 a 100 Hz. 6 Hz es también más o
menos la tasa a la que se midió que cambia nf_conntrack. Se guarda cuando
cambia, más un latido cada 60 s.
Contraste con la API
Sección titulada «Contraste con la API»Contrasta el recuento del slab con la API una vez, para fiarte de él a partir de entonces:
/ip/firewall/connection/print count-onlyEn el RB5009 esa cuenta dio 6 212 el 2026-09-11, el día antes de las lecturas del slab. Esas, el 2026-09-12, fueron 6 582 en el contenedor de descubrimiento privilegiado y 6 287 desde el agente, y el fragmento de arriba recogió un tercer momento, sin fecha, 6 240. Con un día de diferencia, muestran el mismo orden de magnitud, no que los dos se sigan: en tu equipo, haz el recuento y lee el slab en el mismo minuto.
El almacén de referencia lo ha hecho desde entonces durante cinco días. Con
forward --conntrack-every activado, el colector pidió el recuento a la API
mientras el agente leía el slab, y el gráfico muestra los dos como medias
horarias, con el cociente entre ellos debajo:
Ni aun así coincidirán exactamente: se muestrean en instantes distintos, y el slab cuenta objetos que el asignador aún retiene. La diferencia de coste es lo que importa: la lectura de un fichero varias veces por segundo frente a recorrer una tabla por una sesión de la API.
Techo de la tabla
Sección titulada «Techo de la tabla»Junto a nf_conntrack_count en /proc/sys/net/netfilter, nf_conntrack_max no
va por namespace. Marca 966 656 desde dentro del contenedor, el mismo número
que un /ip/ de solo lectura da como
max-entries en el router de referencia (2026-09-14). Así que “cómo de llena está
la tabla de conexiones” se puede responder sin la API: la población del slab
sobre ese techo.
El agente lee el techo una vez al arrancar, porque es un sysctl que edita una
persona y no un contador, y lo envía junto a la población que acota:
mikroscope_ en /metrics, limit en la fila slab de
InfluxDB.
El colector ejecuta dos detecciones sobre la población y su techo:
conntrack-cliff, cuando nf_conntrack cae por debajo de la mitad de su valor
guardado anterior, y conntrack-high, cuando la ocupación supera el 80 % de
nf_conntrack_max y sube en los últimos 60 s, sin estimación de tiempo hasta
llenarse. La regla de alerta mikroscope-conntrack-near-limit vigila la misma
proporción en el almacén y salta tras cinco minutos por encima del 80 %.
Una trampa en el mismo subárbol: los timeouts de conntrack que hay ahí
marcan los valores por defecto de Linux (tcp_timeout_established 432 000 s,
frente al 1d de RouterOS; leído el 2026-09-14), así que nunca deben presentarse
como la configuración del router.
Cachés slab relacionadas
Sección titulada «Cachés slab relacionadas»Merece la pena vigilar por sí mismas las demás cachés del mapa slab:
skbuff_head_cache/skbuff_fclone_cache: búferes de paquetes en tránsito. Un pico aquí durante un suceso de tráfico es presión de memoria que viene del camino de red, no de algo que hayas instalado.TCP/UDP/sock_inode_cache: sockets que mantiene el propio router.kmalloc-1k/kmalloc-2k: donde se ven las tormentas de asignaciones grandes.
No hizo falta provocarlo ·
nf_conntracksubiendo hacianf_conntrack_maxmientras el recuento del propio namespace se queda en 0.nf_conntrackcayendo por debajo de la mitad de su valor guardado anterior, que es lo que marcaconntrack-cliff; la detección dice dónde mirar, no por qué cayó.skbuff_*subiendo con un suceso de tráfico, lo que sitúa la presión de memoria en el camino de red.