SONiC架構分析

目錄

在傳統交換機的架構下，網路作業系統由各設備廠商基於晶片廠商負責提供的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的工作由各個廠家實現）上，使其可以運行在各種硬體設備中，形成白盒交換機軟體生態鏈。

image.png

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內核之間存在交互關係，從而保證了系統的穩定性。

image.png

image.png

設計原則

  • 軟硬體解耦的理念和標準化的軟硬體介面定義，分別讓網路軟體系統和硬體平台飛速發展；
  • 網路軟體系統的演進，也可以讓快速迭代、按需訂製、社區共建成為可能；
  • 網路軟體的開發形成了全新的共建、共享、開放的網路生態系統，快速推進網路自身的發展；
  • 微軟開源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萬

image.png

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組件），它可能引用系統中存在未知的埠成員。本質上，該資料庫存儲了解決跨模組依賴關係所需的所有狀態。

image.png

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

G23164.png

收到消息後，這裡的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 聚合組配置

image.png

配置

teamdmgrd 負責配置過程。

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

image.png

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

image.png

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

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

image.png

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

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

image.png

  • 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添加新增的成員口並設置成員狀態以及刪除不存在的成員口。
    image.png

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

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

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

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

埠狀態交互

埠初始化

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

image.png

  • 建立連接，聲明角色：初始化期間，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中找不到特定埠的有效條目，則任何應用程式都無法使用它。

埠狀態變化

image.png

  • 當埠狀態發生變化時，驅動通過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對等方接收到的新路由。我們將假設此會話已經建立，並且我們正在學習一種新的路由，該路由使用直接連接的對等方作為其下一跳。

image.png

（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狀態交互

image.png

  • （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

S23164.png

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交互

image.png

在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

//github.com/Azure/sonic-mgmt-framework
//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

image.png

SONiC 目前的商用情況？

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

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

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

SONiC有命令行，但伴隨模組的功能分散存在，沒有統一的入口，並且有些模組的命令行缺少交互介面。命令行庫見：//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

參考

Tags:

VirMach 便宜 VPS

QNews

QNews