解耦路由架构：SONiC与VPP的融合之道（第一部分）

本文探讨了在网络架构解耦趋势下，如何将SONiC控制平面与VPP数据平面集成，以在标准x86硬件上构建高性能软件定义路由器。文章详细分析了二者的架构特点、协同工作流程，以及这种融合如何打破厂商锁定，实现敏捷、经济的网络基础设施。

网络行业正在经历一场根本性的架构变革，其驱动力来自云规模数据中心的无情需求和软件定义基础设施的兴起。这一演进的核心是解耦原则：将曾经紧密集成在专有、单体系统中的组件进行系统性拆分。

这一运动始于网络硬件与网络操作系统（NOS）的分离，这一范式转变由超大规模云服务商倡导，旨在摆脱供应商锁定并加速创新。在这篇博文中，我们将探讨解耦网络如何成形，当SONiC控制平面与VPP数据平面相遇时会发生什么。您将看到它们的集成如何创建一个完全软件定义的路由器——一个能在标准x86硬件上提供ASIC级性能，同时保持基于Linux系统的开放性和灵活性。

如今的解耦已延伸至软件栈，将控制平面与数据平面分离。这种解耦实现了模块化设计、独立的组件选择以及更高效的性能和成本管理。

云计算开放网络软件（SONiC）与矢量数据包处理（VPP）框架的集成代表了这种解耦模型的巅峰。SONiC最初由微软开发，现已成为Linux基金会下一个蓬勃发展的开源项目，确立了其作为解耦NOS事实标准的地位，提供了一套丰富的、在全球最大数据中心经过实战检验的L3路由功能。其核心设计理念是抽象底层交换硬件，允许一个单一、一致的软件栈运行在不同供应商的多种ASIC上。这解放了运营商对专有系统的束缚，并培育了一个竞争、创新的硬件生态系统。

与SONiC控制平面能力相辅相成的是VPP，一个由思科开发、现已成为Linux基金会Fast Data Project（FD.io）一部分的高性能用户空间数据平面。VPP的唯一重点是 在商用现货（COTS）处理器上提供非凡的数据包处理吞吐量。通过采用矢量处理和绕过传统内核网络栈等技术，VPP实现了过去被认为是ASIC和FPGA等专用昂贵硬件专属的性能水平。

这两个强大的开源项目的融合创造了一种新型网络设备：一个完全软件定义的路由器，它结合了SONiC成熟、功能丰富的控制平面和VPP极速的转发性能。这种架构直接应对了业界对一个同时具备可编程性、开放性且无需依赖专用硬件就能实现线速性能的网络平台的迫切需求。

其经济影响是深远的。通过用运行在标准x86服务器上的软件栈替换垂直集成、供应商锁定的路由器，组织可以从根本上改变其采购和运营模式。这种转变将网络基础设施从资本支出（CAPEX）重型的模式（以对专有硬件的大量前期投资为特征）转变为更敏捷、可扩展的运营支出（OPEX）模式。利用COTS硬件的能力极大地降低了总体拥有成本（TCO），并打破了供应商锁定的循环，使高性能网络民主化，并实现了更动态、更具成本效益的基础设施战略。

解构组件：双雄记

要充分理解SONiC-VPP集成的协同效应，首先必须了解每个组件独特的架构理念和能力。虽然它们共同构成了一个连贯的系统，但其内部设计针对完全不同却又互补的目的进行了优化。SONiC为管理层面的控制、抽象和可扩展性而设计，而VPP则是专为原始、纯粹的数据包处理速度而构建。

SONiC：云规模控制平面

SONiC是一个基于Debian Linux构建的完整的开源NOS。其架构是现代软件设计的典范，摒弃了传统网络操作系统的单体结构，采用了模块化、容器化、基于微服务的方法。这种设计提供了卓越的开发敏捷性和可维护性。

关键网络功能，例如：

  • 边界网关协议（BGP）路由栈
  • 链路层发现协议（LLDP）
  • 平台监控（PMON）

各自在独立的Docker容器中运行。这种模块化允许在不影响整个系统的情况下更新、重启或替换单个组件，这是在大型环境中保持高可用性的关键特性。

这种分布式架构的中枢神经系统是一个内存中的Redis数据库引擎，它作为交换机状态的唯一真实来源。SONiC的容器不通过直接的进程间通信或僵化的API进行通信，而是通过发布和订阅Redis数据库中的各种表来异步交互。这种松耦合的通信模型是SONiC灵活性的基础。关键数据库包括：

  • CONFIG_DB：存储交换机的持久化、预期配置。
  • APPL_DB：网络状态的高层次、以应用为中心的表征，例如路由和邻居。
  • STATE_DB：保存各个组件的运行状态。
  • ASIC_DB：转发平面期望状态的硬件无关表征。

SONiC硬件独立性的基石，也是使VPP集成成为可能的关键特性，是交换机抽象接口（SAI）。SAI是一个标准化的C API，定义了一种供应商无关的方式，供SONiC软件控制底层转发元件。一个专用的容器 syncd 负责监控ASIC_DB。当检测到变化时，它调用相应的SAI API来编程硬件。每个硬件供应商提供一个 libsai.so 库来实现此API，将标准化调用转换为其ASIC SDK所需的特定命令。这种优雅的抽象使得整个SONiC控制平面可以完全不了解其运行的具体芯片。

VPP：用户空间数据平面加速器

SONiC管理网络的高级状态，而VPP则专注于尽可能快地移动数据包。作为FD.io项目的核心组件，VPP是一个可扩展的框架，完全在软件中提供路由器或交换机的功能。其卓越的性能源于几个关键的架构原则。

矢量处理 第一个也是最重要的原则是矢量处理。与传统的标量处理（CPU一次处理一个数据包穿过整个转发流水线）不同，VPP以批次或“矢量”的形式处理数据包。一个矢量通常包含多达256个数据包。整个矢量先通过流水线的第一阶段处理，然后是第二阶段，依此类推。这种方法对CPU效率有深远影响。矢量中的第一个数据包有效地“预热”了CPU的指令缓存（i-cache），加载了特定任务所需的指令。然后矢量中后续的数据包就可以使用这些缓存的指令进行处理，从而显著减少了从主存进行的昂贵取指次数，并最大化现代超标量CPU架构的优势。

用户空间导向与内核旁路 第二个原则是用户空间操作和内核旁路。Linux内核网络栈虽然强大且灵活，但会引入系统调用、内核与用户空间之间的上下文切换以及中断处理带来的性能开销。VPP完全避免了这一点，它作为一个用户空间进程运行。它通常利用数据平面开发套件（DPDK）来获得对网络接口卡硬件的直接、独占访问。使用轮询模式驱动程序（PMD），VPP持续轮询NIC的接收队列以获取新数据包，消除了与内核中断相关的延迟和开销。这种直接的硬件访问是其高吞吐量、低延迟性能特征的关键组成部分。

数据包处理图 最后，VPP的功能被组织成一个数据包处理图。每个特性或操作（例如L2 MAC查找、IPv4路由查找或访问控制列表检查）都被实现为有向图中的一个“节点”。数据包在被处理时从一个节点流向另一个节点。这种模块化架构使得VPP具有高度可扩展性。新的网络功能可以作为插件添加，这些插件引入新的图节点或重新布线现有图，而无需更改核心VPP引擎。

SAI的设计堪称神来之笔，其初衷是抽象不同硬件ASIC之间的差异。然而，其真正的力量在此得以体现。这种抽象定义得如此之好，以至于它可以用来代表的不仅仅是一块物理硅片，还可以是一个软件进程。SONiC控制平面不知道也不关心SAI API另一端的实体是博通Tomahawk芯片还是运行在x86 CPU上的VPP实例。它只是使用标准化的SAI语言进行通信。这证明SAI不仅成功地抽象了数据平面的实现细节，还抽象了其物理性本身，从而可以极其优雅地用纯软件转发器来替代。

特性 SONiC VPP
主要功能 控制平面 & 管理平面 数据平面
架构模型 容器化微服务 数据包处理图
关键抽象 交换机抽象接口（SAI） 图节点 & 插件
运行环境 内核/用户空间混合（基于Linux） 纯用户空间（内核旁路）
核心性能机制 通过Redis进行分布式状态管理 矢量处理 & CPU缓存优化
主要配置方式 声明式（config_db.json, Redis） 命令式（startup.conf, 二进制API）

创建高性能软件路由器

SONiC与VPP的集成是一个复杂的过程，它将两个独立的系统转变为一个单一的、连贯的软件路由器。该架构的关键在于SONiC的解耦状态管理和一个巧妙的转换层，该层连接了控制平面的抽象世界和数据平面的具体转发逻辑。追踪单个路由更新的生命周期揭示了这种设计的优雅之处。

端到端控制平面流程 当控制平面学习到一条新路由时，过程开始。在典型的L3场景中，这通过BGP发生。

  1. 路由接收：一个eBGP对等体向SONiC路由器发送路由更新。该更新由 bgpd 进程接收，该进程在BGP容器内运行。SONiC利用成熟的FRRouting（FRR）套件处理其路由协议，因此 bgpd 是FRR的BGP守护进程。
  2. RIB更新：bgpd 处理更新，并将新的路由信息传递给 zebra，这是FRR的核心组件，充当路由信息库管理器。
  3. 内核与FPM移交：zebra 执行两个关键操作。首先，它通过Netlink消息将路由注入到主机Linux内核的转发表中。其次，它使用转发平面管理器（FPM）接口将相同的路由信息发送给 fpmsyncd 进程，FPM是一种设计用于将路由更新从RIB管理器推送到转发平面代理的协议。
  4. 发布到Redis：fpmsyncd 进程充当传统路由世界与SONiC数据库中心架构之间的第一座桥梁。它从 zebra 接收路由，并将其写入Redis数据库的 APPL_DB 表中。至此，路由已成功进入SONiC生态系统。
  5. 编排与转换：编排代理（orchagent）是交换机状态服务（SWSS）容器中的一个关键进程，它持续订阅 APPL_DB 的变化。当它看到新的路由条目时，会执行关键的转换。它将高层次的应用意图（“通过下一跳Y路由到前缀X”）转换为硬件无关的表征，并将此新状态写入Redis中的 ASIC_DB 表。
  6. 同步到数据平面：SONiC控制平面的最后一步由 syncd 容器处理。该进程订阅 ASIC_DB。当它检测到 orchagent 创建的新路由条目时，它知道必须将此状态编程到底层转发平面。

整个流程之所以成为可能，是因为采用了Redis作为中心化、异步消息总线的架构决策。在传统的单体NOS中，BGP守护进程可能会直接、紧密地调用转发平面驱动程序函数。这会形成脆弱的依赖关系。相比之下，SONiC的发布/订阅模式确保了每个组件完全解耦。BGP容器的唯一职责是将路由发布到 APPL_DB；它不知道谁会消费这些信息。这允许最终消费者——数据平面——在零改动任何上游控制平面组件的情况下被替换。这种解耦架构是VPP能够如此干净地替代硬件ASIC的原因，并暗示未来可以集成其他数据平面——只需创建一个新的SAI实现即可。

集成基础：libsaivpp.so 从 syncd 到数据平面的移交是SONiC-VPP具体集成发生的地方。

在标准SONiC部署在物理交换机上的情况下，syncd 容器会加载一个供应商提供的共享库（例如 libsai_broadcom.so）。当 syncd 从 ASIC_DB 读取时，它调用适当的标准化SAI API函数（例如 sai_api_route->create_route_entry()），然后供应商库将其转换为专有的SDK调用，以编程物理ASIC。

在SONiC-VPP架构中，这个供应商库被一个专门构建的共享库取代：libsaivpp.so。这个库是整个系统的关键基础。它实现了完整的SAI API，向 syncd 呈现与任何硬件SAI库完全相同的接口。

然而，其内部逻辑完全不同。当 syncd 调用像 create_route_entry() 这样的函数时，libsaivpp.so 并不与硬件驱动程序通信。相反，它将SAI对象及其属性转换为VPP进程理解的二进制API消息。然后，它将该消息发送给VPP引擎，指示其将相应的条目添加到其软件转发信息库（FIB）中。这完成了一个“从决策到执行”的闭环，将SONiC的抽象控制平面与VPP的高性能软件数据平面连接起来。

组件（容器） 关键进程 在集成中的角色
BGP 容器 bgpd 使用FRRouting栈接收来自外部对等体的BGP更新。
SWSS 容器 zebra, fpmsyncd zebra 管理RIB。fpmsyncd 从 zebra 接收路由更新并将其发布到Redis的 APPL_DB。
数据库容器 redis-server 作为所有SONiC组件的中心化、异步消息总线。承载 APPL_DB 和 ASIC_DB。
SWSS 容器 orchagent 订阅 APPL_DB，将应用意图转换为硬件无关格式，并发布到 ASIC_DB。
Syncd 容器 syncd 订阅 ASIC_DB，并调用适当的SAI API函数来编程数据平面。
VPP 平台 libsaivpp.so VPP的SAI实现。由 syncd 加载，它将SAI API调用转换为VPP二进制API消息。
VPP 进程 vpp 用户空间数据平面。接收来自 libsaivpp.so 的API消息，并相应地编程其内部转发表。

在本系列的第二部分，我们将从架构转向实践——在容器化实验室中构建和测试一个完整的SONiC-VPP软件路由器。我们将配置BGP路由，验证控制平面到数据平面的同步，并分析展示这种解耦设计实际潜力的性能基准测试。

来源

comments powered by Disqus
© 2020 - 2026 qife
使用 Hugo 构建
主题 Stack 由 Jimmy 设计
本站总访问量次 本站访客数人次