SONiC架構分析

目錄

• 系統架構
  • 設計原則
  • 核心組件
    • SWSS 容器
    • syncd 容器
    • 網絡應用容器
• 內部通信模型
  • SubscriberStateTable
  • NotificationProducer/Consumer
  • Producer/ConsumerStateTable
  • ProducerTable & ConsumerTable
  • 與內核的通信方式
• teamd 聚合組配置
  • 配置
  • 聚合過程
• 端口狀態交互
  • 端口初始化
  • 端口狀態變化
• 路由狀態交互
• LLDP狀態交互
• syncd 組件
  • orchagent 寫操作
  • orchagent 讀操作
  • 獲得driver通知
  • syncd 啟動 notify 線程
  • syncd與SDE交互
• mgmt-framework
• 配置
• 測試框架
• FAQ
  • SONiC 未來的發力方向？
  • SONiC 目前的商用情況？
  • SONiC有統一的命令行入口么？
  • SONiC支持API接口么？
  • SONiC是全開源的么？
  • 組件為什么需要容器化？
  • Switchdev 與SONiC 區別？
  • 哪些公司在白盒領域？
• 參考

推薦一個chatgpt代理站(支持gpt4): www.gptschools.cn

在傳統交換機的架構下，網絡操作系統由各設備廠商基於芯片廠商負責提供的ASIC芯片和SDK自行設計、開發，設備廠商需要開發上層APP、適配層以在特定設備商完成應用，實現各種網絡功能。傳統交換機的軟硬件開發均由設備廠商提供，系統完全封閉，無法適應新功能快速開發部署的需求：

為構建一個開放的系統，OCP（Open Compute Project, 開發計算項目）開始推動硬件、網絡操作系統開源與標准化進程。其中，SONiC (Software for Open Network in the Cloud) 是由微軟於2016年發起，並在2017年貢獻給OCP的項目。SONiC的所有軟件功能模塊都開源，這極大地推動了OCP社區以及其他廠商/用戶在開放網絡方面的創新。SONiC通過將SAI作為南北向互聯的中間件，屏蔽不同ASIC之間的驅動差異，也正是由於SAI的存在，SONiC的網絡功能應用才能夠支持多個廠家的ASIC。絡軟件建立在交換機抽象接口（SAI，SAI接口適配ASIC的工作由各個廠家實現）上，使其可以運行在各種硬件設備中，形成白盒交換機軟件生態鏈。

SONiC自推出后，迅速得到了產業界的支持，大部分網絡芯片供應商都在SDK上支持SAI，並配合微軟為SAI版本添加新的接口，如網絡分析接口、L3快速重路由和BFD等。

系統架構

SONiC構建在Linux系統之上，並且利用鍵值數據庫（redis）、容器技術（docker）、標准化硬件接口定義等技術，使其成為一個軟硬件徹底解耦、軟件模塊松耦合（loose coupling）、高可靠、易於擴展、開源開放的網絡軟件系統。其架構特點主要體現在3個方面：

• SAI接口：SAI是SONiC的核心，並為SONiC提供了統一的API。設備廠家、網絡開發者可以基於芯片廠家提供的SAI接口開發應用，而不需要關心底層硬件實現，加速產品迭代與創新；
• 數據庫架構：在數據庫架構方面，SONiC使用數據庫架構代替原有的模塊化耦合架構，將應用模塊之間的傳遞數據模式變成應用模塊之間通過數據庫進行數據交換的模式，從關注流程轉變為關注數據，實現了功能模塊之間的解耦。數據庫成為了所有模塊的樞紐，模塊與模塊之間解耦，數據庫是穩定的，各個模塊升級與故障不會影響其他模塊，在整個切換過程中轉發面不受到影響；
• 容器化組件：容器化使得SONiC具有極高的可擴展性，網絡運營管理人員能夠快速引入第三方、專有或開源組件，而不對原有業務造成影響；
• 與內核交互少： 運行在用戶空間的SONiC系統，只有為數很少的模塊（pmon、swss和syncd）與Linux內核之間存在交互關系，從而保證了系統的穩定性。

設計原則

• 軟硬件解耦的理念和標准化的軟硬件接口定義，分別讓網絡軟件系統和硬件平台飛速發展；
• 網絡軟件系統的演進，也可以讓快速迭代、按需定制、社區共建成為可能；
• 網絡軟件的開發形成了全新的共建、共享、開放的網絡生態系統，快速推進網絡自身的發展；
• 微軟開源SONiC的同時，將自己在數據中心網絡運營實踐方面的經驗也一並開放給了外界，everflow、netbouncer等功能就是SONiC軟件里要支持的功能。這些功能的開放，是廣大網絡運維工程師的福音，讓網絡排障再也不僅僅只是依靠ping、traceroute或者純人工經驗，而是走向智能化和科學化；
• SONiC也提供了Ipv6的支持、Fast Reboot的功能，能夠保證在升級的過程當中，數據平面的中斷不超過30秒；
• 2018年，SONiC進一步引入了Warm Reboot功能，該功能可以把數據平面的中斷‍‍控制在一秒之內，在很多現有的通用平台上，甚至能夠做到無中斷的升級。同時也‍‍引入了一些新的service，比如Streaming Telemetry‍‍和一些虛擬化的支持。

核心組件

• sonic-swss-common : 1.3萬
• sonic-swss: 6萬行
• sonic-sairedis ： 22萬

CLI、REST FUL API、CFG Manager 配置 redis 數據庫 CFG_DB，redis 通過 key-space 機制將修改的信息發布給 SWSS 中的各個 mgrd，xxx-mgrd 調用linux命令或者發送 netlink 消息，將信息同步給linux，成功后，同時將信息插入到APP_DB的PORT_TABLE中，portorch 訂閱 APPL_DB中的PORT_TABLE，接收相關信息，處理加工，並更新ASIC_DB信息。

大部分組件的表都是redis hash表，同類型中不同的對象表的前綴相同，后綴不同，同一個哈希表中，不同的key對應不同的屬性。

SWSS 容器

SWSS （switch state service）是一套工具，用於協調所有SONiC模塊之間、模塊與redis引擎之間的通信。swss還承載以下服務，這些服務通過netlink與SONiC應用層交互（在其他容器中運行的進程除外，即fpmsyncd、teamsyncd和lldp_syncd）。下面的前三個服務（portsyncd、intfsyncd、neighsyncd）將狀態推送到redis引擎，而最后三個服務（orchagent、intfMgrd、vlanMgrd）從引擎收集狀態，並重新發布狀態到應用。

• portsyncd :偵聽與端口相關的netlink事件。當交換機啟動時，portsyncd解析交換機的硬件配置文件以獲取物理端口信息，然后將收集的狀態推送到APPL_DB中。portsyncd 設置端口速度、lane和MTU，並將狀態注入狀態數據庫。
• intfsyncd ：偵聽與接口相關的netlink事件，並將收集的狀態推送到APPL_DB中。intfsyncd還管理與接口關聯的新的或更改的IP地址等元素。
• neighsyncd ：偵聽新發現的鄰居由於ARP處理而觸發的與鄰居相關的netlink事件，並將收集的狀態推送到APPL_DB中。neighsyncd管理諸如MAC地址和鄰居地址族之類的屬性，並最終構建數據平面中用於二級重寫目的所需的鄰接表。
• teamd: 鏈接聚合（LAG）容器，它提供了在SONiC交換機上配置綁定的功能。teamd服務是LAG協議的一個基於Linux的開源實現。teamsyncd服務管理teamd和southbound子系統之間的交互。
• orchagent ：swss子系統中最關鍵的組件。orchagent提取各種syncd服務注入的所有相關狀態，相應地處理和發送這些信息，最后將其推送到ASIC_DB。orchagent在這些服務中是獨一無二的，因為它既是消費者（如從APPL_DB獲取狀態）又是生產者（如推進ASIC_DB）。
• intfMgrd ：對來自APPL_DB、CONFIG_DB和state_DB的狀態作出反應，以配置Linux內核中的接口，前提是所監視的任何數據庫中沒有沖突或不一致的狀態。
• vlanMgrd ：對來自APPL_DB、CONFIG_DB和state_DB的狀態作出反應，以在Linux內核中配置VLAN，前提是所監視的任何數據庫中沒有沖突或不一致的狀態。

相關的模塊功能角色總結如下：

• xxx-mgrd ： 對來自APPL_DB、CONFIG_DB和state_DB的狀態作出反應，以配置linux內核中的接口。
• xxx-syncd： 偵聽與內核相關的netlink事件，並將收集的狀態寫入APP_DB。
• orchagent： swss子系統中最關鍵的組件。orchagent提取各種syncd服務注入的所有相關狀態，相應地處理和發送這些信息，最后將其推送到ASIC_DB。orchagent在這些服務中是獨一無二的，因為它既是消費者（如從APPL_DB獲取狀態）又是生產者（如推進ASIC_DB）。

syncd 容器

將交換機的網絡狀態與ASIC同步，這包括ASIC當前狀態的初始化、配置和收集。主要邏輯組件包括：

• syncd：執行同步邏輯的進程。在編譯時，syncd與ASIC SDK庫鏈接，並將從接口收集的狀態注入ASIC。syncd訂閱ASIC_DB以接收來自swss參與者的狀態，並將來自硬件的狀態推回ASIC_DB。
• SAI API：交換機抽象接口（SAI）定義了API，以提供獨立於供應商的方式來控制轉發元素，如交換ASIC、NPU或軟件交換機。
• ASIC SDK：驅動ASIC所需SDK的SAI兼容實現。SDK鈎住syncd，syncd 負責驅動其執行。

網絡應用容器

• lldp：鏈路層發現協議容器，在其中運行以下進程：1) lldpd：LLDP服務，它與外部對等方建立LLDP連接，以公布和接收系統功能。2) lldp_syncd：此服務將lldp發現狀態上載到redis引擎（集中式系統的消息基礎結構），將lldp狀態傳遞給需要它的應用程序，如SNMP。3) lldpmgr：lldpd服務的配置工具。
• snmp：承載snmp功能。此容器中有兩個相關流程：1) snmpd：處理來自外部網絡元素的傳入SNMP輪詢的服務器。2) snmp代理：這是SONiC對AgentX snmp子代理SONiC_ax_impl的實現。sonic_ax_impl子代理向主代理（snmpd）提供從集中式Redis引擎中的sonic數據庫收集的信息。
• pmon: 此容器是Sensord 服務運行的地方。sensord定期記錄硬件組件的傳感器讀數，並在觸發報警時發出警報。pmon容器還承載fancontrol進程，該進程從相應的平台驅動程序收集與風扇相關的狀態。
• bgp: 運行路由堆棧。BGP容器運行以下服務: 1) bgpd：標准的BGP服務。外部方的路由狀態通過常規TCP或UDP套接字接收，並通過zebra/fpmsyncd接口向下推送到轉發平面。2) zebra：傳統的IP路由管理器。它提供內核路由表更新、接口查找和跨各種路由協議的路由重新分配服務。zebra還通過netlink將計算出的FIB向下推送到內核，並通過轉發平面管理器（FPM）推送到轉發過程中涉及的南向組件。3) fpmsyncd：此服務收集zebra生成的FIB狀態，並將其內容轉儲到redis引擎內的應用程序數據庫（APPL_DB）中。

內部通信模型

sonic消息傳遞機制2，sonic消息傳遞機制3

SONiC使用了發布訂閱機制與redis的鍵空間通知機制（當客戶端修改數據時，redis服務器會通知其他相關訂閱者（client）的數據變化）。

SONiC 中使用到的數據庫如下：

• 0號數據庫：APPL_DB，存儲所有應用程序生成的狀態——路由、下一跳、鄰居等。這是應用程序與其他SONiC子系統交互的入口點;
• 1號數據庫：ASIC_DB，存放底層 ASIC 的狀態信息和配置表項，格式對底層芯片友好，芯片重啟可以從ASIC_DB快速恢復；
• 2號數據庫：CONTERS_DB，存放每個端口計數器和統計信息，這些信息可以被cli使用或者反饋給telemetry；
• 3號數據庫：LOGLEVEL_DB，存放日志配置等級信息；
• 4號數據庫：CONFIG_DB，存儲SONiC應用程序創建的配置狀態——端口配置、接口、VLAN等，有的APP/模塊可能沒有配置，可以沒有對應表，有的配置直接調用linux的命令進行配置，有的配置還需要下發到芯片，這時需要往APPL_DB里寫；
• 5號數據庫：FLEX_COUNTER_DB，存放靈活計數器配置；
• 6號數據庫：STATE_DB，存儲系統中配置實體的“關鍵”操作狀態。此狀態用於解決不同SONiC子系統之間的依賴關系。例如，LAG端口channel（由teamd子模塊定義）可能指系統中可能存在或不存在的物理端口。另一個例子是VLAN的定義（通過vlanmgrd組件），它可能引用系統中存在未知的端口成員。本質上，該數據庫存儲了解決跨模塊依賴關系所需的所有狀態。

SubscriberStateTable

在SONiC中，CONFIG_DB和STATE_DB之間的數據監聽通過 key-space 機制實現。key-space 機制的消費者通過 sonic-swss-common/common 中的 SubscriberStateTable 類實現。

對CONFIG_DB的修改一般用於對系統進行配置操作，如使用命令行來配置系統功能，SONiC在sonic-py-swsssdk組件中封裝了對CONFIG_DB的操作，根據傳遞data是否為空執行hmset或delete操作。

這里以監聽CONFIG_DB配置VLAN為例說明。

VlanMgr 組件在初始化時監聽CFG_VLAN_TABLE_NAME和CFG_VLAN_MEMBER_TABLE_NAME兩個 key-space 事件，當通過config命令（sonic cli）添加 vlan 100的操作時，redis服務器的 CONFIG_DB 會為“VLAN|Vlan100”的KEY產生 key-space事件消息， VlanMgr 組件收到后，調用 VlanMgr::doTask(Consumer &consumer) 處理。

@startuml

config -> redis服務器 : 寫redis
redis服務器 -> client : 產生keyspace消息 
client -> client : 接收消息，並調用函數處理

@enduml

收到消息后，這里的Consumer即是通過orch類封裝過的 SubscriberStateTable 。

NotificationProducer/Consumer

通過消息隊列來傳遞信息，內容可以靈活定義。在 SONiC 中，該通信模型主要用於 SWSS容器中的 orchagent 與 syncd 容器中的之間的事件通知。

以FDB事件為例，SYNCD收到來自底層驅動的FDB事件，調用對數據庫的hset或del操作更新ASIC_DB中的FDB表項，同時作為Notification生產者發送名為“fdb_event”的通知消息。
Notification的消費者流程在fdborch中實現，通知消息觸發FdbOrch::doTask(NotificationConsumer&consumer)來進行后續處理，更新orchagent中的FDB信息。

Producer/ConsumerStateTable

sonic-swss-common 中 ProducerStateTable 與 ConsumerStateTable 實現

該機制通過一個set集合傳遞key，通過publish命令通知有新的key產生。消費者通過key組合成一個hash表的key，用於獲取真實的消息，set不保證順序，在publish通知KEY修改事件前允許對key-value進行多次操作，操作過程不保證執行順序。這樣做的好處是不必在每次設置key-value時都觸發事件通知，可以提升處理效率，但對orchagent處理流程有一定要求。

示例：

## 在集合INTF_TABLE_KEY_SET中增加一個key
"SADD" "INTF_TABLE_KEY_SET" "PortChannel1:1.1.1.1/8"

## 在hash表INTF_TABLE:PortChannel1:1.1.1.1/8中添加內容
"HSET" "INTF_TABLE:PortChannel1:1.1.1.1/8" "scope" "global" 
"HSET" "INTF_TABLE:PortChannel1:1.1.1.1/8" "family" "IPv4"

## 通知訂閱者頻道 INTF_TABLE_CHANNEL 有消息，訂閱者根據 INTF_TABLE_組合成 INTF_TABLE_KEY_SET 獲取key，
## 然后，根據key獲取hash表 INTF_TABLE:PortChannel1:1.1.1.1/8 的內容，如果該內容為空則表示刪除操作，否則表示SET操作。
"PUBLISH" "INTF_TABLE_CHANNEL" "G"    

Orchagent調度處理采用epoll事件通知模型，事件觸發即會產生調度；在調度處理中，可能出現因資源依賴等因素導致任務處理無法完成，此時可以選擇將任務保留在m_toSync中等待下一次調度處理。在大規模控制表項和較復雜邏輯關系的場景下，這種調度機制可能出現因資源限制、依賴條件不滿足等因素導致的頻繁或無效調度，Asterfusion通過優化處理順序、改進批量操作以及在STATE_DB中設置狀態標志等改進方式，提高了組件運行效率並增強了可靠性。

ProducerTable & ConsumerTable

使用redis publish 通知KEY修改事件，利用Key-Value-Operate機制來傳遞信息。該通信模型通過有序鏈表（list）來傳遞key-value-operate三元消息，一次操作在LIST中壓入三個值(通知訂閱者進行消息處理，循環處理消息，一次必須從鏈表中拿出三個key)，分別為key，value，operate。其中的 value 是把一個 hash表進行json編碼后形成了一個單一的字符串，所以訂閱者得到消息后需要進行解碼還原，最后一個是操作類型。

SYNCD 通過這種方式List隊列獲得 key-value-operation, 然后解碼，寫入到ASIC_STATE，同時調用底層SAI接口。

在SONiC中，該模型用於圍繞ASIC_DB和FLEX_COUNTER_DB的消息傳遞。與模型3相比，該模型保證了操作的嚴格執行順序，在 syncd 執行 SAI API 調用時保證了對底層ASIC的操作時序。

示例：

"LPUSH" "ASIC_STATE_KEY_VALUE_OP_QUEUE" "SAI_OBJECT_TYPE_ROUTE_ENTRY:{\"dest\":\"1.1.1.0/24\",\"switch_id\":\"oid:0x21000000000000\",\"table_id\":\"oid:0x0\",\"vr\":\"oid:0x3000000000043\"}" "[\"SAI_ROUTE_ENTRY_ATTR_PACKET_ACTION\",\"SAI_PACKET_ACTION_FORWARD\",\"SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID\",\"oid:0x600000000063a\"]" "Screate"

## 通知訂閱者進行消息處理，循環處理消息，一次必須從鏈表中拿出三個key
"PUBLISH" "ASIC_STATE_CHANNEL" "G"  

與內核的通信方式

網絡接口事件和路由等需要SONiC應用程序與Linux內核通信，主要通過兩種方式：

• 調用Linux工具命令， 如調用ip命令配置網絡接口IP地址和設置VRF，又如調用bridge命令配置VLAN。用封裝的swss::exec方法最終通過popen執行拼裝好的command指令。
• 對netlink消息操作則是通過以libnl庫為基礎封裝的NetLink類來完成，同時SWSS也定義了一套NetDispatcher機制來實現netlink消息監聽和分發處理。

teamd 聚合組配置

配置

teamdmgrd 負責配置過程。

• CLI創建名稱為PortChannel0001的聚合組,加入聚合組成員口Ethernet0和Ethernet4，在CONFIG_DB中生成配置表項；

• teamdmgrd 進程監聽相應鍵值變化，調用doLagTask和doLagMemberTask方法處理。a）doLagTask方法解析參數並生成所需的配置文件conf，通過調用teamd命令創建並配置聚合組，並調用ip命令設置聚合組接口MAC地址和管理狀態；b) doLagMemberTask方法中先判斷聚合組及待加入聚合組成員接口狀態是否滿足要求，如果滿足則調用teamdctl和ip命令來配置聚合成員接口，這里會將聚合成員口設置為down，否則掛起當前任務后續再處理；

• teamdmgrd作為生產者將聚合組和成員的配置信息寫入APPL_DB。

• portsorch作為消費者訂閱APP_LAG_TABLEAPP_LAG_MEMBER_TABLE進行處理。

• portsorch調用sairedis的API，檢查參數類型合法性並將LAG配置信息寫入ASIC_DB。

• SYNCD訂閱ASIC_DB中的LAG相關表項並處理。

• SYNCD調用ASIC SDK對SAI API的實現，並通過ASICdriver下發到底層芯片。

聚合過程

teamsyncd 負責聚合過程：

• teamsyncd初始化階段注冊監聽RTM_NEWLINK和RTM_DELLINK類型的netlink消息，同時也會注冊teamd的操作handler，用於處理teamd聚合成員口狀態變化以及teamd參數變化觸發的事件。a) 一類是netlink消息，當觸發NEWLINK或DELLINK時對應操作STATE_LAG_TABLE設置聚合組狀態；b) 另一類是teamd狀態變化消息，當teamd通過LACP交互及內部狀態機產生聚合成員口狀態變化，調用TeamSync::TeamPortSync::onChange進行處理。

• teamd感知聚合成員口發生狀態變化，teamsyncd從teamd獲取當前聚合成員列表和狀態，與變化前的聚合成員列表進行比較。如果聚合成員已存在且狀態發生變化，則直接修改相應的APP_LAG_MEMBER_TABLE成員狀態，如果成員列表發生變化，則向APP_LAG_MEMBER_TABLE添加新增的成員口並設置成員狀態以及刪除不存在的成員口。
  

• portsorch作為消費者訂閱APP_LAG_MEMBER_TABLE進行處理，根據聚合成員口狀態設置SAI_LAG_MEMBER_ATTR_INGRESS_DISABLE和SAI_LAG_MEMBER_ATTR_EGRESS_DISABLE，決定是否允許通過該成員口接收流量以及從該成員口發送流量。

• portsorch 調用sairedis的API，並更新LAG Member配置表項及屬性到ASIC_DB。
  

• SYNCD訂閱ASIC_DB中的LAG Member表項並處理。

• 調用ASIC SDK對SAI API的實現，並通過ASIC driver下發到底層芯片。

端口狀態交互

端口初始化

如下圖所示，展示了公開系統中對生成或使用端口相關信息感興趣的多個組件：

• 建立連接，聲明角色：初始化期間，portsyncd與redis引擎中的主數據庫建立通信通道。Portsyncd聲明它打算充當APPL_DB和STATE_DB的發布者，以及CONFIG_DB的訂戶。同樣，portsyncd還訂閱負責承載端口/鏈路狀態信息的系統netlink通道。
• 解析配置：Portsyncd首先解析與系統中使用的硬件配置文件/sku關聯的端口配置文件（port_config.ini）（有關更多詳細信息，請參閱配置部分）。與端口相關的信息，如通道、接口名稱、接口別名、速度等，通過該通道傳輸到APPL_DB。
• 轉換到ASIC_DB：Orchagent聽到所有這些新狀態，但將推遲對其進行操作，直到portsyncd通知它已完全完成對port_config.ini信息的解析。一旦發生這種情況，orchagent將繼續初始化硬件/內核中相應的端口接口。Orchagent調用sairedis API，通過常用的ASIC_DB接口將此請求傳遞給syncd
• 創建端口：Syncd通過ASIC_DB接收此新請求，並准備調用滿足Orchagent請求所需的SAI API。Syncd使用SAI API+ASIC SDK創建與正在初始化的物理端口相關聯的內核主機接口。
• 更新狀態：上一步生成netlink消息，被portsyncd接收，並與先前從port_config.ini（步驟1）解析的所有端口進行對比，若都完成，則聲明“初始化”過程已完成。portsyncd 將寫入一個條目到 STATE_DB 中，表示端口初始化完成。
• 依賴使用：從現在起，以前訂閱STATE_DB content的應用程序將收到一個通知，允許這些應用程序開始使用它們所依賴的端口。換句話說，如果在STATE_DB中找不到特定端口的有效條目，則任何應用程序都無法使用它。

端口狀態變化

• 當端口狀態發生變化時，驅動通過syncd注冊的函數通知syncd
• syncd調用通知函數發送事件給 ASIC_DB
• Orchagent 通過notification 線程監聽ASIC_DB事件，執行端口狀態變化函數：1）產生APPL_DB更新消息，通知上層應用；2）調用sairedis API以提醒syncd需要更新與所選端口的主機接口關聯的內核狀態，orchagent再次通過常用的ASIC_DB接口將此請求傳遞給syncd
• Syncd使用SAI API+ASIC SDK將受影響主機接口狀態（關閉）更新;
• portsyncd接收到與上一步相關的netlink消息，由於所有SONiC組件現在都完全知道端口關閉事件，因此該消息將被悄悄丟棄。

路由狀態交互

在本節中，我們將迭代SONiC中發生的一系列步驟，以處理從eBGP對等方接收到的新路由。我們將假設此會話已經建立，並且我們正在學習一種新的路由，該路由使用直接連接的對等方作為其下一跳。

（0）在BGP容器初始化期間，zebra通過常規TCP套接字連接到fpmsyncd。在穩定/非瞬態條件下，zebra、linux內核、APPL_DB和ASIC_DB中保存的路由表應完全一致/等效。
（1） 一個新的TCP包到達內核空間中bgp的套接字。內核的網絡堆棧最終將相關的有效負載交付給bgpd進程。
（2） Bgpd解析新數據包，處理bgp更新，並通知zebra此新前綴及其關聯協議下一跳的存在。
（3） zebra確定此前綴的可行性/可達性（例如，現有轉發nh）后，zebra生成路由netlink消息，將此新狀態注入內核。
（4） Zebra利用FPM接口將此netlink路由消息傳遞給fpmsyncd。
（5） Fpmsyncd處理netlink消息並將此狀態推送到APPL_DB。
（6） 作為APPL_DB消費者，它將接收先前推送到APPL_DB的信息內容。
（7） 在處理接收到的信息后，orchagentd將調用sairedis API將路由信息注入ASIC_DB。
（8） 當與ASIC_DB消費者同步時，它將接收orchagentd生成的新狀態。
（9） Syncd將處理該信息並調用SAI API將該狀態注入相應的asic驅動程序。
（10） 新的路線最終被推到了硬件上。

LLDP狀態交互

• （0）lldpmgrd進程啟動時訂閱STATE_DB數據中物理口的狀態，周期性獲取接口最新狀態。基於這些信息，lldpd(及其網絡對等方)將隨時了解系統端口狀態的更改以及影響其操作的任何配置更改
• （1）內核收到lldp報文后會分發給lldp進程去處理
• （2）lldp解析LLDP報文獲取最新狀態，lldp_syncd周期性執行lldpctl cli獲取該最新狀態
• （3）lldp_syncd把最新的狀態寫入APPL_DB數據庫中的LLDP_ENTRY_TABLE表
• （4）其他監聽這張表的app就能獲取lldp的最新狀態了

syncd 組件

syncd 通過注冊回調函數與driver通信，syncd和sai共享命名空間。syncd 啟動線程監聽共享隊列，處理driver的通知。

syncd 進程是介於orchagent與driver之間的進程。syncd從asic-db中讀取的數據經轉換后調用驅動提供的sai接口下發到硬件，同時需要將驅動的應答進行一定的處理，還需要處理驅動的事件通知(比如端口up/down，mac老化等信息)。處理的消息如下圖所示:

@startuml

Orchagent -> asic_db : 步驟1
asic_db -> syncd : 步驟2
syncd -> driver : 步驟3
driver -> syncd : 步驟4
syncd -> asic_db : 步驟5
asic_db -> Orchagent : 步驟6
driver -> syncd : 步驟7
syncd -> asic_db : 步驟8
asic_db -> Orchagent : 步驟9
@enduml

orchagent 寫操作

create，remove，set寫操作：異步寫。orchagent會在 sairedis 層構建一個虛擬的sai層:sairedis。orchagent執行sai接口只是對asic-db進行操作，生成或者刪除虛擬對象(vid)。默認所有操作都是成功的，直接返回，不等待syncd的應答。執行上圖的1和6。syncd從asic-db中讀出請求執行上圖的2,3,4。如果4步驟返回成功，則整個請求運行結束，否則，syncd將會發送shutdown通知給orchagent。orchagent會退出，如上圖的5,6；

orchagent 讀操作

get 讀操作：同步讀。orchagent執行1后會使用select阻塞等待syncd的應答，如果syncd在60分鍾內沒有應答，那么orchagent會產生segment退出。get操作執行順序為1->2->3->4->5->6。

// sonic-sairedis/lib/src/sai_redis_generic_get.cpp:257:sai_status_t redis_generic_get(
sai_status_t redis_generic_get() {
// ...
// internal_redis_generic_get
    std::string str_object_type = sai_serialize_object_type(object_type);
    std::string key = str_object_type + ":" + serialized_object_id;

    // 寫入本次get事件，不會寫輸入到asic數據庫，只是加入到隊列中
    g_asicState->set(key, entry, "get");

    // 創建臨時 select，添加事件，等待響應
    swss::Select s;
    s.addSelectable(g_redisGetConsumer.get());
    //循環等待syncd的應答
    while (true)
    {
        swss::Selectable *sel;
        //阻塞等待，時間為GET_RESPONSE_TIMEOUT  
        int result = s.select(&sel, GET_RESPONSE_TIMEOUT);
        //只處理應答情況OBJECT
        if (result == swss::Select::OBJECT) {
            swss::KeyOpFieldsValuesTuple kco;
            g_redisGetConsumer->pop(kco);

            const std::string &op = kfvOp(kco);
            const std::string &opkey = kfvKey(kco);


            if (op != "getresponse") // ignore non response messages
            {
                continue;
            }

            sai_status_t status = internal_redis_get_process(
                    object_type,
                    attr_count,
                    attr_list,
                    kco);
           
            return status;
        }
        break;
    }
    //超時和異常都返回SAI_STATUS_FAILURE
    return SAI_STATUS_FAILURE;
}

對於get操作，當syncd比較忙的時候，極端情況下會導致orchagent異常退出。

獲得driver通知

driver的notify： 驅動檢測到硬件事件后，調用syncd注冊的回調函數通知syncd，將相關事件寫入隊列。syncd中有一個專門處理driver-notify的線程ntf-thread。ntf-thread解析driver的notify，然后通過asic-db通知orchagent （orchagent會在主進程的select中監聽asic-db。）。執行順序7->8->9。

注： orchagent 與syncd關於sai這一層非常相似。它們會調用大量的同名函數。這些函數只是名字相同，orchagent調用的是sai-redis庫中的函數，而syncd調用的是driver提供的sai庫

• syncd向驅動注冊回調函數，syncd定義了幾個notify全局函數指針

sai_switch_state_change_notification_fn     on_switch_state_change_ntf = on_switch_state_change;
sai_switch_shutdown_request_notification_fn on_switch_shutdown_request_ntf = on_switch_shutdown_request;
sai_fdb_event_notification_fn               on_fdb_event_ntf = on_fdb_event;
sai_port_state_change_notification_fn       on_port_state_change_ntf = on_port_state_change;
sai_packet_event_notification_fn            on_packet_event_ntf = on_packet_event;
sai_queue_pfc_deadlock_notification_fn      on_queue_deadlock_ntf = on_queue_deadlock;

syncd和sai共享命名空間，所以驅動直接使用這些函數指針即可調用對應的函數，在初始化的時候將這些全局函數指針通過驅動提供的sai_set_switch_attribute函數設置到sai層。

/*
* Routine Description:
*    Set switch attribute value
*
* Arguments:
 *   [in] switch_id Switch id
*    [in] attr - switch attribute
*
* Return Values:
*    SAI_STATUS_SUCCESS on success
*    Failure status code on error
*/
sai_status_t sai_set_switch_attribute(_In_ sai_object_id_t switch_id,
                                      _In_ const sai_attribute_t *attr) {

  sai_status_t status = SAI_STATUS_SUCCESS;
  switch_status_t switch_status = SWITCH_STATUS_SUCCESS;
  switch_uint64_t flags = 0;
  switch_api_device_info_t api_device_info;
  sai_packet_action_t sai_packet_action;
  switch_acl_action_t switch_packet_action;
  switch_packet_type_t switch_packet_type = SWITCH_PACKET_TYPE_UNICAST;
  bool cut_through = false;

  if (!attr) {
    status = SAI_STATUS_INVALID_PARAMETER;
    SAI_LOG_ERROR("null attribute: %s", sai_status_to_string(status));
    return status;
  }

  memset(&api_device_info, 0x0, sizeof(api_device_info));
  if (status != SAI_STATUS_SUCCESS) {
    return status;
  }
  if (attr->id <= SAI_SWITCH_ATTR_ACL_STAGE_EGRESS) {  // Unsupported
    SAI_LOG_DEBUG("Switch attribute set: %s", switch_attr_name[attr->id]);
  }

  switch (attr->id) {
    //......
        
    case SAI_SWITCH_ATTR_FDB_EVENT_NOTIFY:
      sai_switch_notifications.on_fdb_event = attr->value.ptr;
      break;
    case SAI_SWITCH_ATTR_PORT_STATE_CHANGE_NOTIFY:
      sai_switch_notifications.on_port_state_change = attr->value.ptr;
      break;
    case SAI_SWITCH_ATTR_PACKET_EVENT_NOTIFY:
      sai_switch_notifications.on_packet_event = attr->value.ptr;
      break;
    case SAI_SWITCH_ATTR_SWITCH_STATE_CHANGE_NOTIFY:
      sai_switch_notifications.on_switch_state_change = attr->value.ptr;
      break;
    case SAI_SWITCH_ATTR_SHUTDOWN_REQUEST_NOTIFY:
      sai_switch_notifications.on_switch_shutdown_request = attr->value.ptr;
      break;
    ......

    default:
      SAI_LOG_ERROR("Unsupported Switch attribute: %d", attr->id);
      // Unsupported: Temporary hack till all attrs are supported
      switch_status = SWITCH_STATUS_SUCCESS;
  }
  //......
}

sai接口初始化的時候會向驅動注冊回調函數，回調函數中會調用我們注冊的全局函數指針，我們以fdb為例進行說明：

sai_status_t sai_fdb_initialize(sai_api_service_t *sai_api_service) {
  sai_api_service->fdb_api = fdb_api;
  switch_uint16_t mac_event_flags = 0;
  mac_event_flags |= SWITCH_MAC_EVENT_LEARN | SWITCH_MAC_EVENT_AGE |
                     SWITCH_MAC_EVENT_MOVE | SWITCH_MAC_EVENT_DELETE;
  //初始化fdb的sai接口的時候，向驅動注冊了 sai_mac_notify_cb 回調函數。
  switch_api_mac_notification_register(
      device, SWITCH_SAI_APP_ID, mac_event_flags, &sai_mac_notify_cb);
  switch_api_mac_table_set_learning_timeout(device, SAI_L2_LEARN_TIMEOUT);
  return SAI_STATUS_SUCCESS;
}

static void sai_mac_notify_cb(const switch_device_t device,
                              const uint16_t num_entries,
                              const switch_api_mac_entry_t *mac_entry,
                              const switch_mac_event_t mac_event,
                              void *app_data) {
  SAI_LOG_ENTER();
  sai_fdb_event_notification_data_t fdb_event[num_entries];
  sai_attribute_t attr_lists[num_entries][2];
  uint16_t entry = 0;

  for (entry = 0; entry < num_entries; entry++) {
    memset(&fdb_event[entry], 0, sizeof(fdb_event[entry]));
    fdb_event[entry].event_type = switch_mac_event_to_sai_fdb_event(mac_event);
    memcpy(fdb_event[entry].fdb_entry.mac_address,
           mac_entry[entry].mac.mac_addr,
           ETH_ALEN);
    fdb_event[entry].fdb_entry.switch_id =
        (((unsigned long)SWITCH_HANDLE_TYPE_DEVICE)
         << SWITCH_HANDLE_TYPE_SHIFT) |
        0x1;
    fdb_event[entry].fdb_entry.bv_id = mac_entry[entry].network_handle;

    memset(attr_lists[entry], 0, sizeof(attr_lists[entry]));
    attr_lists[entry][0].id = SAI_FDB_ENTRY_ATTR_TYPE;
    attr_lists[entry][0].value.s32 = SAI_FDB_ENTRY_TYPE_DYNAMIC;
    attr_lists[entry][1].id = SAI_FDB_ENTRY_ATTR_BRIDGE_PORT_ID;
    attr_lists[entry][1].value.oid = mac_entry->handle;
    fdb_event[entry].attr_count = 2;
    if (fdb_event[entry].event_type == SAI_FDB_EVENT_FLUSHED) {
      // Overwriting now for SONiC to be able to process it correctly
      fdb_event[entry].event_type = SAI_FDB_EVENT_AGED;
    }
    fdb_event[entry].attr = attr_lists[entry];
  }
  //調用syncd的回調函數
  sai_switch_notifications.on_fdb_event(num_entries, fdb_event);
  return;
}

syncd 啟動 notify 線程

std::shared_ptr<std::thread> ntf_process_thread;

void startNotificationsProcessingThread()
{
    runThread = true;
    ntf_process_thread = std::make_shared<std::thread>(ntf_process_function);
}

void ntf_process_function()
{
    while (runThread) {
        cv.wait(ulock);
        // this is notifications processing thread context, which is different
        // from SAI notifications context, we can safe use g_mutex here,
        // processing each notification is under same mutex as processing main
        // events, counters and reinit
        swss::KeyOpFieldsValuesTuple item;
        while (tryDequeue(item))//從隊列中取出notify
        {
            processNotification(item);//處理notify
        }
    }
}

bool tryDequeue(
        _Out_ swss::KeyOpFieldsValuesTuple &item)
{
    std::lock_guard<std::mutex> lock(queue_mutex);
    if (ntf_queue.empty()) {
        return false;
    }
    item = ntf_queue.front();
    ntf_queue.pop();
    return true;
}

void processNotification (
        _In_ const swss::KeyOpFieldsValuesTuple &item)
{
    std::lock_guard<std::mutex> lock(g_mutex);

    SWSS_LOG_ENTER();

    std::string notification = kfvKey(item);
    std::string data = kfvOp(item);

    if (notification == "switch_state_change") {
        handle_switch_state_change(data);
    } else if (notification == "fdb_event") {
        handle_fdb_event(data);
    }
    else if (notification == "port_state_change")
    {
        handle_port_state_change(data);
    }
    else if (notification == "switch_shutdown_request")
    {
        handle_switch_shutdown_request(data);
    }
    else if (notification == "queue_deadlock")
    {
        handle_queue_deadlock(data);
    }
    else
    {
        SWSS_LOG_ERROR("unknow notification: %s", notification.c_str());
    }
}

// 以 fdb 為例
void handle_fdb_event(
        _In_ const std::string &data)
{
    SWSS_LOG_ENTER();
    uint32_t count;
    sai_fdb_event_notification_data_t *fdbevent = NULL;
    sai_deserialize_fdb_event_ntf(data, count, &fdbevent);
    process_on_fdb_event(count, fdbevent);
    sai_deserialize_free_fdb_event_ntf(count, fdbevent);
}

void process_on_fdb_event(
        _In_ uint32_t count,
        _In_ sai_fdb_event_notification_data_t *data)
{
    for (uint32_t i = 0; i < count; i++) {
        sai_fdb_event_notification_data_t *fdb = &data[i];
        fdb->fdb_entry.switch_id = translate_rid_to_vid(fdb->fdb_entry.switch_id, SAI_NULL_OBJECT_ID);
        fdb->fdb_entry.bv_id = translate_rid_to_vid(fdb->fdb_entry.bv_id, fdb->fdb_entry.switch_id);
        translate_rid_to_vid_list(SAI_OBJECT_TYPE_FDB_ENTRY, fdb->fdb_entry.switch_id, fdb->attr_count, fdb->attr);

        /*
         * Currently because of bcrm bug, we need to install fdb entries in
         * asic view and currently this event don't have fdb type which is
         * required on creation.
         */
        redisPutFdbEntryToAsicView(fdb);
    }

    std::string s = sai_serialize_fdb_event_ntf(count, data);
    send_notification("fdb_event", s);
}

void send_notification(
        _In_ std::string op,
        _In_ std::string data,
        _In_ std::vector<swss::FieldValueTuple> &entry)
{
    //寫入數據庫
    notifications->send(op, data, entry);
}

void send_notification(
        _In_ std::string op,
        _In_ std::string data)
{
    SWSS_LOG_ENTER();

    std::vector<swss::FieldValueTuple> entry;

    send_notification(op, data, entry);
}

syncd與SDE交互

在SONiC中，syncd容器是與ASIC通信的唯一通道，控制面的業務進程想將數據下發ASIC時，最終處理流程都是將數據按照SAI標准接口格式寫入Redis中的ASIC_DB，syncd容器中的同名主進程syncd訂閱ASIC_DB中的相關表項並處理這些下發的數據，調用ASIC SDK對SAI API的實現，並通過ASIC driver下發到ASIC。

其中SDE就包括了ASIC SDK以及運行在Tofino ASIC上的tofino.bin（由P4源碼編譯生成的二進制程序）。

mgmt-framework

https://github.com/Azure/sonic-mgmt-framework
https://github.com/Azure/SONiC/blob/master/doc/mgmt/Management Framework.md

mgmt-framework 負責提供各種通用北向接口（North Bound Interfaces , NBI），用於管理SONiC交換機的配置和狀態。
管理框架利用golang編寫的翻譯庫（Translib）將向管理客戶機公開的數據模型轉換為Redis ABNF模式格式。

配置

登錄設備后，SONiC軟件可以通過三種方式進行配置：

• Command Line Interface （CLI）
• config_db.json
• minigraph.xml

測試框架

Sonic測試研究（一）：測試架構介紹

FAQ

SONiC 未來的發力方向？

Chassis、Kubernetes、AI agent、Test Infrastructure

SONiC 目前的商用情況？

‍‍到2020年為止，SONiC現在‍‍已經被超過10個的雲運營商‍‍以及大型企業所采納。以‍‍微軟的Azure network為例，現在‍‍已經做到了新裝機完全采取SONiC。SONiC歷經多年，被很多運營商‍‍采用，現在SONiC的技術非常成熟和穩定了，截止到2020年初，‍‍據微軟不完全統計，SONiC的裝機容量已經接近400萬個端口。Criteo （該公司目前的核心業務是重定向廣告）所有新增裝機都采用 SONiC。

SONiC是開源的，這樣‍‍能夠獲得全球性的支持和全球性的供應鏈，其次，由於現在SONiC已經有了很多‍‍供應商和‍‍企業用戶，也就表明SONiC獲得了業界的共同承認，SONiC已經是一個穩定成熟的解決方案，對於降低組網‍‍和管理的復雜度‍‍非常有效。

SONiC有統一的命令行入口么？

SONiC有命令行，但伴隨模塊的功能分散存在，沒有統一的入口，並且有些模塊的命令行缺少交互界面。命令行庫見：https://github.com/Azure/sonic-utilities/

SONiC支持API接口么？

SONiC有一個原生RESTAPI框架，基於Golang實現，但功能僅有VLAN、VLAN interface、VXLAN tunnel、路由，功能上側重業務。

SONiC是全開源的么？

SONiC不是全開源的，交換芯片適配部分，僅提供二進制格式。這主要受限於芯片廠商的License保護，微軟也不能直接開源。

組件為什么需要容器化？

容器化可以屏蔽不同組件之間的依賴沖突，版本限制，實現不影響的故障、恢復、升級。

Switchdev 與SONiC 區別？

1）感覺其思路不一樣: SONiC 把 交換機當交換機，switchdev 是把交換機當網卡（如1822），利用開放的Linux網絡工具管理交換機；
2）SONiC 包括SAI接口、較重的容器化管理框架等，設備驅動由廠商SDK提供。 switchdev 框架包括Linux內核（統一定義的接口）、驅動和應用等方面，大部分由廠家實現在內核中，對於用戶較輕量，使用起來像使用網卡一樣。

哪些公司在白盒領域？

• 銳捷：白盒交換機的開發取決於設備廠商的3個關鍵架構（可靠性、可擴展性和開放性）選擇和2個關鍵能力（芯片/SDK BUG修復能力和網絡軟件功能支持能力）。而銳捷網絡在數據通信領域具有二十年軟硬件自主研發能力，恰好匹配了當前的這些能力訴求。銳捷網絡以主動擁抱變化的態度參與白盒交換機的標准制定和商用落地，已經成為了SONiC生態的主要合作伙伴之一。

銳捷網絡在白盒交換機產品設計方面，CPU采用標准的x86架構，配合博通數據中心專用ASIC構建了開放化白盒交換機的基礎，同時支持ONIE安裝環境、提供支持SAI的BSP+SDK包，並提供基於SONiC的軟件開發、咨詢服務。同時，銳捷網絡基於多年商用交換機的開發及規模商用經驗，積累了完整的軟、硬件測試案例及全自動化測試套件、測試方法以及專業的測試人員，可以提供專業的硬件、軟件定制化服務，同時為白盒交換機的品質提供了強有力的支撐和保障。

nfvschool 微信公共號: nfvschool
nfvschool網址： nfvschool.cn

參考

• sonic消息傳遞機制與架構(2)
• sonic-utilities
• ouyangxibao 的segmentfault
• docs-nvidia-system-architecture
• sonic orchagent與syncd之間的請求與應答
• 連接SONiC與P4交換芯片的SDE
• 詳解：SONiC演進四部曲
• 微軟解穎：SONiC Update 2020
• SONiC Warm Reboot
• 京東網絡開放之路——自研交換機探索與實踐
• 微軟解穎：SONiC Update 2020
• RESTAPI在SONiC中的實現
• 一文了解SONiC內部通信模型
• SONi CSoftwareSubsystemsOverview-OCP-workshop 2018
• SONiC Application DB schema format
• SONiC官網
• SONiC官方wiki