SONiC系统架构

SONiC系统由两部分组成：
1.彼此交互的模块
2.用于交互的基础设施（集中式，可扩展）

其中用于交互的基础设施主要是一个非关系型数据库Redis引擎：
1.提供了一个无视语言的接口
2.是一种数据保持，复制和多进程交互的手段

每个模块只订阅自己关注的数据

每个模块都存在于各自的Docker容器里形成独立的组件，每个组件都与平台细节完全解耦

SONiC由一下几个容器组成：

• Dhcp-relay
• Pmon
• Snmp
• Lldp
• Bgp
• Teamd
• Database
• Swss
• Syncd

下图描绘出了每个模块中包含的功能，以及它们之间的交互。
不是所有的功能都与Redis服务器交互，其中一些功能与外部实体（netlink，文件系统等）产生交互。
图中蓝色箭头表示与Redis数据库的交互，黑色交投表示与外部实体的交互

不是所有的功能都位于某个容器中，比如CLI和sonic配置模块，就是位于Linux主机上的

SONiC子系统描述

Teamd container:

Pmon container:

Snmp container:

Dhcp-relay container:

Lldp container:

Bgp container:

可以运行Quagga或FRR的路由协议栈
此容器可以进一步分为以下几个部分：

• bgpd :
  获取路由状态，并将其通过zebra和fpmsyncd接口下发到转发面
• zebra :
  是一个路由管理器。它提供路由表更新，接口查询，不同协议间的路由分发
  同时，它会将计算好的FIB下发到内核（通过netlink）和南向转发进程组件（通过Forwarding-Plane-Manager interface也就是FPM）
• fpmsyncd:
  一个小小的守护进程。主要负责将从zebra处收集到的FIB状态注入到Redis引擎中的APPL_DB表

Database container:

Swss container:

SWitch State Service是一组工具套装，它能有效促使SONiC各个模块之间的交流
它提供了一个机制去促成多方的交流和仲裁

同时，SWSS的几个进程会负责与SONiC应用层的北向交互
其中有三个进程是运行在其他容器里的，包括Fpmsyncd，Teamsyncd和Lldp_syncd
但是无论它们运行在哪个容器里，都有着一个共同的目标：
【提供了 能够使 SONiC应用 和 SONiC的集中式消息基础设施（Redis引擎） 保持连接的途径】
【provide the means to allow connectivity between SONiC applications and SONiC’s centralized message infrastructure (redis-engine).】
这些进程 约定俗成地 命名为 *syncd。下面介绍各种syncd:

• Portsyncd
  监听与端口相关的（port-related）netlink事件。在启动期间，portsyncd会通过解析系统的硬件配置文件 获取物理端口的信息。
  最终portsyncd将所有收集到的状态信息推送到APPL_DB中。像 端口速率，lanes和MTU将通过此途径传送。
  portsyncd还会将状态注入到STATE_DB。
• Intfsyncd
  监听与接口相关的（interface-related）netlink事件并将收集到的状态信息推送到APPL_DB。像 新建/修改 的接口IP地址 这样的参数将通过此进程得到处理。
• Neighsyncd
  监听与邻居关系相关的（neighbor-related）netlink事件，这种事件通常是 新发现的邻居产生的ARP处理进程 触发的。
  像 MAC地址和邻居的地址族信息都是通过这个进程处理的。出于 数据平面的L2重写的目的，最终这个状态信息将用于构建邻接表。再次强调，这个状态信息最终会被传送到APPL_DB中。
• Teamsyncd
  在teamd容器中运行，其获取到的状态信息将被传送到APPL_DB中。
• Fpmsyncd
  在bgpd容器中运行，其获取到的状态信息将被传送到APPL_DB中。
• Lldp_syncd
  在lldp容器中运行。

以上进程都是发布者，根据 发布者/订阅者 模型，SWSS还需要订阅者的角色来完成对接收到的消息的消耗和转移，下面的几个进程就是这样的角色：

• Orchagent
  这是SWSS子系统最重要的组件。Orchagent包含一个逻辑处理功能，用来将所有 从其他*syncd进程注入的 状态信息提取出来，然后处理并转发这些信息，最终将这些信息推送至Orchagent的南向接口。这个南向接口就是redis引擎中的ASIC_DB，所以我们可以发现，Orchagent既是订阅者，又是生产者，因为它既从APPL_DB获取数据，也向ASIC_DB提供数据。
• IntfMgrd
  处理来自APPL_DB，CONFIG_DB和STATE_DB的状态信息，然后在Linux内核中配置接口信息。只有在被检测的任何数据库中没有发生冲突和不一致的数据时，这一步骤才会执行。
• VlanMgrd
  处理来自APPL_DB，CONFIG_DB和STATE_DB的状态信息，然后在Linux内核中配置vlan接口信息。正如IntfMgrd，只有在没有冲突数据存在的情况下才会执行这一步骤。

Syncd container:

Syncd 的主要目标就是提供一种 能让交换机的网络状态信息 和 交换机硬件/ASIC上的实际状态 保持同步的一种机制。这种机制主要包括初始化，配置以及收集交换机ASIC当前的状态。

它包含了几个主要的逻辑模块：

• Syncd:
  Syncd执行上述提到的同步机制。在编译时，syncd与 硬件供应商提供的ASIC SDK连接，并且把状态信息注入到ASIC，这个效果是通过引用 被提供的接口 实现的。Syncd订阅ASIC_DB的信息，从SWSS获取信息，与此同时 将自身注册为一个生产者，将从硬件获得的状态信息发布出去。
• SAI API:
  SAI(Switch Abstraction Interface)定义了一个API，这个API提供了与厂商无关的方式去控制转发单元，例如交换ASIC，它是一个统一化的NPU或者一个软交换。
• ASIC SDK:
  硬件供应商期望能够提供一种SAI友好型的能够驱动他们的ASIC的SDK实现方法。这种实现方式通常通过动态链接库（dynamic-linked-library）的形式实现，这种机制调取驱动程序（在这里是指syncd）来执行它的驱动。

CLI / sonic-cfggen:

SONiC中负责提供命令行和系统配置的功能模块。
CLI组件重度依赖Python的Click库，该库为用户提供了一种灵活的客制化的方式去构建一个命令行工具。

Sonic-cfggen组件被SONIC的CLI调用，来完成 对配置修改 和 任何与SONiC模块交互的配置相关的动作。

SONiC子系统的交互

路由状态交互

在这一部分，我们来看一下在收到一个eBGP路由更新时SONiC的处理流程。我们假设会话已经建立起来了，而且学到的新路由以它的直连接口作为下一跳。

下图展示处理流程，有些不必要的步骤已经被省略：

(0) 在BGP容器初始化时，zebra通过一个常规的TCP套接字连接到fpmsyncd。在稳定状态下，zebra所持有的路由表，Linux内核，APPL_DB和ASIC_DB需要保持高度一致。

(1) 一个新的TCP数据包到达位于内核空间的BGP位。内核的网络栈最终将携带的载荷递送至bgpd进程。

(2) Bgpd解析这个新的数据包，处理这个bgp更新，并且通知zebra这个新前缀的存在和与该协议相关的下一跳。

(3) 根据zebra的可达性判断，zebra生成一个route-netlink状态信息并将其注入到内核。

(4) Zebra 利用 FPM接口 发送这个netlink-route消息至fpmsyncd.

(5) Fpmsyncd处理该netlink消息然后推送该消息至APPL_DB.

(6) 作为订阅APPL_DB的订阅者，orchagentd将接收之前被推送至APPL_DB的信息内容。

(7) 完成对接收信息的处理后，orchagentd将引用sairedis APIs完成对ASIC_DB的路由信息注入。

(8) 作为订阅ASIC_DB的订阅者，syncd将接收 产生于orchagentd的 新状态信息。

(9)Syncd将会处理信息，然后引用SAI APIs，将这个状态信息注入到相应的asic驱动器中。

(10) 最终，新路由信息被推送到硬件。