# SONiC Software for Open Networking in the Cloud。オープンソースのネットワーク OS(NOS)。Switch Abstraction Interface(SAI)標準とともに多様なスイッチング ASIC の制御を統一し、ディスアグリゲートされたベンダ非依存のファブリックを複数ハードウェア間で実現する。Microsoft Azure などのハイパースケールな本番環境で実証され、コンテナ化されたアーキテクチャと FRRouting(FRR)のコントロールプレーンにより機能の高速な進化を可能にする。([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] §2) - AI/HPC ファブリックでは RoCEv2 が要求するロスレス Ethernet 部品(PFC・ECN)を提供し、EVPN/VXLAN によるスケーラブルな L2/L3 オーバーレイを支える。([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] §2) - [[SAKURAONE]] は Edgecore AIS800-64O(Broadcom Tomahawk 5)上で SONiC を運用し、トップ 100 TOP500 で唯一のフルオープンなネットワーキングスタックを構成する。([[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]]) - [[@2023__NSDI__Empowering Azure Storage with RDMA]] では、[[Azure Storage]] のリージョン内 RDMA 展開で異種スイッチ ASIC/OS の運用負荷を下げるため、Microsoft が SAI ベースのクロスプラットフォームなスイッチ OS として SONiC を開発・展開したと説明される。ECN marking、PFC、PFC watchdog、共有バッファモデルを含む RDMA 必須機能の統一実装が主な役割である。 - [[ソフトバンク株式会社]]の800G AECケーブル検証([[@2025__SpeakerDeck__SONiCで800G AECケーブルを検証してみた]])では、SONiCの`show logging xcvrd`コマンドでCMISログを絞り込み、`i2cdump`/`i2cset`でトランシーバーのCMISレジスタを直接読み書きすることで、CLIの標準コマンドだけでは特定できない障害(Tx Output Controlsレジスタの意図しない無効化)を切り分けられることが示された。一方でSONiC/Linuxコマンドではポート単位の消費電力測定ができず、PSU単位の計測に留まるという制約も確認された。 - [[SAKURA internet Inc]]の「高火力」GPUクラウド基盤([[@2025__SpeakerDeck__SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク]])では、Clos topology上でSONiCを採用し、GPU Interconnect・Storage Network・Service・Managementの4種のネットワークを構築した。運用コマンドの不足に対してLinux/Pythonで自社スクリプト(`sakura-neighbor`によるLLDP/BGP情報整理、`sakura-config-compare`によるSONiC設定の差分比較)を開発し、監視はSNMP(RoCEメトリクス非対応)からPrometheusベースの内製実装へ刷新した。config管理では新規OS導入を機にjsondiff差分生成→dry run(構文チェック)→applyの3段構成へ切り替え、Container再生成を伴うconfig置き換え方式(冪等性0・通信断あり)から冪等性を担保した運用へ移行した。SONiC特有の課題として、YANGスキーマ未整備によりapply patch時にSNMP_MANAGEMENT_ADDRESSやRDMA設定全般で構文チェック緩和が必要になること、RDMA設定新規追加時にCPU100%となるため初回はreplace&rebootで回避する必要があることを報告した。また、コミュニティSONiCをメーカーが拡張する性質上、一貫したBug trackが難しいという構造的課題(vendorとcommunityのFix時間差など)を指摘した。 ## Stratumとの比較とPINSによる統合(*Software-Defined Networks: A Systems Approach* 第5章) *Software-Defined Networks: A Systems Approach* 第5章は、SONiCを[[Stratum]](Thin Switch OS)と並ぶベンダー非依存のSwitch OSとして位置づけ、両者の関係を具体的に整理する。SONiCはもともとMicrosoftによってオープンソース化され、現在もAzure Cloudの Switch OS として使われ続けている。SONiCは[[SAI (Switch Abstraction Interface)]]をベンダー非依存のSDKとして活用し、スイッチ向けにカスタマイズされたLinuxディストリビューションを含む——すなわちStratumとSONiCは同じ需要を満たそうとしている。両者のアプローチは現在では大きく補完的であり、2つのオープンソースコミュニティは「両方の長所を併せ持つ」解決策に向けて協働しており、この取り組みは[[PINS (P4 Integrated Network Stack)|PINS]](P4 Integrated Network Stack)と呼ばれる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] ch.5 §5.4) SONiCとStratumはいずれも構成インターフェースをサポートするため、両者の統合はそれぞれのデータモデルとツールチェーンをすり合わせる問題に帰着する。主な違いは、Stratumが(P4と[[P4Runtime]]を含む)プログラム可能なフォワーディングパイプラインをサポートする点であり、これに対しSAIは最大公約数的なフォワーディングへのアプローチを取る。PINSの目標は、(1) リモートのSDNコントローラ/アプリがP4Runtimeと[[gNMI]]を使ってSAIと相互作用できるようにすること、(2) データプレーンの機能開発速度を高めるためにP4を使ったSAI拡張を可能にすることの2つであり、いずれもSAIの振る舞いモデル・パイプラインをP4プログラム(`sai.p4`)で新たに表現することに依拠する。(Source: ch.5 §5.4) ## アーキテクチャの全体像(『実践SONiC入門』第1章) SONiCは、機能ごとのコンテナが相互に連携しながらネットワークOSとしての機能を実現する。本家Wiki(SONiCリポジトリ)のArchitectureページに従い、機能ごとのコンテナ(例: bgpコンテナ, teamdコンテナ, swssコンテナ)を**サブシステム**、サブシステム内で動作し機能を提供するプロセスを**モジュール**と呼ぶ(例: swssコンテナ内で動作するorchagentやvlanmngrd)。各サブシステムはコンテナとして分離動作することで、プラットフォーム(ハードウェアやホストOS)に依存せず機能を提供できる。例外はCLIとsonic-cfggenで、これらはホストOS上で動作する。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 1 ホワイトボックススイッチとSONiCアーキテクチャ]] ch.1 §1.3.1) モジュールにはSONiC専用に開発されたものに加え、既存オープンソース実装を利用しているものもある。例としてFRRouting(FRR)のデーモンであるbgpd・zebraや、teamd、lldpdなどが挙げられる。各サブシステム(内部で動作するモジュール)は主にdatabaseコンテナを介してデータをやり取りすることで連携する。SONiCはRedisをデータベースとして利用し、役割に応じてDB名(APPL_DB(0), ASIC_DB(1), COUNTERS_DB(2), CONFIG_DB(4), STATE_DB(6)など)を付けて管理する。DB名とRedis DBIDおよびテーブル名の対応は`sonic-swss-common/common/schema.h`に定義される。各サブシステムはdatabaseコンテナ以外に、ホストOS(Netlink・/sysファイルシステム・netdevによるステート取得/反映、コントロールパケットの送受信)、Switch ASIC(ASIC SDK/ドライバによる設定反映・ステータス/統計情報のやり取り)、設定ファイル(config_db.json)、CLIとも連携する。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 1 ホワイトボックススイッチとSONiCアーキテクチャ]] ch.1 §1.3.1) サブシステムとデータベース連携の具体例として、FRRが動作するbgpコンテナが学習したルーティング情報がSwitch ASICに反映されるまでの流れは次のとおりである: ①FRR(bgpコンテナ)がルーティング情報を学習、②転送情報に変換しFPMプロトコルでfpmsyncdへ伝達、③fpmsyncdが受信情報をAPPL_DB形式に変換しデータベースへ登録、④APPL_DBからswssコンテナ(orchagent)へエントリ更新を通知、⑤orchagentがAPPL_DBのエントリをASIC_DB形式に変換して登録(隣接情報など他情報と組み合わせる場合もある)、⑥ASIC_DBからsyncdへエントリ更新を通知、⑦syncdがASIC_DBエントリを読み出しSAI経由でSwitch ASICを設定。詳細はSONiCの内部構造を扱う第7章・第8章で解説される。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 1 ホワイトボックススイッチとSONiCアーキテクチャ]] ch.1 §1.3.2) ## 機能一覧とユースケースの広がり(『実践SONiC入門』第2章) コミュニティ版SONiCは、プラットフォーム制御・レイヤー2/3機能(VRF, ECMP, FRRによるBGP/IS-IS/OSPF, VXLAN, SRv6, MPLS, BFD等)・セキュリティ(CoPP, ACL, TACACS+/RADIUS)・QoS(シェーピング, RoCEv2)・管理(CLI, syslog, REST API)・モニタリング(gNMIによるTelemetry, SNMP, sFlow)・拡張([[PINS (P4 Integrated Network Stack)|PINS]])・テスト/開発(PDK/PDDF/PDE)という広範な機能をサポートする。リリースはSONiC.YYYYMM形式(例: SONiC.202305)で年2回行われ、機能ロードマップは「Sonic Roadmap Planning」Wikiページ、機能詳細はリリースノートと対応するHLD(デザイン文書)で追跡できる。2017年から2024年にかけての機能追加は、まずデータセンターファブリックに必要なレイヤー3/2機能から始まり、VXLANなどのオーバーレイ・ZTPなどの管理機能、SRv6などの高度な機能、そして近年ではSwitch ASIC以外のアーキテクチャサポートへと広がってきた。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.1) 採用事例は[[Microsoft]](公開元、SmartNIC上の[[SONiC-DASH]]へも拡大)・[[Alibaba Group|Alibaba.com]](拠点間接続・データセンターファブリック)・[[Target]](キャンパスLAN)・[[eBay]](サプライチェーン多様化)・[[Google]]([[PINS (P4 Integrated Network Stack)|PINS]]によるSDN統合)・[[Orange S.A|Orange S.A.]](通信事業者アクセス回線)・[[LINE株式会社]](国内初のIP CLOS導入)・[[KDDI株式会社]](ZTPによるHaaS管理NW)と、データセンターファブリックにとどまらず広がっている。Switch ASIC以外への適用としては、IPU/DPU向けの[[SONiC-DASH]]、ソフトウェアデータプレーンの[[SONiC-VPP]]、サードパーティーコンテナ管理のTPCMという3方向の拡張が進む。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.2, §2.3) ## コンテナとモジュール構成(『実践SONiC入門』第7章) 第1章が示したアーキテクチャ全体像を受け、第7章はサブシステム(コンテナ)とモジュール(プロセス)の内部構成をさらに掘り下げる。主要コンテナは database(Redis DBによるサブシステム間連携の中心)、swss(docker-orchagent。DB間・DBとホスト間のデータ変換/仲介を担う中核)、syncd(docker-syncd-\<platform\>。SAI API経由でSwitch ASICを制御)、bgp(docker-fpm-frr。FRRベースのルーティング)、mgmt-framework/gnmi(REST・gNMIによるノースバンドAPI)、pmon(プラットフォームモニタリング)、snmp、lldp、teamd(LAG制御)、eventd(イベント/アラーム通知)である。コンテナ内で動作するモジュールの起動順序・起動可否はsupervisord.confに集約され、switch_type(fabric/dpu/chassis-packet/voq)に応じてJinjaテンプレートから条件付き生成される場合がある。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 7 SONiCの内部構造：アーキテクチャとサブシステム]] ch.7 §7.2.2, §7.3.2) swssコンテナの内部モジュールは`*orch`(orchagent。APPL_DB→ASIC_DBの変換)・`*syncd`(portsyncd等。ホストNetlink→APPL_DB/STATE_DB)・`*mgrd`(vlanmgrd等。CLI/CONFIG_DB→ホスト設定)という命名規約で3分類される。`*syncd`という命名パターンはswssコンテナに閉じず、fpmsyncd(bgp)・teamsyncd(teamd)・lldp_syncd(lldp)のように各アプリケーション連携用コンテナにも分散配置される点に注意が必要である(syncdコンテナ自体とswssコンテナ内`*syncd`は役割が異なる)。詳細な命名規約と責務分離の設計思想は[[SONiCのモジュール責務分離]]を参照。(Source: ch.7 §7.5.1) ## ステートの流れとモジュール連携(『実践SONiC入門』第8章) 第7章の静的な構造(サブシステム/モジュール、命名規約)に対し、第8章はSONiCを「Redisデータベースに格納された各種ステートを機能毎のモジュールが読み出し・変換・書き込みすることによって動作するシステム」として動的に定義し直す。データベースへのアクセスはDBConnector(基本操作)→Table(セパレータ差異を吸収したテーブル操作)→ProducerStateTable(高頻度更新向けのパイプライン処理)という3層のクラスで行い、ASIC_DBのみsairedis経由でアクセスする(SAIスキーマ準拠のため)。モジュール間通信は原則として「双方がデータベースアクセスを行う」形にほぼすべて帰着し、唯一の例外がorchagent内部の`xxxOrch`クラス間の直接メソッド呼び出し(例: SRv6OrchがNeighOrchの`getNextHopId()`を呼ぶ)である。データベースを介した疎結合連携の一般的な設計原則は[[データベースを介した疎結合なモジュール連携]]に整理した。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 8 SONiCの内部構造：ステートの流れとモジュール連携]] ch.8 §8.1〜§8.2, §8.4) ルーティング機能を例に取ると、BGPパケット受信からSwitch ASICへの反映は、bgpd→zebra→fpmsyncd→APPL_DB→orchagent→ASIC_DB→syncd→SAI APIという経路をたどる(第1章§1.3.2で示した概要フローの詳細版)。FRRの設定管理には4モード(separated/unified/split/split-unified)があり、CONFIG_DBで管理する場合は初期設定をsonic-cfggen、設定変更をbgpcfgdが担う。これを発展させたFRR管理フレームワークは`frrcfgd`モジュールがCONFIG_DBをSSOTとしてFRRを制御し、RESTCONF/gNMI/CLIといったSONiC管理フレームワークの共通インターフェースでBGP以外のプロトコルも扱えるようにする。詳細は[[FRRouting (FRR)]]を参照。(Source: ch.8 §8.7.2〜§8.7.4, §8.9.5) **SONiC管理フレームワーク**(第6章で導入したREST/gNMI/CLI(Klish)の基盤)は、YANGモデルからOpenAPIスペック・Go-bindオブジェクトを生成するビルドタイム・パイプラインと、TransLib(モデル変換)・CVL(構文/意味検証)によるランタイム・パイプラインの2層で構成される。Redisへのアクセスはロック・ロールバックに対応しないCheck-and-Set(CAS)方式であり、CLI(Click)との併用時には注意が必要である。詳細は[[SONiC管理フレームワーク]]を参照。(Source: ch.8 §8.9〜§8.9.4) ## 高度な設定とSRv6の実践(『実践SONiC入門』第10章) 第6章が示した宣言的設定管理(CLI/CONFIG_DB経由)には、CLIやCONFIG_DBスキーマがまだ整備されていない新機能を先行して使うための、もう1つの経路が存在する。それがAPPL_DBへの直接投入である。第10章はこの経路の具体例としてSRv6(Segment Routing over IPv6)を扱う。SONiC(SAI)のSRv6実装は2017年のSAI 1.2.0まで遡るが、実装元のCavium XPliant ASICがディスコンとなったため2021年に再設計され、SONiC.202111でEnd, End.DT46, H.Encaps.Redという標準Behaviorが実装された。このリリースでの設定方法はコントローラーや手動操作によるAPPL_DBへの直接投入のみで、FRRとの連携は執筆時点(2024年11月)ではコミュニティ版SONiCで未サポートである(2024年11月にfpmsyncdの対応PRがマージされSONiC.202411での対応が見込まれる)。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]] §10.1.1) SRv6のサポート状況はデータプレーン(Switch ASIC)ごとに異なり、2023年9月時点でIntel Tofino ASIC、Cisco Silicon One ASIC、Linux Kernelの3つがサポートを表明している。sonic-vs(Linux Kernel)はAPPL_DB/ASIC_DBへの設定投入は可能だがデータプレーンとの連携が無いため、パケット変換動作の確認にはTofino ASIC搭載の実機(Wedge100BF32)を要する。End.DT46(受信したSRv6パケットをデカプセル化しVRFのルーティングテーブルに従い転送)とH.Encaps.Red(オリジナルパケットをSRv6にカプセル化して送出)という対をなす2つのBehaviorについて、APPL_DBのSRV6_MY_SID_TABLE/SRV6_SID_LIST_TABLE/ROUTE_TABLEへswssconfigで直接投入したエントリが、orchagent内のRouteOrchとSrv6Orchの協調動作によりASIC_DBのSAIオブジェクト(MY_SID_ENTRY, SRV6_SIDLIST, TUNNEL, NEXT_HOP, ROUTE_ENTRY)へ変換される様子を、実機でのパケットキャプチャとデータベースエントリの両面から確認できる。SRv6の実装・アーキテクチャの詳細は[[SRv6]]を参照。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]] §10.1.2, §10.2, §10.3) ## 入手とインストール(『実践SONiC入門』第5章) SONiCイメージの入手方法は、日次ビルドのプリビルドイメージ(Supported PlatformsページまたはAzure Pipelinesページ経由)とソースコードからのビルドの2種類があり、独自修正が不要ならプリビルドイメージが推奨される。実行イメージのファイル名は`sonic-<platform>.bin`(platformはASICベンダー名)で、仮想マシン向け`sonic-vs`のみ`.bin`に加えKVM起動用の`.img.gz`が存在する。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 5 SONiCの入手とインストール]] §5.2) 実機へのインストールは[[ONIE (Open Network Install Environment)]]経由が主流で、ブートローダーがONIEを起動しインストーラーがSONiCをインストールする初回起動と、ブートローダーが直接SONiCを起動する2回目以降の起動という2段階のフローを踏む。稼働後のアップグレード・ダウングレードは、ONIE Installerの再利用または`sonic-installer`コマンド(旧名`sonic_installer`はDeprecated)で行う。ハードウェアが無くても、KVM上で`sonic-vs.img`を起動する仮想環境(sonic-vs on KVM)で学習やコントロールプレーン中心の機能テストが可能である。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 5 SONiCの入手とインストール]] §5.3, §5.4) ## ソースコードからのビルド(『実践SONiC入門』Appendix 1) 第5章のプリビルドイメージ入手経路に対し、独自機能の追加や不要機能の削除、バグ修正を自分で行いたい場合はソースコードからのビルドが必要になる。SONiCイメージのビルドとは、各モジュールのソースコンパイル・バイナリダウンロードを通じて.debパッケージやDockerイメージを生成し、それらをsonic-$(PLATFORM).binへ統合する多段の過程であり、これを実現するスクリプト・フレームワーク群を「SONiCのビルドシステム」と呼ぶ。ビルドはsonic-buildimageレポジトリをクローンし、README.mdの手順(GNU make利用)に従うことで実行でき、著者はMultipassによるUbuntu仮想マシン上で常に同じ環境を再現してビルドしている(ビルド自体はsonic-slaveというDockerコンテナ内で実行される)。ビルドシステムには「同じソースコードをもとにビルドしても外部環境の変化でビルドが失敗する」という課題があり、SONiC Reproducible Buildなどの改善文書がこれを緩和する取り組みとして公開されている。(Source: [[@2025__Gihyo__実践SONiC入門 - Appendix 1 ソースコードからのビルド]]) ビルドオプションのカスタマイズはrules/config.userへの記載で行い(rules/config本体は変更しない)、機能の追加・削除(SONiC.202405ではINCLUDE_SYSTEM_GNMIやINCLUDE_MACSECなど20種以上)やデバッグ機能の有効化が可能である。全体ビルドは数時間(著者環境で初回約176〜210分)を要するため、変更したモジュール単体のみをビルドし`docker image load`で稼働中のSONiCへ入れ替えることで、開発・デバッグを効率化できる。(Source: [[@2025__Gihyo__実践SONiC入門 - Appendix 1 ソースコードからのビルド]]) ## 基本操作と設定方法(『実践SONiC入門』第6章) SONiCは実行中の設定をCONFIG_DBというRedisデータベースでSingle Source of Truth(SSOT)として管理する。起動時に`/etc/sonic/config_db.json`をCONFIG_DBへ読み込むが、CLIなどによるCONFIG_DBの変更は自動的にはこのファイルへ反映されず、反映には`save`コマンドが必要である。CONFIG_DBの内容は`sonic-db-cli`コマンドで直接確認できる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] §6.1.2) 設定操作は`config load`(既存設定への上書き、ファイルに無い設定は削除しない)と`config reload`(現在の設定を削除してから読み込む全体置き換え)で行う。設定のスナップショットは`config checkpoint`/`config rollback`で保存・復元でき、内部ではConfig Rollbacker→Config Replacer→Patch ApplierというチェーンがJSON Patchで差分を計算・適用する(既存設定や変更内容によっては動作しない場合もあり、利用前の検証が推奨される)。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] §6.2.1, §6.2.2) SONiCにはClickベースCLIとKlishベースCLIの2種類が併存する。`show`/`config`を軸とするClickベースCLIは初期から存在し公式Wikiのコマンドラインリファレンスの前提でもあるコミュニティ版の事実上の標準で、`sonic-cli`で起動するKlishベースCLIは2019年以降開発が進むCiscoライクな階層的CLIで、SONiC管理フレームワークのREST API経由でCONFIG_DBを操作する。コミュニティ版でのKlishベースCLIのコマンド対応・安定性はClickベースCLIに劣り、商用版(Dell SONiC)で拡張が進んでいる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] §6.3) ## 関連 - 本ソース: [[@2026__MLSys2026__SAKURAONE - An Open Ethernet-Based AI HPC System]] / [[@2023__NSDI__Empowering Azure Storage with RDMA]] / [[@2025__SpeakerDeck__SONiCで800G AECケーブルを検証してみた]] / [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] / [[@2025__SpeakerDeck__SONiCで構築・運用する生成AI向けパブリッククラウドネットワーク]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 1 ホワイトボックススイッチとSONiCアーキテクチャ]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 5 SONiCの入手とインストール]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 6 SONiCの基本操作と設定方法]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 7 SONiCの内部構造：アーキテクチャとサブシステム]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 8 SONiCの内部構造：ステートの流れとモジュール連携]] / [[@2025__Gihyo__実践SONiC入門 - Chapter 10 高度な設定と利用法]] / [[@2025__Gihyo__実践SONiC入門 - Appendix 1 ソースコードからのビルド]] - 採用システム: [[SAKURAONE]] - 採用組織(第2章事例): [[Microsoft]] / [[Alibaba Group]] / [[Target]] / [[eBay]] / [[Google]] / [[Orange S.A|Orange S.A.]] / [[LINE株式会社]] / [[KDDI株式会社]] - 拡張プロジェクト: [[SONiC-DASH]] / [[SONiC-VPP]] / [[PINS (P4 Integrated Network Stack)]] - 関連概念: [[オープンネットワーキング]] / [[CMIS]] / [[AECケーブル]] / [[ホワイトボックススイッチ]] / [[ネットワークオペレーティングシステム]] / [[ネットワーク機器のブートストラップとイメージ配布]] / [[SONiCのモジュール責務分離]] / [[宣言的設定管理]] / [[プログラマブルデータプレーン]] / [[ネットワーク自動化]] / [[ヘルメティックビルド]] / [[データベースを介した疎結合なモジュール連携]] / [[SRv6]] - 関連エンティティ: [[Stratum]] / [[SAI (Switch Abstraction Interface)]] / [[P4Runtime]] / [[gNMI]] / [[ONIE (Open Network Install Environment)]] / [[FRRouting (FRR)]] / [[SONiC管理フレームワーク]] - 関連 MOC: [[Network - MOC]]