# Visibilidad del contenedor

Qué ficheros del kernel describen el router dentro de un contenedor RouterOS y cuáles solo el contenedor, y qué supone eso para el tráfico, las conexiones y los montajes del host.

Source: https://docs.jmrp.io/mikroscope/es/limits/namespaces/

Un contenedor de RouterOS comparte el kernel del router, pero no toda la visión del kernel: unos
ficheros dentro de él describen el router y otros solo el contenedor. Esa línea la trazan los
espacios de nombres del kernel, y ningún ajuste del contenedor que mikroscope pudiera elegir la
mueve. Qué ficheros caen a cada lado es una propiedad del kernel y de cómo construye RouterOS sus
contenedores ([sin comprobar en otras placas y versiones](https://docs.jmrp.io/mikroscope/es/about/status/#not-tested)).

## Ficheros globales

Los ficheros de CPU, interrupciones, memoria y dispositivos de bloque son globales: dentro del
contenedor son los del propio router, y se leen en cada tick (la fila de un dispositivo de bloque
solo se guarda cuando hizo algo):

- [`/proc/stat`](https://man7.org/linux/man-pages/man5/proc_stat.5.html), por núcleo
- `/proc/interrupts` y `/proc/softirqs`
- [`/proc/net/softnet_stat`](https://docs.kernel.org/filesystems/proc.html#networking-info-in-proc-net): descartes y _time squeezes_ en la ruta de recepción del kernel. Vive
  bajo `/proc/net` pero cuenta por CPU, no por espacio de nombres.
- `/proc/meminfo`, `/proc/vmstat` y `/proc/loadavg`
- `/proc/diskstats`

Un contenedor normal, sin privilegios, también lee como los del router estos otros: las zonas
térmicas bajo `/sys/class/thermal`, `scaling_cur_freq` por núcleo, los contadores de desgaste de
la NAND en `/proc/yaffs` y las listas de bloques libres del asignador de páginas en
`/proc/buddyinfo`. La cadena `model` del árbol de dispositivos tampoco está en un espacio de
nombres, y es como el agente identifica la placa sin la API de RouterOS.

## Ficheros de red del contenedor

`/proc/net/dev`, `/proc/net/snmp`, `/proc/net/netstat` y `nf_conntrack_count` son por
[espacio de nombres de red](https://man7.org/linux/man-pages/man7/network_namespaces.7.html). Dentro del contenedor describen la veth del propio contenedor: unos
pocos paquetes mientras el router reenvía millones. El agente no los lee como datos del router, y
`/capabilities` los lista bajo `namespaced` para que un consumidor vea que se dejaron fuera a
propósito y no por descuido.

**`privileged=yes` no cambia esto.** Elimina el espacio de nombres de _usuario_ del contenedor, no
su espacio de nombres de red ([verificado](https://docs.jmrp.io/mikroscope/es/about/status/#campaign-netns-2026-09-12)).

Así que los bytes y paquetes por interfaz vienen en su lugar de la API de RouterOS, y el colector
los fusiona con la capa del kernel sobre el reloj del agente. No se interpolan a partir de nada
que el contenedor pueda ver. Cómo se consulta esa capa está en
[Capa de la API de RouterOS](https://docs.jmrp.io/mikroscope/es/sinks/api-tier/).

La misma frontera aparece en otros sitios:

| Qué                                                                               | Lo que ve el contenedor                                                                              |
| --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| `/sys/class/net`                                                                  | solo `lo` y la veth; ningún dispositivo para ningún puerto frontal, privilegiado o no                |
| `/sys/class/mdio_bus`, `/sys/class/phy`                                           | `mdio_bus` solo contiene `fixed-0`; `phy` está vacío                                                 |
| `netdev_budget`, `netdev_max_backlog` y las demás entradas globales de `net.core` | ausentes; las entradas por espacio de nombres, como `somaxconn`, están presentes                     |
| ficheros de `/proc/net/*` creados por módulos                                     | los del propio contenedor: `fib_trie` muestra solo el `/30` de la veth, `snmp6` cuenta sus paquetes  |
| `nf_conntrack_max`                                                                | el techo real del router, el mismo valor que RouterOS informa como `max-entries`                     |
| tiempos de expiración de conntrack                                                | los valores por defecto de Linux (`tcp_timeout_established` 432 000 s frente al `1d` de RouterOS)    |

Las dos últimas filas están en el mismo directorio y se separan en direcciones opuestas.
`nf_conntrack_max` se lee una vez al arrancar y se envía como el techo de la tabla de conexiones.
Los tiempos de expiración nunca se presentan como la configuración del router, porque no lo son.

La ausencia de `netdev_budget` es también la razón por la que los paneles de _squeeze_ no tienen un
denominador de presupuesto: es cosa del espacio de nombres, no del agente.

## Cuenta de conntrack

El número de conexiones es la excepción. Con `privileged=yes` el agente lee [`/proc/slabinfo`](https://man7.org/linux/man-pages/man5/slabinfo.5.html), y el
asignador slab es global: la cuenta de objetos activos de la caché `nf_conntrack` es la población
real de conntrack del router, mientras el espacio de nombres propio del contenedor informa de 0.
[Conntrack sin la API](https://docs.jmrp.io/mikroscope/es/playbooks/conntrack/) tiene las lecturas, y cómo contrastar
la cuenta una vez con la API.

Eso sustituye un recorrido de tabla por la API con la lectura de un fichero, y es la razón por la
que el colector nunca consulta la cuenta de conntrack salvo que se indique `--conntrack-every`
(desactivado por defecto en todos los `--api-mode`). Con el techo de más
arriba, «cuánto de llena está la tabla de conexiones» se puede responder solo desde el contenedor.

Lo que no puede decirte es qué son esas conexiones. `/proc/slabinfo` cuenta objetos en una caché y
nada más: ni protocolo, ni dirección, ni estado. Una inundación de conntrack y una ráfaga
legítima de muchas conexiones (un torrent) se ven igual en él. Sin `privileged=yes` el fichero no se puede leer y la cuenta
desaparece; consulta [Modo privilegiado](https://docs.jmrp.io/mikroscope/es/limits/privileged/).

## Montajes del host

Montar las rutas propias del router dentro de un contenedor privilegiado no atraviesa los espacios
de nombres ([probado](https://docs.jmrp.io/mikroscope/es/about/status/#verified-host-mounts)):

- `/proc` del host se monta pero muestra **cero PID**. RouterOS genera un procfs nuevo en el punto
  de montaje, así que el espacio de nombres de PID se mantiene y la CPU por proceso de los
  procesos propios de RouterOS sigue fuera de alcance.
- `/sys` del host se monta pero no tiene `class/net`. La parte de red de sysfs es por espacio de
  nombres de red y el montaje no lleva la del host, así que los contadores por interfaz siguen
  siendo solo de la API.
- `/` del host funciona, y expone el sistema de ficheros de la flash de RouterOS: configuración y
  ficheros, no telemetría en vivo. Un contenedor privilegiado con `/` montado lee la configuración
  entera, secretos incluidos. El instalador de mikroscope no monta nada en el contenedor y nunca
  debe hacer esto.

Los espacios de nombres son fronteras del kernel, y un montaje de sistema de ficheros no las cruza.

## Véase también

- [Capa de la API de RouterOS](https://docs.jmrp.io/mikroscope/es/sinks/api-tier/): de dónde viene el tráfico por
  interfaz, ya que el contenedor no puede verlo.
- [Modo privilegiado](https://docs.jmrp.io/mikroscope/es/limits/privileged/): el espacio de nombres de usuario
  que elimina, y los dos que deja en su sitio.
- [Conntrack sin la API](https://docs.jmrp.io/mikroscope/es/playbooks/conntrack/): leer la cuenta del slab y
  contrastarla una vez con RouterOS.
- [Nombres de puertos](https://docs.jmrp.io/mikroscope/es/reference/port-names/): poner nombre a
  un puerto que el contenedor no puede ver como dispositivo.