XDP y eBPF para el procesamiento de paquetes de alto rendimiento

XDP (eXpress Data Path) y eBPF (extended Berkeley Packet Filter) permiten a Linux procesar paquetes de red antes de que intervenga la pila de red normal del kernel. En lugar de asignar estructuras de memoria para cada paquete entrante, XDP intercepta el tráfico directamente en el controlador de la tarjeta de red, decide qué hacer con él y lo descarta, reenvía o redirige. El resultado es un procesamiento de paquetes de millones de paquetes por segundo por núcleo, con una fracción de la sobrecarga de CPU de herramientas tradicionales como iptables.

Cómo funcionan conjuntamente eBPF y XDP

eBPF es una máquina virtual dentro del núcleo de Linux. Ejecuta código byte personalizado que ha sido verificado en cuanto a seguridad (sin bucles infinitos ni acceso no autorizado a la memoria) y luego compilado JIT a instrucciones nativas de la CPU. Los programas tienen un alcance limitado. No pueden llamar a funciones arbitrarias del núcleo, solo a un conjunto de ayudantes predefinidos para tareas como búsquedas en mapas y redireccionamiento de paquetes.

Para la gestión de estados, eBPF utiliza mapas, que son almacenes de clave/valor (tablas hash, matrices, árboles LPM) que persisten entre las llegadas de paquetes. Los mapas son legibles y modificables desde el espacio de usuario, por lo que se pueden actualizar listas de bloqueo o reglas de enrutamiento sin necesidad de recargar el programa.

XDP es un punto de enganche de eBPF. Se acopla a la ruta de recepción del controlador de la NIC, antes de que el núcleo asigne una sk_buff estructura (el objeto de metadatos de 200-300 bytes por paquete del que depende la pila de red tradicional). La ganancia de rendimiento proviene precisamente de saltarse esa asignación.

XDP se ejecuta en tres modos:

• Modo nativo: se ejecuta dentro del controlador de la NIC. Ofrece el mejor rendimiento.
• Modo descargado: se ejecuta en el ASIC de la NIC. Libera la CPU por completo.
• Modo genérico: se ejecuta tras sk_buff la asignación. Útil para realizar pruebas en hardware no compatible, pero sin beneficio de rendimiento.

Tras procesar cada paquete, el programa XDP devuelve un veredicto:

XDP frente a iptables: pruebas de rendimiento

Las cifras son contundentes. iptables gestiona aproximadamente 200 000 paquetes por segundo por núcleo. nftables mejora esa cifra hasta unos 400 000 pps. XDP en modo nativo procesa de 10 a 40 millones de pps por núcleo en el mismo hardware.

La razón es sencilla: un XDP_DROP cuesta una comprobación de límites y un valor de retorno. Un iptables DROP requiere sk_buff una asignación, un recorrido de la cadena de netfilter, una consulta de seguimiento de conexiones, la propia acción DROP y, a continuación, una desasignación. A 100 Gbps con paquetes de 64 bytes, un servidor se enfrenta a 148 millones de paquetes por segundo, lo que deja unos 100 nanosegundos por paquete. A esa escala, sk_buff la asignación se convierte en el cuello de botella.

El ahorro de CPU es igual de significativo. Pasar una lista de bloqueados de iptables a XDP en una prueba de rendimiento redujo el uso de la CPU por interrupciones de software del 28 % al 3 % a 1 millón de pps. Ese margen liberado permite ejecutar procesos de aplicaciones, bases de datos o máquinas virtuales en el mismo servidor.

Mitigación de DDoS y seguridad

El caso de uso más destacado de XDP en el ámbito del alojamiento web es la mitigación de DDoS. Dado que opera a nivel de controlador, los paquetes maliciosos se descartan antes de que lleguen a la pila de red del kernel. Un solo núcleo que ejecute XDP puede descartar 26 millones de paquetes por segundo.

Cloudflare lleva utilizando desde al menos 2018 un sistema basado en XDP llamado L4Drop para la mitigación de DDoS volumétricos. El sistema procesa y descarta el tráfico de ataque en el contexto de XDP, impidiendo que llegue a la capa de aplicación. Katran, de Meta, un equilibrador de carga de capa 4 de código abierto basado en XDP, gestiona el tráfico de Facebook e Instagram a más de 10 millones de paquetes por segundo por núcleo.

Para el filtrado dinámico, los mapas eBPF como BPF_MAP_TYPE_LPM_TRIE permiten gestionar listas de bloqueo de IP que abarcan direcciones IP individuales y subredes CIDR en una sola consulta. Las actualizaciones se realizan desde el espacio de usuario en tiempo real, sin necesidad de recargar el programa. Durante un ataque activo, se pueden enviar nuevas firmas en milisegundos utilizando bpftool:

bpftool map update id <MAP_ID> key <KEY_VALUE> value <VALUE>

En cuanto a la observabilidad, eBPF recopila métricas por aplicación, por IP y por flujo directamente desde la ruta de datos del kernel. El xdp_md contexto proporciona telemetría como ingress_ifindex y rx_queue_index, para que puedas identificar qué interfaz o cola está bajo presión. Para la monitorización a largo plazo, herramientas como ebpf_exporter convierten los datos de mapa eBPF sin procesar en métricas compatibles con Prometheus para su visualización en Grafana.

Herramientas, implementación y requisitos de hardware

La cadena de herramientas comienza con Clang y LLVM para compilar C restringido en código byte eBPF. A partir de ahí, se necesita una biblioteca de carga:

• libbpf: la biblioteca C estándar para uso en producción. Admite CO-RE (Compile Once, Run Everywhere) para la portabilidad entre kernels.
• libxdp: específica de XDP, admite la ejecución de múltiples programas XDP en una sola interfaz.
• cilium/ebpf: una biblioteca Go pura para pilas basadas en Go.

Para la gestión, bpftool te permite inspeccionar programas en tiempo real y mapear contenidos. xdp-loader (de la xdp-tools suite) se encarga de la carga y descarga. BCC es útil para la creación de prototipos con front-ends de Python/Lua, pero libbpf con CO-RE es la mejor opción para producción.

Habilita el compilador JIT de BPF antes de la implementación:

sysctl -w net.core.bpf_jit_enable=1

Para actualizaciones sin tiempo de inactividad, utiliza la XDP_FLAGS_REPLACE indicador para intercambiar de forma atómica un programa en ejecución. Fija los mapas a /sys/fs/bpf/ para que persistan después de que el cargador se cierre.

Compatibilidad de hardware y del kernel

XDP se introdujo en el kernel 4.8, pero se recomienda 5.x o posterior para disponer de todas las funciones. Comprueba tu kernel con uname -r y compruebe que el sistema de archivos BPF existe en /sys/fs/bpf/.

Tu controlador de NIC determina qué funciones de XDP están disponibles:

Comprueba tu controlador con ethtool -i <interface>. Si el modo nativo no es compatible, el sistema recurre al modo genérico, que se ejecuta tras sk_buff la asignación y no ofrece ninguna ventaja de rendimiento.

Desactive GRO y LRO antes de conectar un programa XDP, ya que entran en conflicto:

ethtool -K <iface> gro off lro off

El XDP estándar requiere que los paquetes quepan en una sola página de memoria de 4096 bytes. En i40e los ice , el límite de MTU de x86 es de 3.046 bytes.

Introducción a XDP

Empieza por evaluar tu entorno. Ejecuta uname -r para confirmar que el kernel es 4.8+ (se prefiere 5.x), y ethtool -i <interface> para comprobar la compatibilidad nativa con el controlador XDP.

Empieza por la observabilidad, no por la aplicación. Utiliza mapas eBPF para clasificar y contar el tráfico, de modo que tengas una referencia de la actividad normal. Una vez que comprendas tus patrones de tráfico, pasa a la aplicación: prueba primero con el xdpgeneric modo y, a continuación, cambie a xdpdrv (nativo) para la producción.

Tenga en cuenta que XDP gestiona el filtrado a nivel de paquete, no el ancho de banda bruto. Para ataques a gran escala a 100 Gbps, combínelo con infraestructura bare-metal y BGP FlowSpec para gestionar el tráfico ascendente antes de que llegue al servidor.

Si ejecutas cargas de trabajo de alto tráfico que requieren un filtrado rápido de paquetes, los servidores dedicados de FDC proporcionan la base bare-metal para sacar el máximo partido a XDP.