Si está leyendo esto, probablemente esté de acuerdo en que la revolución de las redes abiertas es real. Recientemente he asistido a la Cumbre Mundial de OCP y a la Cumbre ONE de la Fundación Linux, y lo cierto es que se respiraba electricidad en el aire. El tamaño de la comunidad ha crecido de forma espectacular y cada día atrae a nuevos usuarios y proveedores.

En Hedgehog, estamos construyendo un tejido de red utilizando un código totalmente abierto. NOS (SONiC) para las modernas cargas de trabajo nativas de la nube. Cuando hablo con la gente sobre lo que está ocurriendo en el ecosistema SONiC, la respuesta más común es: "¿No es esto lo que intentó hacer Cumulus Networks?".

El "Open Networking" no es nuevo. Cualquiera que haya estado en este segmento de la industria de las redes estará familiarizado con el auge de una empresa llamada Cumulus Networks.

Introduzca la tortuga cohete

Cumulus tuvo un ascenso al estrellato bastante emocionante, pero no consiguió crear lo que la industria necesitaba, UNA REVOLUCIÓN REAL.

Cumulus basó toda su estrategia empresarial en la idea de que toda la infraestructura de servidores ya había pasado de los sistemas operativos propietarios a Linux. Los administradores de servidores disponían ahora de herramientas (Ansible/Chef/Puppet) que les permitían gestionar miles de dispositivos, pero los operadores de red estaban atascados con unos conjuntos de herramientas de la edad de piedra basados en CLI y, como resultado, no podían ampliar sus conocimientos para gestionar más dispositivos. Así que Cumulus se propuso crear un sistema operativo de red (NOS) basado en Linux y en una distribución genérica (Debian) que pudiera ejecutarse en hardware de caja blanca.

La conmutación de caja blanca también era algo nuevo en aquella época. Los mayores clientes del mundo (en su mayoría hiperescaladores) habían estado comprando conmutadores básicos a fabricantes de dispositivos originales (ODM) que contenían ASIC de Broadcom, Marvell o Mellanox. Dado que Cisco utilizaba en aquel momento Broadcom Trident 2 en muchos de sus productos, Cumulus podía prometer el mismo nivel de rendimiento siempre que consiguiera el software necesario para programar correctamente el ASIC. ASIC hardware.

Bueno, ése era el plan. El concepto suscitó mucha expectación. Los administradores de red estaban llenos de quejas en ese momento, desde las costosas licencias, a los precios exorbitantes de las ópticas SFP propietarias que eran idénticas a las que los clientes podían comprar por una décima parte del precio, al "churn" de las cajas (EOL de una plataforma una vez que se ha lanzado una nueva). Un conocido analista llegó incluso a mencionar que Cumulus y la conmutación de cajas blancas eran una amenaza existencial para los principales vendedores de cajas. Esa predicción se basaba en que los clientes estaban dispuestos a renunciar a sus CLI por un prompt bash de linux.

Bueno, Cumulus despegó, y de hecho adquirió muchos clientes, pero era increíblemente difícil conseguir cada cliente. Verás, muchos vendedores habían hecho algunas tácticas de venta interesantes en 2000-2010. Una de estas tácticas era una campaña de marketing y ventas llamada "Enciéndelo". Básicamente, se ordenó a los SE que consiguieran que los clientes activaran todas las funciones posibles, ya que esto crearía un bloqueo para futuras ventas. La configuración de un dispositivo no podía convertirse fácilmente a la sintaxis de otro proveedor porque muchas de las funciones ni siquiera existían para el segundo proveedor. Algunas de estas funciones eran geniales, otras no eran más que una carga adicional. A los clientes no les importaba mucho que sus configuraciones fueran cada vez más propietarias. Esta iniciativa funcionó y muchos clientes de la época tenían RFP/RFQ que incluían características propietarias como requisitos.

Para captar clientes, Cumulus entró en una guerra de paridad de prestaciones con Cisco y Arista. Básicamente, intentaron añadir todas las funciones que pedía el mercado. Algunas de estas características eran sin duda necesarias, otras no. Pero el reto era que Cumulus tenía que conseguir que un dispositivo linux hiciera lo que podía hacer un switch Cisco. Y había un par de problemas REALMENTE GRANDES con eso, ya que linux fue diseñado para ser un sistema operativo de servidor, no se preocupaba realmente por las mejores prácticas de red. Así que todo tipo de cosas no estaban allí o no funcionaban idealmente para la creación de redes. Echemos un vistazo a los grandes problemas y cómo Cumulus resolvió estos problemas:

Contribuciones de Cumulus a las redes abiertas

Aceleración ASIC de conmutadores - switchd & SAI

Linux no fue diseñado originalmente para gestionar un switch ethernet. No había demonios o servicios para programar y gestionar TCAM o tablas de flujo. A los administradores de servidores les parecía bien que se programaran nuevos flujos en las NIC unos segundos después de hacer un cambio. Pero, ¿para las redes de los centros de datos? Unos segundos es una eternidad. Así que Cumulus creó un nuevo demonio llamado switchd que se encargaba de tratar con el hardware y el ASIC. Se trataba de un concepto totalmente nuevo para los clientes de la época. Desgraciadamente, Cumulus tomó la decisión estratégica de mantener este fragmento de código propietario y de código cerrado. Dado que switchd es necesario para que Cumulus funcione en hardware de conmutación, esto dio lugar a la extraña distinción de marketing entre "Open Networking" y "Open Source". Verás, Cumulus Linux era "Open Networking", es decir, te permitían consumir este nuevo modelo desagregado de hardware/software, pero no eran completamente de código abierto. Switchd no funcionaba correctamente sin que el usuario introdujera una clave de licencia. Si SAI hubiera existido, Cumulus habría tenido más opciones para hacer Switchd potencialmente de código abierto, pero una vez más, ¡el tiempo manda!

Pero era una idea realmente genial y fue la precursora de la Interfaz de Abstracción de Conmutadores (SAI) que todos utilizamos ahora en SONiC para soportar múltiples plataformas de hardware.

Enrutamiento de nivel 3 - Quagga se convierte en FRR

Linux siempre había carecido de una pila de enrutamiento realmente buena. En ese momento no había muchas opciones; rutas estáticas, algún software de enrutamiento propietario y caro, o algún extraño paquete de software llamado Quagga. Todo el mundo sabe que tuvo un momento "WTF" la primera vez que escuchó a alguien mencionar "Quagga". Qué nombre más raro, ¿verdad? Quagga es una especie de cebra que fue cazada hasta su extinción en el siglo XIX. Quizá eso debería haber presagiado lo que le ocurrió. En cualquier caso, Quagga (la cosa de red, no el caballo emo) es un conjunto de demonios de protocolo de enrutamiento que incluye BGP y OSPF. Antes de Cumulus, Quagga era sobre todo experimental. Tenía muchos bugs y realmente no escalaba muy bien. Faltaban muchos botones de BGP. Cumulus comenzó a mejorar Quagga y a subir todos sus cambios al mantenedor, que resultó ser una sola persona que utilizaba una extraña metodología de control de versiones. Esto requirió una tonelada de ingeniería. Determinar las limitaciones reales de escalado de rutas para FIB y TCAM es complicado si eres el gestor de producto de un dispositivo, pero ¿a través de múltiples ASICs, CPUs, SerDes, bloques de puertos y ópticas? 

Es una locura, ¿verdad? Pero, efectivamente, Cumulus siguió adelante con determinación para superar en ingeniería y automatización esta complejidad. Con el tiempo, el rendimiento de Quagga se hizo bastante fiable y ahora se ha demostrado que es capaz de soportar la ingestión de toda la tabla de enrutamiento global. Todos sabemos que FRR puede gestionar la tabla de Internet, que es lo más complejo y sucio que se puede hacer. Sin embargo, debido a problemas con la velocidad a la que el mantenedor original estaba integrando los cambios, Cumulus finalmente decidió bifurcar Quagga en un nuevo proyecto llamado Free Range Routing (FRR). Ese proyecto es ahora la suite de enrutamiento de código abierto más ampliamente desplegada y utilizada, que se ejecuta en nubes masivas como Azure y AWS.

Las ideas geniales se convierten en realidad

De hecho, este es uno de mis ejemplos favoritos de cómo Cumulus demostró la democratización de las redes. BGP Unnumbered. Así es, ¿sabías que no fue una creación de un "gran proveedor"? Cumulus diseñó, pulió y promovió la implementación de BGP Unnumbered, y luego dejó que todo el mundo copiara su obra maestra. Copiar es la forma más sincera de adulación, ¿verdad? Otros vendedores implementaron esta sencilla técnica en sus NOS prácticamente de la noche a la mañana.

Básicamente, Cumulus estaba construyendo redes linux, optimizadas para el centro de datos.

Linux Network Interface Management - ifupdown recibe una actualización

Como he dicho antes, linux no fue diseñado para ser un sistema operativo de conmutación, y era dolorosamente obvio cada vez que intentabas hacer cambios en un solo puerto con los comandos de red nativos de linux. Básicamente, si querías cambiar la configuración de un puerto, o incluso rebotar un puerto, esencialmente estarías rebotando todos los puertos del servidor a la vez. Esto no es un gran problema para un servidor cuando se está haciendo el mantenimiento, pero imagínese rebotando una interfaz en un conmutador de 48 puertos y todos los puertos se caen, eso es ridículo e inaceptable en el centro de datos. Este era un diseño técnico bastante arraigado en linux y cambiarlo requería una ENORME cantidad de esfuerzo. Al final, Cumulus publicó ifupdown2, que incorporaron para que todo el mundo pudiera beneficiarse de su trabajo, y ahora toda la comunidad de redes abiertas puede disfrutar de las nuevas capacidades de gestión de puertos.

Automatización y programabilidad: las CLI se pasan a Ansible

Cumulus no proporcionó una CLI o API cuando se lanzó por primera vez. La idea era que la CLI era un callejón sin salida y que nadie debería utilizar la CLI para gestionar un conmutador de estructura de centro de datos. Así que Cumulus tomó la iniciativa y creó los primeros playbooks Ansible reales para automatizar una red, provocando que Cisco hiciera un rápido "yo también" consiguiendo que un desarrollador externo creara herramientas Ansible para el Nexus 9k. De hecho, el enfoque DevOps-first fue bastante progresista, y realmente hizo que la industria avanzara más rápidamente hacia un modelo más programable.

Eso es MUCHO desarrollo y resolución de deuda técnica para una startup con pocos ingresos. Algunos ya saben cómo acabó esto...

En 2020, Nvidia adquirió Cumulus Networks, poco después de comprar Mellanox. En aquel momento, Cumulus era compatible con dos grandes proveedores de ASIC, Broadcom y Mellanox. Poco después de anunciarse el acuerdo, Broadcom revocó el acceso de Cumulus al SDK de Broadcom, con lo que Cumulus dejó de ser compatible con los ASIC de Broadcom. Según una estimación no oficial, 90% de los clientes de Cumulus utilizaban ASIC de Broadcom (vendidos como Dell, Edgecore, etc.). Las capacidades multiproveedor de Cumulus terminaron y ahora Cumulus es una pieza de la cartera de redes de Nvidia, con optimizaciones específicas para cargas de trabajo AI/ML y redes de almacenamiento.

¡Un aplauso para Cumulus!

Me gusta decir a la gente que Cumulus derribó un muro en la industria lanzando todo su peso en él, básicamente rompiéndose el cuello en el proceso. Lo que quiero decir es que Cumulus dio un impulso increíble a la comunidad del código abierto y las redes abiertas, pero al hacerlo emplearon demasiados recursos (costes y tiempo de desarrollo), por lo que no pudieron diferenciarse de forma efectiva más allá de ser un NOS de Linux. Cumulus inició esta revolución en la que estamos inmersos, pero el mercado tardó demasiado en adoptar el modelo desagregado. Aunque no fue el disruptor de la industria que todo el mundo quería, rompió muchos modelos de negocio heredados, y muchos proveedores todavía están luchando para hacer frente a la nueva realidad.

Así que sin más preámbulos, en nombre de la comunidad, me gustaría dar un ENORME AGRADECIMIENTO a Cumulus y a todos los empleados que han contribuido a mejorar el estado del arte de las redes.

¿En qué se diferencia hoy?

Cumulus no vinculó eficazmente su tecnología a ninguna transición importante del mercado. Se podría argumentar que intentaron crear la transición por sí mismos, pero bash en lugar de CLI y whitebox T2 en lugar de Cisco T2 no fue suficiente para crear un factor de motivación para que las empresas actualizaran todos sus NOC y sistemas de monitorización, así como para sustituir a todos los CCIE por expertos en linux. No fue suficiente para crear una transición. En su lugar, deberían haber buscado una transición mayor a la que adherirse.

SONiC tiene un impulso ENORME. Fue diseñado para ser automatizado como una aplicación moderna. Hedgehog está trabajando para llevar todas las bondades de la transición de la plataforma Kubernetes a la red SONiC. Esto incluye actualmente tejidos de red de centros de datos y plataformas de alojamiento de aplicaciones de borde, pero algún día se extenderá a campus, WAN y otros modelos de despliegue. Ningún otro NOS de código abierto cuenta con una comunidad colaboradora tan amplia y, dado que los principales proveedores ya son compatibles con SONiC, se espera que este sea el NOS estándar para la mayoría de las nuevas construcciones en un futuro próximo. El momento de adoptar SONiC es AHORA.

Hasta la próxima...