SONiC Docker 模块分析

本篇继续分析 SONiC 构建 log

Q:SONiC 构建中用到的 rootfs A:SONiC-VS 构建时，会创建./fsroot-vs 路径，其他的镜像也会使用相应的后缀，fsroot 即最终生成镜像的rootfs

Q: SONiC 是否使用了修改版或者小众的 Docker 实现 (如 Podman) A: 并没有，其在构建脚本中使用的是

shell

chroot ./fsroot-vs curl -o /tmp/docker.asc -fsSL https://download.docker.com/linux/debian/gpg
add-apt-repository 'deb [arch=amd64] https://download.docker.com/linux/debian bullseye stable'
apt-get update
apt-get -y install docker-ce=5:20.10.14~3-0~debian-bullseye docker-ce-cli=5:20.10.14~3-0~debian-bullseye containerd.io=1.5.11-1

可以看到是来自 docker. com 的 docker-ce

以下是他们的作用

REPOSITORY                    TAG                       IMAGE ID       SIZE
docker-orchagent              202305.431112-d297c4fd3   960cc799360e   330MB
docker-fpm-frr                202305.431112-d297c4fd3   2ea1a20c531d   349MB
docker-nat                    202305.431112-d297c4fd3   0f6e45c0d768   321MB
docker-sflow                  202305.431112-d297c4fd3   f1020323191b   319MB
docker-teamd                  202305.431112-d297c4fd3   c0d750b7a82c   318MB
docker-gbsyncd-vs             202305.431112-d297c4fd3   d4452a0753e2   311MB
docker-syncd-vs               202305.431112-d297c4fd3   cc01a2d69795   315MB
docker-eventd                 202305.431112-d297c4fd3   89d300e3e39c   300MB
docker-snmp                   202305.431112-d297c4fd3   8a598e074416   339MB
docker-platform-monitor       202305.431112-d297c4fd3   b6fce4f623d6   422MB
docker-sonic-telemetry        202305.431112-d297c4fd3   c0bfad00bd70   387MB
docker-lldp                   202305.431112-d297c4fd3   e78f50b0ff2f   343MB
docker-database               202305.431112-d297c4fd3   da5ce45d383a   300MB
docker-mux                    202305.431112-d297c4fd3   a54b4cb4200c   349MB
docker-router-advertiser      202305.431112-d297c4fd3   f711ff63dd78   300MB
docker-sonic-mgmt-framework   202305.431112-d297c4fd3   24d1b4b5f569   414MB

在接下来的目录中，不会出现单独的 docker-* 前缀，这系列文章默认所有的独立章节都是 docker 容器

orchagent

它名字的含义，orchagent 是由 Orchestration 和 Agent 拼凑而成的一个词，这也解释了它主要的功能是进行调度和执行任务。以下是一个用例

APPL_DB 中订阅事件，对于 APPL_DB 来说，它是消费者。
同时，根据任务逻辑，它会作为生产者给 ASIC_DB 进行增删改查的操作，这也是它的Task本身。

Orchagent 通过 APPL_DB 访问了 APPL_ DB 中的邻居表，路由表，网络表，转发表，接口表
接下来，它根据 task 逻辑去调用 ASIC_DB 的 public 接口，ASIC_DB 在这里提供了路由查询，修改IP关联引用计数，检查IP是否有效，添加删除临时与永久路由的接口
最后，它调用 SAI 去更新路由信息，即
status = sai_route_api->create_route_entry(&unicast_route_entry, 1, &attr);

名词解释：
SAI（Switch Abstraction Interface）是一个用于网络交换设备的开放式编程接口标准。它的目标是提供一种标准化的方式，允许网络设备供应商、开发者和用户编写通用的网络应用程序，而不需要深入了解底层硬件细节。

SWSS（Switch State Service）：SWSS是一种用于管理交换机状态信息的服务。它主要用于将交换机状态从数据平面（Data Plane）传递到控制平面（Control Plane）。SWSS负责从ASIC_DB和CONFIG_DB等数据库中提取状态信息，并使其可供其他应用程序或服务使用。

APPL_DB（Application Database）：APPL_DB是一个用于存储应用程序配置和状态信息的数据库。这里的应用程序通常指的是网络应用程序或服务，它们需要访问和管理交换机的配置和状态信息。APPL_DB包含与这些应用程序相关的数据。

ASIC_DB（Application-Specific Integrated Circuit Database）：ASIC_DB是一个用于存储硬件特定信息的数据库，通常与交换机上的硬件相关。这包括ASIC（应用特定集成电路）的配置和状态信息，因为ASIC通常用于高性能的数据包处理。

CONFIG_DB（Configuration Database）：CONFIG_DB是一个用于存储交换机配置信息的数据库。这包括网络接口配置、VLAN设置、路由策略、ACL（访问控制列表）规则等。CONFIG_DB中的数据用于配置交换机的行为。

STATE_DB（State Database）：STATE_DB是一个用于存储交换机状态信息的数据库。这包括各种组件的运行状态、连接状态、链路状态等。STATE_DB的数据通常由SWSS服务使用，并在控制平面中用于网络决策和管理。

注：并不是说明它只能从 APPL_DB 中往 ASIC_DB 中写数据，它可以定义任务去访问多个 DB 并执行指定的逻辑熟悉上层开发的同学可能会意识到这是一个触发器+Runner 的实现

fpm-frr

frr 即 FRRouting 是一个开源的网络路由软件套件，它实现了多个路由协议，如 BGP、OSPF、RIP、ISIS 等。FRRouting 旨在提供高性能、可扩展性和可靠性的路由功能，通常用于网络设备、路由器和交换机，以及网络虚拟化和 SDN 环境中

FPM 是 FRR 的转发平面控制器，它是 FRR Zebra 模块中的一部分 Zebra 用于管理 FRR 的路由

fpmsyncd

fpmsyncd 这个机制用于同步 FRR 控制平面的路由，

在202305 以后的 SONiC 版本中，dplane_fpm_nl 被作为默认的 FPM 模块实现而非 Zebra 原生的 fpm 模块

具体可参考上图，通过动态路由学到的路由表项会通过 zebra 传递给 fpmsyncd，其再去修改 APPL_DB

其默认行为如下

需要注意的是，fpmsyncd 不是一个单独的可执行程序，是对 Zebra 到 APPL_DB 中同步行为的一种概括。在该镜像中并不存在名为 fpmsyncd 的程序或服务。

NAT

NAT（Network Address Translation）是一种网络通信技术，通常用于连接私有网络（例如家庭网络或企业内部网络）与公共互联网之间。NAT的主要目标是允许多个设备共享一个或多个公共IP地址，同时保护内部网络的隐私和安全性。

接触过路由和防火墙系统的人对 Nat 应该不会感到陌生，大多数时候，它会和防火墙被放到一起，在 Linux 上面 Nat 功能通常由 iptables 作为前端实现，而在更现代一点的 Linux 上面，nftables 正在逐渐的普及。 docker-nat 模块使用了 iptables 作为与 Kernel 交互的途径，他会动态的将下发的配置转换成 iptables 指令。 SONiC Docker 里面的 NAT 其包含了 NatSyncd 与 NatMgrd 模块，其不能被独立的运行停止和重启。当这个容器被停止时，会进行这些行为：

iptables 中所有的 nat 表和 conntrack 表将会被清空
APP_DB 和 ASIC_DB 中的 NAT/NAPT 表项将会被清空

以下是一个配置案例

在该案例中，用户编写的 config_db. json 文件被插入 CONFIG_DB ，被 natmgrd 感知到， Natmgrd 将自己计算的路由结果写入 APPDB，同时调用 iptables 去添加路由表项给软件转发表。接下来，natorch 模块获取到 APP_DB 里面的结构用于更新 ASIC_DB ， ASIC_DB 中的更新被 syncd 带到 sai+sdk，syncd 也会通知 natorch 模块去更新 COUNTERS_DB 。

同样的，它也可以被 NatOrch 调用

在该案例中，NatOrchAgent 去获取 SAI 中的表项，同时与内核交互。而 NatSync 的则获取到内核表项的更新，去处理 APP_DB, 接下来将结果反馈给 NatOrchAgent 使得其去更新 ASIC_DB

sflow

sFlow (defined in https://sflow.org/sflow_version_5.txt ) is a standard-based sampling technology the meets the key requirements of network traffic monitoring on switches and routers. sFlow uses two types of sampling: Statistical packet-based sampling of switched or routed packet flows to provide visibility into network usage and active routes Time-based sampling of interface counters. The sFlow monitoring system consists of: sFlow Agents that reside in network equipment which gather network traffic and port counters and combines the flow samples and interface counters into sFlow datagrams and forwards them to the sFlow collector at regular intervals over a UDP socket. The datagrams consist of information on, but not limited to, packet header, ingress and egress interfaces, sampling parameters, and interface counters. A single sFlow datagram may contain samples from many flows. sFlow collectors which receive and analyze the sFlow data. sFlow is an industry standard, low cost and scalable technique that enables a single analyzer to provide a network wide view.

简单的来说，sFlow 是一种数据包的抽样技术，可以进行基于时间的端口技术，又或者是指定的包关键字进行统计。

上图是一个基本结构，来自 SONiC 文档在 SONiC 中，Sflow 会通过 SAI driver 转发到内核的 netlink 接口，并上送到 sFlow 容器，sFlow 在拿到报文后会与 Database 进行交互，将计算结果写入 Database 中。 syncd 容器会处理 ASIC_DB 中的配置信息，用来配置 SAI 驱动层控制那些 sFlow 会继续上到 netlink 层。

teamd

首先？它是什么 SONiC 并没有单独的给它在 SONiC/doc at master · sonic-net/SONiC (github.com) 单独的新建一个文件夹去说明它的功能。但仍然能在 SONiC 的架构说明里面找到它的作用

Teamd container: Runs Link Aggregation functionality (LAG) in SONiC devices. "teamd" is a linux-based open-source implementation of LAG protocol. "teamsyncd" process allows the interaction between "teamd" and south-bound subsystems.

teamsyncd works together with teammgrd and multiple teamd processes in teamd docker to handle LAG protocol for SONiC switch. The main functionality of teamsyncd is to monitor multiple teamd instances and check the changes of LAG membership.

这里又引入了更多没有提到的东西，什么是 teammgrd，什么是 teamsyncd？为什么会有多个 teamd 进程，teamd 又实现了什么功能？在思考这些问题之前，不如先弄清楚，team 是什么在 Linux 上面寻找一个应用程序最好的办法永远是看看有没有对应的库，正好，与 teamd 对应的就是 libteam

Team softdev Linux 驱动程序的目的是提供一种机制，将多个 NIC（端口）组合成一个 L2 层的逻辑 NIC（teamdev）。该过程称为“通道绑定”、“以太网绑定”、“通道组合”、“链路聚合”等。这已经通过 bonding 程序在 Linux 内核中实现。 "teammgrd" 的代码可以在 sonic-swss/cfgmgr/teammgrd.cpp at master · sonic-net/sonic-swss (github.com) 中找到，其功能是通过 DB 中存储的配置去管理 teamd 程序 “teamsyncd”的代码可以在 sonic-swss/teamsyncd/teamsyncd.cpp at master · sonic-net/sonic-swss (github.com) 中找到，其功能是注册“RTM_NEWLINK”，“RTM_DELLINK”两个 Handler，并跟踪 teamd 实例，当 teamd 发生改变或接收到消息时，将变化写入 APP_DB 或 STATE_DB

如果只看它功能的话，这样一段介绍就足够了，但接下来的才是最有趣的

需要注意的一点是，Team softdev Linux 驱动程序项目确实尝试提供与绑定驱动程序类似的功能，但是在体系结构上它与绑定驱动程序有很大不同。Team softdev Linux 驱动程序是模块化的、用户空间驱动的、非常精简和高效的，并且它确实比bonding具有一些明显的优势。Teamd 的配置方式与 bonding 的方式有很大不同。请注意，由于控制逻辑发生在用户空间中，因此不会增加性能开销。数据包永远不会离开内核。

在回答为什么它的控制逻辑发生在用户空间，而数据包不会离开内核，或许这是个值得思考的问题，但显然有点离题，让我们继续这场旅途吧。

gbsyncd

这里的 gb 是 gearbox 的简称，gearbox 的原含义是齿轮/变速器。

先过一遍专有名词 SYSFS Linux 内核的虚拟文件系统，用于导出内核对象到用户空间，通常位于 /sys FPGA/CPLD 可编程控制器，CPLD 通常比 FPGA 结构简单，但他们同样是 NPU 网络处理单元 (神经网络处理器也叫 NPU) MDIO 在以太网中的低速串行接口，通常用于 MCU 或者 CPU 去管理 PHY 芯片 SAI 与 PAI，SAI 在前文中已经介绍过了，是在上层提供一套通用的交换机抽象接口，而 PAI 则是（Platform Abstraction Interface），它对应平台层。并通常可以直接与厂商定义或者不寻常的设备交互。

对于 GB_SYNC 而言，更典型的用例是 ORCHAGENT 被更详细的可以参考下 HLD 设计 SONiC/doc/gearbox/gearbox_mdio-HLD.md at master · sonic-net/SONiC (github.com)

https://github.com/sonic-net/SONiC/blob/master/doc/gearbox/gearbox_mdio-HLD.md

Syncd

在前文中，已经部分介绍了 Syncd，

Syncd container: In a nutshell, syncd's container goal is to provide a mechanism to allow the synchronization of the switch's network state with the switch's actual hardware/ASIC. This includes the initialization, the configuration and the collection of the switch's ASIC current status.

与 Gearbox-syncd 不同，syncd-docker 所能管理的东西更多，其由三部分组成 syncd 进程：它会实现一套同步逻辑，并通过硬件厂商提供的 ASIC SDK 为 ASIC 注入状态或提供需要的响应，Syncd 也会订阅 ASIC_DB 去接受 SWSS 的动作，并同时对硬件执行控制和接收逻辑。 SAI API：SAI 在前文介绍过，他是一套将厂商定义的 ASIC/NPU 调用逻辑封装成上层接口的机制 ASIC SDK：这一部分由芯片厂商提供，用于直接的调用硬件提供的功能

eventd

eventd 在 SONiC 文档中对应的功能模块是 event-alarm-framework 图来自 SONiC 文档，但画的并不是很清晰。 Apps 是上层调用，它会将请求发到 zmqproxy 中，zmqproxy 是 ZeroMQ 的代理服务，ZeroMQ 是一套高性能的消息队列系统。 zmqproxy 和 eventdb 同属于 docker-eventd 容器，eventd 在接收到来自消息队列的消息后，根据规则去改写 Database 中的数据（在此图中被表示成 EVENT, EVENT_STATS, ALARM...）接下来数据被被送给 mgmt-framework，通过 mgmt-framework 再去调用 gNMI/REST/KLISH 等更上层的接口。它最主要的功能是用来采集并记录警报或者事件消息去执行调用逻辑，如传感器温度，接口状态等。其可以更具对应的状态去实现改变 LED 灯颜色，发出报警信号等行为。

snmp

SNMP 是广泛应用于 TCP/IP 网络的网络管理标准协议，该协议能够支持网络管理系统，用以监测连接到网络上的设备是否有任何引起管理上关注的情况。SNMP 采用轮询机制，提供最基本的功能集，适合小型、快速、低价格的环境使用，而且 SNMP 以用户数据报协议（UDP）报文为承载，因而受到绝大多数设备的支持，同时保证管理信息在任意两点传送，便于管理员在网络上的任何节点检索信息，进行故障排查。

这个功能资料比较多稍微有点不同的是 SONiC 的 SNMP 实现是混合了 yaml 和 ACL 的配置用于管理，而非传统的 mib 文件但 SONiC 的 SNMP 可以通过 config DB 通过 json 去集成新的节点，具体可参考 SONiC/doc/snmp/snmp-schema-addition.md at master · sonic-net/SONiC (github.com)

platform-monitor

在我构建的版本里面这个容器目录下直接存了个 iSmart (硬盘信息检测工具) 二进制执行文件它的主要功能是收集系统部件的传感器消息，例如风扇，处理器温度，硬盘读写次数，损耗等。通常里面会提供 pcied, psud, syseepromd, thermalctld, xcvrd 等工具用于采集这些消息，而具体的采集逻辑根据厂商定义和SONiC版本不同也会不同。

Eventd 里面也写到了它有些逻辑可能会跟 Eventd 打架，比如控制 LED 灯，platform 里面有专门的 LEDD 去跑 LED 控制，而 Eventd 也要控制 LED

SONiC 的解法是大家都去操作 Redis DB ，功能模块修改 DB 内容，器件执行模块订阅表项目

SNMP 也需要订阅 STATE_DB 去获取硬件状态

sonic-telemetry

已经专门写了一篇文章讲这个了

lldp

SONiC/doc/fpmsyncd/hld_fpmsyncd-NTT.md at master · sonic-net/SONiC (github.com)

说起容器的调度，我们会想到什么？对，K8s 它是一个对我来说陌生又熟悉的存在。我不止一次的进行过 K8s 的部署，deploy yaml，检查节点，用它搭建服务，但其背后的调度机制却对我来说像一个黑盒。

SONiC Docker 模块分析 ​

orchagent ​

fpm-frr ​

fpmsyncd ​

NAT ​

sflow ​

teamd ​

gbsyncd ​

Syncd ​

eventd ​

snmp ​

platform-monitor ​

sonic-telemetry ​

lldp ​