Sistema operativo de red SONiC y desagregación de conmutadores

Resumen ejecutivo

Microsoft desarrolló SONiC para Azure y lo publicó a través del Open Compute Project en 2016, creando una arquitectura compartida de Linux, contenedores y bases de datos para conmutadores de varios proveedores de hardware.
La Switch Abstraction Interface dota a SONiC de un vocabulario común para programar distintos ASICs, pero las capacidades de la plataforma, la escala, el comportamiento ante errores y el soporte siguen dependiendo de las implementaciones de los proveedores y de los SDKs propietarios.
La gobernanza de la Linux Foundation amplió la participación sin eliminar la influencia de Microsoft. La autoridad técnica, la financiación del proyecto, el desarrollo de SAI y el soporte en producción permanecen divididos entre varias instituciones y participantes comerciales.
SONiC se está expandiendo hacia sistemas con chasis, conmutación empresarial y tejidos de IA antes de que la conformidad uniforme y la titularidad de la seguridad estén plenamente maduras. Su credibilidad depende del comportamiento medible, no de la amplitud de sus listas de soporte.

Una ruta llega al silicio a través de una cadena de traspasos

Una ruta del Border Gateway Protocol en SONiC no pasa directamente de un proceso de enrutamiento a la tabla de reenvío del conmutador. FRRouting recibe la actualización, aplica la política y selecciona la ruta. Zebra transfiere el estado de reenvío a través de la interfaz del Forwarding Plane Manager, fpmsyncd escribe la intención de la aplicación en APPL_DB y el Switch State Service resuelve los vecinos, próximos saltos e interfaces necesarios.

A continuación, la solicitud se serializa a través de ASIC_DB, syncd la consume, la implementación de la Switch Abstraction Interface del proveedor y su kit de desarrollo de software propietario la traducen, y finalmente se programa en el ASIC.

Esa cadena explica tanto la importancia de SONiC como su dificultad. Cada frontera permite que una parte del sistema se desarrolle sin conocer directamente todos los demás componentes. El software de enrutamiento puede operar contra un modelo de aplicación común, mientras que los proveedores de hardware traducen objetos de conmutación estándar a las instrucciones que requiere su silicio. Esa misma separación también crea más lugares donde el estado deseado, el estado informado y el comportamiento real de reenvío pueden divergir.

Los conmutadores de red tradicionales generalmente llegaban como productos integrados verticalmente. El proveedor combinaba hardware, sistema operativo, hoja de ruta de funcionalidades y relación de soporte, dando al comprador un único interlocutor al que acudir cuando el sistema fallaba. El acuerdo simplificaba la responsabilidad, pero ataba la elección de software, las interfaces de automatización y la adquisición de hardware al mismo proveedor. Los grandes operadores de nube que gestionan decenas de miles de conmutadores prácticamente similares tuvieron que aceptar ese acoplamiento o construir más partes de la pila ellos mismos.

SONiC tomó la segunda vía. Utiliza Linux como base, divide las funciones de red en servicios de software, intercambia estado a través de bases de datos respaldadas por Redis y coloca una abstracción de hardware debajo de las aplicaciones de red. El proyecto no elimina las diferencias de hardware ni proporciona un contrato de soporte global único. Crea una capa de software común que puede sobrevivir a un cambio de proveedor de conmutadores, fabricante de diseño original o familia de ASIC, siempre que alguien complete y dé soporte al trabajo específico de la plataforma subyacente.

La promesa económica es la desagregación. Un operador puede tomar decisiones independientes sobre hardware, silicio, distribución del sistema operativo, integración y soporte, en lugar de adquirirlos como un solo producto. La consecuencia operativa es la responsabilidad dividida. Una funcionalidad puede existir en la versión comunitaria, pero permanecer indisponible o comportarse de manera diferente en una plataforma concreta porque la limitación decisiva reside en el firmware, los controladores, el código SAI del proveedor, un SDK o la pipeline física.

Azure convirtió un problema de flota en una plataforma abierta

Microsoft desarrolló SONiC para Azure antes de presentarlo públicamente. Su origen fue, por tanto, un problema de producción y no una propuesta abstracta para el networking abierto. Los operadores a hiperescala necesitan automatizar grandes flotas de conmutadores, cambiar el software más rápido de lo que permiten los ciclos de producto convencionales y adquirir hardware de varios proveedores sin mantener un modelo operativo completamente distinto para cada uno.

Microsoft anunció su contribución de SONiC al Open Compute Project el 9 de marzo de 2016. El nombre responde a Software for Open Networking in the Cloud. Microsoft lo describió como una colección de componentes de software de red para conmutadores y lo acompañó de la Switch Abstraction Interface, o SAI. Esta combinación era esencial porque una pila superior portable habría ofrecido un valor limitado si cada aplicación de enrutamiento, orquestación y gestión aún necesitara conocer directamente la interfaz de cada fabricante de silicio.

SAI proporcionó un vocabulario común de programación para objetos como puertos, VLANs, rutas, próximos saltos, vecinos, entradas de control de acceso, colas, búferes, túneles y contadores. Un proveedor de ASIC o de plataforma podía implementar esos objetos contra su propio SDK y pipeline de reenvío. Las aplicaciones de SONiC podían entonces solicitar un objeto estándar en lugar de incrustar llamadas propietarias al hardware por todo el código común.

La participación en el Open Compute Project conectó el software con operadores de centros de datos, fabricantes de diseño original, proveedores de conmutadores y empresas de silicio que ya trabajaban en hardware abierto y codiseño hardware-software. Microsoft aportó un entorno operativo real, mientras que el grupo más amplio suministró la diversidad de hardware necesaria para probar la promesa del proyecto. Ninguno de los dos factores hizo que la portabilidad fuera completa.

Cada plataforma seguía necesitando integración de arranque, controladores, gestión térmica, manejo de ópticas, una implementación de SAI, soporte de SDK y pruebas sostenidas.

El trabajo menos visible se convirtió en el fundamento del ecosistema. El código común de enrutamiento, orquestación y gestión podía compartirse, mientras que las empresas más cercanas al hardware mantenían las capas específicas de la plataforma. Microsoft siguió aportando ingeniería y requisitos extraídos de Azure, pero otros operadores de nube, proveedores e integradores adquirieron una vía de entrada al proyecto que no dependía únicamente de la hoja de ruta interna de una sola compañía.

Esa historia hace que el papel actual de Microsoft sea más fácil de entender. La empresa creó SONiC y acumuló años de conocimiento operativo antes de que se estableciera una gobernanza neutral. Trasladar el proyecto no borró esa ventaja. Creó un marco en el que otras empresas podían invertir, gobernar y contribuir sin pretender que la experiencia de producción del creador se hubiera vuelto intercambiable de la noche a la mañana.

Linux y Redis hicieron el conmutador modular… y con estado

SONiC suele describirse como un sistema operativo de red basado en Linux, pero Linux por sí solo no explica su arquitectura. El sistema anfitrión proporciona el kernel, el acceso a dispositivos y los servicios base. Las principales funciones de red se ejecutan en contenedores separados, mientras que las bases de datos respaldadas por Redis ofrecen las interfaces de estado compartido y mensajería a través de las cuales esos servicios se coordinan. El Switch State Service convierte la intención de la aplicación en operaciones SAI, y un proceso orientado al hardware conecta esas operaciones con la implementación del proveedor.

La estructura de contenedores ha separado históricamente funciones como enrutamiento, Link Layer Discovery Protocol, Simple Network Management Protocol, agregación de enlaces, monitorización de la plataforma, bases de datos, SWSS y sincronización del ASIC. La separación mejora el empaquetado y la titularidad organizativa, pero no debe confundirse con un límite de seguridad fuerte en todos los casos. Los servicios de red pueden compartir recursos del host y requerir privilegios elevados para interactuar con el kernel y el hardware.

Su valor reside sobre todo en permitir que los componentes se desarrollen, reinicien y actualicen sin compilar el conmutador completo en un único proceso opaco.

Redis proporciona el lenguaje común. CONFIG_DB contiene la configuración prevista. APPL_DB transporta la intención de reenvío y servicio a nivel de aplicación hacia la capa de orquestación. ASIC_DB representa objetos SAI serializados para el proceso orientado al hardware, mientras que STATE_DB registra la disponibilidad en tiempo de ejecución y las dependencias. COUNTERS_DB almacena estadísticas de interfaz y hardware utilizadas por herramientas operativas y telemetría.

La configuración puede llegar a través de archivos, herramientas de línea de comandos, gNMI, REST u otros programas de gestión. Los procesos gestores traducen esa entrada en operaciones de aplicación, y SWSS consume el estado resultante. orchagent resuelve dependencias y crea solicitudes SAI, sairedis las serializa en ASIC_DB y syncd llama a la biblioteca SAI y al SDK del proveedor. Componentes escritos en diferentes lenguajes y mantenidos por distintos equipos pueden, por tanto, coordinarse a través de un estado definido en lugar de una densa red de llamadas privadas.

El resultado es una máquina de estados distribuida. Una clave de base de datos puede quedarse obsoleta, un escritor puede adelantar a otro y una aplicación puede aceptar el estado previsto antes de que el hardware lo rechace. Los contadores pueden ejercer presión sobre la ruta de la base de datos, mientras que los reinicios requieren que varios contenedores reconstruyan una visión coherente de lo que el conmutador debería estar haciendo. Redis no es un detalle de implementación pasivo. Sus esquemas, persistencia y comportamiento ante fallos influyen en la fiabilidad de todo el sistema.

La modularidad hace que estas transiciones sean más visibles. Los operadores pueden inspeccionar hasta dónde ha llegado una solicitud e identificar qué servicio es responsable del siguiente paso. Sin embargo, la visibilidad no garantiza la corrección. Una ruta seleccionada en FRRouting, escrita en APPL_DB y representada en ASIC_DB puede seguir ausente del hardware de reenvío. El sistema necesita reconciliación, diagnósticos y evidencia de tráfico capaces de distinguir la aceptación administrativa de la entrega real de paquetes.

SAI movió la frontera propietaria sin eliminarla

SAI es la razón principal por la que SONiC puede mantener una arquitectura superior ampliamente común a través de varias familias de ASIC. orchagent puede solicitar una ruta, puerto, siguiente salto, entrada de control de acceso, cola, túnel o contador sin contener llamadas al SDK de un proveedor. Esto reduce el acoplamiento y da a las aplicaciones de red un modelo de objetos estable incluso cuando cambia el proveedor de hardware subyacente.

La interfaz no puede hacer que ASICs físicamente distintos sean equivalentes. El silicio varía en capacidad de tabla, diseño de pipeline, arquitectura de búferes, combinaciones de objetos admitidas, semántica de contadores, funciones de telemetría, atomicidad de actualización, procesamiento de túneles y comportamiento de reinicio. Un proveedor debe mapear los objetos SAI sobre esos recursos, a menudo mediante código propietario y un SDK que los mantenedores de la comunidad no pueden inspeccionar.

Dos plataformas pueden, por tanto, anunciar la misma versión de SAI y ofrecer un comportamiento materialmente diferente. Una puede soportar una tabla EVPN más grande, una política de control de acceso más compleja o un reinicio más cálido que otra. Una funcionalidad puede requerir una capacidad del silicio o una extensión de SAI ausente en un chip anterior. La interfaz común reduce cuánto debe cambiar el software superior, pero no certifica la escala ni el resultado.

La frontera de gobernanza refuerza la técnica. SONiC se trasladó a la Linux Foundation en abril de 2022, mientras que SAI permaneció bajo el Open Compute Project. Las dos comunidades se coordinan, pero no comparten estructuras de decisión idénticas. Un nuevo requisito en telemetría, redes de IA o Ethernet de escalado vertical puede necesitar cambios simultáneos en las aplicaciones de SONiC, las definiciones de SAI, las implementaciones de los proveedores, los SDKs y el silicio.

El diagnóstico sigue la misma cadena. Una solicitud válida puede fallar en el código de orquestación común, en un adaptador del proveedor, en un SDK o en el propio hardware. Los mantenedores de la comunidad pueden ver el error de SAI sin acceso a la capa propietaria que lo produjo, mientras que un proveedor de hardware puede dar soporte solo a una combinación específica de imagen y SDK. Una distribución comercial puede asumir más carga de integración, pero la versión comunitaria de SONiC no crea una vía de escalado universal única.

Por tanto, SONiC ha desplazado la dependencia del proveedor hacia un límite más estrecho y explícito orientado al hardware. Se trata de un cambio arquitectónico sustancial. No ha eliminado la dependencia, y en fallos difíciles la respuesta final puede seguir proviniendo de la empresa que controla la implementación propietaria más cercana al ASIC.

La reconciliación de estado es el precio de la modularidad

Una aplicación puede aceptar una configuración, escribirla en la base de datos prevista e informar de su finalización antes de que la capa orientada al hardware descubra que el ASIC no puede crear el objeto solicitado. Cuando el fallo no regresa a través de la cadena con suficiente contexto, el estado previsto, el estado de la aplicación y el estado real de reenvío dejan de coincidir. Un sistema modular hace que esa divergencia sea más fácil de localizar, pero también le da más lugares donde producirse.

Algunos diseños históricos de SONiC trataban los fallos de creación o establecimiento de SAI como fatales. Detener un proceso puede ser más seguro que continuar con un estado de hardware desconocido, pero puede dejar el conmutador difícil de recuperar. Trabajos posteriores de gestión de errores introdujeron diseños como ERROR_DB y retroalimentación a la aplicación para objetos seleccionados como rutas y vecinos. El objetivo es dar a una solicitud asíncrona un resultado duradero que la aplicación originaria y el cliente de gestión puedan interpretar.

Un cambio de configuración puede implicar varias operaciones dependientes. El sistema podría crear un grupo de próximos saltos, añadir miembros, actualizar una ruta y eliminar estado antiguo. Algunos pasos pueden tener éxito antes de que una llamada posterior falle, y los recursos disponibles del hardware pueden cambiar entre la validación y la ejecución. Un retroceso literal puede ser imposible o inseguro, obligando al sistema a corregir hacia adelante hacia un estado consistente.

El reinicio en caliente traslada el mismo problema a las actualizaciones y la recuperación de procesos. El objetivo es reiniciar el software sin descartar el estado de reenvío e interrumpir todo el tráfico. El nuevo proceso debe reconciliar lo que su predecesor pretendía, lo que Redis contiene y lo que el ASIC sigue haciendo. Los cambios de esquema, las claves obsoletas o las dependencias parcialmente restauradas pueden convertir la persistencia en otra fuente de incertidumbre.

En consecuencia, los operadores necesitan algo más que una respuesta de comando exitosa. CONFIG_DB puede confirmar que se aceptó una solicitud, APPL_DB que fue traducida y ASIC_DB que se solicitó un objeto SAI. Nada de ello prueba que los paquetes estén siguiendo la ruta prevista. Los contadores de hardware, las pruebas de tráfico externas y la reconciliación de estado siguen formando parte del aseguramiento normal.

La arquitectura expone un hecho que los sistemas integrados suelen ocultar: la configuración de red no es una escritura atómica única. Es una secuencia de transiciones de estado entre componentes con diferentes tiempos y comportamientos ante fallos. La fiabilidad de SONiC depende de lo bien que esos componentes se recuperen después de retrasos, rechazos, reinicios y compleciones parciales.

Los sistemas con chasis multiplican tanto la escala como los fallos

La imagen pública temprana de SONiC estaba estrechamente asociada a conmutadores de centro de datos de factor de forma fijo que contenían un ASIC de reenvío principal. El proyecto se ha expandido desde entonces a conmutadores de alta densidad, chasis modulares y sistemas distribuidos de cola de salida virtual con varios ASICs de reenvío, dispositivos de tejido, tarjetas de línea y componentes de gestión.

Un sistema multi-ASIC puede ejecutar instancias separadas de Redis, SWSS, syncd, enrutamiento, descubrimiento de enlaces y agregación de enlaces para cada dispositivo de reenvío. Cada ASIC puede tener su propia instancia de SAI y SDK. El software debe determinar qué interfaces, vecinos y rutas pertenecen a cada espacio de nombres, cómo se representan los enlaces internos y cómo se mueve el estado entre dispositivos.

El sistema más grande cambia el dominio de fallo. Una ruta puede entrar por un ASIC y salir por otro, mientras que un enlace del panel frontal depende de una ruta de tejido interna. Los contadores recogidos en espacios de nombres separados deben presentarse como parte de un conmutador lógico único. Una tarjeta de línea puede reiniciarse mientras otras tarjetas y el plano de control siguen funcionando, obligando al software a coordinar versiones, titularidad de objetos y accesibilidad del tejido entre componentes con estado independiente.

Las arquitecturas de VOQ distribuidas extienden esta coordinación a través de un chasis o varias instancias de conmutador. Las decisiones de reenvío y encolado pueden depender del conocimiento compartido de puertos remotos y del estado del tejido. El reemplazo de tarjetas de línea, la redundancia del plano de control y el fallo parcial del tejido deben manejarse sin asumir que todos los componentes están disponibles al mismo tiempo.

La versión SONiC 202605 incluyó el reinicio en caliente multi-ASIC limitado como una funcionalidad Alpha para una topología restringida. Esa etiqueta es tan importante como la presencia de la funcionalidad. Confirma un trabajo de implementación activo al tiempo que deja claro que el reinicio resiliente en sistemas multi-ASIC complejos no era aún una capacidad universalmente cualificada.

El soporte de chasis amplía la relevancia de SONiC para las redes de telecomunicaciones, las nubes de alta densidad y la infraestructura de IA. También introduce el proyecto en sistemas donde los proveedores integrados han acumulado años de lógica de recuperación específica de la plataforma. La arquitectura abierta puede competir, pero la cobertura de pruebas, la secuenciación de actualizaciones y las obligaciones de soporte crecen más deprisa que el simple recuento de ASICs.

La gestión decide si la apertura puede operarse

Un sistema operativo de conmutador común solo es útil cuando los operadores pueden configurarlo, observarlo y actualizarlo en toda una flota. SONiC admite herramientas de línea de comandos, configuración estática, SNMP y trabajos relacionados con gNMI, YANG, REST, OpenAPI, Translib y marcos de validación. Las funciones disponibles aún dependen de la versión, el modelo de datos, la distribución y la plataforma.

La gestión basada en modelos pretende traducir una solicitud externa al sistema de configuración basado en Redis. Los modelos YANG definen estructuras válidas, mientras que CVL y componentes relacionados pueden rechazar entradas mal formadas. Translib y los componentes de servicio mapean operaciones de API en tablas de SONiC, permitiendo a los controladores trabajar a través de una interfaz soportada en lugar de manipular directamente las bases de datos internas.

La validación de esquemas no puede probar que un servicio solicitado esté autorizado, sea compatible con otro cambio o pueda ser soportado por los recursos restantes del ASIC. Un diseño documentado también describía operaciones de comparación e intercambio sin bloqueo general ni retroceso. Por tanto, los desarrolladores de aplicaciones deben definir la titularidad, la concurrencia y la compensación, en lugar de asumir que la capa de gestión proporciona una transacción universal.

OpenConfig y gNMI muestran la diferencia entre incluir un componente y completar una funcionalidad operativa. SONiC 202605 incluía sonic-gnmi 0.1, mientras que la telemetría de salida de OpenConfig YANG seguía siendo Alpha. Una declaración de soporte útil debe identificar el modelo, la ruta, la operación de lectura o escritura, el modo de telemetría, la versión y la distribución del proveedor. La afirmación genérica de que un conmutador soporta OpenConfig transmite demasiado poco.

Las interfaces heredadas siguen siendo necesarias. SNMP conecta los conmutadores con los sistemas de monitorización establecidos, LLDP proporciona información de vecinos y los servicios de plataforma exponen ventiladores, temperatura, alimentación y ópticas. El trabajo con BMC y Redfish aborda funciones de ciclo de vida fuera de banda, pero varios flujos de trabajo relacionados en la versión 202605 también conservaban el estado Alpha.

La conmutación empresarial plantea otro conjunto de expectativas de gestión. SONiC se diseñó para entornos a hiperescala cuyos operadores pueden construir imágenes, mantener laboratorios de cualificación y mantener relaciones directas con el hardware. Las redes de campus y acceso requieren funciones como Power over Ethernet, spanning tree, control de admisión 802.1X y gestión predecible de puntos finales, a menudo para equipos sin capacidad de ingeniería a escala de nube.

El grupo de trabajo PENS, que cubre PoE y servicios de red empresarial, es un intento de cerrar esa brecha. Otros grupos abordan la gestión, los sistemas operativos de plataforma, la integración de BMC, los planos de datos virtuales y la documentación. Su existencia muestra trabajo activo, no madurez uniforme. La adopción empresarial dependerá de llevar las funciones desde el diseño y la implementación hasta la inclusión en la versión, la cualificación de hardware y la entrega comercial con soporte.

Las distribuciones comerciales adquieren especial importancia en esta frontera. Pueden proporcionar una superficie de gestión probada, una política de actualización, una matriz de hardware y un proceso de soporte alrededor de los componentes upstream. La versión comunitaria de SONiC suministra la base común; el operador aún necesita un interlocutor que sea responsable del ciclo de vida de la imagen que realmente se ejecuta en el conmutador.

El nombre de la Fundación cubre un proyecto y un fondo dirigido

El nombre “SONiC Foundation” puede sugerir una organización constituida por separado con su propio consejo estatutario, empleados y cuentas. El registro de gobernanza disponible apoya una descripción más estratificada. La SONiC Foundation es el proyecto técnico y la comunidad alojados en la Linux Foundation, mientras que no se identificó en las pruebas aportadas ninguna compañía SONiC Foundation constituida por separado ni entidad jurídica independiente sin ánimo de lucro.

Una estructura relacionada, el SONiC Fund, es un Fondo Dirigido de la Linux Foundation. Recauda y gasta dinero en apoyo del proyecto técnico. Su Consejo Rector supervisa la membresía, los presupuestos, la divulgación, las políticas y los posibles programas de conformidad. El Comité Directivo Técnico se ocupa de la dirección técnica y, aunque está representado dentro de la estructura más amplia, la autoridad técnica y la financiera permanecen diferenciadas.

Esta división evita que la membresía se convierta en un sustituto del despliegue o del mando técnico. Una empresa puede unirse al Fondo Dirigido sin ejecutar SONiC en producción. Un puesto en el Consejo Rector no decide cada discusión de diseño, y un colaborador puede influir en el software sin adquirir la membresía Premier. La Linux Foundation administra los fondos y las marcas del proyecto, mientras que los derechos del código siguen regidos por las licencias pertinentes y los derechos de autor de los colaboradores.

SAI añade otra frontera institucional porque sigue siendo una iniciativa del Open Compute Project. El proyecto SONiC desarrolla el software operativo común, el Fondo Dirigido financia y promueve ese trabajo, OCP aloja SAI y la actividad de hardware relacionada, y los proveedores u operadores integran los componentes resultantes con conmutadores y soporte comercial. Dell Enterprise SONiC y otras distribuciones se sitúan aguas abajo del proyecto comunitario, en lugar de convertir a la Fundación en un proveedor de software convencional.

El acuerdo identifica dónde residen las decisiones y la responsabilidad. Un grupo de trabajo y el TSC pueden dar forma a una funcionalidad, el estatuto del Fondo Dirigido regula las cuotas de membresía y los participantes de OCP desarrollan un objeto o versión de SAI. Un fallo en producción puede seguir requiriendo al equipo del SDK propietario o al proveedor que cualificó la imagen final. Tratar cada capa como una sola Fundación ocultaría las fronteras que los operadores deben gestionar.

La gobernanza neutral no ha borrado la influencia de Microsoft

La Linux Foundation anunció la transición de SONiC el 14 de abril de 2022. Para entonces, el proyecto había superado la apariencia de una pila interna de una sola empresa de nube. Un marco neutral ofrecía membresía compartida, financiación, elecciones, marca y participación técnica a empresas que de otro modo podrían dudar en depender de una gobernanza alojada por Microsoft.

El anuncio decía que SONiC ya funcionaba en millones de puertos y más de 100 modelos de conmutadores, con más de 50 socios. Se trataba de afirmaciones del proyecto y de sus creadores, no de un censo independiente. No obstante, muestran que el movimiento se presentó como la institucionalización de una plataforma desplegada, no como la incubación de un nuevo experimento.

El estatuto del Fondo Dirigido, modificado el 5 de mayo de 2026, permite a los miembros Premier nombrar representantes en el Consejo Rector. Los miembros General eligen representantes como clase en función del tamaño de esa membresía, mientras que los miembros Asociados no reciben puestos en el Consejo. El Consejo está normalmente limitado a 19 representantes con voto, salvo ampliación, el quórum es del 50 por ciento y las decisiones ordinarias requieren mayoría simple cuando existe quórum, aunque se prefiere el consenso.

La cuota anual del Fondo Dirigido para un miembro Premier es de 100 000 USD, independiente de la membresía corporativa requerida en la Linux Foundation. Las cuotas de los miembros General oscilan entre 1 000 USD para organizaciones de hasta 499 empleados y 20 000 USD para organizaciones con al menos 5 000 empleados. Los miembros Asociados aprobados participan sin cuota del Fondo. La Linux Foundation aplica un cargo general y administrativo del 9 por ciento a los primeros 1 millón de USD de ingresos brutos anuales y del 6 por ciento por encima de ese nivel.

Estas cifras explican el mecanismo de financiación, pero no revelan el presupuesto real del proyecto. No se identificaron estados públicos de ingresos, gastos, reservas o asignaciones a nivel de programa del Fondo. Las reuniones del Consejo Rector son privadas por defecto, a menos que el Consejo decida lo contrario, lo que hace que los repositorios técnicos y los grupos de trabajo sean más visibles que las decisiones financieras que respaldan las pruebas, eventos, divulgación o infraestructura.

El efectivo es solo una parte del modelo de contribución. Microsoft, los operadores de nube, las empresas de silicio, los proveedores de conmutadores y los integradores proporcionan ingeniería, ports de plataforma, implementaciones de SAI, laboratorios, capacidad de integración continua, documentación y trabajo de versiones. El valor de esas contribuciones no se publica como un total financiero único, y el proyecto sigue expuesto cuando un equipo corporativo cambia de prioridades.

Microsoft ocupa la concentración más visible de liderazgo actual. En la fecha de corte de la investigación, Dave Maltz presidía el Consejo Rector, Xin Liu presidía el Comité de Divulgación y Guohan Lu presidía el Comité Directivo Técnico. Microsoft era también el creador del proyecto, miembro Premier, colaborador activo y un importante operador de producción.

La gobernanza más amplia es genuinamente multiempresarial. La representación en el Consejo Rector ha incluido a Alibaba Cloud, Arista, Broadcom, Celestica, Cisco, Dell, Google, Marvell, Nokia, NVIDIA, PLVision, Upscale AI, Nexthop AI y otros. Las elecciones al TSC de 2026 produjeron un presidente y ocho miembros con voto asociados con Microsoft, Google, Broadcom, NVIDIA, Alibaba Cloud, Cisco, Dell, Marvell y una afiliación independiente.

El voto formal no captura toda la autoridad técnica. El proyecto describe un modelo meritocrático y reconoce un elemento de “dictadura benevolente” a nivel de componente o proyecto para resolver conflictos. Los mantenedores e ingenieros con profundo conocimiento operativo pueden influir en los resultados porque otros participantes dependen de sus revisiones, incluso cuando la gobernanza financiera permanece separada.

La ventaja de Microsoft combina posiciones de liderazgo con evidencia operativa de Azure. Los fallos, las actualizaciones y los límites de escala generan un conocimiento que los documentos de diseño públicos rara vez capturan. La prueba de la gobernanza neutral es, por tanto, si otras organizaciones pueden apropiarse de subsistemas difíciles, desafiar las decisiones de diseño y mantener las versiones si cambian las prioridades de Microsoft. La diversidad del Consejo proporciona un marco; la concentración de contribuciones y la titularidad de los mantenedores proporcionarían una evidencia más sólida.

Las versiones definen una línea base, no un producto certificado

SONiC 202605 muestra cuánto software integra un sistema operativo de red moderno. La versión utilizaba Debian 13 Trixie, un kernel SONiC 6.12.41, SAI 1.18.1, FRR 10.5.4, Redis 8.0.2, Docker 28.2.1 y Python 3.13.5. También reunía paquetes de descubrimiento de enlaces, agregación, SNMP, DHCP, anuncios de enrutamiento, telemetría y plataforma, cuya seguridad y ciclo de vida no avanzan en un único calendario.

La lista de dependencias establece una línea base de la rama. No significa que todos los conmutadores ejecuten binarios idénticos. Las imágenes de plataforma pueden contener módulos del kernel del proveedor, bibliotecas SAI, SDKs, firmware, controladores y configuración, mientras que las distribuciones comerciales pueden incluir parches ausentes en la rama comunitaria.

Las etiquetas de calidad son, por tanto, esenciales. La versión 202605 clasificó la telemetría de salida OpenConfig YANG, el reinicio en caliente multi-ASIC limitado, los flujos de trabajo BMC Redfish, las operaciones de contraseña de unidades con autocifrado, el enlace de telemetría a VRF y un marco de eventos o alarmas como Alpha. Los usuarios pueden evaluar esas implementaciones, pero la inclusión en la versión no es una promesa de comportamiento estable en todas las plataformas listadas.

Las pruebas deben cubrir combinaciones de ASIC, conmutador, topología, funcionalidad, rama y ruta de actualización. Las condiciones públicas de sonic-mgmt incluyen omisiones y fallos esperados específicos de la plataforma. Una omisión puede indicar una función no soportada, una limitación de la prueba, un problema conocido o un caso irrelevante, por lo que no debe tratarse automáticamente como un defecto del producto. El patrón más amplio muestra por qué la frase “soporta SONiC” es demasiado amplia para las adquisiciones.

Una declaración de plataforma significativa identifica el hardware, el ASIC, el proveedor de la imagen, la versión de SONiC, la implementación de SAI, el SDK, las funcionalidades probadas y el responsable del soporte. El reinicio en caliente en un conmutador fijo dice poco sobre un chasis distribuido. Una escala de control de acceso en un ASIC no puede transferirse a otro, y una ruta gNMI en la imagen comunitaria puede diferir de la interfaz ofrecida por una distribución comercial.

La comunidad puede publicar una versión común y un marco de pruebas, pero la responsabilidad de producción pertenece al operador y a las partes que cualificaron la imagen final. El estatuto del Fondo Dirigido permite programas de conformidad, pero no se identificó ninguna matriz independiente completa que mostrara resultados comparables de aprobación y fallo en las plataformas actuales. Hasta que exista dicha evidencia, una versión es un contrato de integración alrededor de código común, no una certificación universal de los sistemas construidos a partir de ella.

Los tejidos de IA son la prueba más exigente para la capa común

Los grandes clústeres de GPU están cambiando las exigencias impuestas a las redes de centros de datos. El entrenamiento distribuido puede generar flujos sincronizados de larga duración, baja entropía de tráfico, microrráfagas y un rendimiento limitado por el participante más lento. Los operadores necesitan gran ancho de banda, rápida convergencia ante fallos, escala densa de vecinos y sesiones, evidencia precisa de congestión y funcionalidades que pueden depender de nuevos silicios de conmutación.

Un artículo de la SONiC Foundation de julio de 2026, firmado por Guohan Lu de Microsoft y Mehak Mahajan de Broadcom, describía la arquitectura Fairwater de Microsoft y cuatro capacidades supuestamente disponibles para la versión 2025.11: mayor escala BGP, distribución de tráfico seleccionada por el origen basada en SRv6, recorte de paquetes y telemetría de flujo de alta frecuencia. El mismo artículo describía un diseño multi-plano y multi-carril destinado a soportar hasta 512 000 GPUs.

Se trataba de afirmaciones del proyecto y de los profesionales, no de evidencia auditada independientemente de que todo ese número estuviera operando simultáneamente.

El trabajo sobre BGP se describió como capaz de soportar 512 sesiones por conmutador, unas 1 000 rutas y 512 próximos saltos en el diseño correspondiente. Se indicó que FRR 10 y aproximadamente 20 parches específicos producían una convergencia del plano de datos por debajo de 100 milisegundos. El artículo no proporcionaba una topología completa, distribución percentil, especificación de hardware ni un método independientemente reproducible, por lo que la cifra pertenece a la arquitectura descrita y no a SONiC como garantía universal de rendimiento.

SRv6 y uSID abordan la entropía limitada creada por un pequeño número de flujos muy grandes. Las rutas seleccionadas por el endpoint pueden distribuir el tráfico de forma más deliberada que el hashing convencional, pero el mecanismo requiere endpoints o NICs compatibles, un análisis ASIC adecuado, capacidad de tabla, soporte de enrutamiento y recuperación ante fallos. La funcionalidad del sistema operativo solo funciona como parte de una pila coordinada.

El recorte de paquetes preserva una cabecera corta de un paquete descartado y la reenvía para que el destino pueda detectar la pérdida más rápidamente. El artículo de la Fundación describía un caso específico de hardware en el que las cabeceras recortadas de hasta 18 puertos de entrada podían drenar a través de un puerto de salida en el hardware actual de 512 puertos. El resultado depende del ASIC y del patrón de tráfico y no demuestra que todas las plataformas o endpoints SONiC soporten el mecanismo.

La telemetría de alta frecuencia pretende capturar eventos que el sondeo más lento pasa por alto. El camino descrito utiliza la exportación de contadores IPFIX del ASIC, Counter SyncD, COUNTERS_DB y, o bien análisis en el conmutador, o bien exportación OpenTelemetry a sistemas como Prometheus o InfluxDB. Ese diseño sitúa a Redis y al procesamiento de telemetría dentro del bucle de retroalimentación del tejido de IA, aumentando tanto su valor operativo como su carga de rendimiento.

La membresía ha seguido la misma dirección. Upscale AI se convirtió en miembro Premier en febrero de 2026. Supranett se unió al nivel Premier el 28 de julio, mientras que Exaware, TeraHop e Infrawaves se hicieron miembros General. Nexthop AI y otras empresas de redes de IA también ocupan puestos de gobernanza o de grupo de trabajo. La membresía muestra inversión e intención, no despliegue, pero identifica los problemas que las empresas esperan que la plataforma común resuelva.

El Ethernet de escalado vertical acerca a SONiC a sistemas de aceleración que históricamente han utilizado interconexiones especializadas. El grupo de trabajo de Scale-Up Ethernet pretende traducir los requisitos emergentes, incluido el trabajo alineado con OCP E-SUN, en implementaciones que cubran la retransmisión a nivel de enlace, el control de flujo basado en crédito, el hashing de flujo adaptativo, las cabeceras de paquetes de escalado vertical y tejidos de endpoints más grandes.

La oportunidad es significativa. Una implementación madura podría permitir que un único entorno abierto de sistema operativo de red sirviera para grandes tejidos de escalado horizontal y partes de un mercado emergente de Ethernet de escalado vertical. Los operadores podrían reutilizar prácticas de gestión, telemetría y plataforma en más partes de la red de IA.

El trabajo no había alcanzado un estándar universal terminado ni un despliegue amplio en la fecha de corte de la investigación. Los requisitos aún estaban evolucionando, los proveedores podían exponer funciones esenciales a través de extensiones, y los cambios debían atravesar SONiC, SAI, el software de los endpoints, las NICs, el firmware y el silicio. A medida que SONiC se acerca al comportamiento especializado de los aceleradores, la semántica precisa del hardware se vuelve más importante. La capa común puede expandirse mientras que la frontera propietaria subyacente se vuelve más trascendente.

La seguridad se formalizó después de que la plataforma ya estuviera en producción

Una imagen de SONiC combina Debian, el kernel de Linux, un entorno de ejecución de contenedores, Redis, FRRouting, servicios de gestión, LLDP, SNMP, componentes DHCP, paquetes Python, controladores de plataforma, bibliotecas SAI del proveedor, SDKs propietarios, firmware e infraestructura de compilación. Una vulnerabilidad en cualquiera de esas capas puede afectar al conmutador o a su plano de gestión, mientras que la responsabilidad de la corrección puede estar dividida entre varios proyectos y proveedores.

Un Grupo de Trabajo de Seguridad público fue aprobado en junio de 2026. Su alcance incluía listas de materiales de software (SBOM), información de Intercambio de Explotabilidad de Vulnerabilidades (VEX), higiene de dependencias, análisis estático y dinámico, fuzzing, pruebas de penetración, seguridad de la cadena de suministro, endurecimiento y arranque seguro o medido. Brad House de Nexthop AI fue identificado como presidente y Qi Luo de Microsoft como copresidente.

El documento de formación reconocía que un trabajo de seguridad sustancial carecía previamente de una titularidad suficientemente clara. La seguridad no estaba ausente: los proyectos upstream, los mantenedores y los proveedores habían manejado vulnerabilidades, y existía un proceso de notificación. La admisión era que la responsabilidad sobre el sistema integrado no se había organizado en un flujo de trabajo público visible acorde con el uso en producción de la plataforma.

Un grupo de trabajo no completa esa tarea. Un programa maduro necesita SBOMs actuales, registros de procedencia, clasificación de vulnerabilidades, construcción firmada o reproducible, políticas de parches, manejo de divulgaciones privadas, backports y avisos específicos de la plataforma. Las bibliotecas SAI propietarias, los SDKs y el firmware complican la visión upstream porque la comunidad no puede inspeccionar su código fuente ni controlar sus calendarios de publicación.

Los servicios de gestión merecen un escrutinio especial. gNMI, REST, SSH y SNMP exponen control o información privilegiada, lo que requiere gestión de certificados, diseño de roles, auditoría, manejo de secretos y aislamiento de red. Los contenedores mejoran el empaquetado, pero no crean automáticamente límites de seguridad fuertes cuando comparten recursos del host y requieren capacidades elevadas. Un compromiso en la ruta de orquestación o de base de datos puede afectar a muchos objetos de reenvío.

Los proveedores comerciales emiten sus propios avisos porque sus productos contienen combinaciones y políticas de soporte diferentes. Una vulnerabilidad en Dell Enterprise SONiC no debe generalizarse automáticamente a todas las imágenes comunitarias, y un operador no puede asumir que la página del proyecto upstream cubre todos los componentes propietarios de su conmutador.

El Grupo de Trabajo de Seguridad se ha convertido en una de las pruebas más claras de madurez del proyecto. SONiC ha demostrado que la colaboración abierta puede integrar enrutamiento, bases de datos y abstracción de hardware. Ahora debe demostrar que el mismo modelo institucional puede asignar la titularidad a lo largo de una cadena de suministro cuyas capas más sensibles no son todas abiertas.

El código abierto traslada los costes de soporte, en lugar de eliminarlos

La versión comunitaria de SONiC suministra código fuente, arquitectura, versiones, grupos de trabajo y un marco de pruebas compartido. No proporciona un acuerdo de nivel de servicio de producción universal. Un operador que utilice el proyecto comunitario debe seguir asignando la responsabilidad de la cualificación del hardware, el ensamblaje de imágenes, las actualizaciones, los backports de seguridad, la respuesta a incidentes y la relación con el proveedor del ASIC o de la plataforma.

Los hiperescalares pueden aceptar esa carga porque el control de la pila es la razón por la que buscaron la desagregación. Pueden mantener equipos de Linux, enrutamiento, ingeniería de versiones y hardware, gestionar laboratorios de cualificación y negociar directamente con los proveedores de silicio. Su modelo operativo convierte la independencia del software en un compromiso interno de ingeniería sustancial.

Muchas empresas y proveedores de servicios necesitan que un proveedor absorba más riesgo de integración. Dell ofrece Enterprise SONiC con hardware cualificado y soporte comercial. Nokia proporciona imágenes y soporte de la versión comunitaria de SONiC en plataformas seleccionadas, mientras que otros proveedores de conmutadores, fabricantes de diseño original e integradores empaquetan sus propias combinaciones. Estas ofertas pueden establecer una vía de escalado más clara, pero pueden diferir en parches, funciones de gestión, cobertura de hardware y calendario de versiones.

La capa comercial es donde se venden el trabajo de ciclo de vida y la responsabilidad. Los operadores de nube obtienen flexibilidad de adquisición; los proveedores de conmutadores y silicio venden sistemas; los distribuidores venden suscripciones y soporte; los integradores venden ingeniería; y los clientes pueden reducir la dependencia de un único proveedor integrado verticalmente. El Fondo Dirigido en sí no tiene accionistas de capital, valoración corporativa ni beneficio independiente publicado.

Los participantes cooperan en torno a la capa compartida mientras compiten por encima y por debajo de ella. Arista, Cisco, Dell, Nokia y NVIDIA pueden contribuir al mismo proyecto mientras venden productos diferentes. Los operadores de nube pueden soportar interfaces comunes mientras negocian agresivamente con los proveedores de hardware, y las empresas de ASIC se benefician cuando SONiC facilita la integración de su silicio, al tiempo que conservan la diferenciación en funcionalidades y rendimiento.

La capa común reduce el trabajo duplicado solo donde los participantes aceptan un comportamiento común. Las implementaciones privadas de SAI, los parches descendentes y las extensiones del proveedor pueden debilitar la portabilidad incluso cuando los productos comparten el nombre SONiC. Las empresas tienen incentivos para contribuir lo suficiente para sostener el ecosistema, preservando al mismo tiempo la diferencia suficiente para vender su propia oferta.

Las cuotas de membresía hacen visible la participación financiera, pero la ingeniería es probablemente la moneda más importante. Una cuota Premier de 100 000 USD es significativa para el Fondo y pequeña en comparación con el coste de mantener un equipo especializado o un laboratorio de hardware. Las organizaciones que suministran años de implementación y pruebas pueden moldear los resultados a través de la realidad operativa, incluso cuando el estatuto separa formalmente el pago de la aceptación técnica.

La falta de un presupuesto público del Fondo limita el análisis de cómo se eligen las prioridades de gasto. Una mayor transparencia financiera ayudaría a los operadores a comparar las prioridades declaradas con el gasto en seguridad, pruebas, documentación, integración continua y conformidad. La creación del Grupo de Trabajo de Seguridad muestra que un área crítica puede permanecer insuficientemente apropiada incluso cuando el ecosistema contiene miembros grandes y bien dotados de recursos.

Los compradores deben tratar “basado en SONiC” como el comienzo de la diligencia debida, no como su conclusión. Necesitan conocer la rama, la versión de SAI, el SDK, el firmware, el propietario de la imagen, las funcionalidades cualificadas, la política de seguridad y la ruta de soporte. También necesitan saber si la imagen puede reproducirse y qué sucede cuando los calendarios de la comunidad, del proveedor y del hardware divergen.

La desagregación crea opciones solo cuando esas fronteras permanecen visibles. De lo contrario, un operador puede reemplazar la dependencia de un proveedor por la dependencia de una imagen personalizada, un integrador o una compilación de SDK que no puede mantenerse en otro lugar. La arquitectura abierta hace posibles las alternativas; los contratos de soporte y la ingeniería interna determinan si siguen siendo utilizables.

El despliegue es sustancial, pero la comparabilidad sigue siendo escasa

El anuncio de transición de la Linux Foundation de 2022 decía que SONiC funcionaba en millones de puertos y más de 100 modelos de conmutadores. En abril de 2024, la Fundación informó de 4 250 colaboradores de más de 520 organizaciones y un crecimiento anual de la comunidad del 20 por ciento. Una biografía de gobernanza indicaba que Alibaba operaba cerca de 100 000 conmutadores, puertas de enlace y enrutadores basados en SONiC.

Cada cifra indica escala, pero ninguna es un censo auditado independiente. Los totales de colaboradores pueden incluir participantes históricos en lugar de mantenedores activos, un modelo soportado puede tener poco volumen de producción y la membresía en la Fundación no prueba el despliegue. Las afirmaciones públicas describen unidades diferentes y no pueden combinarse en una cuota de mercado fiable única.

Los casos nombrados proporcionan evidencia más firme de uso. Microsoft desarrolló y opera SONiC en Azure. Alibaba, eBay y EPFL respaldaron la transición a la Linux Foundation y describieron su uso. Orange informó de un despliegue inicial en producción de unos 90 conmutadores en 2024 y de la intención de ampliarlo, mientras que los materiales de la Fundación destacaron posteriormente los despliegues de SAKURAONE, Tokyo-1, Rakuten y pagos en la India. Dell y Nokia ofrecen productos con soporte vinculados a hardware seleccionado.

La evidencia es más que suficiente para rechazar la descripción de SONiC como un proyecto de laboratorio experimental. Tiene un origen de producción, repositorios activos, varios socios de silicio y hardware, distribuciones comerciales y despliegues de operadores nombrados. Lo que sigue sin estar disponible es una medida consistente de sistemas activos, conjuntos de funcionalidades soportadas y comportamiento comparable entre plataformas.

Esa limitación se vuelve más importante a medida que SONiC se expande hacia redes empresariales y tejidos de IA. Las cifras agregadas de puertos ofrecen confianza categórica, mientras que la evidencia a nivel de plataforma decide si un despliegue concreto es soportable. Los operadores necesitan la versión, el ASIC, la imagen, la matriz de funcionalidades, el historial de actualizaciones, el historial de incidentes y el proveedor responsable.

SONiC se sitúa entre el software personalizado de hiperescala y los productos de red comerciales integrados verticalmente. Arista EOS, Cisco NX-OS, Junos y Nokia SR Linux ofrecen sistemas maduros con una única relación de producto soportado. NVIDIA Cumulus Linux proporciona otro enfoque comercial basado en Linux. Dell Enterprise SONiC y las ofertas con soporte de Nokia comercializan la base de SONiC, mientras que DENT, FBOSS, Open Network Linux, Stratum y Linux switchdev representan arquitecturas abiertas o desarrolladas por operadores adyacentes.

La ventaja de SONiC es la escala del ecosistema compartido en torno a un único modelo de Linux, contenedores, Redis, SWSS y SAI. Los operadores pueden inspeccionar y modificar el código común, elegir entre varias rutas de hardware y reutilizar partes de su automatización entre proveedores. Su desventaja es la matriz de integración creada por esa libertad. El rendimiento y el soporte dependen de cuán exitosamente se hayan reensamblado las capas.

Las redes de IA elevan las apuestas porque los compradores están adquiriendo grandes volúmenes de conmutadores mientras exigen nuevas funcionalidades rápidamente. Un sistema operativo común puede reducir la integración duplicada entre proveedores de sistemas y de silicio. Esa misma urgencia puede alentar extensiones que resuelvan un despliegue a costa de debilitar la portabilidad. La posición de mercado de SONiC dependerá de si sus interfaces mantienen el ritmo sin convertirse en abstracciones nominales sobre implementaciones incompatibles.

La frontera es visible; la responsabilidad aún debe demostrarse

SONiC cambió la conmutación de red al convertir la arquitectura interna de un operador de nube en una plataforma de software compartida. Linux, los contenedores y Redis crearon un plano operativo común. SWSS separó la intención de la aplicación de las operaciones de hardware, y SAI dio a varias familias de ASIC un modelo de objetos común. La gobernanza de la Linux Foundation proporcionó una estructura más neutral a través de la cual empresas competidoras podían financiar y desarrollar el software.

El proyecto no ha hecho que los conmutadores sean intercambiables. No certifica todas las plataformas listadas, no elimina los SDKs propietarios ni proporciona una experiencia de soporte única. Una versión comunitaria puede contener funciones Alpha, mientras que una versión compartida de SAI puede ocultar diferentes capacidades, comportamientos de error y características de reinicio. La coordinación de la seguridad no puede controlar componentes que el proyecto upstream ni posee ni ve.

Esos límites revelan la verdadera contribución del proyecto. Antes de la desagregación, la frontera hardware-software residía en gran medida dentro de un único proveedor. SONiC hizo que una mayor parte de ella fuera explícita y disputable, permitiendo a los operadores identificar qué funciones son comunes, cuáles siguen siendo específicas de la plataforma y qué parte ha aceptado la responsabilidad por el sistema final.

La siguiente fase pondrá a prueba si esa frontera puede mantenerse coherente a medida que la plataforma se expande. Los tejidos de escalado horizontal de IA exigen una convergencia rápida y telemetría de alta frecuencia. El Ethernet de escalado vertical acerca el proyecto a los sistemas de aceleración, los chasis multi-ASIC aumentan la complejidad del estado, el trabajo empresarial amplía la base de usuarios y la gobernanza de la seguridad debe abarcar una gran cadena de suministro de fuentes mixtas.

SONiC ha separado una parte grande y valiosa del sistema operativo del conmutador de la pila de hardware de un proveedor. No ha separado el reenvío del silicio, y ninguna arquitectura de software podría hacerlo. La interoperabilidad sigue dependiendo de las implementaciones de SAI, los SDKs, los controladores, el firmware, las ópticas, la cualificación y el soporte.

La prueba observable no es, por tanto, cuántos productos llevan el nombre de SONiC. Es si diferentes plataformas pueden demostrar un comportamiento comparable, si la titularidad de la seguridad y el mantenimiento sobreviven a los cambios corporativos y si un operador puede moverse entre sistemas soportados sin reconstruir el modelo operativo en torno a otra dependencia indocumentada.

SONiC y la separación inacabada del software de conmutación del hardware

Por qué importa