SONiC実機とGNS3 SONiC VSによる事前コンフィグ検証 ― 生成AIエージェントを環境構築・検証支援に使ってみた ―

SONiC実機とGNS3 SONiC VSによる事前コンフィグ検証　
― 生成AIエージェントを環境構築・検証支援に使ってみた ―

株式会社マクニカ
佐々木太郎

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

Transcript

1. ©Macnica,Inc. 株式会社マクニカ フィネッセカンパニー 第3統括部 OpenNetworking事業推進部 佐々木太郎 2026/6/19 SONiC実機とGNS3 SONiC VSによる 事前コンフィグ検証 (生成AIエージェントを環境構築・検証支援に使ってみた)
2. © Macnica, Inc. 2 自己紹介 ⚫ 株式会社マクニカ フィネッセカンパニー 第３統括部 OpenNetworking事業推進部 https://www.macnica.co.jp/go/OpenNetworking.html ⚫ 佐々木太郎 1999年に同社入社。 Ethernet Switch等のFAE(フィールド・アプリケーション・エンジニア） としてハードウエア・ソフトウエア開発サポートを経験。 2021年よりOpen Networking事業のエキスパートとして ホワイトボックススイッチやネットワークOSのサポートに従事。
3. ©Macnica,Inc. Agenda 1. 結論 2. 現場あるある 3. 今日話すこと 4. なぜGNS3 + SONiC VSなのか 5. Dockerコンテナ比較 6. 全体アーキテクチャー 7. ユースケースと検証フロー 8. 生成AIエージェント活用 9. おわりに 3
4. ©Macnica,Inc. 4 結論 — AIエージェント × VS × 実機の三層で安全な事前検証を ① AIエージェント層 VS/実機の環境構築 / Ansible を使った事前検証(手順調査・エラー解析・デバッグ) 生成した Playbook を投入（失敗してもOK） ② VS環境（GNS3 + SONiC VS）層 Ansible PlaybookをAIと自由に実験する場所。ハルシネーションはここで潰す PASS したものだけが次の層へ進む 検証済 Playbook のみ通過 — AIハルシネーション遮断 ③ 実機環境（SONiC スイッチ）層 事前検証済の Ansible Playbook を適用するだけ。AIハルシネーションが届かない領域 AIを「信じる」のではなく「使い倒す」。正しさの検証は Ansible + VS に任せる
5. ©Macnica,Inc. 5 設計変更時の現場あるある ・検証環境（予備機）や検証時間が十分でない → ぶっつけ本番 ・設定自動化の学習コスト(Ansible, YAML等)が高い → 毎回、手作業を継続 ・AI活用したいけどハルシネーション（要は嘘）が怖い → AI使いたいのに使えない ・実機で直接設定変更 → 打ち間違い/手順ミス/ハルシネーションで通信断！？
6. ©Macnica,Inc. 6 今日話すこと 【 話すこと 】 ・VSで事前検証してから実機に適用するフロー ・AnsibleによるVS/実機共通の自動化 ・生成AIによる環境構築・検証支援 ・仮想環境ならハルシネーション恐れずどんどん試せる 【 話さないこと 】 ・AIエージェント比較 ・GNS3/Ansibleの詳細
7. ©Macnica,Inc. なぜGNS3 + SONiC VSなのか
8. ©Macnica,Inc. 8 なぜGNS3 + SONiC VSなのか 【 GNS3の強み 】 ・実機と同じトポロジー作成でき、疎通テストも可能 【 VSの強み 】 ・実機を占有せず、事前検証・自動化テストに最適 ・SONiC CLIがそのまま使える ・HwSKUを実機に合わせてポート構成を揃えられる ・AIハルシネーションのコマンド入力してもVS壊れるだけ ・VSでバグ出しして実機に適用できる
9. ©Macnica,Inc. Dockerコンテナ比較 （Broadcom SONiC v4.5.1）
10. ©Macnica,Inc. 10 Dockerコンテナ（実機とVSで共通20個） イメージ 役割 docker-platform- monitor プラットフォーム監視 docker-snmp Simple Network Management Protocol docker-vrrp VRRP docker-udld UDLD docker-teamd Link Aggregation / PortChannel docker-fpm-frr FRR（BGP / OSPF 等の ルーティング） docker-lldp Link Layer Discovery Protocol docker-stp STP docker-l2mcd L2 Multicast docker-sflow sFlow イメージ 役割 docker-iccpd ICCP（MLAG/MCLAG） docker-nat NAT docker-sonic- mgmt-framework Management Framework（ sonic-cli / REST） docker-sonic- telemetry gNMI / Telemetry docker-timesync NTP / PTP docker-tam TAM（Telemetry & Analytics） docker-eventd Event Daemon docker-mfa Multi-Factor Auth docker-database Redis（CONFIG_DB / STATE_DB 等） docker-router- advertiser Router Advertisement
11. ©Macnica,Inc. 11 Dockerコンテナ（実機とVSの差分4，5個） 実機イメージ 役割 VSイメージ 役割 docker-syncd-brcm-ent- base Broadcom ASIC 用 syncd （ASIC ドライバ） docker-syncd-vs 仮想 ASIC 用 syncd（VS ドライバ） docker-gbsyncd-brcm Broadcom Gearbox syncd（PHY/retimer ） docker-gbsyncd-vs 仮想 Gearbox syncd docker-swss-brcm-ent-base Broadcom 用 Switch State Service（ASIC） docker-orchagent Orchestration Agent（ VS 版 swss 相当） docker-dhcp-relay-ent- base Enterprise Base 版 DHCP Relay docker-dhcp-relay 標準版 DHCP Relay docker-macsec MACsec（VS ビルドに含 まれる）
12. ©Macnica,Inc. 全体アーキテクチャー
13. ©Macnica,Inc. 13 全体アーキテクチャー Ansible [core 2.17.0] SONiC実機 (Edgecore AS7726-32X) Broadcom SONiC v4.5.1 クライアントPC (AI Agent, SSH, GNS3 client) GNS3サーバー 2.2.54 Broadcom SONiC VS v4.5.1
14. ©Macnica,Inc. ユースケースと検証フロー
15. ©Macnica,Inc. 15 ユースケース（現状の運用）
16. ©Macnica,Inc. 16 ユースケース（テナントVRF追加）
17. ©Macnica,Inc. 17 ユースケース（テナントVRF追加） 【 変更前 】 VRF: default Vrfのみ VLAN：10のみ SVI：192.168.10.1/24のみ 【 変更後 】 VRF: default Vrfと Vrf_a VLAN：10と20 SVI：192.168.10.1/24と 192.168.20.1/24
18. ©Macnica,Inc. 18 事前コンフィグ検証フロー Step1. 実機の現状設定を読み出し Step2. VSに実機設定を反映(実機とVSで同じ設定に) Step3. VSに追加設定を適用(動作・影響を事前検証) Step4. 実機に検証済設定を適用(本番動作確認) 【 ポイント 】 ・実機とVSで同じAnsible Playbookを使う ・VSで動作検証済のPlaybookだけが実機に入る安全設計
19. ©Macnica,Inc. 19 Ansible Playbook構成 Makefile：手順固定化（誤設定防止） Playbook名 内容 Sync 実機の設定をVSに同期コピー Precheck 現状の設定が想定通りか（破壊防止） showコマンド＋Redis DBで判定 Change 新規設定の投入 sonic-cliで順番に設定投入 Test 新規設定投入後のテスト showコマンド＋Redis DBで判定
20. ©Macnica,Inc. 20 事前コンフィグ検証フロー 【 実機 】 【 VS 】 Sync(現状設定読み出し) Sync(実機設定を反映) ↓ Precheck(想定通りか確認) ↓ Change(テナント追加適用) ↓ Test(検証) Precheck (想定通りか確認) ↓ Change(テナント追加適用) ↓ Test(検証)
21. ©Macnica,Inc. 21 Sync Playbook — 実機設定を VS へ自動同期 ▪ 設計のポイント 2 Play 構成 Play1: HW で config save → fetch Play2: VS へ filtered config 適用 ホワイトリストでフィルタ VRF / VLAN / VLAN_INTERFACE など アプリ層テーブルのみ同期 VS 固有設定は上書きしない DEVICE_METADATA / PORT 等は除外 make vs-sync 一発で完了 # Play1: HW から設定を取得 - hosts: sonic_hw tasks: - command: sudo config save -y - fetch: src: /etc/sonic/config_db.json dest: /tmp/hw_config_db.json flat: yes # ホワイトリストフィルタ - name: Build filtered config ansible.builtin.set_fact: filtered_config: >- {{ hw_config | dict2items | selectattr('key','in',sync_tables) | items2dict }} # Play2: VS へ適用 - hosts: sonic_vs tasks: - command: sudo config load /tmp/filtered_hw_config.json -y
22. ©Macnica,Inc. 22 Precheck Playbook — CONFIG_DB で安全ゲート ▪ 設計のポイント show コマンド不使用 CONFIG_DB (Redis db=4) を直接参照 キーの存在確認のみ → 高速・安定 precheck_strict: true → assert でブロック（実機用） precheck_strict: false → レポートのみ（VS用） VS / 実機で同一 Playbook を使用 # CONFIG_DB ping 確認 - name: CONFIG_DB ping (db=4) ansible.builtin.command: "redis-cli -n 4 ping" register: db_ping # VRF の存在チェック - name: Check VRF key existence ansible.builtin.command: redis-cli -n 4 exists 'VRF|{{ vrf_name }}' register: vrf_exists - name: Gate - VRF must not exist ansible.builtin.assert: that: - "vrf_exists.stdout | int == 0" when: precheck_strict | bool
23. ©Macnica,Inc. 23 Change Playbook — sonic-cli で安全投入 ▪ 設計のポイント sonic-cli の -c オプションで 1 コマンド = 1 タスクに分割 既存設定（default VRF / VLAN10） には一切触れない 投入後に CONFIG_DB を再確認 → 変更の適用を自己保証 ▪ 共通変数 vrf_name: Vrf_a vlan_tenant_id: 20 vlan_tenant_ip: 192.168.20.1/24 # VRF 作成 - name: Create VRF ansible.builtin.command: > sonic-cli -c 'configure' -c 'ip vrf {{ vrf_name }}' # VLAN SVI 作成 + VRF 割当 - name: Create VLAN SVI with VRF ansible.builtin.command: > sonic-cli -c 'interface Vlan {{ vlan_tenant_id }}' -c 'ip vrf forwarding {{ vrf_name }}' -c 'ip address {{ vlan_tenant_ip }}' # 変更後の自己確認（CONFIG_DB） - name: Assert change really applied ansible.builtin.assert: that: - "results[0].stdout|int == 1" # VRF - "results[1].stdout|int == 1" # VLAN - "results[2].stdout|int == 1" # SVI
24. ©Macnica,Inc. 24 Test Playbook — 事後確認で安心 ▪ 設計のポイント `expect_tenant_present` フラグで変更前 / 変更後どちらでも使える `show` コマンド + CONFIG_DB の二重確認 ルーティング分離（VRF 分離）まで検証 ▪ モード切替フラグ true = 変更後：Vrf_a / VLAN20 が存在する はず false = 変更前：Vrf_a / VLAN20 が存在しな いはず expect_tenant_present: true ### テナント設定の存在確認（post モード） - name: Assert tenant VRF/VLAN/SVI presence (post-change expectation) ansible.builtin.assert: that: - "vrf_out.stdout is search('^¥¥s*' ~ vrf_name ~ '(¥¥s|$)', multiline=True)" - "vlan_out.stdout is search('^¥¥|¥¥s*' ~ vlan_tenant_id ~ '¥¥s', multiline=True)" - "ipif_out.stdout is search('Vlan' ~ vlan_tenant_id)" - "ipif_out.stdout is search(vlan_tenant_ip)" - "ipif_out.stdout is search(vrf_name)" fail_msg: "Post-check failed: tenant VRF/VLAN/SVI not found as expected." when: expect_tenant_present | bool ### VRF ルーティング分離の確認 - name: Assert default VRF route table contains VLAN10 and not VLAN20 ansible.builtin.assert: that: - "route_def.stdout is search('192¥¥.168¥¥.10¥¥.0/24')" - "route_def.stdout is not search('192¥¥.168¥¥.20¥¥.0/24')" fail_msg: "Routing separation check failed in default VRF." when: - expect_tenant_present | bool - vlan10_oper_up | bool - name: Assert tenant VRF route table contains VLAN20 ansible.builtin.assert: that: - "route_vrf.stdout is search('192¥¥.168¥¥.20¥¥.0/24')" fail_msg: "Routing separation check failed in tenant VRF." when: - expect_tenant_present | bool - vlan20_oper_up | bool
25. ©Macnica,Inc. 25 Test検証（おなじテナントVrf内でのみPing疎通可能）
26. ©Macnica,Inc. 生成AIエージェントの活用
27. ©Macnica,Inc. 27 生成AIエージェントの活用 【 活用の成果 】 ・環境構築が大変なツールでも簡単に構築できた ・ノーコード（日本語で指示するだけ）でPlaybook実装できた 【 具体的な内容 】 ・Google Antigravity GNS3環境構築、VSへのSSHアクセス設定等 ・Claude Code Ansible環境構築 Playbookコーディング Playbook実行デバッグ ・Microsoft Copilot Workshopプレゼン内容、シナリオ検討
28. ©Macnica,Inc. 28 生成AIエージェント活用（Google AntigravityでGNS3環境）
29. ©Macnica,Inc. 29 生成AIエージェント活用(Claude CodeでAnsible Playbook)
30. ©Macnica,Inc. 30 生成AIエージェントの活用(Microsoft Copilotでプレゼン検討)
31. ©Macnica,Inc. 31 ハルシネーションによる設定エラー例 ・SONiC でVrf名の命名規則の理解不足 先頭 Vrfから始まる必要あるが、無視したVrf名を提案された ← 実機適用前にVSで検出 ・SONiCのIPアドレス表記の理解不足 SONiCでのCIDR形式(192.168.1.1/24)でなく サブネットマスク表記(192.168.1.1 255.255.255.0)を提案 ← 実機適用前にVSで検出
32. ©Macnica,Inc. 32 おわりに • GNS3 + SONiC VSは「実機運用の延長」であり「AIの実験場」 でもある • VSがAIと実機の間の「安全弁」になる。VSでPASSしたものだけが 実機へ。AIハルシネーションを実機に持ち込まない • AnsibleでAIを「信じる」のではなく「使い倒す」。正しさの検証は Ansible + VSに任せる ・AIエージェント x VS x 実機の三層で安全に事前検証して、 Happy SONiC Life を楽しみましょう！
33. ©Macnica,Inc. 33 ご清聴ありがとうございました！
34. ©Macnica,Inc. ・本資料に記載されている会社名、 商品またはサービス名等は各社の商標または登録商標です。 なお、 本資料中では、 「 」、 「®」は明記しておりません。 ・本資料のすべての著作権は、 第三者または株式会社マクニカに属しており、 （著作権法で許諾される範囲を超えて）無断で本資料の全部または一部を複製・転載等することを禁じます。 ・本資料は作成日現在における情報を元に作成されておりますが、 その正確性、 完全性を保証するものではありません。