# FRRouting (FRR) FRR(FRRouting)は、SONiCのbgpコンテナ(`docker-fpm-frr`)で既定のルーティングエンジンとして動作するオープンソースのルーティングスイートである。オリジナルのソースコードは`https://github.com/FRRouting/frr/`で開発され、SONiC固有のパッチは`sonic-buildimage`リポジトリの`/src/sonic-frr`に配置される。SONiCはFRR以外にもgoBGPを用いた`docker-fpm-gobgp`コンテナ(2020年頃からビルド関連以外の更新なし)や、Juniperの仮想ルーターcRPD・ArrcusのArcOSといった商用ルーティングエンジンへの置き換えにも対応する。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 8 SONiCの内部構造：ステートの流れとモジュール連携]] ch.8 §8.7) ## SONiCとの統合 bgpコンテナで動作するFRR本体のデーモンはzebra(bgpd・staticdが集めたルーティング情報から最適経路を計算し、FRRのForwarding Plane Manager(FPM)経由でデータプレーンへ伝達)・staticd(スタティックルート管理)・bgpd(BGPプロトコルの動作)の3つで、いずれもSONiC固有ではなくFRR自身のデーモンである。SONiC側はfpmsyncd(FPM経由でzebraから受け取った転送情報をAPPL_DBへ反映。swssの一部だがbgpコンテナ内で動作しFRR-SONiC統合の中心を担う)・bgpcfgd(CONFIG_DBをもとにFRRの設定を管理)・bgpmon(BGP関連情報をSTATE_DBへ反映)・staticroutebfd(スタティックルートのBFDセッション作成)という4モジュールでFRRを橋渡しする。起動するモジュールはsupervisordの設定(`docker-fpm-frr/frr/supervisord/supervisord.conf.j2`)により、共通モジュール(fpmsyncd, bgpmon, zebra, staticd, bgpd)に加え、FRR管理フレームワーク利用時はbgpcfgdの代わりにfrrcfgd・bfdd・ospfd・pimdが起動するなど設定に応じて変化する。(Source: ch.8 §8.7.1) BGPが収集したルーティング情報がSwitch ASICへ反映されるまでは、bgpd→zebra→fpmsyncd→APPL_DB→orchagent→ASIC_DB→syncd→SAI APIという経路をたどる(詳細は[[データベースを介した疎結合なモジュール連携]]・[[@2025__Gihyo__実践SONiC入門 - Chapter 8 SONiCの内部構造：ステートの流れとモジュール連携]]を参照)。(Source: ch.8 §8.7.2) ## 設定管理の4モードとFRR管理フレームワーク FRRの設定管理は「設定ファイルが1つかデーモン毎か」と「CONFIG_DBで管理するかしないか」の組み合わせで4モード(separated/unified/split/split-unified)に分かれ、`DEVICE_METADATA`の`docker_routing_config_mode`で選択する。CONFIG_DB管理下(separated/unified)では、初期設定時にsonic-cfggenがJinja2テンプレートから設定ファイルを生成し、設定変更時はbgpcfgdがCONFIG_DBの変更を検知してvtysh経由で反映する。この方式はOSPF等BGP以外のプロトコルが使えない、設定パラメータに制限がある、という欠点を持つ。(Source: ch.8 §8.7.3) **FRR管理フレームワーク**は[[SONiC管理フレームワーク]]の拡張機能として、この欠点を改善する新しい設定管理方式である。`frrcfgd`モジュールがCONFIG_DBを通じてFRRを制御することで、RESTCONF・gNMI・CLIといった共通インターフェースやOpenConfigモデルでの設定管理が可能になり、BGP以外のプロトコルにも対応する(従来のbgpcfgdは起動しない)。CONFIG_DBが設定情報のSingle Source of Truth(SSOT)であるため、設定情報の参照はFRRに直接アクセスせずCONFIG_DBから取得し、状態や統計情報の参照はSTATE_DBを使わずfrrcfgdがFRR(vtysh)から直接取得するという、設定変更・設定参照・状態参照で異なる経路をとる。vtyshへの直接設定はCONFIG_DBに保存されないため、フレームワークが非対応の機能を使う場合を除き推奨されない。(Source: ch.8 §8.7.4, §8.9.5) ## 未解決の問い(備考) - FRR管理フレームワーク導入によりOSPF・BFD等が使えるようになった場合、STATE_DBを経由しないfrrcfgd直接取得という状態参照経路は、SONiCの他機能が前提とする「STATE_DBがオペレーションステートの集約点」という一般則からの例外になる。この例外はSONiC全体の設計にどの程度整合しているか(本書からは読み取れない)。 - コミュニティ版SONiCでのFRR管理フレームワークの成熟度(対応プロトコル範囲、商用版との差)は本書執筆時点でどこまで進んでいるか。 ## 関連 - 実体: [[SONiC]] / [[SONiC管理フレームワーク]] - 概念: [[データベースを介した疎結合なモジュール連携]] - ソース: [[@2025__Gihyo__実践SONiC入門 - Chapter 8 SONiCの内部構造：ステートの流れとモジュール連携]] ## 出典 - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第8章 §8.7〜§8.7.4, §8.9.5.