SONiC学习笔记（1）--SONiC架构与各模块功能

1. 什么是SONiC

SONiC是构建网络设备（如交换机）所需功能的软件集合。它可以通过交换机换抽象接口（SAI）运行在不同的ASIC平台。

SAI向上给SONiC提供了一套统一的API 接口，向下则对接不同的ASIC。

SONiC是一个将传统交换机操作系统软件分解成多个容器化组件的创新方案，这使得增加新的组件和功能变得非常方便。

SONiC大量使用了现有的开源项目和开源技术，如Docker，Redis，Quagga和LLDPD 以及自动化配置工具Ansible、Puppet和Chef等。

SONiC只是构建交换机网络功能的软件集合，它需要运行在Base OS上。SONiC所使用的Base OS 是ONL (Open Network Linux ) 。ONL是一款为白盒交换机而设计的开源Linux操作系统，ONL中包括了许多硬件（温度传感器、风扇、电源、CPLD控制器等）的驱动程序。

将SONiC和Base OS、SAI、ASIC平台对应的驱动打包制作成为一个文件，这个文件才是可直接安装到白盒交换机的NOS镜像 。

SONiC与传统网络的区别，如下图所示，左侧代表SONiC，右侧为传统网络架构，LAG App，BGP App等都属于控制层，生成控制面的表项，SAI，ASIC Control Software相当于软转发层面，用来将控制面的数据转化为ASIC的数据，然后下发驱动。硬件转发层包含SDK和硬件。

2. SONiC架构（总述）

关于SONiC的架构，主要参考官方文档https://github.com/Azure/SONiC/wiki/Architecture，进行了翻译，并记录了自己的笔记。

SONiC系统的架构由许多模块组成，这些模块通过一个集中的、可扩展的架构相互作用。

这个结构依赖于redis-database引擎的使用：即一个键-值数据库。它提供一个独立于语言的接口，一个用于所有SONiC子系统之间的数据持久性、复制和多进程通信的方法。

具有publisher/subscriber 的消息传递模式，应用程序可以只订阅它们需要的数据，无须知道功能的具体实现细节。

SONiC将每个模块放置在独立的docker容器中，以保持组件之间的高内聚性，同时减少不相连组件之间的耦合。

主要有以下docker容器，具体功能介绍见第3节。

• Teamd：运行并实现链路聚合（LAG）功能。
• Pmon：记录硬件传感器读数并发出警报。
• Snmp：实现SNMP功能。
• Dhcp-relay：将DHCP请求从没有DHCP服务器的子网中连接到其他子网上的一台或多台DHCP服务器。
• Lldp：实现链路层发现协议功能。建立lLLDP连接。
• Bgp：运行支持的路由协议之一，例如ospf，isis，ldp，bgp等。
• Database：redis-engine托管的主要数据库。
• Swss：实现所有SONiC模块之间进行有效通信和与SONiC应用层之间的交互。监听并推送各个组件的状态。
• Syncd：实现交换机网络状态和实际硬件进行同步

下图是这些容器的结构图以及如何容器之间如何进行交互。蓝色箭头来表示与集中式redis引擎的交互，黑色箭头来表示其他的交互（netlink, /sys file-system, etc）。SONiC的配置模块sonic-cfggen和CLI是存在于Linux主机中的模块。

3. SONiC架构（各模块功能）

3.1 Teamed container

运行并实现LAG（Link Aggregation functionality）链路聚合。teamsyncd 模块允许teamed与南向子系统进行交互

另：LAG：链路聚合是在两个设备间使用多个物理链路创建一个逻辑链路的功能，这种方式允许物理链路间共享负载。交换机网络中使用的一种链路聚合的方法是EtherChannel。EtherChannel可以通过协议PAGP（Port Aggregation Protocol）或LACP（Link Aggregation Protocol）来配置。

3.2 Pmon container

“ sensored”的守护程序，记录硬件传感器读数并发出警报。托管“ fan-control”进程，收集与风扇相关的状态。

3.3 Snmp container

Snmpd：snmp服务器，负责处理从外部网络元素传入的snmp轮询。

Snmp-agent(sonic_ax_impl)：snmp子代理的实现，从集中式redis-engine中的SONiC数据库收集信息,提供给主代理(snmpd)。

另：SNMP(Simple Network Management Protocol)：应用层协议，靠UDP进行传输。常用于对路由器交换机等网络设备的管理，管理人员通过它来收集网络设备运行状况，了解网络性能、发现并解决网络问题。SNMP分为管理端和代理端(agent)，管理端的默认端口为UDP 162，主要用来接收Agent的消息如TRAP告警消息;Agent端使用UDP 161端口接收管理端下发的消息如SET/GET指令等。

3.4 Dhcp-relay container

DHCP中继代理可将DHCP请求从没有DHCP服务器的子网中连接到其他子网上的一台或多台DHCP服务器。

另：DHCP（Dynamic Host Configuration Protocol）：动态主机配置协议，是一个应用层协议。当我们将客户主机ip地址设置为动态获取方式时，DHCP服务器就会根据DHCP协议给客户端分配IP，使得客户机能够利用这个IP上网。集中的管理、分配IP地址，使网络环境中的主机动态的获得IP地址、Gateway地址、DNS服务器地址等信息。工作过程如下图所示。

3.5 Lldp container

lldp：实现LLDP功能，建立lldp连接以advertise/receive系统功能。

Lldp_syncd：上传LLDP的发现的状态到redis-engine，这样可以使得需要此状态的应用（如SNMP）从redis处获得此信息。

Lldpmgr：为lldp进程提供incremental-configuration功能，它通过订阅redis引擎中的STATE_DB来实现。

另：LLDP（Link Layer Discovery Protocol）：链路层发现协议。设备通过在网络中发送LLDPDU（Data Unit）来通告其他设备自身的状态（理地址，设备标识，接口标识等）。可以使不同厂商的设备在网络中相互发现并交互各自的系统及配置信息。 当一个设备从网络中接收到其它设备的这些信息时，它就将这些信息以MIB的形式存储起来。LLDP只传输，不管理。

另：MIB（Management Information Base）：管理信息库。网络管理的标准架构之一，MIB定义了受管设备必须保存的数据项、允许对每个数据项进行的操作及其含义，即管理系统可访问的受管设备的控制和状态信息等数据变量都保存在MIB中。

3.6 Bgp container

运行支持的路由协议之一，例如ospf，isis，ldp，bgp等。

bgpd：路由的实现。外部的路由状态通过常规的tcp/udp sockets 接收，并通过zebra / fpmsyncd接口下推到转发平面。

zebra：充当传统的IP路由管理。它提供内核路由表的更新，接口的查找和路由的重新分配。将计算出的FIB下推到内核（通过netlink接口）和转发过程中涉及的南向组件（通过Forwarding-Plane-Manager，FPM接口）

fpmsyncd：收集zebra下发的FIB状态，将内容放入redis-engine托管的APPL-DB中。

另：FIB（Forward Information dataBase）：转发信息库。路由一般手段：先到路由缓存（RouteTable）中查找表项，如果能查找到，就直接将对应的一项作为路由规则；如果查不到，就到FIB中根据规则换算出来，并且增加一项新的，在路由缓存中将项目添加进去。

另：RIB（Route Information dataBase）：FIB强调的是作为转发的路由表，RIB是用来做路由管理的表。RIP、OSPF、BGP、ISIS都是动态路由协议，它们学习到的路由首先要通告给RIB表。RIB表把所有路由协议学习到的路由汇总到一起，把优选结果的路由加入到FIB表，供转发使用。所以FIB是RIB的一个子集。

3.7 Database container

redis-engine托管的主要数据库。SONiC应用程序可以通过公开的UNIX socket访问该引擎中保存的数据库。

APPL_DB: 储存所有应用容器生成的状态，如路由、下一跳、邻居节点等。所有应用与SONiC其他子系统交互的南向接入点。

CONFIG_DB: 储存SONiC应用产生的配置状态，如 port configurations, interfaces, vlans, 等。

STATE_DB: 储存实体配置的 “key” 操作状态，以确保SONiC子系统间的依赖性。例如，LAG端口通道可能潜在的指代物理端口、VLAN的定义可以引用系统中不确定的端口的成员。存储所有解决交叉模块依赖性的状态。

ASIC_DB: 存储必要的运行ASIC配置和操作的驱动状态。存储格式易于syncd与asic SDK的交互。

COUNTERS_DB: 存储每个端口的 counters/statistics。能够满足CLI本地需求或用于遥测通道。

3.8 Swss container

Switch State Service，包含一组工具，以允许所有SONiC模块之间进行有效通信。database container主要提供存储能力，Swss主要侧重于提供促进所有不同方之间的通信和仲裁的机制。

Swss也负责与北向的应用层进行交互。fpmsyncd, teamsyncd and lldp_syncd是例外。这种提供SONiC应用与SONiC中心架构(redis-engine)的连接的进程都被命名为*syncd。

Portsyncd: 监听端口相关的连接事件。portsyncd在启动阶段获得物理端口信息，全部发送给APPL_DB，端口速度，链路和mtu都通过这个通道传输。Portsyncd还将状态发送到STATE_DB。

Intfsyncd: 侦听与接口相关的netlink事件，发送给APPL_DB。例如新的和更改的接口的IP地址在这个进程中处理。

Neighsyncd:监听邻居事件相关的netlink事件，例如mac地址与邻居的address-family。 这些状态会构建数据平面中以L2-rewrite为目的所需的adjacency-table。所有的状态也都会传输给APPL_DB。

Teamsyncd: 和Teamd container共同运行，获得的状态发送给APPL_DB。

Fpmsyncd: 和bgp container共同运行，获得的状态发送给APPL_DB。Previously discussed – running within bgp docker container. Again, collected state is injected into APPL_DB.

Lldp_syncd: 和lldp container共同运行。

当将信息注入redis-engine所代表的publisher-subscriber流水线时，上述过程显然充当了状态产生者的角色。但是，必须有一个进程集合来订阅和重新分配所有到来的状态，这就是以下进程：

Orchagent: Swss里最关键的部分。包含如何从*synd中提状态的逻辑，相应地处理和发送信息，最终发送到南向接口。Orchagent既获取来自APPL_DB的状态，又将状态推送到ASIC_DB中。

IntfMgrd: 对到达APPL_DB、CONFIG_DB、STATE_DB的状态做出反应来配置Linux内核接口。这一步只在没有状态冲突或者状态不一致的情况下完成。

VlanMgrd: 对到达APPL_DB、CONFIG_DB、STATE_DB的状态做出反应来配置Linux内核vlan接口。只有在没有任何依赖状态/条件被满足时，才会执行此步骤。

3.9 Syncd container

提供机制允许交换机网络状态和实际硬件进行同步，包括初始化、配置、ASIC当前状态的收集。

Syncd: 执行同步逻辑，在编译时，连接硬件厂商提供的ASIC SDK库，并通过调用为此提供的接口将状态注入ASIC。Syncd订阅ASIC_DB来获取Swss的状态，同时，推送来自硬件的状态。

SAI API: Switch Abstraction Interface (SAI) 定义了一个API来提供一个厂商独立的统一规范的控制转发元素，例如交换机ASIC，NPU或者软件交换机。

ASIC SDK: 硬件厂商应提供一个与SAI能够友好交互的SDK来驱动他们的芯片。通常以动态链接库的形式提供此实现，该库链接到对应驱动程序。

3.10 CLI / sonic-cfggen

负责提供CLI功能和系统配置能力。

CLI ：依赖于Python的Click库来提供使用者灵活性和自定义的方法来构建命令行工具。

Sonic-cfggen：被CLI调用来实现配置的改变或者任何与SONiC模块交互的配置动作。

参考文档

https://github.com/Azure/SONiC/wiki/Architecture
https://blog.csdn.net/armlinuxww/category_9162329.html