hardware y dimensionamiento

El servidor correcto depende de su rol

EdgeWarden es un solo paquete que funciona como all-in-one, analyzer o scrubber, definido por una línea en config.toml. Cada rol exige un recurso distinto: el que analiza vive de disco y memoria; el que limpia tráfico vive de la tarjeta de red y de los núcleos.

Pedir ayuda para dimensionar Ver la demanda por rol

Vale para todos los roles

Sistema
Debian 13 (Trixie), kernel 6.12
Arquitectura
x86_64
Software
El mismo paquete y el mismo binario en los tres roles; la licencia define la cuota de nodos de limpieza
Tarjeta para filtrar
XDP nativo en el driver: mlx5, ice, i40e o ixgbe
demanda por rol

Dónde exige cada rol

Una escala relativa entre roles para orientar la compra. El número exacto depende del volumen de flows, de la retención y del tráfico que atraviesa el filtro.

Demanda relativa de CPU, RAM, disco y red por rol de nodo
Rol CPU RAM Disco Red Qué lo exige
All-in-oneel predeterminado Mediacrece con los flows/s Alta Altacrece con la retención Bajamuy alta si filtra en línea Recolección, análisis, bases de datos, interfaz y filtro en la misma máquina. En la instalación típica solo recibe muestras de flow y anuncia FlowSpec; quien descarta es el router. Si además filtra en línea, sume la demanda del scrubber.
Analyzerfuera del camino del tráfico Mediacrece con los flows/s Alta Altacrece con la retención Baja Ejecuta ClickHouse, MariaDB, Redis, GoBGP y la interfaz. Solo recibe muestras de flow, así que la tarjeta importa poco; ClickHouse quiere NVMe y memoria libre para la caché de páginas, y el swap arruina la latencia.
Scrubberen el camino del tráfico desviado Muy altapor núcleo, en el nodo NUMA de la tarjeta Baja Bajasin bases locales Muy altaXDP nativo, PCIe x16 Solo el core con el filtro XDP, sin bases de datos, sin BGP y sin interfaz. Lo que cuenta es una tarjeta con XDP nativo, núcleos físicos en el mismo nodo NUMA que ella y un slot PCIe x16 de generación suficiente.
Packet Sensormódulo opcional (SPAN/TAP) Alta Media Media Alta Captura de paquetes para detectar en menos de 1 s y leer SNI, DNS y HTTP Host. No es un rol: se suma al all-in-one o al analyzer (el scrubber lo desactiva). Orden de magnitud estimado por motor: libpcap ~1–2 Gbps y AF_PACKET v3 ~5 Gbps; la captura por AF_XDP y el motor DPDK llegan próximamente.

Baja, Media, Alta y Muy alta comparan los roles entre sí; no son mediciones.

En el scrubber, menos es más. El nodo de limpieza usa el mismo paquete, pero solo arranca el core. No instale MariaDB, Redis, ClickHouse, Apache, PHP, Node.js, GoBGP ni certbot: lee la cola de mitigación en el ClickHouse del analyzer.

Firewall solo con nftables, nunca con ufw, que descartaría el tráfico limpio.

dos nodos

Un nodo fuera del camino, otro dentro de él

Cuando hay limpieza de tráfico, el modo recomendado separa a quien decide de quien recibe el ataque. Por eso cada máquina tiene una lista de compras distinta.

Dos nodos: analyzer fuera del camino del tráfico y scrubber en el camino del tráfico desviado El router de borde envía muestras de flow al analyzer, que anuncia por BGP el desvío de la víctima. El router entrega el tráfico desviado al scrubber por el puerto sucio; el scrubber lo filtra con XDP y devuelve el tráfico limpio por el puerto limpio, que sigue hacia la red del cliente. El analyzer consulta el /health del scrubber cada 10 segundos, y los dos nodos comparten la cola de mitigación en ClickHouse. Internet víctima + ataque Router de borde tabla principal + CLEAN Red del cliente 203.0.113.10 limpio muestras de flow NetFlow · sFlow BGP desvío /32 · /128 puerto sucio (desvío) puerto limpio (CLEAN) Analyzer fuera del camino del tráfico colector · detección · GoBGP ClickHouse · MariaDB · Redis interfaz web y API exige: disco NVMe y RAM Scrubber en el camino del tráfico desviado core + filtro XDP en el driver sin bases, sin BGP, sin UI devuelve el tráfico limpio exige: tarjeta de red y núcleos GET /health · 10 s 3 fallas: retirar cola de mitigación ClickHouse :8123 Dos nodos: analyzer fuera del camino del tráfico y scrubber en el camino del tráfico desviado El router de borde envía muestras de flow al analyzer, que anuncia por BGP el desvío de la víctima. El router entrega el tráfico desviado al scrubber por el puerto sucio; el scrubber lo filtra con XDP y devuelve el tráfico limpio por el puerto limpio, que sigue hacia la red del cliente. El analyzer consulta el /health del scrubber cada 10 segundos, y los dos nodos comparten la cola de mitigación en ClickHouse. Internet víctima + ataque Red del cliente 203.0.113.10 Router de borde principal + CLEAN flows BGP sucio limpio Analyzer fuera del camino colector · detección GoBGP · ClickHouse MariaDB · Redis · UI exige disco y RAM Scrubber en el camino desviado core + filtro XDP sin bases de datos sin BGP, sin UI exige tarjeta y núcleos GET /health · 10 s cola de mitigación ClickHouse :8123
Modo B, el recomendado para limpiar tráfico. En Juniper MX, el puerto sucio y el limpio comparten el mismo cable; en Huawei NE40E/NE8000 son dos puertos.
  • AnalyzerRecibe las muestras de flow del router, detecta y anuncia por BGP el desvío /32 o /128 de la víctima, con next-hop en el scrubber.
  • Puerto sucioEl router entrega al scrubber solo el tráfico de la víctima desviada, no la red entera.
  • Puerto limpioLo que pasa por XDP vuelve al router por la tabla CLEAN, que nunca contiene el desvío. No hay bucle.
  • Monitor de saludEl analyzer consulta el /health del scrubber cada 10 s. Tres fallas seguidas retiran los desvíos activos; una respuesta correcta vuelve a habilitar el desvío.
  • Cola de mitigaciónLos dos nodos se comunican por el ClickHouse del analyzer. El puerto 8123 queda abierto solo para el scrubber; el 8090, del /health, solo para el analyzer.
tamaños de referencia

Tres tamaños, según el volumen de flows

Los tamaños dimensionan la máquina que recolecta y analiza (all-in-one o analyzer). El scrubber se dimensiona por la tarjeta de red, en las secciones siguientes.

Small

ISP regional

Hasta 20K flows/sredes de hasta ~5 Gbps

CPU
8 núcleos (Xeon / EPYC)
RAM
32 GB DDR4
Disco
500 GB NVMe SSD
Red
1 Gbps
Sistema
Debian 13+ (Trixie)

Medium

recomendado

ISP / DC mediano

Hasta 50K flows/sredes de hasta ~20 Gbps

CPU
16 núcleos (Xeon Scalable / EPYC)
RAM
64 GB DDR4 ECC
Disco
2 TB NVMe SSD
Red
10 Gbps
Sistema
Debian 13+ (Trixie)

Enterprise

Tier-1 / DC grande

100K+ flows/sredes de 40 Gbps+

CPU
32+ núcleos (EPYC / Xeon Platinum)
RAM
128+ GB DDR4/DDR5 ECC
Disco
4+ TB NVMe (RAID 10)
Red
25 / 40 / 100 Gbps
Sistema
Debian 13+ (Trixie)
  • eBPF/XDP: Debian 13 ya trae kernel 6.x; use una tarjeta con XDP nativo (se recomiendan Mellanox o Intel).
  • ClickHouse: a partir del tamaño Medium, sepárelo en un servidor dedicado.
  • Retención: dimensione el disco según el período de retención deseado (compresión de cerca de 10:1).
  • Alta disponibilidad: en Enterprise, se recomienda un clúster de 2 o más nodos.
centro de limpieza

Centro de limpieza de referencia: Dell PowerEdge R760

El montaje documentado en detalle para limpiar tráfico a 100G. Un servidor equivalente sigue la misma lógica: una tarjeta por CPU, slot x16 y XDP nativo.

Tarjetas
2 × NVIDIA/Mellanox ConnectX-6 Dx (MCX623106A) con 2 puertos de 100G cada una: 4 × 100G. También sirven ConnectX-5 Ex, ConnectX-6 y ConnectX-7.
Slots
Una tarjeta por CPU: slots 2 + 7 (PCIe Gen5 x16) o 3 + 6 (Gen4 x16).
Conexión
Hoy, un router por scrubber: un puerto de 100G o LACP con un puerto de cada tarjeta (200G), que sigue en pie si falla una tarjeta completa. Los demás routers desvían a través de él, con una VLAN limpia entre ellos. Conexión directa a varios routers (hasta 4 Juniper o 2 Huawei): próximamente.
Sistema
Debian 13, kernel 6.12 LTS con BTF, intel_iommu=on iommu=pt, sin irqbalance y con el driver mlx5 del propio kernel (sin MLNX_OFED).
BIOS
Perfil Performance, Sub-NUMA Cluster desactivado, SR-IOV desactivado.
Ajuste de la tarjeta
Una cola por núcleo físico del nodo NUMA de la tarjeta, anillos de 4096, LRO y GRO por hardware desactivados, qdisc mq y afinidad de IRQ fija, reaplicados en el arranque por una unit de systemd.
Gestión
iDRAC fuera de banda; la gestión del host pasa por el puerto de datos.

Dos modos de implementación

Modos de implementación del centro de limpieza
ÍtemModo A: todo en el R760Modo B: analyzer separado recomendado
En el R760Colector, ClickHouse, MariaDB, interfaz, GoBGP y XDPSolo el core con XDP
BGP con el bordeEl propio R760El analyzer
Monitor de saludNo hace faltaObligatorio

Bordes con plantilla de camino limpio

Juniper MXValidado en producción

Un puerto por router, sucio y limpio en el mismo cable; un filtro de entrada envía el tráfico limpio a la routing-instance CLEAN. IPv4 e IPv6.

Huawei NE40E / NE8000Validación pendiente

Plantilla VRP8 escrita a partir de la documentación oficial, con un puerto sucio y uno limpio. Aún necesita validación en laboratorio.

Capacidad: lo que se puede afirmar

148,8Mpps

Tasa de línea de un puerto de 100G con tramas de 64 B: el peor caso que el filtro tiene que enfrentar.

~24Mpps

Descarte XDP por núcleo en la literatura (paper XDP, CoNEXT 2018, ConnectX-5 Ex). referencia, no benchmark de EdgeWarden

80%

Tope de desvío sobre la capacidad medida en su implementación. Por encima de eso, la decisión pasa a scrubbing externo, FlowSpec sobre el vector y, en último caso, RTBH.

Arquitectura 100G/200G por router, con capacidad validada en cada implementación. Descartar es barato; el tráfico limpio que sigue adelante cuesta un orden de magnitud más y no tiene cifra publicada. Por eso la capacidad se mide en la instalación y queda registrada en el sistema, y el tope del 80 % se aplica sobre ella.

tarjetas de red

Lo que cuenta es el XDP nativo

El filtro corre en el driver de la tarjeta. Sin soporte nativo, EdgeWarden pasa al modo genérico (SKB): funciona, pero el paquete se filtra recién después de que el kernel ya gastó recursos en él.

Tarjetas de red recomendadas para eBPF/XDP
TarjetaDriverVelocidadXDPObservación
Gama alta
Mellanox ConnectX-5 / 6mlx525G / 100GNativoEl mejor soporte de XDP nativo. Para dos puertos de 100G a la vez, use ConnectX-5 Ex, ConnectX-6 Dx o ConnectX-7.
Intel E810ice25G / 100GNativoGeneración actual de Intel, con XDP completo.
Costo-beneficio (producción)
Intel X710i40e10G / 40GNativoExcelente soporte de XDP, muy probada.
Intel X520 / X540ixgbe10GNativoMás antigua, pero con XDP sólido y fácil de conseguir usada.
Mellanox ConnectX-4mlx510G / 25GNativoMuy buen precio en el mercado de usados.
Laboratorio
Intel I350 / I210igb1GBásicoBuena para pruebas.
virtio-netvirtioVMPruebaPara pruebas en VM con KVM.

Para recibir ataques reales, el mínimo es una Intel X520 (10G); lo ideal, una Mellanox ConnectX-5 (25G).

200 Gbps exige PCIe 4.0 x16. La ConnectX-5 común (MCX516A-CCAT, PCIe Gen3) no sostiene dos puertos de 100G al mismo tiempo, y en un slot x8 ninguna tarjeta entrega la tasa nominal.

En VM con vmxnet3, el XDP nativo exige kernel 6.3 o más reciente; por debajo, solo modo genérico. El orden de magnitud queda en 1–2 Gbps.

Identifique la tarjeta por el driver, nunca por la MAC: ya apareció un OUI de Mellanox en una tarjeta Intel.

verificación

Cómo verificar el servidor

Comandos de solo lectura: no cambian nada en la tarjeta ni en el sistema. El ajuste en sí (anillos, colas, IRQ) está en el paso 11 de la guía de instalación y requiere ventana de mantenimiento.

bash · solo lectura
IF=eth0   # interfaz del plano de datos (la que recibe el tráfico sucio)

# Driver de la tarjeta: define si XDP puede correr nativo
ethtool -i $IF | grep driver

# Nodo NUMA de la tarjeta (0 o 1; -1 = BIOS sin SLIT)
cat /sys/class/net/$IF/device/numa_node

# ¿En qué modo arrancó XDP? (con el core en marcha)
ip -d link show $IF | grep -i xdp
#    "xdp"        = nativo, en el driver — obligatorio a esta escala
#    "xdpgeneric" = fallback SKB, corre DESPUÉS de GRO

# Verificar si la tarjeta está descartando paquetes (todo debe quedar en cero)
ethtool -S $IF | grep -iE "drop|discard|miss|nobuf|error" | grep -v ": 0$"

# Ancho y generación del slot PCIe
lspci -vv -s $(basename $(readlink /sys/class/net/$IF/device)) | grep -i "LnkSta:"

Qué esperar

  • Driver mlx5_core, ice, i40e o ixgbe: XDP nativo disponible.
  • xdp en la salida de ip link: el filtro está en el driver. Si aparece xdpgeneric, resuelva la tarjeta o el driver antes de poner tráfico real.
  • Contadores: ninguna línea en la salida de ethtool -S, es decir, nada descartado en la tarjeta.
  • LnkSta: Width x16 y Speed 16GT/s (Gen4) o 32GT/s (Gen5). x8 o Gen3 indica slot o riser equivocado, con la mitad del ancho de banda.
  • NUMA: use solo los núcleos del nodo de la tarjeta; 16 colas en el nodo correcto rinden más que 64 repartidas.

¿Necesita ayuda para dimensionar?

Cuéntenos el volumen de flows, la retención que quiere mantener y cuántos routers van a desviar a limpieza. El equipo le indica el servidor y la tarjeta de cada rol. La atención se brinda en portugués.

Hablar con el equipo Hablar por WhatsApp
Guía de instalación Plataforma y roles de nodo