コミュニティSONiCを仮想・実機で検証してみた

コミュニティSONiCを仮想・実機で検証してみた

国立研究開発法人情報通信研究機構
一関工業高等専門学校
青木汰一

SONiC Workshop Japan 2026
https://sonic.connpass.com/event/385386/

Transcript

1. コミュニティ SONiC を仮想・実 機で検証してみた Containerlab と DELL S5232F / S5296F による Leaf-Spine 検証 青木 汰一（NICT / 一関工業高等専門学校） 2026-06-19
2. 発表後の修正履歴 発表時資料 (コミュニティ SONiC を仮想・実機で検証してみた-発表前資料.pdf) から本版で変更した主な点 該当箇所 修正内容 本編「性能ざっくり」 BGP 行 旧「BGP 経路 10,000 件投入 126.5 秒」(spine1 bgpcfgd 律速 + 固定 sleep を含む) を破棄し、 sv001 gobgp による cold-start 計測値「10K = 2.7 秒 / 100K = 16.8 秒」に置換 (詳細 A.37) E-3 / A.13 / A.14 (VLAN 大量作成時の挙動) 追加検証で測定方法を見直し、結果で全面書き換え。 (1) 中央値: 旧「N=2000 で 505 ms / N 依存増分 +361 ms」(sonic-db-cli を 1 件ずつ呼び出すオーバーヘッド 込み) → 新「131 ms / N 依存増分 +34 ms」(swsscommon を直接呼ぶ方式) に更新 (2) 機構: 「kernel netdev 作成パスが O(N)」(旧、未特定) → 「iproute2 /sbin/bridge の ll_init_map が全 N netdev DUMP」(直接観測で確定) に変更 A.34 / A.35 / A.36 (新設) VLAN 大量作成時の追加調査: 2 経路の機構整理 / 一括投入後の安定時間 (真の残処理完了 = 区間 [192, 200] 秒) / 検証手段とエビデンス (bpftrace / 経路分離実験 / 待ち時間の総当たり計測) A.37 (新設) BGP スケール cold-start 再計測 (sv001 gobgp 経由、neighbor 接続を遅延させて事前投入による汚染を除去)。 100K route まで FIB 完了 2
3. 自己紹介 青木 汰一 (Aoki Taichi) • NICT サイバーセキュリティ研究所 サイバーセキュリティネ クサス ‣ CYNEX 研究開発運用室 リサーチアシスタント • 一関工業高等専門学校 システム創造工学専攻 普段の業務: CYNEX で使用する機材の検証 直近の活動: Interop Tokyo 2026 (6/6〜6/12) で ShowNet Team Member (STM) として参加 @aoki-taquan 3
5. 目次 1. 検証の動機 2. コミュニティ版 vs 商用版／用語 3. 検証環境 ― 仮想 (Containerlab) と 実機 (DELL Leaf-Spine) 4. どれぐらい使えるか 5. 踏んだ落とし穴 5 件 • VXLAN 越し不通 • VNI 上限 • HW BFD • 設定永続化 • VLAN 作成時間 6. まとめ ※ 詳細は本編後の付録で補足 5
6. 1. 検証の動機
7. なぜこの検証をやったのか 動機 1 既存スイッチの 延命 保守切れ機材を コミュニティ NOS で 継続管理したい 動機 2 新規調達コストの圧縮 ホワイトボックス＋OSS で ベンダー商用 NOS の ライセンス費を抑えたい → 「コミュニティ版でどこまで運用できるか」を確かめたかった 7
8. 2. コミュニティ版 vs 商用版 ／用語
9. コミュニティ版 vs 商用版 4 レイヤで差が出る (Dell / Broadcom Enterprise SONiC 等) • ① ビルド構成: INCLUDE_ICCPD / INCLUDE_STP 等の flag → MC-LAG / STP / EVPN-MH の有無 • ② SAI driver: Community vs Enterprise → VNI 128 / Tunnel 5 などのスケール上 限 • ③ SAI 同梱 uKernel app: BFD / OAM 等 → 非同梱なら HW offload BFD 不可 • ④ 商用付加: SLA / ハード認定 / 独自管理拡張 9
10. 今日出てくる用語のミニ集 用語 ざっくり意味 EVPN / VXLAN L2 を L3 越しに運ぶオーバーレイ。BGP で MAC/IP を広告 SAI スイッチ機能を共通 API 化した抽象層。ASIC SDK の上 orchagent / syncd SAI 経由で ASIC を叩く SONiC のコア (SWSS) CONFIG_DB / STATE_DB Redis 上の「設定 DB」/「状態 DB」 bgpcfgd / frrcfgd CONFIG_DB → FRR 設定への変換役 (排他で 1 つ動く) vtysh FRR (BGP/BFD 等) の対話 CLI 10
11. 3. 検証環境
12. 仮想 (Containerlab) ― 手順確立の場 • 投入手順・テストは仮想で固めてから実機に持ち込む • Containerlab + sonic-vs (vrnetlab/sonic_sonic-vs:2025_9_16_master) • マルチベンダー: Cisco NX-OS 9000v、Juniper cJunos Evolved • pytest + SSH で全部スクリプト化、--env=clab / --env=physical で同じテストを両 環境で実行 • 実機側では実 ASIC・実 NIC でしか取れない値 (ライン性能 / TCAM / コンバージェン ス) を追加 • 詳細は付録 A.18〜A.20 12
13. 実機: DELL Leaf-Spine 4 台 Spine × 2 — DELL S5232F-ON • 32 × 100G QSFP28 • Spine 間 iBGP (PortChannel 31) Leaf × 2 — DELL S5296F-ON • 96 × 25G SFP28 + 8 × 100G サーバ × 3: sv001 / sv002 / sv003 • NIC は 10G (ASIC ライン性能ではなく E2E 評価) ビルド: SONiC 202505.990579-61784b174 SAI: 13.2.1.14 / SDK: 6.5.32-SP2 13
14. 4. どれぐらい使えるか
15. 使える側 (主な OK 機能) 領域 OK だったもの L2 VLAN、LAG/LACP、Storm-control、MAC 学習 L3 eBGP/iBGP、Static、ECMP、VRF、BGP Unnumbered EVPN/VXLAN Type-2/3/5、Symmetric IRB、Distributed GW、SAG マルチベンダー SONiC ⇄ NX-OS ⇄ cJunos の EVPN 経路交換 + 疎通 ACL/QoS/監視 ACL、CoPP、Mirroring、SNMP、gNMI、GCU、CRM HA (一部) Link Damping、Cold Reboot、Auto-techsupport 15
16. 使えない / 条件付き側 (要注意) 機能 判定 ひとこと VXLAN 越し 条件付 config.bcm 修正が必須 VNI / VXLAN Tunnel 上限 128 / 5 Community SAI ライセンス制限 VLAN 大量作成 (1K+) 条件付 既存 VLAN 数に応じて 1 個あたりの作成が遅くなる、4000 で約 14 分 HW offload BFD NG show bfd peer は常に空 MC-LAG / STP / EVPN-MH NG community ビルドの flag で除外 Warm/Fast Reboot (VXLAN) NG buildimage #22560 EVPN/BFD/GR の永続化 条件付 bgpcfgd モードでは消える OSPF neighbor NG default CoPP に OSPF trap 無し (A.27) 16
17. 性能ざっくり (Dell S5296F / BCM TD3) RTT (avg) • 同一 Leaf: 0.169 ms / Underlay: 0.245 ms • VXLAN 越し: 0.337 ms（encap +0.17 ms） コンバージェンス • BGP 経路追加 → Spine 伝搬: 2.2 秒 • BGP cold-start 受信 (sv001 gobgp → leaf1): 10K = 2.7 秒 / 100K = 16.8 秒 (詳細 A.37) • VLAN 4,000 作成: 835 秒 (E2E、詳細 E-1) ※ 物理トラフィックジェネレータ未使用。ping / iperf3 等の ソフトウェア計測 による値 17
18. 5. 踏んだ落とし穴
19. A-1: VXLAN 越しの ping が通らない 症状: EVPN Type-2/3/5 経路は飛んでいるのに VXLAN 越しの ping が 100% loss (同一 Leaf や Underlay は OK) 探索の旅 — 排除した仮説 • encap MAP_ENTRY 欠落 → Broadcom SAI が内部対応 (シロ) • ASIC_DB FDB / TUNNEL / BRIDGE_PORT 不正 → 全て正常 • カーネル bridge FDB 空 → ASIC offload では仕様 • CoPP ARP trap / 物理ケーブル誤接続 → 全て正常 19
20. A-2: 真因は config.bcm の 2 行欠落 決定打 — bcmcmd で BCM ハードウェア直視 ING_L3_NEXT_HOP[0].DROP = 1 （Policy Discard で 全 DROP） 回避: config.bcm に • l3_ecmp_levels=2 • host_as_route_disable=1 を追記して cold reboot （初回 reboot で L3 が壊れる初期化タイミング問題 あり、 2 回目で安定） 20
21. B-1: VNI を増やすと orchagent がクラッシュループする 症状 • 130 個目の VNI 投入で orchagent SIGABRT クラッシュループ • syncd がフリーズし他の SAI 操作も止まる 探索の旅 — 排除した仮説 • 投入順タイミング起因説 → VLAN 500 先入れしても 128 で頭打ち • config.bcm パラメータ不足説 → buildimage #8371 の全パラを揃えても同じ • SAI バイナリの動的ライセンス制限説 → BCM SAI に該当機構なし (Community と Enterprise は別バイナリ) • ASIC テーブル自体は受けてる: 130 投入で VLAN_XLATE_1=134、 データプレーンも 128 超で動作 21
22. B-2: bcmsai scaletrack で確認できる SAI SDK 上限 Dell S5296F (BCM56870 / Trident 3) 実機での Community SAI SDK 上限 ID リソース（運用上の意味） 上限 3 VXLAN Tunnel — 自 Leaf から見たリモート VTEP ピア数 5 4 VXLAN VLAN-VNI Map — L2 テナント数 (VLAN ↔ VNI) 128 5 VXLAN VRF-VNI Map — L3 テナント数 (VRF ↔ VNI, L3VNI) 64 2 VXLAN Tunnel Map — 上記マップを束ねる親オブジェクト 128 1 Tunnel Next Hop — ECMP の VXLAN パス数 1,024 6 IP-in-IP Tunnel 513 7 Tunnel Loopback 5 8 Counter — ユーザー定義 SAI カウンター 4,096 ASIC 物理上限ではなく Community SAI SDK のソフトウェア上限 （Enterprise SAI で拡張、例: VLAN-VNI 4K+ / Tunnel 512） 22
23. B-3: Broadcom 公式立場とクラッシュ連鎖 Broadcom 公式立場 ( buildimage #17763 への adyeung 回答、原 issue は Tunnel 5 制限 につ いての質問) •“VxLAN scaling is limited with the public domain SAI binary. Please reach out to your business partner for licensing options.” VNI 128 到達時のクラッシュ連鎖 (本検証で実測) • SAI_STATUS_TABLE_FULL → orchagent が 永続エラー扱いせず無限リトライ • syncd 占有 → 他 SAI 操作が 60 秒タイムアウト → abort() → SIGABRT • Enterprise SAI では 4K+ VNI / 512 Tunnel まで拡張されている 23
24. C-1: show bfd peer が常に空 症状: SONiC CLI の show bfd peer / show bfd summary が 常に空表示 • ただし BFD ピア自体は動作している（BGP も BFD タイマで切替確認） 当初仮説: frr_mgmt_framework_config=false が原因？ → 的外れ 4 段階の検証 — どこに投入しても SONiC CLI には現れず 1. frrcfgd モードに切替 + BFD_PEER_SINGLE_HOP 投入 2. CONFIG_DB の BFD_SESSION に直接投入 3. APPL_DB BFD_SESSION_TABLE に直書き 4. STATIC_ROUTE bfd=true（staticroutebfd 起動） → 次スライドで構造、その次で決定打 24
25. C-2: SONiC の BFD は独立した 2 経路 設計の穴 • SAI HW 不在時、orchagent は software fallback を選ん で 別テーブル BFD_SOFTWARE_SESSION_TABLE に書込 • しかし show bfd peer は HW 用テーブルのみ参照 → fallback は CLI に反映されない • 報告: utilities #4139 (Open) — 関連: swss #4511 / #4513 (software_bfd 設定強制) 未確認の橋渡し • BFD HW Offload HLD では bgpcfgd BfdMgr が fallback → FRR bfdd へ 橋渡しする想定。本検証では未確認 25
26. C-3: 真因は uKernel BFD app の非同梱 決定打 — docker exec syncd bcmcmd 'bfd init' 0:bcmi_xgs5_bfd_init: uKernel BFD application not available Command failed. Feature unavailable 真因 • Trident 3 は BFD を ASIC 内 uKernel app で動かす設計 • Community SAI には uKernel BFD バイナリ非同梱 （Enterprise SAI ライセンスでの み提供される） • 同症状: buildimage #22624 (Cisco T2)、 #18012 (Dell S6100) • FRR bfdd 経路 (vtysh) では BFD ピア up が観測できる 26
27. D-1: EVPN/BFD/GR が再起動で消える 症状 • docker restart bgp で advertise-all-vni / neighbor X bfd / graceful-restart が すべて消失 • クラッシュからの自動復旧時にも同じ 真因 • bgpcfgd の Jinja2 テンプレートにこれらのスキー マが 無い • CONFIG_DB → bgpd.conf の自動生成経路に乗らない • 手動 vtysh 投入分は docker restart bgp で sonic- cfggen が bgpd.conf 再生成 → 消失 27
28. D-2: frrcfgd 切替の副作用 回避 (根本解): frr_mgmt_framework_config: true で frrcfgd 切替 • 永続化 OK (実機確認): ✅ EVPN ✅ BFD ✅ GR ✅ ピア up • ospfd / pimd / pathd も自動起動 が、副作用が大きい • 自動生成されていた FROM_BGP_PEER_V4、RM_SET_SRC 等の route-map が 消える → ebgp- requires-policy で経路全フィルタ • 結果: BGP は Established、しかし VXLAN ping 100% loss 解決: route-map を ROUTE_MAP_* へ手動移行 / 退路: false で復帰 28
29. E-1: VLAN 4000 作成に 14 分 症状 (CONFIG_DB → ASIC 全パイプライン実測) VLAN 数 CONFIG_DB 投入 orchagent → ASIC 完了 E2E (削除待ち含む) 100 5.7s 1.0s 14s 1,000 25s 18s 144s 4,000 100s 239s 835s (14 分) 4000 VLAN 全件 ASIC 投入は成功 — 機能としては動く ただし運用上「テナント追加で 14 分待ち」は運用上厳しい ※ 上記実時間は測定スクリプト (sonic-db-cli を 1 件ずつ呼び出し、python 起動 200ms × N) 込みの値。別方式 (swsscommon を直接呼ぶ) で再 計測した per-VLAN 中央値は 131 ms (既存 VLAN 数 N=2000、200 サンプル、平均値は 363 ms で外れ値が支配)。 「orchagent → ASIC 完了」列の 239s は per-VLAN orchagent 同期の累積。 「E2E (削除待ち含む)」列の 835s はそれに加え一括投入後の処理滞留 (A.35: 区間 [192, 200] 秒) と削 除待ちを含む。詳細は付録 A.13 / A.14 / A.34 / A.35 29
30. E-2: VLAN 生成パイプライン VLAN 1 個追加が 2 プロセスを直列 で経由 1. vlanmgrd (VlanMgr::doVlanTask) • CONFIG_DB を subscribe • /sbin/ip link add ... type vlan を exec → kernel が netdev 作成 + RTM_NEWLINK broadcast • 続いて /sbin/bridge vlan add も exec (← 次スラ イド E-3 の主因) • 同期完了後 APPL_DB.VLAN_TABLE に書込 2. orchagent (PortsOrch::doVlanTask) • APPL_DB を subscribe • sai_create_vlan() → syncd → ASIC 並列ではなく直列。kernel の ip link 同期完了まで orchagent は動かない 30
31. E-3: 主因は /sbin/bridge の ll_init_map per-VLAN time の N 依存 (中央値) • N=2 → 98 ms ／ N=2000 → 131 ms = +34 ms 増大 • 平均値は N=2000 で 363 ms (一部の VLAN 追加が 1〜30 秒まで極端に遅くなる) 子プロセス 1 個あたりの実時間 を bpftrace で実測 子プロセス N=2 N=2000 Δ /sbin/bridge 3.4 ms 35.4 ms +30.9 ms (×9) /sbin/ip 6.1 ms 11.1 ms +4.8 ms 機構 (iproute2 bridge/vlan.c do_vlan() 1 行目) • ll_init_map() = iproute2 コマンドが起動時に kernel から全 netdev リストを取得する関数 (2.9 KB × N の RTM_GETLINK 応答) • vlanmgrd が VLAN ごとに /sbin/bridge を fork+exec → 子プロセスが ll_init_map で全 N netdev DUMP → N に比例 ※ kernel register_netdevice per-call は 0.33 ms/VLAN 一定 (N 依存増分 Δ +30.9 ms の約 1%)。主因は /sbin/bridge 子プロセス起動の処理時間 (+30.9 ms/VLAN の N 依存増分を直接観測) 31
32. 6. まとめ
33. 検証からわかったこと 普通に動いたもの • EVPN Type-2/3/5、Symmetric IRB、SAG、ECMP、BGP 基本機能 • SONiC ⇄ NX-OS ⇄ cJunos のマルチベンダー相互接続 挙動が微妙だったもの • VXLAN 越し: config.bcm 修正しないと不通 (本編 A) • EVPN/BFD/GR: bgpcfgd モードでは BGP 再起動で消失 (本編 D) • VLAN 4000: 作れるが 14 分かかる (本編 E) • CoPP: フレームワークは動くが default rule に穴 (OSPF 不通 等) 動かなかったもの • VNI 128 / Tunnel 5 を超えると orchagent SIGABRT (本編 B) • HW offload BFD (本編 C) / MC-LAG / STP / EVPN-MH • VXLAN 環境での Warm / Fast Reboot • 一部の show / config CLI が信用できない （付録 A.18〜A.20） 33
34. 個人的な宣伝: SONiC 非公式ドキュメント aoki-taquan.github.io/sonic-unofficial- docs/ • SONiC は HLD・実コード・CLI・Issue に情報が分散し ていて欲しい情報を一発で引きづらい • トピック単位で 1 ページに集める日本語サイトを AI に書かせて運営中 • ベースは SONiC master の 2026-05-09 時点 のスナッ プショット (随時作成中) • 各ページに参照元 (HLD / 実コード / Issue) を添付。 正確性が必要な場合はそちらを参照 • 誤り・ご意見は Issue 歓迎 ※ AI 生成で個人で作っています。記載内容の正確性 は保証しません
35. ご清聴ありがとうございました
36. Appendix（付録）
37. A.1 HW-Bug 一覧 (1〜10) ID 事象 重大度 関連 HW-Bug-1 S5296F chassis.py PORTS_IN_BLOCK (thermalctld ク ラッシュ) Critical #7644 類似 HW-Bug-2 config.bcm RIOT 欠落 → VXLAN 越し不通 Critical 本編 A 章 HW-Bug-3 VNI 128 制限 (Community SAI) 高 #22296 / #17763 HW-Limit-4 bgpcfgd で EVPN/BFD/GR 非永続化 中 #12370 HW-Bug-5 orchagent port_state_change TUNNEL 非対応 中 #10004 / swss#3383 Merged HW-Bug-6 show vxlan tunnel に EVPN 学習 VTEP 非表示 中 #9028 HW-Bug-7 SAI_STATUS_TABLE_FULL 無限リトライ → SIGABRT 中 #2125 HW-Bug-8 syncd 単独再起動でカウンター凍結 中 swss restart 必須 HW-Note-9 BFD ピア down 時 BGP ブロック (FRR 仕様) 運用注意 両端揃え HW-Bug-10 VlanOrch SAI bulk 未使用 (O(n) 劣化) 低 本編 E 章 37
38. A.2 HW-Limit 一覧 (11〜16, community ビルド固有) ID 事象 重大度 回避 / 解消 HW-Limit-11 ERROR_DB 本ビルドで未定義 中 syslog + STATE_DB 代替 HW-Limit-12 MC-LAG / ICCPd 不在 (INCLUDE_ICCPD=n) 中 Enterprise / 再ビルド HW-Limit-13 EVPN-MH (Type-1/4) orchagent 未統合 中 bgpd syntax は受理 HW-Limit-14 Static Route + BFD HW path 不在 中 HW-Limit-16 共通因 HW-Limit-15 STP INCLUDE_STP default 未設定 低 再ビルドで解消 HW-Limit-16 Community SAI に uKernel BFD app 非同梱 中 #22624 / #18012 38
39. A.3 性能データ — 実測値全件 スループット (サーバ NIC 10G 上限、ASIC 性能ではない) 経路 実測 備考 同一 Leaf L2 転送 9.41 Gbps サーバ NIC 10G 上限 同一 Leaf L3 Inter-VNI 9.41 Gbps VXLAN 越し TCP (4 並列) 9.42 Gbps retransmit 少 VXLAN 越し UDP 3.34 Gbps ロス 0.02% VXLAN 越し Jumbo (9216B) 5.09 Gbps フレームサイズ別 UDP — 64B: 0.06 / 128B: 0.20 / 256B: 0.57 / 512B: 1.23 / 1518B: 1.98 / 9216B: 5.09 Gbps RTT (min/avg/max ms): 同一 Leaf 0.1140.399、 Underlay 0.1390.925、VXLAN 0.1510.473 UDP Jitter 0.8 μs / Loss 0% (1000 pkt ping) 39
40. A.4 【A 補足】排除した 6 つの仮説 VXLAN 越し不通の原因として検証し 否定 した仮説一覧 仮説 検証結果 encap TUNNEL_MAP_ENTRY 欠落 Broadcom SAI が内部で対応 (swss #2042) ASIC_DB FDB / TUNNEL / BRIDGE_PORT 不正 全て正しくプログラム済 カーネル bridge FDB 空 ASIC offload モードでは仕様で空 CoPP ARP trap 未設定 installed 済、原因ではない 物理ケーブル誤接続 LLDP + SAI カウンターで全リンク確認 config.bcm RIOT パラメータ不足 (PR #18505 適用後) decap MAP_ENTRY は正常作成。だが症状継続 → 別パラ欠落が真 因 → bcmcmd でハードウェアテーブル直視に進む（次スライド） 40
41. A.5 【A 補足】bcmcmd で見た ASIC テーブル oper_down 状態で 不完全にプログラム されていたエントリ テーブル 期待値 実際 影響 VLAN_TAB[100].VIRTUAL_PORT_EN 1 0 VFI 未接続 VLAN_TAB[100].VFI 100 0 VXLAN forwarding 不可 ING_L3_NEXT_HOP[0].DROP 0 1 PDISC で全 DROP ASIC_DB ROUTE 10.255.1.2 NH valid ECMP oid:0x0 NULL NH EGR_VLAN_XLATE_1_SINGLE VFI→VNI 有 有 (VFI=100→VNI=10100) encap 側は正常 L2MC flood groups VP メンバー 空 BUM flood 不可 決定的証拠: ING_L3_NEXT_HOP[0].DROP=1 で全 VXLAN パケットが PDISC ドロップ。 RDBGC0 BITMAP=0x800 (bit 11 = PDISC) で確認。 41
42. A.6 【A 補足】BCM 手動 NH 修正で 3/10 パケット到達 実証: ASIC ハードウェアが動くこと自体は問題ない、 config.bcm 不足で SAI が NH を正しくプログラム できていない と確定 手動コマンド bcmcmd 'ING_DVP_TABLE[6].ECMP=0, NEXT_HOP_INDEX=2' (spine2 方向 NH に手動上書き) 結果 • sv001 ping → sv002: 10 パケット中 3 パケット到達 • orchagent が周期的に table を re-sync して DROP NH に戻すため完全には通らず • だが ASIC 自体は VXLAN encap/decap 動作可能 と実証 これにより「真因は SAI 上流（config.bcm パラメータ不足） 」と確定し、 最終的に l3_ecmp_levels=2 / host_as_route_disable=1 の 2 行追記に至った 42
43. A.7 【B 補足】bcmsai scaletrack summary 出力 drivshell> bcmsai scaletrack summary type name max used free 1 _BRCM_SAI_SCALE_TYPE_MPTNL_TNL_NH 1024 N/A N/A 2 _BRCM_SAI_SCALE_TYPE_MPTNL_VXLAN_TNL_MAP 128 N/A N/A 3 _BRCM_SAI_SCALE_TYPE_MPTNL_VXLAN_TNL 5 1 4 4 _BRCM_SAI_SCALE_TYPE_MPTNL_VXLAN_VLAN_VNI 128 2 126 5 _BRCM_SAI_SCALE_TYPE_MPTNL_VXLAN_VRF_VNI 64 0 64 6 _BRCM_SAI_SCALE_TYPE_MPTNL_IPIP_TNL 513 1 512 7 _BRCM_SAI_SCALE_TYPE_MPTNL_TNL_LPBK 5 0 5 8 _BRCM_SAI_SCALE_TYPE_COUNTER 4096 0 4096 ID=4 の累計使用 (aggr-used) は 332 — つまり 332 エントリ投入を試行 したが SAI SDK が 128 でブロッ クした証拠 ASIC 物理テーブル (VLAN_XLATE_1_DOUBLE: 16K) は余裕あり 43
44. A.8 【B 補足】ASIC は 130 でも受けている 130 VNI を投入した状態の ASIC 物理テーブル (bcmcmd で実測) テーブル 実測値 意味 VLAN_XLATE_1 134 VXLAN decap mapping 134 エントリ書き込み済 VFI 138 Virtual Forwarding Instance 138 個 データプレーン 動作 128 超の VNI でも実際に転送される 結論: SAI の OID 管理テーブル（ライセンスで絞られている層）だけが SAI_STATUS_TABLE_FULL を返している。 → ASIC テーブル容量は問題なし、SAI SDK の意図的制限が単一原因 44
45. A.9 【C 補足】BFD 5 段階検証コマンド Step 投入コマンド 結果 1 sonic-db-cli CONFIG_DB hset DEVICE_METADATA|localhost frr_mgmt_framework_config true + docker restart bgp frrcfgd 起動 OK / vtysh -c 'show bfd peers' ピア up / SONiC CLI 依然空 2 sonic-db-cli CONFIG_DB hmset 'BFD_SESSION|default|10.0.2.0| 10.0.2.1' tx_interval 300 ... bfdcfgd 不在で APPL_DB / STATE_DB に伝播なし 3 sonic-db-cli APPL_DB hmset 'BFD_SESSION_TABLE:default:10.0.2.0:10.0.2.1' ... + publish orchagent が ProducerStateTable 経由でないと反応せず、無反 応 4 sonic-db-cli CONFIG_DB hmset 'STATIC_ROUTE|10.99.99.0/24' nexthop 10.0.1.0 ifname Ethernet96 bfd true staticroutebfd → APPL_DB → orchagent → STATE_DB BFD_SOFTWARE_SESSION_TABLE 書込 (software fallback)、しかし show bfd peer 用の HW テーブルは空 5 docker exec syncd bcmcmd 'bfd init' uKernel BFD application not available / Feature unavailable — 決定打 45
46. A.10 【C 補足】SONiC コード抜粋 orchagent bfdorch.cpp の offload_supported() status = sai_query_attribute_capability( gSwitchId, SAI_OBJECT_TYPE_SWITCH, attr.id, &capability); if (!capability.get_implemented) { SWSS_LOG_NOTICE("BFD offload type not implemented"); return false; // ← 本機ではここに入る } // ... if (use_software_bfd) { m_stateSoftBfdSessionTable->set(createStateDBKey(key), data); // ← BFD_SOFTWARE_SESSION_TABLE に書く（HW 用ではない） } show/main.py の bfd summary bfd_keys = db.db_clients[namespace].keys(db.db.STATE_DB, "BFD_SESSION_TABLE|*") # ← HW 用テーブルのみ参照、SOFTWARE_SESSION_TABLE は読まない 46
47. A.11 【D 補足】frrcfgd 切替後 running-config router bgp 65201 bgp router-id 10.255.1.1 neighbor 10.0.1.0 remote-as 65100 neighbor 10.0.1.0 bfd ← 永続化 ✓ neighbor 10.0.1.0 update-source 10.0.1.1 address-family ipv4 unicast network 10.255.1.1/32 neighbor 10.0.1.0 activate neighbor 10.0.2.0 activate exit-address-family address-family l2vpn evpn ← 永続化 ✓ neighbor 10.0.1.0 activate neighbor 10.0.2.0 activate advertise-all-vni ← 永続化 ✓ exit-address-family BGP 2 セッション Established / BFD 2 ピア Up / EVPN Type-2 4 prefixes 確認 → docker restart bgp 後も全て保持されることを確認 47
48. A.12 【D 補足】bgpcfgd で生成され、frrcfgd で消えるもの bgpcfgd で自動生成 frrcfgd 切替後の影響 bgp suppress-fib-pending FIB install 待ちなしで即広告 (影響小) no bgp ebgp-requires-policy 無いと FRR 10.x がデフォルト有効化 → eBGP 経路全フィルタ bgp bestpath as-path multipath-relax 異 AS-path での ECMP が効かない ip prefix-list / route-map FROM_BGP_PEER_V4 eBGP ポリシ不在 → 経路受信不可 → VXLAN ping 100% loss ip protocol bgp route-map RM_SET_SRC FIB 送信元 IP が Loopback0 にならない bgp community-list community ベースフィルタ不可 neighbor PEER_V4 soft-reconfiguration inbound soft-reset 用 Adj-RIB-In 未保存 解決には ROUTE_MAP / ROUTE_MAP_SET / ROUTE_MAP_MATCH 各テーブルに手動移行が必要 48
49. A.13 【E 補足】VLAN 1 個追加の実時間内訳 ユーザ側の実時間 内訳 [VLAN 追加 1 個分の実時間] ├ python db.set (CONFIG_DB 投入) ~1 ms ├ vlanmgrd: /sbin/ip link add (exec 含む) N=2: 6.1 ms / N=2000: 11.1 ms ├ vlanmgrd: /sbin/bridge vlan add (exec 含む) N=2: 3.4 ms / N=2000: 35.4 ms ★ │ └ 子プロセスの ll_init_map() が全 N netdev DUMP (+30.9 ms/VLAN) ├ orchagent: APPL_DB → sai_create_vlan → ASIC 1〜8 ms (一定) └ 別経路の非同期処理 (ユーザ側の実時間 外) +156 ms CPU/VLAN (zebra→FPM→fpmsyncd nl_cache_refill) 2 経路の見え方 • 直接見える: /sbin/bridge +30.9 ms + /sbin/ip +4.8 ms = +35.7 ms/VLAN @ N=2000 • 非同期で system load: fpmsyncd nl_cache_refill +156 ms CPU/VLAN (vtysh no fpm address で消える) 49
50. A.14 【E 補足】per-VLAN レートと daemon 停止比較 200 個ずつ追加して N に対する変化を観測 — 中央値 vs 平均値で挙動が違う 条件 N=2 中央値 N=2000 中央値 Δ 中央値 Δ 平均値 基準 (全 daemon ON) 98 ms 131 ms +34 ms +229 ms fpm + zebra 停止 82 ms 123 ms +41 ms +52 ms bgp container 全停止 57 ms 94 ms +37 ms +62 ms 2 種類の効果 • N 非依存の固定処理時間: 基準 98 ms → bgp 全停止 57 ms = −41 ms 削減 • N に依存する増分: 中央値で +34〜+41 ms の幅、daemon 停止しても傾きは変わらず 中央値 vs 平均値の乖離 • N=2000 で 一部の VLAN 追加が 1〜30 秒まで極端に遅くなる • 平均値 363 ms (中央値 131 ms) の差はこの遅い外れ値の影響、fpmsyncd / zebra 停止で大幅縮小 (Δ 平均: +229 → +52 ms) 50
51. A.15 bgpcfgd vs frrcfgd の仕組み SONiC の BGP 設定管理デーモンは 2 種類が排他で動く • bgpcfgd (デフォルト): CONFIG_DB 監視が限定的。EVPN/BFD/GR は Jinja2 テンプレに含まれず → vtysh 投入のみ → BGP 再起動で消失 • frrcfgd: DEVICE_METADATA|localhost|frr_mgmt_framework_config: true で起動。CONFIG_DB から EVPN/BFD/GR 全て生成 可能 bgpd.conf 生成フロー (BGP コンテナ起動時) 1. sonic-cfggen が CONFIG_DB + Jinja2 から初期 bgpd.conf を生成 2. bgpd がそれを読込 3. bgpcfgd / frrcfgd が CONFIG_DB 変更を監視 → vtysh で FRR に反映 → vtysh 投入が消えるのは 1. で再生成されるため (定期上書きではない) device_type も独立軸: ToRRouter は bgp graceful-restart 自動付与、 SpineChassisFrontendRouter は l2vpn evpn が bgpcfgd テンプレに含まれる例外 51
52. A.16 マルチベンダー相互接続 構成: SONiC (実機 Leaf) ⇄ NX-OS 9000v ⇄ cJunos Evolved (clab) • sv003 (Ubuntu 24.04) 上で clab に NX-OS / cJunos を起動 • 物理 Spine の Ethernet128 経由でブリッジ接続 検証範囲 (ASIC 同士の相互接続ではない) • BGP L2VPN EVPN セッション確立 • Type-2 / Type-3 / Type-5 経路の相互広告 • Spine1 shutdown 時のフェイルオーバー • Leaf → 仮想 Leaf 配下のデータプレーン疎通 結果: 仮想 34 / 実機 84 テスト全 Pass。コントロールプレーン ＋ E2E 疎通レベルで相互運用性を確認 52
53. A.18 CLI ギャップ集 (SONiC CLI 不在 → 代替) 欲しいコマンド 回避策 関連 config interface description sonic-db-cli CONFIG_DB HSET 直 #16443 config acl add rule sonic-db-cli 直接 utilities#2550 config interface mtu (PortChannel) sonic-db-cli 直 #6430 show bgp l2vpn evpn summary vtysh -c '...' show bfd peer / summary vtysh -c 'show bfd peers' HW-Limit-16 (本編 C) show interfaces loopback show ip interface で代替 show mclag mclagdctl dump state (ただし HW-Limit-12 で機能不在) show qos * このビルドに不在 → CONFIG_DB / ASIC_DB 直接 show buffer pool show buffer information / configuration 53
54. A.19 show interfaces 系の落とし穴 コマンド 症状 回避策 show interfaces status EEPROM 権限で intfutil クラッシュ sudo 必須 同上 (S5296F) chassis.py バグ (HW- Bug-1) でクラッシュ ip link show / ip -br link show show interfaces transceiver eeprom / lpmode sfpshow / sfputil が sonic_platform に依存し クラッシュ sudo + ホスト側に whl 手動 install show interfaces transceiver presence 全 104 ポートが Not present と嘘表示 リンク状態は show interfaces status か ip link show show platform psustatus / fan / temperature / syseeprom S5296F で ModuleNotFoundError: 'sonic_platform' whl をホスト OS にも pip install / IPMI 経由 監視に逃げる 54
55. A.19 (続き) show コマンド系の落とし穴 コマンド 症状 回避策 show interfaces counters 出力列幅可変でパース不安定 SAI カウンター直読み (COUNTERS_DB) show ip interface Vlan100 No such command "Vlan100" 引数なしで全件 → grep show interfaces loopback このビルドに不在 show ip interface で代替 show lacp counters teamshow 出力が空 show interfaces portchannel show bfd peer / summary 常に空 (HW-Limit-16) vtysh -c 'show bfd peers' show qos * / show buffer pool サブコマンド一切不在 CONFIG_DB / ASIC_DB 直接 show mclag コマンド不在 (HW-Limit-12) sonic-db-cli CONFIG_DB hgetall 'MCLAG_DOMAIN\|*' show evpn es 受理されるが常に空 (HW-Limit-13) —（EVPN-MH 未統合） 55
56. A.20 その他 CLI / 設定の罠集 罠 詳細 T0/T1 テンプレ IP 全物理ポートに 10.0.0.x/31 自動付与 → Ethernet0 is a router interface! で VLAN add 不 可。config interface ip remove で IP 削除してから VLAN メンバー追加 S5296F ポート stride=1 物理ポート 2 = Ethernet1（S5232F は stride=4 で Ethernet4） 。結線表の Eth4 表記は S5296F では誤り CONFIG_DB key の大文字小文字 BGP_GLOBALS_AF\|default\|ipv4_unicast は 小文字必須。大文字だとテンプレが空で render さ れ neighbor activate 消失 サーバ側 ARP flux sv001 で同一サブネット NIC 2 枚 → arp_ignore=1 / arp_announce=2 必須、未設定だと VXLAN 転送不可 EVPN Route Reflector route-reflector-client は iBGP のみ。eBGP underlay では Spine RR 不可、Leaf で advertise-all-vni する 56
57. A.20 (続き) 設定コマンドの罠集 罠 詳細 config vxlan map add vtep 引数は VLAN 名 (Vlan100) ではなく VLAN ID (100) show vxlan tunnel destination 静的設定のみ表示。EVPN 学習 VTEP は show vxlan remotevtep か vtysh -c 'show evpn vni' show bgp l2vpn evpn route type macip detail FRR 10.3 で % Unknown command。detail を外す config route add/delete FRR への反映が不安定。vtysh -c 'ip route ...' 直接が確実 config acl add rule サブコマンド不在。sonic-db-cli CONFIG_DB hmset 'ACL_RULE\|...' で直 接 config interface description サブコマンド不在。sonic-db-cli CONFIG_DB HSET で直接 show feature status feature flag があっても container 不在の場合あり (MC-LAG / STP 等)。docker ps \| grep で実体確認 57
58. A.21 関連リンク集 本編で引用した upstream issue • VXLAN scaling: buildimage #17763 / #22296 / #8371 • HW BFD 非対応: #22624 (Cisco T2) / #18012 (Dell S6100) / utilities#4139 (CLI 観測ギャップ) • Warm/Fast Reboot in VXLAN: #22560 • VXLAN encap map / TUNNEL state: swss#2042 / buildimage#10004 • ARP Suppression 未実装: #8403 • SAI_STATUS_TABLE_FULL リトライ: #2125 関連 HLD • BFD HW Offload HLD • Static Route BFD HLD • SAI failure handling HLD 58
59. A.22 community ビルド固有の機能不在 機能 真因 (build flag による除外) MC-LAG / ICCPd INCLUDE_ICCPD=n で iccpd コンテナ非同梱 STP (PVST/MSTP) INCLUDE_STP=n で docker-stp.gz 非同梱 EVPN-MH (Type-1/4) bgpd syntax は通るが orchagent 統合未完了 ERROR_DB Redis instance 自体が未定義 • CLI は受理されるが裏が動かない • INCLUDE_*=y で再ビルド、または Enterprise ビルドでは同梱されている 59
60. A.23 用途別ざっくり判定 用途 判定 条件 小〜中規模 EVPN/VXLAN OK Leaf ≦ 6 / VNI ≦ 128 Leaf-Spine BGP Underlay OK config.bcm 修正 + Spine 間 iBGP マルチベンダー (NX-OS/cJunos) OK Type-2/3/5 相互交換 中〜大規模マルチテナント NG VNI 128 / Tunnel 5 が上限 Warm/Fast Reboot 前提 NG VXLAN 環境では cold 必須 60
61. A.24 [HW-Bug-1] S5296F chassis.py 真因 該当コード (pmon コンテナ内 sonic_platform/chassis.py:73) # S5232F (正): self.PORTS_IN_BLOCK = (self.PORT_END + 1) # S5296F (誤): PORTS_IN_BLOCK = (self.PORT_END + 1) # ← self. 欠落でローカル変数化 • 112 行目で range(self.PORT_START, self.PORTS_IN_BLOCK) を参照 → AttributeError: 'Chassis' object has no attribute 'PORTS_IN_BLOCK' • 同一ビルド 202505.990579 で platform 別ファイル配布、S5296F だけ欠落 派生影響 (実機で観測) • thermalctld クラッシュループ → Fan / Temp 取得不可 • psud は走るが STATE_DB へ PSU データ書込まれず • xcvrd: 装着済みも含め 全 104 ポートが Not present と報告 (装着済みは誤検出、i2c 0x50 / ASIC は健全) • show interfaces status も AttributeError で死亡 61
62. A.25 [HW-Bug-1] 回避策と upstream 回避策 (実適用) • リンク状態: ip link show / ip -br link show で代替 • PSU / Fan / Temp: IPMI 経由 (ipmitool sel list last 10 / iDRAC Redfish) ‣ 注: ipmitool sel list 全件取得は spine1/2 で 60 秒超 timeout する罠あり • show platform syseeprom: ホスト OS 側に sudo pip install sonic_platform*.whl で復旧 ‣ Fan / Temp / PSU は chassis.py バグのため pip install しても復旧せず • 再発防止 smoke test: hw_phase1_basic/test_06_p0_regression.py:93-97 (T003) ‣ S5232F は sudo 必須、S5296F は xfail マーカー付き upstream 状況 • 引用: buildimage #7644 (Dell S5248F-ON psud 即死、S5296F 類似) • PORTS_IN_BLOCK 名指しの専用 PR は upstream に 見当たらず — 報告検討中 62
63. A.26 [HW-Bug-2] config.bcm の修正内容 VXLAN 越し疎通の決め手となった 2 行 (本編 A 章の「2 行欠落」の中身) l3_ecmp_levels=2 host_as_route_disable=1 • 出所: Broadcom 共通テンプレート broadcom-sonic-td3.config.bcm • Dell per-device の config.bcm に common_config_support マーカー未設定 → [Low Inheritance Precedence] マージが効かず、この 2 行が 落ちていた • 無いと: SAI が tunnel underlay の NH を program できず、ASIC route の NH が oid:0x0 → BCM HW で ING_L3_NEXT_HOP[0].DROP=1 → 全パケット DROP 最終構成では PR #18505 の 16 パラメータを全適用 (riot 系・sai_tunnel_support 等) • 適用先: /usr/share/sonic/hwsku/td3-s5296f-25g.config.bcm • 両 Leaf に同変更 ＋ cold reboot 必須 • upstream: buildimage PR #18505 (Merged 2025-07-29, S5232F/S5248F/S5296F) 63
64. A.27 [CoPP] OSPF neighbor が形成されない 症状: OSPF 設定投入・Process up・Area 0 有効。だが Neighbor 形成されず — Hello が CPU に上がらない 真因 — 公式 copp_cfg.j2 の default trap_ids に OSPF が無い • 既定 trap: bgp / bgpv6 / lacp / arp_* / lldp / dhcp / dhcpv6 / udld / ip2me / eapol / nat_miss / sample_packet / neighbor_miss • OSPF / ISIS / PIM は default 不在 → 動かすには COPP_TRAP 追加が必要 関連 upstream • buildimage #13811 (Open) — ISIS not working (同パターン) • sonic-mgmt PR #22431 (Merged) — test_ospf_bfd.py が COPP_TRAP を動的追加 (OSPF が default trap に無いことの裏 付け) 回避方向 (未検証): /etc/sonic/copp_cfg.json に OSPF trap 追加 + coppmgr 再起動 ※ 本検証では症状確認と真因特定まで。CoPP テンプレ修正での回復は未試行 64
65. A.28 VXLAN 環境での Warm/Fast Reboot 本検証の範囲 • capability check のみ実施 (show warm_restart config / show fast-reboot capability) • 実 reboot は未試行 → cold reboot 運用で回避 upstream の既知問題 • buildimage #22560 (Open, regression ラベル) ‣ タイトル: Regression: fast/warm-reboot fails when VXLAN configuration is present ‣ 2025-05-07 起票 (Author: stepanblyschak@MSFT)、202505 ビルドで未修正 • 関連: #12370 (Closed) — EVPN warm-reboot 中のトラフィックロス 結論 • 本検証は cold reboot 運用 (upstream の指摘 22560 に依拠した判断) • どのプロセスがどう失敗するかは本検証では未観測 ※ 実機での再現実験を含む詳細切り分けは今後の課題 65
66. A.29 [HW-Bug-7] TABLE_FULL → SIGABRT 再現条件: VNI 128 超 / Tunnel 5 超 (Community SAI 上限)、130 個目の VNI 投入で発火 • ASIC 自体は受けている: bcmcmd で VLAN_XLATE_1=134, VFI=138 → 制限は SAI SDK の OID 管理層 クラッシュチェーン (sairedis.rec / orchagent ログから復元) 1. sairedis.rec が SAI_STATUS_TABLE_FULL を返却 2. orchagent が task_need_retry 扱い → 無限リトライ 3. syncd 占有 → 他 SAI 操作が 60 秒タイムアウト → abort() → SIGABRT 構造上の問題 • synchronous_mode= (空) → asynchronous default で SAI 失敗の即時検知パス無効 • ERROR_DB 本ビルドに未定義 → SAI failure handling HLD の伝播経路が存在しない 関連 upstream • buildimage #2125 (Open) — TABLE_FULL → orchagent shutdown • swss PR #3908 (2026-01) — 例外クラッシュは修正、リトライ問題は残存 • #17763 (Enterprise SAI 推奨) / #22296 (TD3-X7 max tunnels) 66
67. A.30 DEVICE_METADATA.type による挙動差分 bgpd / bgpcfgd の Jinja2 テンプレが type で分岐する — 同じ config_db でも type が違うと FRR running-config が変わる type 自動付与される句 テンプレ ToRRouter bgp graceful-restart ／ restart-time ／ preserve-fw-state ／ select- defer-time (計 4 行) bgpd.main.conf.j2:118-122 UpperRegionalHub bgp graceful-restart-disable ＋ long-lived-graceful-restart stale- time 864000 同 :124-126 SpineChassisFrontendRouter BGP セッションに address-family l2vpn evpn 句を自動追加 bgpcfgd instance.conf.j2:38 Lower/Upper/FabricSpineRouter Spine 系専用句あり (multi-asic / chassis 構成向け) bgpd.main.conf.j2:20 Lower/Upper/FabricRegionalHub Regional Hub 専用句あり 同 :27 上記以外 デフォルト (GR も EVPN 自動付与もなし) — 別軸: subtype=dualtor / sub_role=BackEnd / switch_type=voq|chassis-packet でも分岐 ※ 本検証は type 未設定 (default)。GR を効かせたい場合は type=ToRRouter を設定するか手動で bgp graceful-restart 行を投入する必 要がある 67
68. A.31 隣接ノード metadata (DEVICE_NEIGHBOR_METADATA) 2 段のテーブル (CONFIG_DB) • DEVICE_NEIGHBOR|<port> — 物理結線: name, port (相手側ポート) • DEVICE_NEIGHBOR_METADATA|<neighbor_name> — 隣接ノードの素性: type, hwsku, lo_addr, mgmt_addr, deployment_id, cluster bgpcfgd 側の挙動 (managers_bgp.py:140, 220-224) • peer_type ごとに DEVICE_NEIGHBOR_METADATA 必須/任意 が分かれる (check_neig_meta フラグ) • 必須側で metadata 未登録だと bgpcfgd は レンダリングを保留: DEVICE_NEIGHBOR_METADATA is not ready for neighbor 'X' - 'name' • 通った場合、テンプレに CONFIG_DB__DEVICE_NEIGHBOR_METADATA として渡り、各ピアの type/hwsku で分岐 bgpcfgd の peer_type 別テンプレディレクトリ • dynamic / general / internal / monitors / sentinels / voq_chassis (それぞれ bgpd/templates/<dir>/instance.conf.j2) ※ 本検証では DEVICE_NEIGHBOR_METADATA を明示登録していない。FRR を vtysh で直接書く運用だったため bgpcfgd の neighbor 待ちには引っか かっていない (D 章の bgpcfgd vs frrcfgd と関連) 68
69. A.32 DEVICE_NEIGHBOR_METADATA の波及範囲 bgp 以外にも複数のコンポーネントが neighbor.type / hwsku を読んで挙動を変える Consumer neighbor metadata を何に使うか 未登録/誤登録時の挙動 bgpcfgd peer_type 別テンプレで neighbor.type を分岐、 lo_addr で peer-group 決定 check_neig_meta=True の peer は レンダリング 保留 buffers_config.j2 / qos_config.j2 switch.type + neighbor.type の組で buffer profile / cable length を選択 (例: LeafRouter ↔ ToRRouter で extra queues、 EdgeZoneAggregator を LeafRouter 扱い) ロール判定失敗 → 標準 profile に fallback pfcwd サーバ判定 (type 文字列マッチ) で start_default 値 を切替 KeyError でプロセス中断のケースあり ecnconfig backend ポートのソート順制御 (type で BackEnd を識別) 起動前条件違反でスキップ db_migrator hwsku=EdgeZoneAggregator の場合 CABLE_LENGTH を再計算 migration 時のみ作用、未該当ならスキップ lldpmgrd / show interfaces neighbor expected LLDP 期待値の元データ、CLI 表示 neighbor 名で照合不可なら Not Available 表示 出典: SONiC 非公式ドキュメント reference/config-db/device-neighbor-metadata 69
70. A.34 VLAN 大量作成時の 2 経路 bpftrace sched:sched_process_exec/exit で 子プロセス 1 個あたり 直接観測 + vtysh no fpm address 実験で経路分離 ユーザ側の実時間で見える主因: vlanmgrd が呼ぶ /sbin/bridge の ll_init_map • VLAN ごとに /sbin/bridge vlan add を fork+exec、子プロセス起動時 ll_init_map() が全 N netdev に RTM_GETLINK DUMP (per-netdev 2.9 KB) • 実測: N=2 → 3.4 ms、N=2000 → 35.4 ms、Δ = +30.9 ms (×9 倍、2 reps、rep 間差 ±1 ms) • ソース根拠: iproute2 bridge/vlan.c do_vlan() 1 行目 / /sbin/ip も同機構で +4.8 ms 非同期で system load を作る経路: zebra → FPM → fpmsyncd nl_cache_refill • +156 ms CPU/VLAN (ユーザ側の実時間 には現れない) / vtysh no fpm address で FPM 切断 → fpmsyncd の per-VLAN CPU が 4 区間 (前処理 / netdev 作成 / ASIC 投入 / 後処理) すべて 0 に • 余波で ユーザ側の実時間 に [0, 25] ms 程度の漏れあり (回によってばらつき) 検証中に否定した仮説 (いずれも一次情報で反証) • ❌「kernel が全 netdev をイテレート → O(n)」← kernel ソースに netdev 全 dump の per-add 経路は無い (RTM_GETLINK DUMP は userspace 側から要求) • ❌「kernel register_netdevice per-call が主因」← kprobe:register_netdevice で 0.33 ms/VLAN 一定、N 依存増分 Δ の約 1% のみ • ❌「orchagent が netlink 発行」← PortsOrch::doVlanTask (E-2) は SAI 経由 ASIC 書込みのみ、netlink/iproute2 経路は vlanmgrd 側 70
71. A.35 VLAN 一括投入 後の安定時間 N=2000 VLAN 一括投入 後、次の VLAN add が待たされる時間 (2 回計測) 一括投入後の sleep 1 回目 2 回目 判定 30 秒 151.6 秒 163.4 秒 大幅な待ち ( 157 秒) 120 秒 62.0 秒 74.0 秒 残処理中 160 秒 33.0 秒 40.0 秒 残処理ほぼ完了 180 秒 12.4 秒 13.6 秒 13 秒の遅延残存 200 秒 0.104 秒 0.060 秒 残処理完了 300 秒 0.063 秒 0.061 秒 正常 450 秒 0.037 秒 0.042 秒 正常 600 秒 0.039 秒 0.030 秒 正常 機構: リスナー (vlanmgrd / fpmsyncd / zebra / orchagent) の滞留分が処理し切るまで次の操作が待たされる。1 VLAN あたり 156 ms の非同期処 理時間 × 1990 個 (= 2000 VLAN 投入のうち事前投入分 10 を除く) で素朴な逐次上限 310 秒。実測 200 秒で完了するのは並列 overlap や統合 処理の影響と推定 (本検証では直接検証していない) 結論 • 真の処理完了 = 区間 [192, 200] 秒 (旧の「300 秒」は粗い sweep 刻みに由来する見かけ上の値) • 本番運用は 300 秒推奨 (1.5× マージン) — 200 秒だと回によっては未完了の恐れ • もしくは一括投入時に間隔を空ける (1 件あたり数秒) ※ N=1990 (本検証の事前投入 VLAN 数) 固有。他 N での処理時間は線形仮定で見積もったもので、直接の計測はしていない 71
72. A.36 VLAN 大量作成時 — 検証手段とエビデンス (1) A/B 比較 (N=2 と N=2,000、各 200 サンプル) • per-VLAN 中央値: N=2 で 98 ms → N=2,000 で 131 ms (Δ +34 ms)、平均値: 134 → 363 ms (Δ +229 ms、一部が極端に遅い) (2) 子プロセス 1 個あたりの実時間 — bpftrace (sched:sched_process_exec/exit で exec→exit を ns 解像で追跡) • /sbin/bridge: 3.4 → 35.4 ms (N=2 → 2000) = +30.9 ms (×9 倍、2 reps、rep 間差 ±1 ms) ← 主因 • /sbin/ip: 6.1 → 11.1 ms = +4.8 ms ← 副次的寄与 / kprobe:register_netdevice: 0.33 ms/VLAN 一定 (N 依存増分 Δ の約 1%) (3) 経路分離実験 (per-VLAN 中央値 / 平均値、2 reps、平均値差は warmup 影響あり — 363→183 は外れ値由来、warmup を除いた中央値ベースで見ると差は数十 ms に縮小) • 基準: 131 / 363 ms / fpm+zebra 停止: 123 / 183 ms / bgp container 全停止: 94 / 196 ms (中央値 −37 ms = 28% 削減) • vtysh no fpm address (FPM 切断のみ): per-VLAN CPU を 4 区間 (前処理 / netdev 作成 / ASIC 投入 / 後処理) に分けて測ると fpmsyncd 分が 全区間で 0 に → 非同期経 路を直接証明 (4) 安定時間 (一括投入後の待ち時間を 30/120/160/180/200/300/450/600 秒で総当たり計測、1 件目の実時間を 2 回計測) • 30 秒: 157 秒待ち / 180 秒: 13 秒待ち / 200 秒: 104/60 ms (区間 [192, 200] 秒で処理完了) / 300 秒: 63/61 ms (推奨) • 計測スクリプトの timeout 上限を 30→60→600 秒に拡張し、上限で打ち切られていた長い待ち時間も測れるよう改修 補助: perf record (CPU profile)、strace で /sbin/bridge の recvmsg 内訳 (per-netdev 2.9 KB × N)、ftrace function_graph (kernel パス) 72
73. A.37 BGP スケール — cold-start 再計測 計測方法の見直し • 旧: spine1 で redistribute static 経由 → spine1 bgpcfgd 律速、本来の受信能力は計測できず • 新: sv001 上に 外部 BGP speaker (gobgp) を立てて leaf1 と peer 事前投入による汚染を回避 (neighbor 接続を遅延) • gobgpd を neighbor 未設定 で起動 → 事前に gobgp 内部 RIB に N route 投入 (leaf1 へは流れない) • leaf1 受信件数 = 0 を確認 → gobgp neighbor add で動的に追加 → session 確立から初回一括受信を計測 cold-start 結果 (leaf1 = DELL S5296F) route neighbor → RIB RIB → FIB 合計 FIB 反映 (n/N) 100 1.42 s 0.12 s 1.54 s 100/100 ✓ 1,000 1.58 s 0.13 s 1.71 s 1000/1000 ✓ 10,000 1.81 s 0.89 s 2.71 s 10000/10000 ✓ 50,000 3.04 s 5.35 s 8.39 s 50000/50000 ✓ 100,000 5.70 s 11.10 s 16.80 s 100000/100000 ✓ ※ 単回計測。100K route で FIB 100000/100000 完了は再計測でも確認 発見 • BCM TD3 / S5296F は 100K route まで FIB 完了 (それ以上は未測定) • RIB → FIB は 10K 以上で 0.1 ms/route (100K で 11.1 秒) 73