Sistema operacional de rede SONiC e desagregação de switches

Resumo executivo

A Microsoft desenvolveu o SONiC para o Azure e o lançou por meio do Open Compute Project em 2016, criando uma arquitetura compartilhada de Linux, contêineres e banco de dados para switches de vários fornecedores de hardware.
A Interface de Abstração de Switch (SAI) fornece ao SONiC um vocabulário comum para programar diferentes ASICs, mas os recursos da plataforma, a escala, o comportamento de erro e o suporte ainda dependem das implementações dos fornecedores e dos SDKs proprietários.
A governança da Linux Foundation ampliou a participação sem eliminar a influência da Microsoft. A autoridade técnica, o financiamento do projeto, o desenvolvimento da SAI e o suporte à produção permanecem divididos entre várias instituições e participantes comerciais.
O SONiC está se expandindo para sistemas chassis, comutação empresarial e malhas de IA antes que a conformidade uniforme e a propriedade da segurança estejam totalmente maduras. Sua credibilidade depende do comportamento mensurável, não da amplitude de suas listas de suporte.

Uma rota chega ao silício através de uma cadeia de passagens

Uma rota do Border Gateway Protocol no SONiC não se move diretamente de um processo de roteamento para a tabela de encaminhamento de um switch. O FRRouting recebe a atualização, aplica a política e seleciona a rota. O Zebra passa o estado de encaminhamento através da interface do Forwarding Plane Manager, o fpmsyncd grava a intenção do aplicativo no APPL_DB, e o Switch State Service resolve os vizinhos, próximos saltos e interfaces necessários.

A solicitação é então serializada pelo ASIC_DB, consumida pelo syncd, traduzida por uma implementação da Interface de Abstração de Switch do fornecedor e pelo kit de desenvolvimento de software proprietário e, finalmente, programada no ASIC.

Essa cadeia explica tanto a importância do SONiC quanto sua dificuldade. Cada limite permite que uma parte do sistema se desenvolva sem conhecimento direto de todos os outros componentes. O software de roteamento pode operar em um modelo de aplicação comum, enquanto os fornecedores de hardware traduzem objetos de switch padrão nas instruções exigidas por seu silício. A mesma separação também cria mais lugares onde o estado desejado, o estado relatado e o comportamento real de encaminhamento podem divergir.

Os switches de rede tradicionais geralmente chegavam como produtos verticalmente integrados. O fornecedor combinava hardware, sistema operacional, roteiro de recursos e relacionamento de suporte, dando ao comprador uma única parte para contatar quando o sistema falhava. O arranjo simplificava a responsabilização, mas vinculava a escolha de software, interfaces de automação e aquisição de hardware ao mesmo fornecedor. Grandes operadores de nuvem que gerenciam dezenas de milhares de switches amplamente semelhantes tinham que aceitar esse acoplamento ou construir mais da pilha por conta própria.

O SONiC tomou o segundo caminho. Ele usa o Linux como base, divide as funções de rede em serviços de software, troca estado por meio de bancos de dados apoiados pelo Redis e coloca uma abstração de hardware abaixo dos aplicativos de rede. O projeto não elimina as diferenças de hardware e não fornece um contrato de suporte global único. Ele cria uma camada de software comum que pode sobreviver a uma mudança de fornecedor de switch, fabricante original de design ou família de ASIC, desde que alguém conclua e ofereça suporte ao trabalho específico da plataforma abaixo dela.

A promessa econômica é a desagregação. Um operador pode fazer escolhas separadas sobre hardware, silício, distribuição do sistema operacional, integração e suporte, em vez de comprá-los como um único produto. A consequência operacional é a responsabilidade dividida. Um recurso pode existir na versão comunitária, mas permanecer indisponível ou se comportar de maneira diferente em uma plataforma específica, porque a limitação decisiva está no firmware, nos drivers, no código SAI do fornecedor, em um SDK ou no pipeline físico.

O Azure transformou um problema de frota em uma plataforma aberta

A Microsoft desenvolveu o SONiC para o Azure antes de apresentá-lo publicamente. Sua origem foi, portanto, um problema de produção, e não uma proposta abstrata para redes abertas. Operadores de hiperescala precisam automatizar grandes frotas de switches, alterar o software mais rapidamente do que os ciclos de produto convencionais podem permitir e comprar hardware de vários fornecedores sem manter um modelo operacional completamente diferente para cada um.

A Microsoft anunciou sua contribuição do SONiC para o Open Compute Project em 9 de março de 2016. O nome significa Software for Open Networking in the Cloud (Software para Redes Abertas na Nuvem). A Microsoft o descreveu como uma coleção de componentes de software de rede para switches e o associou à Interface de Abstração de Switch, ou SAI. Esse emparelhamento era essencial porque uma pilha superior portátil teria oferecido valor limitado se cada aplicativo de roteamento, orquestração e gerenciamento ainda precisasse de conhecimento direto da interface de cada fornecedor de silício.

A SAI forneceu um vocabulário de programação comum para objetos, incluindo portas, VLANs, rotas, próximos saltos, vizinhos, entradas de controle de acesso, filas, buffers, túneis e contadores. Um fornecedor de ASIC ou plataforma poderia implementar esses objetos em seu próprio SDK e pipeline de encaminhamento. Os aplicativos do SONiC poderiam então solicitar um objeto padrão em vez de incorporar chamadas de hardware proprietárias em todo o código comum.

A participação no Open Compute Project conectou o software a operadores de data centers, fabricantes originais de design, fornecedores de switches e empresas de silício que já trabalhavam em hardware aberto e co-design de hardware e software. A Microsoft trouxe um ambiente operacional real, enquanto o grupo mais amplo forneceu a diversidade de hardware necessária para testar a promessa do projeto. Nenhum fator tornou a portabilidade completa. Cada plataforma ainda precisava de integração de inicialização, drivers, gerenciamento térmico, manuseio de ópticas, uma implementação SAI, suporte ao SDK e testes contínuos.

O trabalho menos visível tornou-se a base do ecossistema. O código comum de roteamento, orquestração e gerenciamento poderia ser compartilhado, enquanto as empresas mais próximas do hardware mantinham as camadas específicas da plataforma. A Microsoft continuou a fornecer engenharia e requisitos extraídos do Azure, mas outros operadores de nuvem, fornecedores e integradores adquiriram uma rota para o projeto que não dependia exclusivamente do roteiro interno de uma empresa.

Esse histórico torna o papel atual da Microsoft mais fácil de entender. A empresa criou o SONiC e acumulou anos de conhecimento operacional antes que a governança neutra fosse estabelecida. Mover o projeto não apagou essa vantagem. Criou uma estrutura na qual outras empresas poderiam investir, governar e contribuir sem fingir que a experiência de produção do criador havia se tornado intercambiável da noite para o dia.

Linux e Redis tornaram o switch modular — e stateful

O SONiC é geralmente descrito como um sistema operacional de rede baseado em Linux, mas o Linux sozinho não explica sua arquitetura. O sistema host fornece o kernel, o acesso ao dispositivo e os serviços básicos. As principais funções de rede são executadas em contêineres separados, enquanto os bancos de dados apoiados pelo Redis fornecem o estado compartilhado e as interfaces de mensagens por meio das quais esses serviços se coordenam. O Switch State Service converte a intenção do aplicativo em operações SAI, e um processo voltado para o hardware conecta essas operações à implementação do fornecedor.

A estrutura de contêineres historicamente separou funções incluindo roteamento, Link Layer Discovery Protocol, Simple Network Management Protocol, agregação de links, monitoramento de plataforma, bancos de dados, SWSS e sincronização de ASIC. A separação melhora o empacotamento e a propriedade organizacional, mas não deve ser confundida com uma fronteira de segurança forte em todos os casos. Os serviços de rede podem compartilhar recursos do host e exigir privilégios elevados para interagir com o kernel e o hardware.

Seu valor reside principalmente em permitir que os componentes sejam desenvolvidos, reiniciados e atualizados sem compilar todo o switch em um processo opaco.

O Redis fornece a linguagem comum. O CONFIG_DB contém a configuração pretendida. O APPL_DB transporta a intenção de encaminhamento e serviço no nível do aplicativo para a camada de orquestração. O ASIC_DB representa objetos SAI serializados para o processo voltado para o hardware, enquanto o STATE_DB registra a prontidão do tempo de execução e as dependências. O COUNTERS_DB armazena estatísticas de interface e hardware usadas por ferramentas operacionais e telemetria.

A configuração pode entrar por meio de arquivos, ferramentas de linha de comando, gNMI, REST ou outro software de gerenciamento. Os processos gerenciadores traduzem essa entrada em operações de aplicativo, e o SWSS consome o estado resultante. O orchagent resolve dependências e cria solicitações SAI, o sairedis as serializa no ASIC_DB e o syncd chama a biblioteca SAI e o SDK do fornecedor. Componentes escritos em diferentes linguagens e mantidos por diferentes equipes podem, portanto, coordenar-se por meio de estados definidos, em vez de uma teia densa de chamadas privadas.

O resultado é uma máquina de estados distribuída. Uma chave de banco de dados pode se tornar obsoleta, um gravador pode competir com outro e um aplicativo pode aceitar o estado pretendido antes que o hardware o rejeite. Os contadores podem colocar pressão no caminho do banco de dados, enquanto as reinicializações exigem que vários contêineres reconstruam uma visão consistente do que o switch deveria estar fazendo. O Redis não é um detalhe de implementação passivo. Seus esquemas, persistência e comportamento de falha influenciam a confiabilidade de todo o sistema.

A modularidade torna essas transições mais visíveis. Os operadores podem inspecionar onde uma solicitação chegou e identificar qual serviço é responsável pela próxima etapa. No entanto, a visibilidade não garante a correção. Uma rota selecionada no FRRouting, gravada no APPL_DB e representada no ASIC_DB ainda pode estar ausente do hardware de encaminhamento. O sistema precisa de reconciliação, diagnóstico e evidências de tráfego capazes de distinguir a aceitação administrativa da entrega real de pacotes.

A SAI moveu o limite proprietário sem removê-lo

A SAI é a principal razão pela qual o SONiC pode manter uma arquitetura superior amplamente comum em várias famílias de ASIC. O orchagent pode solicitar uma rota, porta, próximo salto, entrada de controle de acesso, fila, túnel ou contador sem conter chamadas de SDK de um fornecedor. Isso reduz o acoplamento e fornece aos aplicativos de rede um modelo de objetos estável, mesmo quando o fornecedor de switch subjacente muda.

A interface não pode tornar ASICs fisicamente diferentes equivalentes. O silício varia em capacidade de tabela, design de pipeline, arquitetura de buffer, combinações de objetos suportadas, semântica de contadores, funções de telemetria, atomicidade de atualização, processamento de túnel e comportamento de reinicialização. Um fornecedor deve mapear objetos SAI para esses recursos, muitas vezes por meio de código proprietário e um SDK que os mantenedores da comunidade não podem inspecionar.

Duas plataformas podem, portanto, anunciar a mesma versão SAI enquanto oferecem comportamento materialmente diferente. Uma pode suportar uma tabela EVPN maior, uma política de controle de acesso mais complexa ou uma reinicialização mais quente do que outra. Um recurso pode exigir uma capacidade de silício ou extensão SAI ausente em um chip anterior. A interface comum reduz o quanto o software superior precisa mudar, mas não certifica a escala ou o desempenho.

O limite de governança reforça o técnico. O SONiC migrou para a Linux Foundation em abril de 2022, enquanto a SAI permaneceu sob o Open Compute Project. As duas comunidades se coordenam, mas não compartilham estruturas de decisão idênticas. Um novo requisito em telemetria, rede de IA ou Ethernet de expansão pode precisar de mudanças simultâneas nos aplicativos SONiC, definições SAI, implementações de fornecedores, SDKs e silício.

A solução de problemas segue a mesma cadeia. Uma solicitação válida pode falhar no código comum de orquestração, em um adaptador do fornecedor, em um SDK ou no próprio hardware. Os mantenedores da comunidade podem ver o erro SAI sem acesso à camada proprietária que o produziu, enquanto um fornecedor de hardware pode oferecer suporte apenas a uma combinação específica de imagem e SDK. Uma distribuição comercial pode assumir mais desse ônus de integração, mas o SONiC comunitário não cria um caminho de escalonamento universal.

O SONiC, portanto, moveu a dependência do fornecedor para um limite mais restrito e explícito voltado para o hardware. Essa é uma mudança arquitetural substancial. Ela não removeu a dependência e, em falhas difíceis, a resposta final ainda pode vir da empresa que controla a implementação proprietária mais próxima do ASIC.

A reconciliação de estado é o preço da modularidade

Um aplicativo pode aceitar uma configuração, gravá-la no banco de dados esperado e relatar a conclusão antes que a camada voltada para o hardware descubra que o ASIC não pode criar o objeto solicitado. Quando a falha não retorna pela cadeia com contexto suficiente, o estado pretendido, o estado do aplicativo e o estado real de encaminhamento não correspondem mais. Um sistema modular torna essa divergência mais fácil de localizar, mas também lhe dá mais lugares para ocorrer.

Alguns designs históricos do SONiC tratavam falhas de criação ou definição da SAI como fatais. Parar um processo pode ser mais seguro do que continuar com estado de hardware desconhecido, mas pode deixar o switch difícil de recuperar. Trabalhos posteriores de tratamento de erros introduziram designs incluindo ERROR_DB e feedback de aplicativo para objetos selecionados, como rotas e vizinhos. O objetivo é dar a uma solicitação assíncrona um resultado durável que o aplicativo de origem e o cliente de gerenciamento possam interpretar.

Uma alteração de configuração pode envolver várias operações dependentes. O sistema pode criar um grupo de próximo salto, adicionar membros, atualizar uma rota e remover o estado antigo. Algumas etapas podem ter sucesso antes que uma chamada posterior falhe e os recursos disponíveis do hardware podem mudar entre a validação e a execução. Uma reversão literal pode ser impossível ou insegura, forçando o sistema a corrigir para frente em direção a um estado consistente.

A reinicialização a quente traz o mesmo problema para atualizações e recuperação de processos. O objetivo é reiniciar o software sem descartar o estado de encaminhamento e interromper todo o tráfego. O novo processo deve reconciliar o que seu antecessor pretendia, o que o Redis contém e o que o ASIC continua a fazer. Alterações de esquema, chaves obsoletas ou dependências parcialmente restauradas podem transformar a persistência em outra fonte de incerteza.

Consequentemente, os operadores precisam de mais do que uma resposta de comando bem-sucedida. O CONFIG_DB pode confirmar que uma solicitação foi aceita, o APPL_DB que foi traduzida e o ASIC_DB que um objeto SAI foi solicitado. Nenhum deles prova que os pacotes estão seguindo o caminho pretendido. Contadores de hardware, testes de tráfego externos e reconciliação de estado permanecem parte da garantia normal.

A arquitetura expõe um fato que os sistemas integrados geralmente ocultam: a configuração de rede não é uma única gravação atômica. É uma sequência de transições de estado entre componentes com diferentes tempos e comportamentos de falha. A confiabilidade do SONiC depende de quão bem esses componentes se recuperam após atraso, rejeição, reinicialização e conclusão parcial.

Sistemas chassis multiplicam tanto a escala quanto a falha

A imagem pública inicial do SONiC estava fortemente associada a switches de data center de formato fixo contendo um ASIC de encaminhamento principal. O projeto desde então se expandiu para switches de alta densidade, chassis modulares e sistemas distribuídos de fila de saída virtual (VOQ) com vários ASICs de encaminhamento, dispositivos de malha, placas de linha e componentes de gerenciamento.

Um sistema multi-ASIC pode executar instâncias separadas de Redis, SWSS, syncd, roteamento, descoberta de links e agregação de links para cada dispositivo de encaminhamento. Cada ASIC pode ter sua própria instância de SAI e SDK. O software deve determinar quais interfaces, vizinhos e rotas pertencem a cada namespace, como os links internos são representados e como o estado se move entre os dispositivos.

O sistema maior altera o domínio de falha. Uma rota pode entrar em um ASIC e sair por outro, enquanto um link de painel frontal depende de um caminho de malha interno. Contadores reunidos em namespaces separados devem ser apresentados como parte de um switch lógico. Uma placa de linha pode reiniciar enquanto outras placas e o plano de controle continuam operando, forçando o software a coordenar versões, propriedade de objetos e alcançabilidade da malha entre componentes com estado independente.

Arquiteturas VOQ distribuídas estendem essa coordenação para um chassi ou várias instâncias de switch. As decisões de encaminhamento e enfileiramento podem depender do conhecimento compartilhado de portas remotas e do estado da malha. A substituição da placa de linha, a redundância do plano de controle e a falha parcial da malha devem ser tratadas sem presumir que cada componente esteja disponível ao mesmo tempo.

A versão SONiC 202605 incluiu a reinicialização a quente multi-ASIC limitada como um recurso Alfa para uma topologia restrita. Esse rótulo é tão importante quanto a presença do recurso. Ele confirma o trabalho de implementação ativo, deixando claro que a reinicialização resiliente em sistemas multi-ASIC complexos ainda não era uma capacidade universalmente qualificada.

O suporte a chassis expande a relevância do SONiC para redes de telecomunicações, nuvens de alta densidade e infraestrutura de IA. Também traz o projeto para sistemas onde fornecedores integrados acumularam anos de lógica de recuperação específica da plataforma. A arquitetura aberta pode competir, mas a cobertura de testes, o sequenciamento de atualizações e as obrigações de suporte crescem mais rápido do que apenas a contagem de ASIC.

O gerenciamento decide se a abertura pode ser operada

Um sistema operacional de switch comum é útil apenas quando os operadores podem configurá-lo, observá-lo e atualizá-lo em toda uma frota. O SONiC oferece suporte a ferramentas de linha de comando, configuração estática, SNMP e trabalho envolvendo gNMI, YANG, REST, OpenAPI, Translib e estruturas de validação. As funções disponíveis ainda dependem da versão, modelo de dados, distribuição e plataforma.

O gerenciamento orientado por modelo destina-se a traduzir uma solicitação externa no sistema de configuração baseado em Redis. Modelos YANG definem estruturas válidas, enquanto o CVL e componentes relacionados podem rejeitar entradas malformadas. O Translib e componentes de serviço mapeiam operações de API em tabelas do SONiC, permitindo que controladores funcionem por meio de uma interface suportada, em vez de manipular bancos de dados internos diretamente.

A validação de esquema não pode provar que um serviço solicitado está autorizado, é compatível com outra alteração ou pode ser suportado pelos recursos restantes do ASIC. Um design documentado também descreveu operações de comparação e troca sem bloqueio ou reversão geral. Os desenvolvedores de aplicativos devem, portanto, definir propriedade, concorrência e compensação, em vez de presumir que a camada de gerenciamento fornece uma transação universal.

OpenConfig e gNMI mostram a diferença entre incluir um componente e concluir um recurso operacional. O SONiC 202605 incluiu o sonic-gnmi 0.1, enquanto a telemetria de discagem de saída YANG do OpenConfig permaneceu Alfa. Uma declaração de suporte útil deve identificar o modelo, caminho, operação de leitura ou gravação, modo de telemetria, versão e distribuição do fornecedor. A afirmação ampla de que um switch suporta OpenConfig transmite muito pouco.

Interfaces legadas permanecem necessárias. O SNMP vincula switches a sistemas de monitoramento estabelecidos, o LLDP fornece informações de vizinhança e os serviços de plataforma expõem ventiladores, temperatura, energia e ópticas. O trabalho de BMC e Redfish aborda funções de ciclo de vida fora da banda, mas vários fluxos de trabalho relacionados na versão 202605 também mantiveram o status Alfa.

A comutação empresarial levanta outro conjunto de expectativas de gerenciamento. O SONiC foi projetado para ambientes de hiperescala cujos operadores podem criar imagens, administrar laboratórios de qualificação e manter relacionamentos diretos com hardware. Redes de campus e acesso exigem funções como Power over Ethernet, Spanning Tree, controle de admissão 802.1X e gerenciamento previsível de endpoints, muitas vezes para equipes sem capacidade de engenharia em escala de nuvem.

O grupo de trabalho PENS, que cobre PoE e serviços de rede empresarial, é uma tentativa de fechar essa lacuna. Outros grupos abordam gerenciamento, sistemas operacionais de plataforma, integração BMC, planos de dados virtuais e documentação. Sua existência mostra trabalho ativo, não maturidade uniforme. A adoção empresarial dependerá de mover funções do design e implementação para a inclusão de versões, qualificação de hardware e entrega comercial suportada.

As distribuições comerciais tornam-se particularmente importantes nesse limite. Elas podem fornecer uma superfície de gerenciamento testada, política de atualização, matriz de hardware e processo de suporte em torno dos componentes upstream. O SONiC comunitário fornece a base comum; o operador ainda precisa de uma parte para assumir o ciclo de vida da imagem realmente em execução no switch.

O nome Foundation cobre um projeto e um fundo dirigido

O nome "SONiC Foundation" pode sugerir uma organização incorporada separadamente com seu próprio conselho estatutário, funcionários e contas. O registro de governança disponível suporta uma descrição mais em camadas. A SONiC Foundation é o projeto técnico e a comunidade hospedados pela Linux Foundation, enquanto nenhuma empresa SONiC Foundation separadamente incorporada ou entidade legal independente sem fins lucrativos foi identificada nas evidências fornecidas.

Uma estrutura relacionada, o SONiC Fund, é um Fundo Dirigido da Linux Foundation. Ele arrecada e gasta dinheiro em apoio ao projeto técnico. Seu Conselho de Administração supervisiona associações, orçamentos, divulgação, políticas e possíveis programas de conformidade. O Comitê Técnico de Direção lida com a direção técnica e, embora seja representado dentro da estrutura mais ampla, as autoridades técnicas e financeiras permanecem distintas.

Essa divisão impede que a associação se torne um substituto para implantação ou comando técnico. Uma empresa pode ingressar no Fundo Dirigido sem executar o SONiC em produção. Um assento no Conselho de Administração não decide todas as discussões de design e um colaborador pode influenciar o software sem adquirir a associação Premier. A Linux Foundation administra os fundos e marcas do projeto, enquanto os direitos de código permanecem regidos pelas licenças e direitos autorais dos contribuidores pertinentes.

A SAI adiciona mais um limite institucional porque permanece uma iniciativa do Open Compute Project. O projeto SONiC desenvolve o software operacional comum, o Fundo Dirigido financia e promove esse trabalho, o OCP hospeda a SAI e atividades de hardware relacionadas, e fornecedores ou operadores integram os componentes resultantes com switches e suporte comercial. O Dell Enterprise SONiC e outras distribuições estão a jusante do projeto comunitário, em vez de transformar a Foundation em um fornecedor de software convencional.

O arranjo identifica onde as decisões e responsabilidades residem. Um grupo de trabalho e o TSC podem moldar um recurso, o estatuto do Fundo Dirigido rege as taxas de associação e os participantes do OCP desenvolvem um objeto ou versão SAI. Uma falha de produção ainda pode exigir uma equipe de SDK proprietário ou o fornecedor que qualificou a imagem final. Tratar cada camada como uma Fundação ocultaria os limites que os operadores devem gerenciar.

A governança neutra não apagou a influência da Microsoft

A Linux Foundation anunciou a transição do SONiC em 14 de abril de 2022. Até então, o projeto havia superado a aparência de pilha interna de uma empresa de nuvem. Uma estrutura neutra ofereceu associação compartilhada, financiamento, eleições, marca e participação técnica a empresas que, de outra forma, poderiam hesitar em depender da governança hospedada pela Microsoft.

O anúncio dizia que o SONiC já estava sendo executado em milhões de portas e mais de 100 modelos de switches, com mais de 50 parceiros. Essas eram alegações do projeto e do criador, não um censo independente. No entanto, elas mostram que a mudança foi apresentada como a institucionalização de uma plataforma implantada, não a incubação de um novo experimento.

O estatuto do Fundo Dirigido alterado em 5 de maio de 2026 permite que membros Premier nomeiem representantes para o Conselho de Administração. Os membros Gerais elegem representantes como uma classe de acordo com o tamanho dessa associação, enquanto os membros Associados não recebem assentos no Conselho. O Conselho é normalmente limitado a 19 representantes votantes, a menos que seja aumentado, o quórum é de 50% e as decisões ordinárias exigem maioria simples onde houver quórum, embora se prefira o consenso.

A taxa anual do Fundo Dirigido para um membro Premier é de US$ 100.000, separada da associação corporativa exigida à Linux Foundation. As taxas para membros Gerais variam de US$ 1.000 para organizações com até 499 funcionários a US$ 20.000 para organizações com pelo menos 5.000 funcionários. Membros Associados aprovados participam sem taxa do Fundo. A Linux Foundation aplica uma taxa geral e administrativa de 9% aos primeiros US$ 1 milhão em receitas brutas anuais e 6% acima desse valor.

Esses números explicam o mecanismo de financiamento, mas não divulgam o orçamento real do projeto. Nenhuma receita, despesa, reserva ou alocação pública anual do Fundo foi identificada. As reuniões do Conselho de Administração são privadas por padrão, a menos que o Conselho decida o contrário, tornando os repositórios técnicos e grupos de trabalho mais visíveis do que as escolhas financeiras que apoiam testes, eventos, divulgação ou infraestrutura.

O dinheiro é apenas uma parte do modelo de contribuição. Microsoft, operadores de nuvem, empresas de silício, fornecedores de switches e integradores fornecem engenharia, portas de plataforma, implementações SAI, laboratórios, capacidade de integração contínua, documentação e trabalho de versão. O valor dessas contribuições não é publicado como um total financeiro único e o projeto permanece exposto quando uma equipe corporativa muda de prioridades.

A Microsoft ocupa a concentração mais visível da liderança atual. No ponto de corte da pesquisa, Dave Maltz presidia o Conselho de Administração, Xin Liu presidia o Comitê de Divulgação e Guohan Lu presidia o Comitê Técnico de Direção. A Microsoft também era a criadora do projeto, membro Premier, contribuidora ativa e uma grande operadora de produção.

A governança mais ampla é genuinamente multiempresa. A representação no Conselho de Administração incluiu Alibaba Cloud, Arista, Broadcom, Celestica, Cisco, Dell, Google, Marvell, Nokia, NVIDIA, PLVision, Upscale AI, Nexthop AI e outros. A eleição do TSC de 2026 produziu um presidente e oito membros votantes associados à Microsoft, Google, Broadcom, NVIDIA, Alibaba Cloud, Cisco, Dell, Marvell e uma afiliação independente.

A votação formal não captura toda a autoridade técnica. O projeto descreve um modelo meritocrático e reconhece um elemento de "ditadura benevolente" no nível de componente ou projeto para resolver conflitos. Mantenedores e engenheiros com profundo conhecimento operacional podem influenciar os resultados porque outros participantes dependem de suas revisões, mesmo quando a governança financeira permanece separada.

A vantagem da Microsoft combina posições de liderança com evidências operacionais do Azure. Falhas, atualizações e limites de escala geram conhecimento que os documentos de design público raramente capturam. O teste da governança neutra, portanto, é se outras organizações podem possuir subsistemas difíceis, desafiar escolhas de design e sustentar versões se as prioridades da Microsoft mudarem. A diversidade do Conselho fornece uma estrutura; a concentração de contribuições e a propriedade dos mantenedores forneceriam evidências mais fortes.

Lançamentos definem uma linha de base, não um produto certificado

O SONiC 202605 mostra quanto software um sistema operacional de rede moderno integra. A versão usava Debian 13 Trixie, um kernel SONiC 6.12.41, SAI 1.18.1, FRR 10.5.4, Redis 8.0.2, Docker 28.2.1 e Python 3.13.5. Também reuniu descoberta de links, agregação, SNMP, DHCP, anúncios de roteamento, telemetria e pacotes de plataforma cuja segurança e ciclo de vida não se movem em um único cronograma.

A lista de dependências estabelece uma linha de base de ramificação. Isso não significa que todos os switches executam binários idênticos. As imagens de plataforma podem conter módulos de kernel do fornecedor, bibliotecas SAI, SDKs, firmware, drivers e configuração, enquanto as distribuições comerciais podem conter patches ausentes na ramificação da comunidade.

Os rótulos de qualidade são, portanto, essenciais. A versão 202605 classificou a telemetria de discagem de saída YANG do OpenConfig, a reinicialização a quente multi-ASIC limitada, os fluxos de trabalho BMC Redfish, as operações de senha de unidade autoencriptável, a vinculação VRF de telemetria e uma estrutura de eventos ou alarmes como Alfa. Os usuários podem avaliar essas implementações, mas a inclusão na versão não é uma promessa de comportamento estável em todas as plataformas listadas.

Os testes devem cobrir combinações de ASIC, switch, topologia, recurso, ramificação e caminho de atualização. As condições públicas do sonic-mgmt incluem pulos específicos da plataforma e falhas esperadas. Um pulo pode indicar uma função não suportada, uma limitação de teste, um problema conhecido ou um caso irrelevante, portanto não deve ser tratado automaticamente como um defeito do produto. O padrão mais amplo ainda mostra por que a frase "suporta SONiC" é muito ampla para aquisição.

Uma declaração de plataforma significativa identifica o hardware, ASIC, fornecedor de imagem, versão do SONiC, implementação SAI, SDK, recursos testados e proprietário do suporte. A reinicialização a quente em um switch fixo diz pouco sobre um chassi distribuído. Uma escala de controle de acesso em um ASIC não pode ser transferida para outro, e um caminho gNMI na imagem da comunidade pode diferir da interface oferecida por uma distribuição comercial.

A comunidade pode publicar uma versão comum e uma estrutura de teste, mas a responsabilidade pela produção pertence ao operador e às partes que qualificaram a imagem final. O estatuto do Fundo Dirigido permite programas de conformidade, mas nenhuma matriz independente abrangente mostrando resultados comparáveis de aprovação e reprovação nas plataformas atuais foi identificada. Até que essas evidências existam, uma versão é um contrato de integração em torno de código comum, não uma certificação universal dos sistemas construídos a partir dele.

As malhas de IA são o teste mais severo da camada comum

Grandes clusters de GPU estão mudando as demandas impostas às redes de data centers. O treinamento distribuído pode gerar fluxos sincronizados de longa duração, baixa entropia de tráfego, microexplosões e desempenho limitado pelo participante mais lento. Os operadores precisam de alta largura de banda, rápida convergência de falhas, escala densa de vizinhos e sessões, evidências precisas de congestionamento e recursos que podem depender de novos silícios de switch.

Um artigo da SONiC Foundation de julho de 2026, de Guohan Lu, da Microsoft, e Mehak Mahajan, da Broadcom, descreveu a arquitetura Fairwater da Microsoft e quatro capacidades que estariam disponíveis na versão 2025.11: maior escala BGP, distribuição de tráfego selecionada pela origem com base em SRv6, corte de pacotes e telemetria de streaming de alta frequência. O mesmo artigo descreveu um design multiplano e multicaminho destinado a suportar até 512.000 GPUs. Essas eram alegações do projeto e dos profissionais, não evidências auditadas de forma independente de que o número total estava operando simultaneamente.

O trabalho BGP foi descrito como suportando 512 sessões por switch, cerca de 1.000 rotas e 512 próximos saltos no design relevante. O FRR 10 e aproximadamente 20 patches direcionados produziriam convergência do plano de dados abaixo de 100 milissegundos. O artigo não forneceu uma topologia completa, distribuição percentual, especificação de hardware ou método reproduzível de forma independente, portanto, o número pertence à arquitetura relatada, e não ao SONiC como uma garantia de desempenho universal.

SRv6 e uSID abordam a entropia limitada criada por um pequeno número de fluxos muito grandes. Caminhos selecionados pelo endpoint podem distribuir o tráfego de forma mais deliberada do que o hashing convencional, mas o mecanismo requer endpoints ou NICs compatíveis, análise de ASIC adequada, capacidade de tabela, suporte de roteamento e recuperação de falhas. O recurso do sistema operacional funciona apenas como parte de uma pilha coordenada.

O corte de pacotes preserva um cabeçalho curto de um pacote descartado e o encaminha para que o destino possa detectar a perda mais rapidamente. O artigo da Foundation descreveu um caso específico de hardware em que cabeçalhos cortados de até 18 portas de entrada poderiam drenar através de uma saída no hardware atual de 512 portas. O resultado depende do ASIC e do padrão de tráfego e não mostra que todas as plataformas SONiC ou endpoints suportam o mecanismo.

A telemetria de alta frequência destina-se a capturar eventos perdidos por pesquisas mais lentas. O caminho descrito usa exportação de contador IPFIX do ASIC, Counter SyncD, COUNTERS_DB e análise no switch ou exportação OpenTelemetry para sistemas como Prometheus ou InfluxDB. Esse design coloca o Redis e o processamento de telemetria dentro do ciclo de feedback da malha de IA, aumentando tanto seu valor operacional quanto sua carga de desempenho.

A associação seguiu a mesma direção. A Upscale AI tornou-se membro Premier em fevereiro de 2026. A Supranett entrou no nível Premier em 28 de julho, enquanto Exaware, TeraHop e Infrawaves tornaram-se membros Gerais. A Nexthop AI e outras empresas de rede de IA também ocupam funções de governança ou grupos de trabalho. A associação demonstra investimento e intenção, não implantação, mas identifica os problemas que as empresas esperam que a plataforma comum resolva.

O Ethernet de escalonamento empurra o SONiC para mais perto dos sistemas aceleradores que historicamente usaram interconexões especializadas. O grupo de trabalho Scale-Up Ethernet destina-se a traduzir requisitos emergentes, incluindo trabalho alinhado com o OCP E-SUN, em implementações que cobrem repetição em nível de link, controle de fluxo baseado em crédito, hashing de fluxo adaptativo, cabeçalhos de pacotes de escalonamento e malhas de endpoint maiores.

A oportunidade é significativa. Uma implementação madura poderia permitir que um ambiente de sistema operacional de rede aberta servisse grandes malhas de escalonamento horizontal e partes de um mercado emergente de Ethernet de escalonamento vertical. Os operadores poderiam reutilizar práticas de gerenciamento, telemetria e plataforma em mais partes da rede de IA.

O trabalho não havia atingido um padrão universal finalizado ou ampla implantação no ponto de corte da pesquisa. Os requisitos ainda estavam evoluindo, os fornecedores podiam expor funções essenciais por meio de extensões e as mudanças tinham que cruzar o SONiC, a SAI, o software de endpoint, as NICs, o firmware e o silício. À medida que o SONiC se aproxima do comportamento especializado de aceleradores, a semântica precisa do hardware se torna mais importante. A camada comum pode se expandir enquanto o limite proprietário abaixo dela se torna mais consequente.

A segurança tornou-se formal depois que a plataforma já estava em produção

Uma imagem do SONiC combina Debian, o kernel Linux, um tempo de execução de contêiner, Redis, FRRouting, serviços de gerenciamento, LLDP, SNMP, componentes DHCP, pacotes Python, drivers de plataforma, bibliotecas SAI do fornecedor, SDKs proprietários, firmware e infraestrutura de compilação. Uma vulnerabilidade em qualquer uma dessas camadas pode afetar o switch ou seu plano de gerenciamento, enquanto a responsabilidade pela correção pode ser dividida entre vários projetos e fornecedores.

Um Grupo de Trabalho de Segurança público foi aprovado em junho de 2026. Seu escopo incluía listas de materiais de software, informações de Exploitabilidade de Vulnerabilidade eXchange, higiene de dependências, análise estática e dinâmica, fuzzing, teste de penetração, segurança da cadeia de suprimentos, endurecimento e inicialização segura ou medida. Brad House, da Nexthop AI, foi identificado como presidente e Qi Luo, da Microsoft, como copresidente.

O documento de formação reconheceu que um trabalho substancial de segurança anteriormente carecia de propriedade suficientemente clara. A segurança não estava ausente: projetos upstream, mantenedores e fornecedores haviam tratado vulnerabilidades e existia um processo de relatório. A admissão foi que a responsabilidade pelo sistema integrado não havia sido organizada em um fluxo de trabalho público visível compatível com o uso de produção da plataforma.

Um grupo de trabalho não conclui essa tarefa. Um programa maduro precisa de SBOMs atuais, registros de proveniência, triagem de vulnerabilidades, compilações assinadas ou reproduzíveis, políticas de patches, tratamento de divulgação privada, backports e avisos específicos da plataforma. Bibliotecas SAI proprietárias, SDKs e firmware complicam a visão upstream porque a comunidade não pode inspecionar seu código-fonte nem controlar seus cronogramas de lançamento.

Os serviços de gerenciamento merecem um escrutínio particular. gNMI, REST, SSH e SNMP expõem controle ou informações privilegiadas, exigindo gerenciamento de certificados, design de funções, auditoria, tratamento de segredos e isolamento de rede. Os contêineres melhoram o empacotamento, mas não criam automaticamente limites de segurança fortes quando compartilham recursos do host e exigem recursos elevados. Um comprometimento no caminho de orquestração ou banco de dados pode afetar muitos objetos de encaminhamento.

Fornecedores comerciais emitem seus próprios avisos porque seus produtos contêm combinações e políticas de suporte diferentes. Uma vulnerabilidade no Dell Enterprise SONiC não deve ser automaticamente generalizada para todas as imagens da comunidade, enquanto um operador não pode presumir que a página do projeto upstream cobre todos os componentes proprietários em seu switch.

O Grupo de Trabalho de Segurança tornou-se um dos testes mais claros de maturidade do projeto. O SONiC mostrou que a colaboração aberta pode integrar roteamento, bancos de dados e abstração de hardware. Agora deve mostrar que o mesmo modelo institucional pode atribuir propriedade em uma cadeia de suprimentos cujas camadas mais sensíveis não são todas abertas.

O código aberto transfere os custos de suporte em vez de removê-los

O SONiC comunitário fornece código-fonte, arquitetura, lançamentos, grupos de trabalho e uma estrutura de teste compartilhada. Não fornece um acordo de nível de serviço de produção universal. Um operador que usa o projeto comunitário ainda deve atribuir responsabilidade pela qualificação de hardware, montagem de imagem, atualizações, backports de segurança, resposta a incidentes e o relacionamento com o fornecedor de ASIC ou plataforma.

Hiperescaladores podem aceitar esse ônus porque o controle da pilha é a razão pela qual buscaram a desagregação. Eles podem manter equipes de Linux, roteamento, engenharia de lançamento e hardware, administrar laboratórios de qualificação e negociar diretamente com fornecedores de silício. Seu modelo operacional converte independência de software em um compromisso substancial de engenharia interna.

Muitas empresas e provedores de serviços precisam de um fornecedor para absorver mais riscos de integração. A Dell oferece o Enterprise SONiC com hardware qualificado e suporte comercial. A Nokia fornece imagens comunitárias do SONiC e suporte em plataformas selecionadas, enquanto outros fornecedores de switches, fabricantes originais de design e integradores empacotam suas próprias combinações. Essas ofertas podem estabelecer um caminho de escalonamento mais claro, mas podem divergir em patches, funções de gerenciamento, cobertura de hardware e cronogramas de lançamento.

A camada comercial é onde o trabalho de ciclo de vida e a responsabilidade são vendidos. Os operadores de nuvem ganham flexibilidade de aquisição; os fornecedores de switches e silício vendem sistemas; os distribuidores vendem assinaturas e suporte; os integradores vendem engenharia; e os clientes podem reduzir a dependência de um fornecedor verticalmente integrado. O próprio Fundo Dirigido não tem acionistas, avaliação corporativa ou lucro independente publicado.

Os participantes cooperam em torno da camada compartilhada enquanto competem acima e abaixo dela. Arista, Cisco, Dell, Nokia e NVIDIA podem contribuir para o mesmo projeto enquanto vendem produtos diferentes. Os operadores de nuvem podem oferecer suporte a interfaces comuns enquanto negociam agressivamente com fornecedores de hardware, e as empresas de ASIC se beneficiam quando o SONiC torna seu silício mais fácil de integrar, mantendo a diferenciação em recursos e desempenho.

A camada comum reduz o trabalho duplicado apenas onde os participantes aceitam o comportamento comum. Implementações SAI privadas, patches downstream e extensões de fornecedores podem enfraquecer a portabilidade, mesmo quando os produtos compartilham o nome SONiC. As empresas têm um incentivo para contribuir o suficiente para sustentar o ecossistema, preservando diferenças suficientes para vender sua própria oferta.

As taxas de associação tornam a participação financeira visível, mas a engenharia provavelmente é a moeda maior. Uma taxa Premier de US$ 100.000 é significativa para o Fundo e pequena ao lado do custo de manter uma equipe especializada ou laboratório de hardware. Organizações que fornecem anos de implementação e teste podem moldar resultados por meio da realidade operacional, mesmo quando o estatuto separa formalmente o pagamento da aceitação técnica.

A falta de um orçamento público do Fundo limita a análise de como as prioridades financeiras são escolhidas. Mais transparência financeira ajudaria os operadores a comparar prioridades declaradas com gastos em segurança, testes, documentação, integração contínua e conformidade. A criação do Grupo de Trabalho de Segurança mostra que uma área crítica pode permanecer insuficientemente apropriada mesmo quando o ecossistema contém membros grandes e bem financiados.

Os compradores devem tratar "baseado em SONiC" como o início da diligência devida, e não sua conclusão. Eles precisam da ramificação, versão SAI, SDK, firmware, proprietário da imagem, recursos qualificados, política de segurança e caminho de suporte. Também precisam saber se a imagem pode ser reproduzida e o que acontece quando os cronogramas de lançamento da comunidade, do fornecedor e do hardware divergem.

A desagregação cria escolha apenas quando esses limites permanecem visíveis. Caso contrário, um operador pode substituir um bloqueio de fornecedor pela dependência de uma imagem personalizada, um integrador ou uma compilação de SDK que não pode ser mantida em outro lugar. A arquitetura aberta torna as alternativas possíveis; contratos de suporte e engenharia interna determinam se elas permanecem utilizáveis.

A implantação é substancial, mas a comparabilidade permanece fraca

O anúncio de transição da Linux Foundation de 2022 dizia que o SONiC estava funcionando em milhões de portas e mais de 100 modelos de switches. Em abril de 2024, a Foundation informou 4.250 colaboradores de mais de 520 organizações e crescimento anual da comunidade de 20%. Uma biografia de governança afirmava que o Alibaba operava cerca de 100.000 switches, gateways e roteadores baseados em SONiC.

Cada número indica escala, mas nenhum é um censo independente auditado. Os totais de colaboradores podem incluir participantes históricos em vez de mantenedores ativos, um modelo suportado pode ter pouco volume de produção e a associação à Foundation não comprova implantação. As declarações públicas descrevem unidades diferentes e não podem ser combinadas em uma participação de mercado confiável.

Casos nomeados fornecem evidências mais firmes de uso. A Microsoft desenvolveu e opera o SONiC no Azure. Alibaba, eBay e EPFL apoiaram a transição da Linux Foundation e descreveram seu uso. A Orange relatou uma implantação de produção inicial de cerca de 90 switches em 2024 e a intenção de expandir, enquanto materiais da Foundation posteriormente destacaram implantações de SAKURAONE, Tóquio-1, Rakuten e pagamentos indianos. Dell e Nokia oferecem produtos suportados vinculados a hardware selecionado.

As evidências são mais do que suficientes para rejeitar a descrição do SONiC como um projeto de laboratório experimental. Ele tem uma origem de produção, repositórios ativos, vários parceiros de silício e hardware, distribuições comerciais e implantações de operadores nomeadas. O que permanece indisponível é uma medida consistente de sistemas ativos, conjuntos de recursos suportados e comportamento comparável entre plataformas.

Essa limitação se torna mais importante à medida que o SONiC se expande para redes empresariais e malhas de IA. Os números agregados de portas oferecem confiança na categoria, enquanto evidências no nível da plataforma decidem se uma implantação específica é suportável. Os operadores precisam da versão, ASIC, imagem, matriz de recursos, registro de atualização, histórico de incidentes e fornecedor responsável.

O SONiC fica entre o software de hiperescala personalizado e os produtos de rede comerciais verticalmente integrados. Arista EOS, Cisco NX-OS, Junos e Nokia SR Linux oferecem sistemas maduros com uma relação de produto suportado. O NVIDIA Cumulus Linux fornece outra abordagem comercial baseada em Linux. O Dell Enterprise SONiC e as ofertas suportadas da Nokia comercializam a base SONiC, enquanto DENT, FBOSS, Open Network Linux, Stratum e Linux switchdev representam arquiteturas abertas ou desenvolvidas por operadores adjacentes.

A vantagem do SONiC é a escala do ecossistema compartilhado em torno de um modelo Linux, contêiner, Redis, SWSS e SAI. Os operadores podem inspecionar e modificar o código comum, selecionar entre vários caminhos de hardware e reutilizar partes de sua automação entre fornecedores. Sua desvantagem é a matriz de integração criada por essa liberdade. O desempenho e o suporte dependem do sucesso com que as camadas foram remontadas.

A rede de IA aumenta as apostas porque os compradores estão adquirindo grandes volumes de switches enquanto exigem novas funções rapidamente. Um sistema operacional comum pode reduzir a integração duplicada entre fornecedores de sistema e silício. A mesma urgência pode encorajar extensões que resolvem uma implantação enquanto enfraquecem a portabilidade. A posição de mercado do SONiC dependerá se suas interfaces acompanham o ritmo sem se tornarem abstrações nominais sobre implementações incompatíveis.

O limite é visível; a responsabilidade ainda precisa ser comprovada

O SONiC mudou a comutação de rede ao transformar a arquitetura interna de um operador de nuvem em uma plataforma de software compartilhada. Linux, contêineres e Redis criaram um plano operacional comum. O SWSS separou a intenção do aplicativo das operações de hardware e a SAI deu a várias famílias de ASIC um modelo de objeto comum. A governança da Linux Foundation forneceu uma estrutura mais neutra por meio da qual empresas concorrentes podiam financiar e desenvolver o software.

O projeto não tornou os switches intercambiáveis. Ele não certifica todas as plataformas listadas, remove SDKs proprietários ou fornece uma experiência de suporte única. Uma versão da comunidade pode conter funções Alfa, enquanto uma versão SAI compartilhada pode ocultar diferentes capacidades, comportamentos de erro e características de reinicialização. A coordenação de segurança não pode controlar componentes que o projeto upstream não possui nem vê.

Esses limites revelam a verdadeira contribuição do projeto. Antes da desagregação, o limite hardware-software ficava em grande parte dentro de um único fornecedor. O SONiC tornou mais explícito e contestável, permitindo que os operadores identifiquem quais funções são comuns, quais permanecem específicas da plataforma e qual parte aceitou a responsabilidade pelo sistema final.

A próxima fase testará se esse limite pode permanecer coerente à medida que a plataforma se expande. As malhas de expansão de IA exigem convergência rápida e telemetria de alta frequência. O Ethernet de escalonamento se aproxima dos sistemas aceleradores, os chassis multi-ASIC aumentam a complexidade do estado, o trabalho empresarial amplia a base de usuários e a governança de segurança deve abranger uma grande cadeia de suprimentos de código misto.

O SONiC separou uma parte grande e valiosa do sistema operacional do switch da pilha de hardware de um fornecedor. Não separou o encaminhamento do silício, e nenhuma arquitetura de software poderia fazê-lo. A interoperabilidade ainda depende das implementações SAI, SDKs, drivers, firmware, ópticas, qualificação e suporte.

O teste observável, portanto, não é quantos produtos carregam o nome SONiC. É se diferentes plataformas podem demonstrar comportamento comparável, se a propriedade da segurança e manutenção sobrevive às mudanças corporativas e se um operador pode alternar entre sistemas suportados sem reconstruir o modelo operacional em torno de outra dependência não documentada.

SONiC e a separação inacabada do software de switch do hardware