SONiC学习笔记（2）--SONiC架构中各模块间的交互

LLDP-state 交互

下图描述了LLDP状态传输的的交互，当LLDP携带的状态改变的消息到来时的一些列动作。

(0) LLDP初始化阶段。lldpmgrd 从STATE_DB处获取系统中物理端口的实时状态（lldpmgrd 轮询周期为5s）。Lldpd 会一直保持对系统端口状态的变化和任何影响其操作的配置变化的感知。

(1) 某一时刻，一个新的LLDP包到达内核空间时，内核会传输相关负载至lldp进程。

(2) lldp解析消化新的状态，由lldp_syncd在执行lldpctl cli命令的过程中获得（周期为10s）。

(3) Lldp_syncd 将新的状态发送给APPL_DB中的LLDP_ENTRY_TABLE表。

(4) 从此时刻起，所有订阅到该表的实体都应该收到一个新状态的副本(目前，snmp是唯一想要获得此信息的实体)

SNMP-state 交互

snmp container包括一个主代理和一个SONiC独特的代理snmp_subagent，subagent与可提取MIB状态的redis databases/tables交互，snmp-agent 订阅以下databases/tables：

• APPL_DB：PORT_TABLE、LAG_TABLE、LAG_MEMBER_TABLE、LLDP_ENTRY_TABLE
• STATE_DB: *
• COUNTERS_DB: *
• ASIC_DB：ASIC_STATE：SAI_OBJECT_TYPE_FDB*

下图描述了在一个snmp询问到来时在SONiC各个组件中的处理过程。

(0) 在snmp-subagent支持的不同MIB子组件初始化时，与上述DBs构建连接。从这刻起，snmp-subagent缓存从所有的DBs获得的状态，这些信息在<60s的时间内更新，来确保DBs和snmp-subagent的同步。

(1) 当一个snmp query到达内核时，内核传输此数据包到snmpd进程。

(2) snmp的信息被解析，发送一个联合的需求到subagent。

(3) Snmp-subagent 基于本地数据结构缓存的状态对query进行服务，发送信息回到snmpd进程。

(4) Snmpd 最终通过通常的socket接口发送回 reply 到最初发起者。

Routing-state 交互

当从eBGP peer处获得一个新路由时，将进行以下操作。假设这个会话已经被建立并且正在学习一条将直接连接的peer 用作下一跳的新路由。

下图展示了整个过程，并且没有画出与SONiC不相关的细节。

(0) 初始化阶段，zebra 通过TCP socket 连接 fpmsyncd 。在稳定/不传输时，确认zebra, the linux kernel, APPL_DB, ASIC_DB 保存的路由表是一致的、等效的。

(1) 新的TCP数据包到达内核空间中bgp’s socket。内核将负载发送到bgpd进程。

(2) Bgpd解析数据包，处理 bgp-update，通知 zebra 新的prefix 存在和它的下一跳协议。

(3) 在zebra确保了这个prefix的灵活性和可到达性时，zebra生成route-netlink消息来发送新的状态到内核。

(4) Zebra 利用 FPM接口传输netlink-route 信息到fpmsyncd。

(5) Fpmsyncd 处理 netlink 信息并且发送状态到 APPL_DB.

(6) 作为 APPL_DB的订阅者，orchagent 将接收先前推送到APPL_DB的信息的内容

(7) 处理完信息后, orchagentd 会调用 sairedis APIs 将路由信息发送到ASIC_DB。

(8) 作为 ASIC_DB 的订阅者, syncd 会接收由orchagent处理后的新状态。

(9) Syncd处理信息调用 SAI APIs 发送这些状态信息到asic-driver。

(10) 新的路由信息最终发送到硬件。

Port-state 交互

当系统在传输与端口相关的信息时，系统间模块的交互过程如下。portsyncd发挥了关键作用，它对其他SONiC子系统也具有依赖关系。

首先，我们呈现了在产生或使用与端口相关的信息的多个组件。其次，呈现了一个例子，即STATE_DB 在系统中如何运行以及不同的应用如何依靠他们的信息进行内部操作。

(0) 初始化阶段，portsyncd构建与redis-engine的主要databases间的通信通道。Portsyncd 是 APPL_DB 和 STATE_DB 的发布者，是 CONFIG_DB 的订阅者。同样的，portsyncd 也订阅了系统的netlink 通道来传输 port/link-state信息。

(1) Portsyncd 通过解析端口配置文件(port_config.ini) 和被系统正在使用的hardware-profile/sku 开始启动。端口相关信息例如lanes, interface name, interface alias, speed等等，都通过此通道到达APPL_DB。

(2) Orchagent 监听所有的新状态，但是会延迟操作直到portsyncd 通知已经完全解析完port_config.ini。一旦解析结束，orchagent将继续进行硬件/内核中相应端口接口的初始化。Orchagent调用sairedis APIs 发送请求到syncd 通过常规ASIC-DB接口。

(3) Syncd 通过 ASIC_DB 接收到请求，准备调用 SAI APIs 来满足 Orchagent’s 请求。

(4) Syncd利用SAI APIs + ASIC SDK 创建与正在初始化物理端口相关的内核 host-interfaces 。

(5) 上一步将生成 netlink 信息，会被portsyncd接收。 与先前从port_config.ini解析的所有端口相关的消息到达portsyncd后，portsyncd 会继续声明已完成初始化步骤。

(6) 作为上一步的一部分，portsyncd记录 record-entry到STATE_DB，对应于每个成功初始化的端口。

(7) 此时起，应用之前订阅的STATE_DB 内容会接收到一个通知，允许他们开始利用他们需要的端口。换句话说，如果没有在STATE_DB 中发现某个端口的有效的entry，没有应用可以使用他们。

NOTE : 如今， teamsyncd, intfmgrd, vlanmgrd 和 lldpmgr 这些应用活跃的监听STATE_DB的改变。其中，lldpmgr已经被介绍了。

当物理端口发生故障时，进行的操作步骤如下：

(0) 和之前提到的一样，syncd既作为ASIC_DB的发布者也是订阅者。订阅模式被syncd评判来获取北向绑定的应用状态，例如所有模块交互的例子。发布模式被需要允许syncd通知高层次组件硬件衍生事件的到达。

(1) 通过ASIC对应光学模块，一点检测到有loss-of-carrier，一个通知就被发送到相关驱动，最终传输到syncd。

(2) Syncd 调用合适的通知处理机制发送port-down事件给ASIC_DB。

(3) Orchagent 利用通知线程（专门用于此任务）来收集ASIC_DB的新状态，并且执行 ‘port-state-change’ ，即:

• a. 生成APPL_DB的更新来警告依赖此状态的操作（例如，CLI – "show interface）
• b. 调用 sairedis APIs 来警告syncd需要更新与端口的主机接口相关的内核状态，orchagent 传输这个需求到syncd通过常规ASIC_DB接口。

(4) Syncd 接收来自ASIC_DB的请求准备调用SAI APIs 来满足此请求。

(5) Syncd 利用 SAI APIs + ASIC SDK 来用受影响的主机接口的最新操作状态（DOWN）。

(6) portsyncd获得一个与上述步骤相关的netlink消息，由于所有SONiC组件现在都已完全意识到port-down事件，因此该消息被丢弃。

参考资料

本文，主要参考官方文档https://github.com/Azure/SONiC/wiki/Architecture，进行了翻译，并记录了笔记。