Resumen

  • 5x9 Networks atribuye a un Xeon 6780E de 144 núcleos un forwarder para 64.000 abonados, 200 Mpps con ACL y sin QoS jerárquica, y 800 Gbps con paquetes de 500 bytes. Los 1,6 Tbps corresponden a dos CPU.
  • La Big VM sustituye dieciséis Small VM y evita copias repetidas de estado en caché. La mejora de localidad está explicada; la continuidad del límite mayor de ejecución y sesiones no está medida en la documentación pública.
  • El operador necesita ensayar sincronización de estado, fallos, reinicio, actualización, sesiones perdidas y recuperación bajo una mezcla declarada de funciones. Una ruta de rendimiento no es, por sí sola, capacidad disponible.

El 11 de febrero de 2026, Branimir Rajtar, CTO y cofundador de 5x9 Networks, intervino en la sesión Network Operations de APRICOT en Yakarta. Su presentación de 19 páginas, Getting 1+ Tbps from an x86 server, relata la evolución de un Broadband Network Gateway virtualizado desde múltiples máquinas pequeñas hacia un único proceso grande optimizado alrededor de CPU, memoria, SR-IOV, DPDK, PCIe y tarjetas de red.

El BNG es el lugar donde las sesiones PPPoE o IPoE dejan de ser una línea de acceso y entran en el servicio IP. Puede aplicar enrutamiento de capa 3, QoS y ACL por usuario, AAA y obligaciones de interceptación legal. La cifra de paquetes importa, pero el activo operativo incluye el estado que relaciona esos paquetes con cada abonado.

La primera configuración publicada por 5x9 tenía dos Xeon Gold de segunda generación, dieciocho núcleos por CPU y dieciséis forwarders. El proveedor declara 40 Mpps sin QoS jerárquica y 26 Mpps con ella; con paquetes de 500 bytes, 160 y 100 Gbps. La reducción de aproximadamente 35% pertenece a ese diseño. No demuestra un coste universal de QoS, pero sí invalida una cifra de capacidad que no indique qué funciones estaban activas.

El recorrido posterior combina varias capas. 5x9 atribuye un 30% a hardware más reciente y trabajo de aplicación, otro 30% a optimización de DPDK, CPU, PCIe, BIOS y NIC, y un 20% a perfilado y reescritura. No es una fórmula transferible. Es un inventario de dependencias que impide explicar el resultado sólo con la palabra x86.

Según la presentación, el cuello de botella principal terminó siendo las esperas y fallos de caché de la CPU. Muchos objetos de memoria ocupaban espacio y sus cambios provocaban paradas. El equipo separó estructuras de lectura y escritura, ajustó la planificación PCIe/DMA y los algoritmos hash, y afirma haber reducido en 90% la huella de la tabla de rutas.

Las dieciséis Small VM guardaban la misma información varias veces en caché. La Big VM las combina, abarca un dominio NUMA entero y emplea todos los núcleos para compartir un conjunto de trabajo. La explicación es física: menos duplicación puede reducir accesos a memoria principal, esperas, tablas repetidas y procesos.

La arquitectura más eficiente no carece de un lugar donde fallar. El punto se vuelve visible en la configuración actual: una CPU Xeon 6780E de 144 núcleos, un forwarder y 64.000 abonados. Intel especifica 108 MB de caché, hasta 88 líneas PCIe 5.0 y 330 W de TDP en modo servidor. Esas características no validan el benchmark, pero mantienen CPU, memoria, ranuras, NIC y alimentación dentro de la cadena de capacidad.

5x9 publica 200 Mpps con ACL y sin QoS jerárquica, 800 Gbps con paquetes de 500 bytes y 32 GB de memoria. Para alcanzar 1,6 Tbps escala a dos CPU. La unidad debe permanecer en el relato: no es correcto presentar el total de un servidor de dos sockets como si fuera el resultado de una CPU.

Tampoco es correcto retirar las condiciones de servicio. La presentación dice que el rendimiento empieza a caer por encima de 100.000 abonados, aunque soporta hasta 260.000. Activar QoS jerárquica para todos reduce alrededor de 30%; aplicar NAT a todos, entre 30 y 40%. Son datos del proveedor y de su implementación, no leyes generales. Aun así, muestran que el camino de 800 Gbps no representa automáticamente una carga BNG completa.

DPDK y SR-IOV recortan la ruta del paquete. Los Poll Mode Drivers acceden directamente a descriptores de recepción y transmisión y sondean las colas sin depender de las interrupciones normales. SR-IOV expone Virtual Functions desde una función física PCIe. Ninguno define cómo se replica el estado, cuántas sesiones se reinician al perder una función o una NIC, ni cómo asume otro servidor el conjunto activo.

La separación CUPS tampoco resuelve por definición esa pregunta. Mantener control y user plane en componentes distintos puede aislar funciones, pero un controlador vivo no conserva los paquetes ni las sesiones cuando desaparece la Big VM, la CPU, el trayecto PCIe, la tarjeta o el servidor del user plane.

En el expediente público no hay topología redundante, mecanismo de sincronización ni reserva N+1. No hay una prueba que mate el forwarder, retire una Virtual Function, pierda una NIC, una CPU o un servidor. No se publican tiempo de reinicio, actualización, rollback, sesiones perdidas o recuperadas, distribución mixta de paquetes, carga simultánea de QoS/NAT/control ni aceptación en un cliente de producción.

La ausencia no significa que 5x9 carezca de esas funciones y no permite afirmar que la Big VM haya fallado. Significa algo más limitado: la presentación mide una ruta de rendimiento y deja sin medir la conducta del dominio de sesiones durante un fallo o cambio.

La diferencia con Small VM es una decisión, no un veredicto. El diseño pequeño paga por duplicar caché y tablas, pero puede asociar un proceso a menos abonados. El grande mejora la localidad y concentra más estado en una sola unidad de software, CPU y mantenimiento. Varios forwarders grandes, servidores separados o replicación podrían limitar el impacto. Esa capa no aparece en las diapositivas.

El propietario de cada evidencia también es distinto. 5x9 controla código, instrumentación, configuración de prueba y afirmación comercial. Intel y los proveedores de NIC controlan silicio, firmware y compatibilidad. El operador de acceso decide topología, reserva, funciones, ventana de cambio y criterios de restauración. APRICOT conserva y publica la exposición; no certifica el servicio.

El coste sigue esa distribución. El operador compra procesadores actuales, tarjetas soportadas, chasis con PCIe suficiente, licencias, ingeniería, repetición de pruebas y capacidad ociosa para recibir carga. Menos servidores activos puede ahorrar espacio y operación. No hay cálculo de coste total ni medición energética en la presentación. La reserva que puede recuperar estado y funciones sigue siendo parte del precio.

Los abonados sólo reciben el beneficio si la continuidad está probada. Una plataforma flexible y con menos servidores puede abaratar el acceso. Una concentración sin recuperación limitada puede correlacionar más sesiones ante un mismo evento. El artículo no atribuye un incidente; exige que la aceptación distinga ambos escenarios.

La contrafactual creíble conserva el Big VM y añade la prueba que falta. Dos o más forwarders y servidores con reserva N+1 y estado sincronizado; una carga declarada de tamaños de paquete, IPv4/IPv6, ACL, QoS jerárquica, NAT, AAA y transacciones de control; fallos deliberados de proceso, VF, NIC, CPU y servidor; actualización y rollback. El acta debe registrar sesiones reiniciadas, tiempo de recuperación y rendimiento estable mientras opera la reserva.

En un borde con menos usuarios, la Small VM puede seguir siendo preferible si su límite menor compensa el coste de caché; 5x9 lo reconoce. Un ASIC o white box sólo ofrece una comparación legítima bajo la misma mezcla y el mismo ensayo de fallo.

El ASN y los prefijos no llenan la casilla vacía. Pueden atribuir el recurso y mostrar que BGP anuncia una ruta. No certifican las sesiones, el NAT o la QoS dentro del gateway. Ni un RIR ni una conferencia adquieren autoridad para aceptar esa capacidad interna por publicar o registrar la ruta.

El valor técnico de la presentación reside en haber encontrado límites concretos en caché, memoria, NUMA, PCIe, NIC y código. El límite siguiente también es concreto: un forwarder, su estado y el servidor que lo sostiene.

La capacidad vendible incluye recuperación, no sólo paquetes por segundo. Los 800 Gbps de una CPU y los 1,6 Tbps de dos son resultados útiles dentro de sus condiciones. Sólo se convierten en capacidad disponible cuando la misma arquitectura atraviesa el fallo y el cambio que el operador promete absorber.

Fuentes