Ajuste de rendimiento

La mayoría de los despliegues funcionan bien con los valores por defecto. Ajusta estas opciones cuando la reconciliación de arranque gestione listas CAPI grandes, un router lento agote los tiempos de espera o necesites ventanas de reinicio predecibles.

Pool de conexiones

mikrotik.pool_size controla cuántas sesiones de la API de RouterOS puede usar el bouncer para trabajo en paralelo, como las eliminaciones de la reconciliación.

mikrotik:
  pool_size: 4

Recomendaciones:

Clase de router	Valor sugerido
Router doméstico pequeño	`1`-`2`
RouterOS 7 de gama media	`4`
Despliegues CAPI grandes	`6`-`8`

El valor configurado debe estar entre 1 y 20. En el arranque, el bouncer consulta max-sessions de la API de RouterOS y limita el pool efectivo a max-sessions - 2, garantizando que al menos dos sesiones queden disponibles para otras operaciones de RouterOS.

Comprueba o aumenta el límite de RouterOS:

/ip/service/print where name=api
/ip/service/set api max-sessions=1000

Comportamiento de adición masiva

Durante la reconciliación, las adiciones con el valor por defecto bulk_add_method: script salen como scripts de RouterOS de hasta 100 direcciones cada uno, en lugar de una llamada a la API por cada IP. En RouterOS 7.8rc1 y posteriores cada script es una sola llamada a /execute; en versiones anteriores es un /system/script temporal que el bouncer crea, ejecuta y elimina.

Ese tamaño de bloque no tiene que ver con el tamaño del mensaje — la API de RouterOS admite palabras mucho mayores que estos scripts, y un bloque de 1.000 entradas se transfiere sin protestar. Es el compromiso entre amortizar los viajes de ida y vuelta que cuesta cada bloque (uno con /execute; cuatro con un script guardado: buscar, añadir, ejecutar, eliminar) y cuánto tiempo retiene al router una única ejecución de script no interrumpible. /execute añade un límite propio: no acepta scripts de más de 64 kB, y un bloque de 100 entradas ronda los 22 kB.

Barriéndolo contra un RB5009 con el script guardado — cinco rondas intercaladas de 4.000 entradas con 50/100/250/500/1000 — las medianas caen entre 4,36 s y 5,78 s en todo ese rango de 20×. El resultado útil es que el barrido no puede resolver un ganador: dentro de un mismo tamaño el rango intercuartílico llega a 2,55 s, mayor que los 1,43 s que separan al mejor tamaño del peor, y qué tamaño parece mejor depende del estimador que uses (mediana y mínimo eligen 1.000; la media elige 100).

Lo que sí es estable es la forma: insertar una fila cuesta ~1,2–1,3 ms y domina todo lo demás, así que importar 22.000 entradas gasta unos 27 s insertando frente a entre 0,2 s y 2,3 s de andamiaje de bloques. No hay motivo para cambiar este valor, ni ninguna medición aquí que te diga a qué cambiarlo.

Si un script masivo falla, el bouncer registra un aviso y recurre a adiciones individuales para ese bloque. Las entradas duplicadas se omiten o se refrescan sin reconectar la sesión de la API.

Lo que le cuesta al router la primera reconciliación

Gráfica de líneas del porcentaje de CPU y los megabytes de RAM del router desde 20 segundos antes de arrancar el bouncer hasta 59 segundos después: CPU cerca del 7% antes, alrededor del 31% entre el marcador de inicio de escritura a los 4,8 segundos y el de reconciliación completa a los 18,5 segundos, y de vuelta cerca del 8%; la RAM sube unos 18 MiB cuando el bouncer se conecta y termina unos 16 MiB por encima de donde empezó. — La configuración por defecto en un RB5009UG+S+ con RouterOS 7.24.4, cargando 17.361 entradas, incluida la lista comunitaria de CrowdSec.

Con la configuración por defecto, llenar listas vacías con 17.361 entradas ocupa alrededor del 31% de los cuatro núcleos de este router durante 13,7 segundos, con un pico de 100 ms del 45%, y la primera reconciliación termina 18,5 segundos después de arrancar el bouncer. La mayor parte del escalón de RAM llega al conectarse, antes de la primera entrada; después, el router guarda unos 16 MiB más que sin el bouncer. Ese es el coste de un arranque con las listas vacías, o de una pasada que tiene que volver a escribir buena parte de la lista; una pasada posterior que no encuentra nada que falte sigue leyendo las dos listas, alrededor de 1,5 segundos de trabajo del router a este tamaño en cada reconciliation_interval (ver más abajo).

Con los scripts guardados que recibe RouterOS anterior a 7.8rc1, las mismas entradas tardaron 24,1 segundos en este router, con aproximadamente el doble de tiempo de CPU, y bulk_add_method: api tardó 22,8 segundos con diez sesiones. Benchmarking muestra las tres juntas y cómo se midieron.

CPU del router

mikrotik.cpu_limit (por defecto 80) baja el ritmo de las reconciliaciones mientras la CPU del router está ocupada; Configuración de MikroTik explica cómo. Bájalo en un router que deba guardar más margen para enrutar. Súbelo, o pon 0, en un router que vive siempre cerca de su límite y si no cargaría cada lista al ritmo más lento. crowdsec_bouncer_routeros_throttled y crowdsec_bouncer_routeros_throttle_seconds_total muestran cuándo y durante cuánto tiempo frenó el bouncer.

Un CHR en un host sobresuscrito puede quedarse sin CPU sin que su cpu-load lo muestre: el tiempo que le quita el host no cuenta como ocupado dentro de RouterOS. El límite no ve ese caso; solo tardan más los comandos del bouncer.

Tiempos de espera

Aumenta mikrotik.command_timeout si RouterOS es lento durante operaciones con listas grandes:

mikrotik:
  command_timeout: "60s"

Aumenta mikrotik.connection_timeout solo cuando el propio login inicial TCP/API sea lento:

mikrotik:
  connection_timeout: "20s"

Intervalo de reconciliación

La reconciliación de arranque se ejecuta siempre. La reconciliación periódica repara la deriva después del arranque.

crowdsec:
  reconciliation_interval: "15m"

Usa 0 para desactivar la reconciliación periódica, o un valor de 1m o superior para activarla. Los valores entre 0 y 1m se rechazan en el arranque.

Los intervalos cortos reparan la deriva más rápido, pero leen la address-list entera de RouterOS más a menudo. Lo que eso cuesta es medible: en un RB5009 con 22.332 entradas, una pasada sin deriva tarda 1,86 s, de los cuales las dos lecturas de lista son el 98,5%. Con el valor por defecto de 15m eso es un ciclo de trabajo del 0,2%; con 1m, del 3,1%.

El coste escala con cuántas entradas guarda el router, no con cuánta deriva haya que reparar — una pasada que no encuentra nada cuesta prácticamente lo mismo que una que arregla algo. Así que merece la pena alargar el intervalo con una lista grande y un router modesto, y poco se gana acortándolo por debajo de lo que realmente exija tu tolerancia a deriva sin detectar.

Métricas de tráfico procesado

metrics.track_processed crea reglas de conteo de tipo passthrough para que el bouncer pueda informar del tráfico total evaluado, no solo del tráfico descartado.

metrics:
  track_processed: true

Ponlo a false para evitar esas reglas de conteo adicionales:

metrics:
  track_processed: false

Ejemplo de referencia

crowdsec:
  origins: ["crowdsec", "cscli"]
  reconciliation_interval: "30m"

mikrotik:
  command_timeout: "60s"
  pool_size: 6

metrics:
  enabled: true
  routeros_poll_interval: "30s"
  track_processed: true

Para routers pequeños, prefiere el modo solo local, pool_size: 1 o 2, y evita el CAPI completo hasta que hayas medido el tiempo de reconciliación.