# Conntrack sin la API El recuento real de conntrack de un router MikroTik desde un contenedor de RouterOS: el slab nf_conntrack donde el namespace da 0, contrastado con la API. Source: https://docs.jmrp.io/mikroscope/es/playbooks/conntrack/ **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 · 2026-09-12 · agente a 10 Hz en un contenedor privilegiado efímero ## 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 · 2026-09-12 · `privileged=yes` no cambia el espacio de nombres de red ## 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: ```text 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_slab_active_objects{cache="nf_conntrack"}`. 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 Contrasta el recuento del slab con la API una vez, para fiarte de él a partir de entonces: ```routeros /ip/firewall/connection/print count-only ``` En 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: _El recuento del slab frente al de la API, cinco días_ — Medias horarias, del 2026-09-19 11:00 al 2026-09-24 11:00 UTC, del almacén InfluxDB de referencia (RB5009UG+S+, RouterOS 7.24.4, Linux 5.6.3): el /ip/firewall/connection/print count-only de la API de RouterOS, una mediana de 338 lecturas por hora, frente a los objetos activos de la caché de slab nf_conntrack que leyó el agente. El recuento de la API fue de 3 444 a 9 761; en todas las horas el del slab fue entre 1,02 y 1,08 veces el de la API, y las dos series horarias correlacionan con r = 0,9995. nf_conntrack_max marcó 966 656 todo el tiempo. 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 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/firewall/connection/tracking/print` 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_slab_limit_objects` 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 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. ## Firma **No hizo falta provocarlo** · 2026-09-12 - `nf_conntrack` subiendo hacia `nf_conntrack_max` mientras el recuento del propio namespace se queda en 0. - `nf_conntrack` cayendo por debajo de la mitad de su valor guardado anterior, que es lo que marca `conntrack-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. > **Deliberadamente no provocado** > > Una tormenta de conntrack. Generar miles de conexiones contra un router de producción arriesga > disparar su propio cortafuegos o un bouncer al estilo de CrowdSec y dejarte fuera del mismo camino > por el que estás trabajando. La comprobación cruzada de arriba liga el contador al recuento de > la API sin ese riesgo, hora a hora durante cinco días, pero no se observó qué aspecto tiene > una tormenta en estas cachés. ## Véase también - [Visibilidad del contenedor](https://docs.jmrp.io/mikroscope/es/limits/namespaces/): qué contadores oculta el namespace de red, y la excepción del slab. - [Modo privilegiado](https://docs.jmrp.io/mikroscope/es/limits/privileged/): los ficheros que solo lee root, `/proc/slabinfo` entre ellos. - [Reglas de detección](https://docs.jmrp.io/mikroscope/es/sinks/detections/): `conntrack-cliff` y `conntrack-high` completas. - [Reglas de alerta](https://docs.jmrp.io/mikroscope/es/dashboards/alerts/): `mikroscope-conntrack-near-limit`, la regla que avisa sobre la misma proporción.