1. 课程导入与 SONiC 架构总览

在数据中心网络里，VXLAN 与多租户早已不是“可选项”，而是云网络、AI 集群、容器平台的基础能力。SONiC（Software for Open Networking in the Cloud）之所以能在这类场景中被广泛采用，核心原因在于它把传统交换机“黑盒式”的封闭系统，拆解成了一套可组合、可替换、可编程的模块化架构。理解这套架构，是后续学习 VXLAN 隧道建立、租户隔离、EVPN 控制面以及多租户转发路径的前提。

本课程围绕 SONiC 的 VXLAN 与多租户网络工程展开，共 30 章。第 1 章不急于进入配置命令，而是先把 SONiC 的整体骨架讲清楚：它由哪些容器组成、SAI 抽象层处在什么位置、配置数据库如何驱动整个系统，以及 VXLAN 与多租户能力在这套架构中究竟落在哪一层。只有先建立这张“全局地图”，后面看到 config vxlan、redis-cli、show vxlan tunnel 这些操作时，才能知道它们背后改动了什么、影响了谁。

一、SONiC 的模块化设计：容器即功能单元

SONiC 运行在 Linux 之上，采用容器化方式把网络功能拆成多个独立进程。每个容器负责一类职责，彼此通过数据库和消息机制通信，而不是把所有逻辑塞进一个单体程序。常见的核心容器包括：

• swss：Switch State Service，负责监听配置数据库变化，把配置翻译成 SAI 调用，是控制面与转发面之间的“执行中枢”。
• syncd：与 SAI 直接交互，负责把 SAI 调用下发到 ASIC，并回收硬件状态。
• bgp：运行 FRR，负责 BGP/EVPN 路由协议，是 VXLAN 控制面（EVPN）的关键组件。
• teamd：负责链路聚合（LAG）。
• database：承载 Redis 实例，提供 CONFIG_DB、APPL_DB、STATE_DB 等数据库。
• pmon：负责光模块、温度、风扇等平台监控。

这种设计的价值在于“可替换性”：BGP 可以用 FRR，也可以用其他实现；SAI 可以对接不同厂商 ASIC；上层管理接口可以走 CLI、REST、gNMI。对 VXLAN 多租户而言，这意味着隧道配置、EVPN 路由、租户 VRF 可以分别由不同容器协作完成，而不是绑定在某一家厂商的私有系统里。

二、SAI 抽象层：屏蔽 ASIC 差异的关键

SAI（Switch Abstraction Interface）是 SONiC 架构中最关键的一层。它定义了一组统一的 C 语言 API，把“创建 VXLAN 隧道”“添加 VRF”“下发下一跳”“写入 ACL 表”等操作抽象成标准对象。不同厂商的 ASIC 只需提供各自的 SAI 实现（通常以 libsai.so 形式存在），SONiC 上层无需关心底层芯片是 Broadcom、Marvell 还是其他平台。

从数据流角度看，一次 VXLAN 隧道创建大致经历：用户通过 CLI 写入 CONFIG_DB → swss 监听到变化 → 调用 SAI API → syncd 将 SAI 调用转为 ASIC 编程 → 硬件开始封装/解封装 VXLAN 报文。SAI 在这里既是“翻译层”，也是“稳定边界”：上层逻辑不随芯片变化，下层驱动不随业务变化。

三、配置数据库：SONiC 的“单一事实来源”

SONiC 使用 Redis 作为配置与状态存储，核心数据库包括：

理解这张表非常重要：在 SONiC 中，“配置”和“状态”是分离的。你写进 CONFIG_DB 的 VXLAN 配置，并不等于硬件已经生效；必须观察 APPL_DB、ASIC_DB 和 STATE_DB，才能确认整条链路是否走通。这也是 SONiC 排障与传统的“一条命令看结果”最大的不同。

四、VXLAN 与多租户在 SONiC 中的整体定位

VXLAN 在 SONiC 中属于“数据面封装能力”，由 SAI 提供隧道对象支持，由 swss/syncd 下发；而多租户则更多体现在“隔离与路由域”上，通常通过 VRF、VLAN、VNI 映射以及 EVPN 路由区分来实现。两者结合后，典型结构是：每个租户拥有独立 VRF 和 VNI 段，Leaf 之间通过 EVPN 交换 MAC/IP 可达信息，VXLAN 隧道负责跨 Leaf 的报文封装，最终在目标 Leaf 解封装并送入对应租户 VRF。

下面这张图把 SONiC 的核心组件、数据库与 VXLAN/多租户能力的位置关系集中呈现出来，建议结合前文对照理解。

从图中可以看到，VXLAN 与多租户并不是某一个容器单独完成的功能，而是贯穿管理面、控制面、数据库、SAI 和 ASIC 的纵向能力。管理面写入配置，bgp 容器负责 EVPN 路由，swss 负责翻译，syncd 负责下发，SAI 负责统一接口，ASIC 负责实际封装与转发。任何一层断裂，都会表现为“隧道不通”或“租户间路由不可达”。

五、一个可观察的入门示例

为了把架构落到可操作层面，下面给出一个最小化的观察示例。假设我们在一台 SONiC 交换机上查看 VXLAN 相关配置与状态，可以按以下顺序执行：

# 查看 CONFIG_DB 中已配置的 VXLAN 隧道
redis-cli -n 4 keys "VXLAN_TUNNEL|*"

# 查看 APPL_DB 中隧道是否被 swss 处理
redis-cli -n 0 keys "VXLAN_TUNNEL_TABLE|*"

# 查看 STATE_DB 中隧道运行状态
redis-cli -n 6 keys "VXLAN_TUNNEL_TABLE|*"

# 查看 ASIC_DB 中隧道对象是否创建
redis-cli -n 1 keys "ASIC_STATE:SAI_OBJECT_TYPE_TUNNEL:*"

# 使用 CLI 查看隧道摘要
show vxlan tunnel

这段操作的价值不在于命令本身，而在于它对应了架构图中的纵向链路：-n 4 是 CONFIG_DB，-n 0 是 APPL_DB，-n 6 是 STATE_DB，-n 1 是 ASIC_DB。如果 CONFIG_DB 有配置但 APPL_DB 为空，说明 swss 没有正确处理；如果 APPL_DB 有但 ASIC_DB 为空，说明 SAI 或 syncd 下发失败；如果 ASIC_DB 有对象但 show vxlan tunnel 显示 down，则要检查底层链路或对端配置。这种“按层排查”的方法，正是理解 SONiC 架构后自然获得的工程能力。