SONiC 网络操作系统与交换机解耦

执行摘要

Microsoft 为 Azure 开发了 SONiC，并于 2016 年通过 Open Compute Project 发布，为多家硬件供应商的交换机创建了共享的 Linux、容器和数据库架构。
交换机抽象接口 (SAI) 为 SONiC 提供了编程不同 ASIC 的通用词汇，但平台能力、规模、错误行为和支持仍取决于厂商实现和专有 SDK。
Linux Foundation 的治理扩大了参与范围，但并未消除 Microsoft 的影响力。技术权威、项目资金、SAI 开发和生产支持仍分散在多个机构和商业参与者之间。
SONiC 正在扩展到机箱系统、企业交换和 AI 网络架构，而统一合规性和安全责任尚未完全成熟。其可信度取决于可衡量的行为，而非支持列表的广度。

路由通过一系列交接到达芯片

在 SONiC 中，一条 BGP 路由并非直接从路由进程进入交换机的转发表。FRRouting 接收更新，应用策略并选择路由。Zebra 通过转发平面管理器接口传递转发状态，fpmsyncd 将应用程序意图写入 APPL_DB，交换机状态服务解析所需的邻居、下一跳和接口。然后请求通过 ASIC_DB 序列化，被 syncd 消费，由厂商的交换机抽象接口实现和专有软件开发工具包进行翻译，最终编程到 ASIC 中。

这条链条解释了 SONiC 的重要性及其难点。每个边界都允许系统的一部分在无需直接了解其他每个组件的情况下进行开发。路由软件可以针对通用应用程序模型运行，而硬件厂商将标准交换机对象转换为硅片所需的指令。同样的分离也造成了更多可能出现期望状态、报告状态和实际转发行为不一致的地方。

传统网络交换机通常以垂直集成产品的形式出现。供应商将硬件、操作系统、功能路线图和支持关系结合在一起，使买方在系统出现故障时有一个联系对象。这种安排简化了责任制，但将软件选择、自动化接口和硬件采购绑定到了同一个供应商。管理着数万台大体相似交换机的大型云运营商不得不接受这种耦合，或者自己构建堆栈的更多部分。

SONiC 走了第二条路。它以 Linux 为基础，将网络功能划分为软件服务，通过 Redis 支持的数据库交换状态，并将硬件抽象层置于网络应用程序之下。该项目并未消除硬件差异，也不提供任何全球支持合同。它创建了一个通用的软件层，可以在切换交换机供应商、原始设计制造商或 ASIC 系列时存活下来，前提是有人完成并支持其下的平台特定工作。

经济上的承诺是解耦。运营商可以就硬件、芯片、操作系统发行版、集成和支持做出单独选择，而非将它们作为一个产品购买。运营上的后果是责任划分。一个特性可能存在于社区版本中，但由于关键限制因素在固件、驱动程序、厂商 SAI 代码、SDK 或物理管道中，在特定平台上可能不可用或表现不同。

Azure 将机群问题转化为开放平台

Microsoft 在公开推出 SONiC 之前，就已为 Azure 开发了它。因此，其起源是一个生产问题，而非关于开放网络的抽象提议。超大规模运营商需要自动化大型交换机机群，比传统产品周期可能允许的速度更快地更改软件，并从多家供应商购买硬件，而无需为每一家维护完全不同的运营模型。

2016 年 3 月 9 日，Microsoft 宣布向 Open Compute Project 贡献 SONiC。该名称代表“云中开放网络软件（Software for Open Networking in the Cloud）”。Microsoft 将其描述为一系列用于交换机的软件网络组件，并将其与交换机抽象接口（SAI）配对。这种配对至关重要，因为如果每个路由、编排和管理应用程序仍需要直接了解每个芯片供应商的接口，那么可移植的上层堆栈将提供有限的价值。

SAI 为对象提供了通用的编程词汇，包括端口、VLAN、路由、下一跳、邻居、访问控制条目、队列、缓冲区、隧道和计数器。ASIC 或平台厂商可以针对自己的 SDK 和转发管道实现这些对象。然后，SONiC 应用程序可以请求标准对象，而不是在整个公共代码中嵌入专有的硬件调用。

Open Compute Project 的参与将该软件与已经在进行开放硬件和软硬件协同设计的数据中心运营商、原始设计制造商、交换机供应商和芯片公司联系起来。Microsoft 带来了真实的运行环境，而更广泛的群体提供了测试项目承诺所需的各种硬件。这两个因素都未能使可移植性完全实现。每个平台仍然需要启动集成、驱动程序、热管理、光学器件处理、SAI 实现、SDK 支持和持续测试。

不太显眼的工作成为了生态系统的基石。通用的路由、编排和管理代码可以共享，而最接近硬件的公司则维护平台特定的层次。Microsoft 继续提供工程支持和源自 Azure 的需求，但其他云运营商、供应商和集成商获得了一条进入项目的途径，不再完全依赖于一家公司的内部路线图。

这段历史使 Microsoft 目前的角色更容易理解。该公司创建了 SONiC，并在建立中立治理之前积累了多年的运营知识。迁移项目并未抹去这一优势。它创建了一个框架，其他公司可以在其中投资、治理和贡献，而无需假装创始者的生产经验已在一夜之间变得可互换。

Linux 和 Redis 使交换机模块化——且有状态

SONiC 通常被描述为基于 Linux 的网络操作系统，但单凭 Linux 不足以解释其架构。主机系统提供内核、设备访问和基本服务。主要的网络功能在单独的容器中运行，而基于 Redis 的数据库提供了共享状态和消息接口，这些服务通过它们进行协调。交换机状态服务将应用程序意图转换为 SAI 操作，而面向硬件的进程将这些操作连接到厂商实现。

容器结构历史上分离了包括路由、链路层发现协议、简单网络管理协议、链路聚合、平台监控、数据库、SWSS 和 ASIC 同步在内的功能。这种分离改善了打包和组织所有权，但不应在每个情况下都把它误认为是强大的安全边界。网络服务可能共享主机资源，并需要提升后的权限才能与内核和硬件交互。它们的价值主要在于允许组件被开发、重启和升级，而无需将整个交换机编译成一个不透明的进程。

Redis 提供了通用语言。CONFIG_DB 包含预期的配置。APPL_DB 承载着面向编排层的应用程序级转发和服务意图。ASIC_DB 表示供面向硬件的进程使用的序列化 SAI 对象，而 STATE_DB 记录运行时就绪状态和依赖关系。COUNTERS_DB 存储运维工具和遥测所使用的接口和硬件统计信息。

配置可以通过文件、命令行工具、gNMI、REST 或其他管理软件进入。管理器进程将这些输入转换为应用程序操作，SWSS 消费生成的状态。orchagent 解析依赖关系并创建 SAI 请求，sairedis 将它们序列化到 ASIC_DB 中，syncd 调用厂商的 SAI 库和 SDK。因此，用不同语言编写并由不同团队维护的组件可以通过定义的状态进行协调，而不是通过密集的私有调用网络。

其结果是一个分布式状态机。数据库键可能变成过时状态，一个写入者可能与另一个写入者竞争，应用程序可能在接受预期状态之后硬件才拒绝它。计数器可能给数据库路径带来压力，而重启则需要多个容器重建交换机应做什么的一致性视图。Redis 并非被动的实现细节。其模式、持久性和故障行为会影响整个系统的可靠性。

模块化使这些转换更加可见。操作员可以检查请求到达了何处，并确定哪项服务负责下一步。然而，可见性并不能保证正确性。在 FRRouting 中被选中、写入 APPL_DB 并在 ASIC_DB 中表示的路由，可能仍然不在转发硬件中。系统需要能够区分管理接受和实际数据包传递的协调、诊断和流量证据。

SAI 移动了专有边界，但未消除它

SAI 是 SONiC 能够在多个 ASIC 系列上维持大致通用的上层架构的主要原因。orchagent 可以请求路由、端口、下一跳、访问控制条目、队列、隧道或计数器，而无需包含任何供应商的 SDK 调用。这降低了耦合性，并使网络应用程序拥有稳定的对象模型，即使底层交换机供应商发生变化。

该接口不能使物理上不同的 ASIC 变得等效。硅片在表容量、管道设计、缓冲区架构、支持的对象组合、计数器语义、遥测功能、更新原子性、隧道处理和重启行为方面各不相同。供应商必须将 SAI 对象映射到这些资源上，通常是通过社区维护者无法检查的专有代码和 SDK 来实现。

因此，两个平台可能宣传相同的 SAI 版本，但提供实质上不同的行为。一个可能支持更大的 EVPN 表、更复杂的访问控制策略或更热的重启。一项功能可能需要较早芯片中缺少的芯片能力或 SAI 扩展。通用接口减少了上层软件必须更改的程度，但它并不认证规模或输出。

治理边界强化了技术边界。SONiC 于 2022 年 4 月移至 Linux Foundation，而 SAI 仍在 Open Compute Project 下。这两个社区进行协调，但并没有共享相同的决策结构。一个在遥测、AI 网络或扩展以太网方面的新需求，可能需要同时更改 SONiC 应用程序、SAI 定义、厂商实现、SDK 和硅片。

故障排除遵循相同的链条。一个有效的请求可能在通用编排代码、供应商适配器、SDK 或硬件本身中失败。社区维护者可能看到 SAI 错误，但无法访问产生错误的专有层，而硬件供应商可能只支持特定的映像和 SDK 组合。商业发行版可以承担更多的集成负担，但社区 SONiC 并不创建一条通用的升级路径。

因此，SONiC 将厂商依赖推向了一个更窄、更明确的面向硬件的边界。这是重大的架构变革。但它并未消除依赖性，在困难的故障中，最终答案可能仍然来自控制着最接近 ASIC 的专有实现的公司。

状态协调是模块化的代价

应用程序可以接受配置，将其写入预期数据库，并在面向硬件的层发现 ASIC 无法创建所请求的对象之前报告完成。当故障未能通过链条返回足够的上下文时，预期状态、应用程序状态和实际转发状态便不再匹配。模块化系统使这种差异更容易定位，但也为其提供了更多发生的位置。

一些历史上 SONiC 的设计将 SAI 创建或设置失败视为致命错误。停止进程可能比在未知硬件状态下继续运行更安全，但这会使交换机难以恢复。后来的错误处理工作引入了包括 ERROR_DB 和对选定对象（如路由和邻居）的应用程序反馈在内的设计。目的是为异步请求提供一个可持久的结果，供发起应用程序和管理客户端解释。

配置更改可能涉及多个相关操作。系统可能创建下一跳组、添加成员、更新路由并移除旧状态。某些步骤可能在后来的调用失败之前成功，而硬件的可用资源可能在验证和执行之间发生变化。字面上的回滚可能不可能或不安全，迫使系统向前纠正以达到一致状态。

热重启将同样的问题带入了升级和进程恢复中。其目标是在不丢弃转发状态和中断所有流量的情况下重启软件。新进程必须协调其前身所期望的、Redis 所含的以及 ASIC 继续执行的内容。模式更改、过时的键或部分恢复的依赖关系可能将持久化变成另一个不确定性来源。

因此，运维人员需要的不仅仅是一个成功的命令响应。CONFIG_DB 可以确认请求已被接受，APPL_DB 确认其已被转换，ASIC_DB 确认已请求 SAI 对象。但无一能证明数据包正遵循预期路径。硬件计数器、外部流量测试和状态协调仍然是正常保障工作的一部分。

该架构揭示了一个集成系统通常隐藏的事实：网络配置不是一次原子写入。它是跨多个组件的状态转换序列，这些组件具有不同的时序和故障行为。SONiC 的可靠性取决于这些组件在发生延迟、拒绝、重启和部分完成后恢复的程度。

机箱系统既放大了规模，也放大了故障

SONiC 早期的公开形象与包含一个主转发 ASIC 的固定形态数据中心交换机密切相关。此后，该项目已扩展到具有多个转发 ASIC、交换矩阵器件、线卡和管理组件的高密度交换机、模块化机箱和分布式虚拟输出队列系统。

多 ASIC 系统可能为每个转发设备运行独立的 Redis、SWSS、syncd、路由、链路发现和链路聚合实例。每个 ASIC 可以拥有自己的 SAI 和 SDK 实例。软件必须确定哪些接口、邻居和路由属于每个命名空间，内部链路如何表示，以及状态如何在设备之间移动。

更大的系统改变了故障域。一条路由可能从一个 ASIC 进入，从另一个 ASIC 离开，而前面板链路则依赖于内部交换矩阵路径。在不同命名空间中收集的计数器必须作为一个逻辑交换机的一部分呈现。一块线卡可能重启，而其他线卡和控制平面继续运行，迫使软件在独立的有状态组件之间协调版本、对象所有权和交换矩阵可达性。

分布式 VOQ 架构将这种协调扩展到整个机箱或多个交换机实例。转发和排队决策可能依赖于对远端端口和交换矩阵状态的共享知识。线卡更换、控制平面冗余和部分交换矩阵故障必须在不能假设每个组件同时可用的情况下处理。

SONiC 202605 版本将有限的多 ASIC 热重启作为针对受限拓扑的 Alpha 特性包含在内。这个标签与该特性的存在同等重要。它证实了正在进行的实现工作，同时明确表示跨复杂多 ASIC 系统的弹性重启尚非普遍合格的能力。

机箱支持扩展了 SONiC 与电信网络、高密度云和 AI 基础设施的相关性。它还将该项目带入了一个集成的供应商已积累了多年平台特定恢复逻辑的系统。开放架构可以竞争，但测试覆盖范围、升级顺序和支持义务的增长速度超过了单纯 ASIC 数量的增长。

管理决定了开放性是否可运维

只有当运维人员能够跨机群配置、观察和升级通用交换机操作系统时，它才有用。SONiC 支持命令行工具、静态配置、SNMP，以及涉及 gNMI、YANG、REST、OpenAPI、Translib 和验证框架的工作。可用的功能仍取决于版本、数据模型、发行版和平台。

模型驱动的管理旨在将外部请求转换为基于 Redis 的配置系统。YANG 模型定义了有效的结构，而 CVL 和相关组件可以拒绝格式错误的输入。Translib 和服务组件将 API 操作映射到 SONiC 表中，允许控制器通过受支持的接口工作，而不是直接操作内部数据库。

模式验证不能证明所请求的服务是经过授权的、与另一更改兼容的，或者是 ASIC 剩余资源所能支持的。一份文档化的设计也描述了比较并交换操作，而没有通用锁定或回滚。因此，应用程序开发者必须定义所有权、并发性和补偿，而不是假设管理层提供了通用事务。

OpenConfig 和 gNMI 显示了包含组件与完成一项运维功能之间的区别。SONiC 202605 包含了 sonic-gnmi 0.1，而 OpenConfig YANG 拨出遥测仍为 Alpha 状态。一份有用的支持声明必须标明模型、路径、读或写操作、遥测模式、版本和供应商发行版。声称交换机支持 OpenConfig 的说法过于宽泛，传递的信息太少。

旧式接口仍然必不可少。SNMP 将交换机连接到既有的监控系统，LLDP 提供邻居信息，平台服务暴露风扇、温度、电源和光学器件。BMC 和 Redfish 工作解决了带外生命周期功能，但 202605 版本中的几个相关工作流也保留了 Alpha 状态。

企业交换带来了另一套管理期望。SONiC 专为超大规模环境设计，这些环境的运维人员可以构建映像、运行认证实验室并维持直接的硬件关系。园区网和接入网需要诸如以太网供电、生成树、802.1X 准入控制和可预测的终端管理等功能，通常针对没有云规模工程能力的团队。

覆盖 PoE 和企业网络服务的 PENS 工作组，是缩小这一差距的一次尝试。其他工作组则处理管理、平台操作系统、BMC 集成、虚拟数据平面和文档。它们的存在表明工作正在进行，而非表示已总体成熟。企业采用将取决于将功能从设计和实现推进到包含在版本中、硬件认证以及受支持的商业交付。

在这个边界上，商业发行版变得尤为重要。它们可以在上游组件周围提供经过测试的管理面、升级策略、硬件矩阵和支持流程。社区 SONiC 提供了通用基础；运维人员仍然需要一个实体来负责交换机上实际运行映像的整个生命周期。

基金会名称涵盖一个项目和一项定向基金

“SONiC Foundation”这一名称可能暗示着一个单独成立的、拥有自己的法定董事会、员工和账户的组织。现有的治理记录支持一种更分层式的描述。SONiC Foundation 是 Linux Foundation 托管的技术项目和社区，而在所提供的证据中未发现单独成立的 SONiC Foundation 公司或独立的非营利法律实体。

一个相关结构，即 SONiC Fund，是一项 Linux Foundation 定向基金。它筹集并支出资金以支持该技术项目。其董事会负责监督成员资格、预算、外联、政策以及可能的合规项目。技术指导委员会处理技术方向，尽管它在更广泛的架构中有代表，但技术和财务权力仍然是分开的。

这种划分防止了成员资格成为部署或技术指挥的代理。公司可以加入定向基金，而无需在生产环境中运行 SONiC。董事会的席位并不能决定每一次设计讨论，贡献者无需购买 Premier 会员资格即可影响软件。Linux Foundation 管理项目资金和商标，而代码权利仍受相关许可证和贡献者版权管辖。

SAI 增加了一层进一步的制度边界，因为它仍是一项 Open Compute Project 倡议。SONiC 项目开发通用操作软件，定向基金为该工作提供资金和推广，OCP 承载 SAI 和相关硬件活动，而供应商或运营商将产生的组件与交换机和商业支持集成。Dell Enterprise SONiC 和其他发行版位于社区项目的下游，而不是将基金会变成一个常规的软件供应商。

这种安排明确了决策和责任所在。一个工作组和 TSC 可能塑造一项功能，定向基金章程管理成员费用，而 OCP 参与者开发 SAI 对象或版本。生产中的故障可能仍需要专有的 SDK 团队或认证最终映像的供应商来解决。将每一层视为一个基金会，会掩盖运维人员必须管理的边界。

中立治理并未抹去 Microsoft 的影响

Linux Foundation 于 2022 年 4 月 14 日宣布了 SONiC 的过渡。从那时起，该项目已不再是一家云公司内部堆栈的模样。一个中立的框架提供了共享的成员资格、资金、选举、品牌和技术参与，那些原本可能犹豫是否要依赖 Microsoft 托管的治理的公司，此时亦可加入。

该公告称，SONiC 已在数百万个端口和超过 100 款交换机型号上运行，拥有超过 50 个合作伙伴。这些是项目和创建者的说法，而非独立统计。尽管如此，它们表明这一举措被呈现为已部署平台的制度化，而非新实验的孵化。

2026 年 5 月 5 日修订的定向基金章程允许 Premier 成员任命董事会代表。General 成员按成员数量作为一个类别选举代表，而 Associate 成员则不获得董事会席位。董事会通常上限为 19 名有表决权的代表，除非增加名额，法定人数为 50%，在存在法定人数的情况下，普通决定需要简单多数票，尽管更倾向于协商一致。

Premier 成员的年度定向基金费用为 100,000 美元，独立于所需的 Linux Foundation 企业会员费。General 会员费从拥有最多 499 名员工的组织的 1,000 美元到拥有至少 5,000 名员工的组织的 20,000 美元不等。获批准的 Associate 成员无需支付基金费用即可参与。Linux Foundation 对年度总收入中首 100 万美元收取 9% 的一般及管理费，超出部分收取 6%。

这些数字解释了资金机制，但未披露项目的实际预算。未发现公开的年度基金收入、支出、储备金或项目级分配。董事会会议默认私下进行，除非董事会另有决定，这使得技术仓库和工作组比支持测试、活动、外联或基础设施的财务决策更加可见。

现金只是贡献模型的一部分。Microsoft、云运营商、芯片公司、交换机供应商和集成商提供工程、平台移植、SAI 实现、实验室、持续集成能力、文档和发布工作。这些贡献的价值并未作为一个财务总额公布，而当企业团队变更优先事项时，项目仍然面临风险。

Microsoft 在目前的领导层中占据着最显眼的集中位置。在研究截止时，Dave Maltz 担任董事会主席，Xin Liu 担任外联委员会主席，Guohan Lu 担任技术指导委员会主席。Microsoft 还是该项目的创建者、Premier 成员、积极贡献者和主要的生产运营商。

更广泛的治理确实是多公司参与的。董事会的代表已包括阿里云、Arista、Broadcom、Celestica、Cisco、Dell、Google、Marvell、Nokia、NVIDIA、PLVision、Upscale AI、Nexthop AI 等。2026 年 TSC 选举产生了一名主席和八名有表决权的成员，分别来自 Microsoft、Google、Broadcom、NVIDIA、阿里云、Cisco、Dell、Marvell 以及一个独立关联方。

正式投票并不能涵盖所有技术权威。该项目描述了一种精英治理模式，并承认在组件或项目层面存在“仁慈的独裁者”元素以解决冲突。拥有深厚运营知识的维护者和工程师可以影响结果，因为其他参与者依赖他们的审查，即使财务治理是分开的。

Microsoft 的优势将领导职位与来自 Azure 的运营证据相结合。故障、升级和规模限制产生的知识，是公开设计文档很少能捕获的。因此，对中立治理的检验在于，其他组织是否能够在 Microsoft 优先级变化时，拥有困难的子系统、挑战设计选择并维持发布。董事会多样性提供了一个框架；贡献集中度和维护者所有权将提供更强有力的证据。

发布定义了基线，而非经认证的产品

SONiC 202605 显示了一个现代网络操作系统集成了多少软件。该版本使用了 Debian 13 Trixie、6.12.41 SONiC 内核、SAI 1.18.1、FRR 10.5.4、Redis 8.0.2、Docker 28.2.1 和 Python 3.13.5。它还集成了链路发现、聚合、SNMP、DHCP、路由公告、遥测和平台包，这些组件的安全性和生命周期并不按同一计划表推进。

依赖项列表建立了一个分支级别的基线。但这并不意味着每台交换机都运行相同的二进制文件。平台映像可能包含厂商的内核模块、SAI 库、SDK、固件、驱动程序和配置，而商业发行版可能带有社区分支中没有的补丁。

因此，质量标签至关重要。202605 发行版将 OpenConfig YANG 拨出遥测、有限的多 ASIC 热重启、BMC Redfish 工作流、自加密硬盘密码操作、遥测 VRF 绑定以及事件或告警框架归类为 Alpha。用户可以评估这些实现，但包含在版本中并不保证在所有列出的平台上都能稳定运行。

测试必须涵盖 ASIC、交换机、拓扑、功能、分支和升级路径的组合。公开的 sonic-mgmt 条件包括特定于平台的跳过和预期失败。跳过可能表示不支持的功能、测试限制、已知问题或不相关的情况，因此不应自动视为产品缺陷。更广泛的模式依然表明，为什么“支持 SONiC”这一说法对于采购而言过于宽泛。

一个有意义的平台声明应标明硬件、ASIC、映像提供商、SONiC 版本、SAI 实现、SDK、已测试的功能和支持所有者。在一台固定交换机上的热重启，对于分布式机箱而言意义甚微。在一个 ASIC 上的访问控制规模无法移植到另一个 ASIC，而社区映像中的 gNMI 路径可能与商业发行版提供的接口不同。

社区可以发布通用的发布和测试框架，但生产责任在于运维人员和对最终映像进行认证的各参与方。定向基金章程允许合规项目，但尚未发现任何全面的独立矩阵以显示当前各平台的可比通过和失败结果。在此类证据存在之前，一个版本只是围绕公共代码的集成契约，而非对其所构建系统的普遍认证。

AI 网络架构是对公共层最严峻的考验

大型 GPU 集群正在改变对数据中心网络的需求。分布式训练可能产生长寿命的同步流、低流量熵、微突发，以及受最慢参与者限制的性能。运维人员需要高带宽、快速故障收敛、密集的邻居和会话规模、精确的拥塞证据，以及可能依赖于新交换机芯片的功能。

2026 年 7 月，SONiC Foundation 上由 Microsoft 的 Guohan Lu 和 Broadcom 的 Mehak Mahajan 撰写的一篇文章，描述了 Microsoft 的 Fairwater 架构和四项据称将在 2025.11 版本中可用的能力：更高的 BGP 规模、基于 SRv6 的源选择流量分发、数据包修剪和高频流式遥测。同一篇文章描述了一种多平面、多轨的设计，旨在支持多达 512,000 个 GPU。这些是项目和从业者的说法，而非经过独立审计的证据，表明全部数量在同时运行。

该 BGP 工作被描述为在相关设计中，每台交换机支持 512 个会话、约 1,000 条路由和 512 个下一跳。据称，FRR 10 和大约 20 个针对性补丁可产生低于 100 毫秒的数据平面收敛时间。该文章未提供完整的拓扑、百分位分布、硬件规格或可独立复现的方法，因此该数字属于所报告的架构，而非 SONiC 作为通用性能保证。

SRv6 和 uSID 解决了由少量极大流量产生的有限熵的问题。端点选择路径可以比传统哈希更刻意地分配流量，但该机制需要兼容的端点或网卡、适当的 ASIC 解析、表容量、路由支持和故障恢复。该操作系统特性仅作为协调堆栈的一部分工作。

数据包修剪保留丢弃数据包的一个短头，并将其转发，以便目的地可以更快地检测到丢失。该基金会的文章描述了一个硬件特定案例，在该案例中，来自多达 18 个入口端口的修剪头，可以在当前的 512 端口硬件上通过一个出口排出。结果取决于 ASIC 和流量模式，并不能表明每个 SONiC 平台或端点都支持该机制。

高频遥测旨在捕获较慢轮询所遗漏的事件。所描述的路径使用 ASIC IPFIX 计数器导出、Counter SyncD、COUNTERS_DB，以及板上分析或通过 OpenTelemetry 导出到 Prometheus 或 InfluxDB 等系统。该设计将 Redis 和遥测处理置于 AI 网络架构的反馈回路中，既增加了它们的运营价值，也增加了其性能负担。

成员资格也遵循了相同的方向。Upscale AI 于 2026 年 2 月成为 Premier 成员。Supranett 于 7 月 28 日加入 Premier 级别，而 Exaware、TeraHop 和 Infrawaves 成为 General 成员。Nexthop AI 和其他 AI 网络公司也担任治理或工作组角色。成员资格显示了投资和意图，而非部署情况，但它明确了企业期望该通用平台解决的问题。

扩展以太网将 SONiC 推向了历史上使用专用互连的加速器系统。Scale-Up Ethernet 工作组旨在将新兴需求（包括与 OCP E-SUN 对齐的工作）转化为实现，涵盖链路级重试、基于信用的流控制、自适应流哈希、扩展数据包头和更大的端点交换矩阵。

机会是显著的。一个成熟的实现可以允许一个开放的网络操作系统环境服务于大型横向扩展网络架构以及新兴的扩展以太网市场的部分。运维人员可能能够在更多的 AI 网络中重用管理、遥测和平台实践。

截至研究截止时，这项工作尚未达到最终通用标准或广泛部署。需求仍在演变，供应商可能通过扩展程序暴露基本功能，而变更必须跨越 SONiC、SAI、端点软件、网卡、固件和硅片。随着 SONiC 更接近专业的加速器行为，精确的硬件语义变得更加重要。公共层可能扩展，而其下的专有边界则变得更为重要。

安全在平台已投入生产后才变得正式化

一个 SONiC 映像结合了 Debian、Linux 内核、容器运行时、Redis、FRRouting、管理服务、LLDP、SNMP、DHCP 组件、Python 包、平台驱动、厂商 SAI 库、专有 SDK、固件和构建基础设施。这些层中的任何一个漏洞都可能影响交换机或其管理平面，而纠正的责任可能分散在多个项目和供应商之间。

一个公开的 Security Working Group 于 2026 年 6 月获批成立。其范围包括软件物料清单、漏洞可利用性交换信息、依赖项卫生、静态和动态分析、模糊测试、渗透测试、供应链安全、加固以及安全或可测量启动。Nexthop AI 的 Brad House 被确定为主席，Microsoft 的 Qi Luo 为联合主席。

成立文件承认，此前大量的安全工作缺乏足够明确的所有权。并非没有安全：上游项目、维护者和供应商已经处理了漏洞，并且存在报告流程。承认的是，集成系统的责任尚未被组织成一个与平台生产使用相称的可见公共工作流。

一个工作组并不能完成该任务。一个成熟的计划需要当前的 SBOM、来源记录、漏洞分类、签名或可复现构建、补丁策略、私有披露处理、回溯移植和特定于平台的公告。专有的 SAI 库、SDK 和固件使上游视图变得复杂，因为社区可能既无法检查其源代码，也无法控制其发布计划。

管理服务值得特别审查。gNMI、REST、SSH 和 SNMP 暴露了特权控制或信息，需要证书管理、角色设计、审计、秘密处理和网络隔离。容器改善了打包，但当它们共享主机资源并需要提升能力时，并不会自动创建强大的安全边界。编排或数据库路径中的一次入侵可能影响许多转发对象。

商业供应商发布自己的公告，因为他们的产品包含不同的组合和支持策略。Dell Enterprise SONiC 中的一个漏洞不应自动推广到每个社区映像，同时运维人员不能假设上游项目页面涵盖了其交换机中的每个专有组件。

Security Working Group 已成为项目成熟度最清晰的考验之一。SONiC 已经表明，开放协作可以集成路由、数据库和硬件抽象。它现在必须表明，同样的制度模型可以在一个并非所有最敏感层都是开放的供应链中分配所有权。

开源转移了支持成本，而非消除它们

社区 SONiC 提供源代码、架构、发布、工作组和共享的测试框架。它并不提供通用的生产级服务等级协议。使用社区项目的运维人员必须仍然为硬件认证、映像组装、升级、安全回溯移植、事件响应以及与 ASIC 或平台供应商的关系分配责任。

超大规模运营商可能接受这种负担，因为对堆栈的控制正是他们追求解耦的原因。他们可以维护 Linux、路由、发布工程和硬件团队，运行认证实验室，并直接与芯片供应商谈判。他们的运营模式将软件独立性转化为巨大的内部工程投入。

许多企业和服务提供商需要一个供应商来承担更多的集成风险。Dell 提供具有合格硬件和商业支持的 Enterprise SONiC。Nokia 在选定平台上提供社区 SONiC 映像和支持，而其他交换机供应商、原始设计制造商和集成商则打包他们自己的组合。这些产品可以建立更清晰的升级路径，但它们在补丁、管理功能、硬件覆盖范围和发布时序上可能存在差异。

商业层是出售全生命周期工作和责任的地方。云运营商获得了采购灵活性；交换机和芯片供应商销售系统；分销商销售订阅和支持；集成商销售工程服务；客户可以减少对一家垂直集成供应商的依赖。定向基金本身没有股权股东、公司估值或公开的独立利润。

参与者在共享层上合作，同时在其上下竞争。Arista、Cisco、Dell、Nokia 和 NVIDIA 可以在销售不同产品的同时为同一个项目做出贡献。云运营商可以支持通用接口，同时与硬件供应商积极谈判，当 SONiC 使其芯片更易于集成，同时保持特性和性能差异化时，ASIC 公司也能从中受益。

只有当参与者接受共同行为时，通用层才能减少重复工作。私有的 SAI 实现、下游补丁和供应商扩展可能削弱可移植性，即使产品共享 SONiC 的名称。公司有动力为维持生态系统做出足够贡献，同时保留足够的差异性以销售自己的产品。

会员费使资金参与变得可见，但工程投入很可能是更大的货币。一笔 100,000 美元的 Premier 费用对基金来说是重要的，但与维护一个专业团队或硬件实验室的成本相比却很小。那些提供了多年实现和测试的组织，即使章程正式将支付与技术接受分开，也能通过运营现实影响结果。

缺乏公开的基金预算限制了对资金优先项如何选择的分析。更高的财务透明度将帮助运维人员将声明中的优先项与在安全、测试、文档、持续集成和合规方面的支出进行比较。Security Working Group 的创建表明，即使生态系统包含大型且资源充足的成员，一个关键领域也可能仍然缺乏足够的所有权。

买方应将“基于 SONiC”视为尽职调查的开始，而非结束。他们需要知道分支、SAI 版本、SDK、固件、映像所有者、合格的功能、安全策略和支持路径。他们还需要知道该映像是否可以复现，以及当社区、供应商和硬件的发布计划出现分歧时会发生什么。

只有当这些边界保持可见时，解耦才能创造选择。否则，运维人员可能会用一种供应商锁定换取对自定义映像、一个集成商或其他地方无法维护的 SDK 构建的依赖。开放架构使替代方案成为可能；支持合同和内部工程则决定了它们是否仍然可用。

部署规模可观，但可比较性仍然薄弱

Linux Foundation 在 2022 年的过渡公告中称，SONiC 已在数百万个端口和超过 100 款交换机型号上运行。2024 年 4 月，该基金会报告了来自 520 多个组织的 4,250 名贡献者，以及 20% 的年度社区增长。一份治理简介指出，阿里巴巴运营着近 100,000 台基于 SONiC 的交换机、网关和路由器。

每个数字都表明了规模，但没有一个是独立审计的统计。贡献者总数可能包括历史参与者而非活跃维护者，一个支持的型号可能几乎没有生产量，而基金会成员资格并不证明部署。公开声明描述了不同的单位，无法合并为一个可靠的市场份额。

具名案例提供了更确凿的使用证据。Microsoft 在 Azure 中开发并运营 SONiC。阿里巴巴、eBay 和 EPFL 支持了 Linux Foundation 的过渡并描述了其使用情况。Orange 报告了 2024 年约 90 台交换机的初始生产部署及扩展意图，而基金会材料后来强调了 SAKURAONE、Tokyo-1、乐天和印度支付部署。Dell 和 Nokia 提供与选定硬件绑定的受支持产品。

现有证据足以拒绝将 SONiC 描述为实验性实验室项目的说法。它拥有生产起源、活跃的仓库、多家芯片和硬件合作伙伴、商业发行版以及具名的运营商部署。仍然缺乏的是对活跃系统、受支持的功能集以及跨平台的可比行为的持续衡量。

随着 SONiC 扩展到企业网络和 AI 网络架构，这一局限性变得更加重要。总端口数提供了类别信心，而平台级证据则决定了特定的部署是否可支持。运维人员需要知道版本、ASIC、映像、功能矩阵、升级记录、事故历史和可归责的供应商。

SONiC 介于定制的超大规模软件和垂直集成的商业网络产品之间。Arista EOS、Cisco NX-OS、Junos 和 Nokia SR Linux 提供了成熟的系统，具有单一受支持的产品关系。NVIDIA Cumulus Linux 提供了另一种基于 Linux 的商业方法。Dell Enterprise SONiC 和受支持的 Nokia 产品将 SONiC 基础商业化，而 DENT、FBOSS、Open Network Linux、Stratum 和 Linux switchdev 则代表了相邻的开放或由运营商开发的架构。

SONiC 的优势在于围绕一个 Linux、容器、Redis、SWSS 和 SAI 模型的共享生态系统规模。运维人员可以检查和修改公共代码，从多个硬件路径中进行选择，并在供应商之间重用他们的部分自动化。其劣势在于这种自由所产生的集成矩阵。性能和支持取决于各层重新集成的成功程度。

AI 网络增加了赌注，因为买方在迅速要求新功能的同时，正在购买大量的交换机。一个通用的操作系统可以减少跨系统和芯片供应商的重复集成。同样的紧迫性可能鼓励那些解决单个部署问题的扩展，同时削弱可移植性。SONiC 的市场地位将取决于其接口是否能跟上步伐，而不会成为基于不兼容实现的名义抽象。

边界可见；责任仍有待证明

SONiC 通过将一家云运营商的内部架构转变为共享软件平台，改变了网络交换。Linux、容器和 Redis 创建了一个通用的操作平面。SWSS 将应用程序意图与硬件操作分离开来，SAI 为多个 ASIC 系列提供了公共对象模型。Linux Foundation 的治理提供了一个更为中立的架构，竞争性公司可以通过它资助和开发该软件。

该项目并未使交换机可互换。它不认证所有列出的平台，不移除专有 SDK，也不提供统一的支持体验。社区版本可能包含 Alpha 功能，而共享的 SAI 版本可能隐藏了不同的容量、错误行为和重启特性。安全协调无法控制上游项目既不拥有也无法看到的组件。

这些局限揭示了该项目的真正贡献。在解耦之前，硬件-软件边界大部分位于一家供应商内部。SONiC 使更多的边界变得明确和可竞争，使运维人员能够识别哪些功能是通用的，哪些是平台特定的，以及哪一方已承担了对最终系统的责任。

下一个阶段将考验该边界能否在平台扩展时保持连贯。AI 横向扩展网络架构要求快速收敛和高频遥测。扩展以太网更接近加速器系统，多 ASIC 机箱增加了状态复杂性，企业端工作扩大了用户基础，而安全治理必须跨越一个庞大的混合来源供应链。

SONiC 已将交换机操作系统中一个庞大而有价值的部分与某一家供应商的硬件堆栈分离开来。它并未将转发与硅片分离开来，也没有任何软件架构能做到这一点。互操作性仍然取决于 SAI 实现、SDK、驱动程序、固件、光学器件、认证和支持。

因此，可观察的测试并非有多少产品带有 SONiC 名称。而是不同的平台能否展示可比的行为，安全与维护所有权的归属能否在公司变化中存续，以及运维人员能否在受支持的系统之间迁移，而无需围绕另一个未记录在案的依赖关系重建运营模型。

SONiC 与交换机软硬件分离的未竟之路