VPP en Producción: Arquitectura, Rendimiento Real y el Fin de la Caja Negra en el Forwarding Linux

Lo primero: no quiero arrancar este episodio sin dar las gracias como se merece a IPng Networks y, en especial, a Pim Van Pelt. Tuve la suerte de compartir un café con él en el ESNOG de Barcelona hace un par de años, y te das cuenta en cinco minutos de que no solo sabe una barbaridad, sino que además tiene la capacidad de explicar cosas muy complejas de forma clara y honesta. Su trabajo y su manera de compartir conocimiento han ayudado a muchos a entender qué demonios está pasando realmente dentro del plano de datos moderno. Este episodio, en buena parte, nace de esa base de conocimiento que otros han currado antes.

Y ahora sí, como dice Felipe, vamos al lío.

Este episodio es la primera parte de un análisis bastante serio —pero contado como lo contaría alguien que lleva más de veinte años en telecomunicaciones— sobre algo que casi todos hemos sufrido alguna vez: tienes un servidor Linux con buena CPU, buena RAM, tarjetas modernas… y de repente empieza a perder paquetes. O aparece jitter. O la latencia hace cosas raras. Y miras la CPU global y está al 20 %. Y piensas: “¿Pero qué está pasando aquí?”

La clave no está en la potencia bruta. Está en el modelo de procesamiento.

El stack de red del kernel Linux está pensado para ser generalista. Tiene que servir para servidores web, bases de datos, firewalls, virtualización, mil aplicaciones a la vez. Cada paquete que entra genera interrupciones, estructuras dinámicas, validaciones, decisiones del scheduler… Todo eso funciona muy bien cuando la carga es razonable.

Pero cuando empiezas a hablar en serio de paquetes por segundo, la historia cambia. No tanto por los gigabits, sino por los pps. Empiezan las invalidaciones de caché, la carga se concentra en una o dos colas, aparecen microbursts que no se absorben bien y el sistema empieza a comportarse de forma poco predecible. No es que Linux “no pueda”. Es que no está optimizado exclusivamente para forwarding masivo.

Aquí es donde entra el enfoque vectorial.

En vez de tratar cada paquete como si fuera un evento único que requiere atención inmediata, el modelo vectorial los agrupa en lotes y los procesa en bloque. Se reducen transiciones, se mantiene la caché caliente y la CPU hace lo que mejor sabe hacer: ejecutar el mismo código repetidamente sobre datos similares.

En lugar de vivir a base de interrupciones, los cores dedicados al plano de datos hacen polling continuo. Sí, están preguntando todo el rato si hay trabajo. A primera vista parece poco eficiente, pero cuando te mueves en millones de paquetes por segundo, el coste del polling es mucho menor que el de gestionar millones de interrupciones.

Sobre esta idea se construye VPP, el Vector Packet Processor. Es un plano de datos en espacio de usuario que, apoyándose en DPDK, toma control directo de las interfaces de red. Organiza el procesamiento como un grafo de nodos: uno clasifica capa 2, otro analiza IP, otro hace el lookup en la FIB, otro reescribe cabeceras, otro aplica ACLs… y todo eso lo hace sobre vectores de buffers ya reservados en hugepages. No hay malloc por paquete. No hay estructuras que se creen y destruyan constantemente.

Y aquí ya nos metemos en terreno físico de verdad: cachés L1, L2, L3, predicción de saltos, TLB, hugepages… Esto no va solo de “configurar BGP”. Va de entender cómo funciona la CPU por dentro. Si ejecutas el mismo código sobre datos contiguos, la caché trabaja a tu favor. Si accedes a memoria del otro socket NUMA, el coste sube. Si no alineas bien colas RSS con workers, puedes saturar un core mientras el de al lado está mirando.

Todo cuenta: CPU, memoria, NIC y cómo lo configuras.

Otro punto importante es que esto no elimina el kernel. Lo separa. El forwarding masivo lo hace el motor vectorial en el plano de datos, pero el plano de control sigue en Linux. Bird o FRR gestionan BGP, OSPF, lo que toque. La sincronización entre ambos mundos se hace por Netlink: el kernel mantiene el RIB y VPP ejecuta la FIB real.

Eso funciona muy bien… siempre que lo entiendas. En una reconvergencia gorda, con miles de rutas BGP entrando o saliendo, puedes generar una tormenta de mensajes Netlink. Si no dimensionas bien los buffers o no separas cores correctamente, puedes tener problemas de sincronización. No es magia. Es ingeniería.

También se habla de cosas muy de campo: caída de enlaces físicos, BFD reaccionando en milisegundos, microbursts, tráfico de paquetes mínimos que te revientan el pps aunque el Gbps no sea alto, y RSS repartiendo mal la carga.

Aquí aparece una métrica que me parece brutal: el “vector size”. Si ves que el promedio se acerca a 256 buffers por llamada, sabes que ese worker está cerca del límite. Mucho más útil que mirar la CPU global y quedarte tranquilo. Es una manera mucho más honesta de saber dónde estás.

A partir de ahí, el dimensionamiento cambia completamente. Dejas de hablar de “este servidor es más potente” y empiezas a hablar de ciclos por paquete. Si el forwarding básico consume X ciclos y añadir NAT o VXLAN suma Y más, puedes estimar cuántos millones de paquetes por segundo puede manejar cada core. Eso ya no es intuición, es matemática.

También se compara de forma honesta con ASIC. Los ASIC siguen siendo impresionantes. Para ciertas escalas y latencias mínimas, son imbatibles. No desaparecen ni mucho menos. Pero el espacio intermedio ha cambiado mucho. Hoy un servidor bien diseñado puede hacer cosas que hace diez o quince años solo estaban al alcance de hardware muy especializado.

La diferencia es que aquí tienes flexibilidad software. Puedes evolucionar, automatizar, versionar configuración, integrar métricas con Prometheus, tratar el router como infraestructura como código.

Y eso cambia la mentalidad.

El plano de datos deja de ser una caja negra. Empiezas a medir ciclos por nodo, vectores procesados, presión de buffers. Dejas de sobredimensionar “por si acaso” y empiezas a dimensionar con números reales.

No es una solución mágica ni sirve para todo el mundo. Requiere entender CPU, hugepages, NUMA, afinidad de cores y cómo se comporta el sistema bajo carga real. Pero si te dedicas a esto desde hace años y te gusta entender lo que pasa de verdad debajo del capó, es difícil no interesarse.

En el fondo, este episodio no va solo de reenviar más tráfico. Va de entender cómo se mueven los paquetes dentro de una máquina moderna, por qué a veces todo parece ir bien hasta que deja de irlo, y cómo rediseñar el plano de datos para que, cuando aprietes de verdad, el sistema responda de forma estable y predecible.

Artículos de VPP en IPngNetworks: https://ipng.ch/s/articles/

Foto de Alex wolf mx: https://www.pexels.com/es-es/foto/carretera-coche-deportivo-deportes-de-motor-carrera-14401648/