1. 新規テナント追加に伴うネットワーク設定変更の事前検証

データセンターでは、新規顧客や新サービス向けにVRF、VLAN、ルーティング設定を追加する作業が頻繁に発生します。
一方で、設定ミスによる通信断やサービス影響は絶対に避けなければなりません。

＜課題＞
・本番環境での設定変更リスク
・検証用機材や検証時間の不足

2. GPUクラスタ増設時のネットワーク設計変更の自動化・検証

AI学習基盤やHPC環境では、GPUサーバー増設時にネットワーク構成変更が頻繁に発生します。特にマルチテナント環境では、VRFやVLANの追加、ルート制御の変更が必要になります。

＜課題＞
・短期間での基盤拡張要求
・ネットワーク担当者不足
・AIが生成した設定に対する信頼性への懸念

3．複数顧客向けネットワーク変更業務の標準化

SIerや運用サービス事業者では、顧客ごとに異なるネットワーク環境を運用しており、設定変更の品質維持と工数削減が大きな課題となっています。

＜課題＞
・顧客ごとに異なる設定手順
・ベテラン依存の運用
・レビューや検証工数の増加

これらの課題は結果的に、設定ミスや手順ミス、本番環境での障害発生リスクにつながります。今回紹介する仕組みは、こうした課題をまとめて解決することを目的としています。

GNS3のメリット

GNS3 (Graphical Network Simulator 3)とは、ネットワーク機器の仮想化・エミュレーションを行うためのツールです。
仮想ルーター・スイッチを使ってネットワーク構成を試すことができます。GNS3を利用することで、実機ネットワークと同等のトポロジーを再現し、疎通テストまで実施できます。

＜GNS3のダウンロード＞
以下公式のGitHubから、インストーラーをダウンロード可能です。
https://github.com/GNS3/gns3-gui/releases/tag/v2.2.54

SONiC VSのメリット

一方、SONiC VSは以下の特徴を備えています。

・実機を占有せず事前検証できる
・SONiCのCLIをそのまま利用可能
・HwSKUを実機に合わせることでポート構成を揃えられる
・AIが誤った設定を生成しても実機へ影響しない
・VSでバグ出しをして実機に適用できる

これらのメリットにより、コンフィグ検証や自動化テストに最適な環境となっています。

VSと実機の比較

では、VSは実機にどこまで近い構成になっているのでしょうか？

下記の表は、VSと実機をDockerコンテナの観点で比較した結果です。
Broadcom  SONiC  v4.5.1環境では、実機とVSで20個のDockerコンテナが共通しています。FRR、LLDP、STP、SNMP、Telemetryなど、制御プレーンやアプリケーション層の主要な機能はほぼ同一構成となっています。
差分としてはASIC関連コンポーネントが中心であり、コンフィグ検証用途では十分に実機の代替として利用することができます。

Ansibleによる自動化設計

次に、検証環境を支えるAnsible設計について、利用した4種類のPlaybookをご紹介します。
Playbookは「Sync」「Precheck」「Change」「Test」の4種類で構成されており、それぞれが明確な役割を持つことで、安全かつ再現性の高い設定変更を実現しています。
さらに、Makefileによって実行手順を固定化し、オペレーションミスの防止も図っています。

まず「Sync Playbook」は、実機の設定をSONiC VSへ同期します。
2つのPlayで構成されていて、Play1では実機側がconfig saveしてファイルを取得、Play2でVSへ適用します。
VRFやVLANなどのアプリケーション層の設定のみをホワイトリスト方式で抽出してVS環境へ反映します。
これにより、実機に近い状態を仮想環境上で再現でき、以降の検証の土台を作ります。

次の「Precheck Playbook」は、安全ゲートとして機能します。

SONiCのCONFIG_DB (Redis)を直接参照し、追加予定のVRFやVLANが既に存在していないかなどを確認します。
実機環境では厳格なチェックによって想定外の状態での設定投入を防ぎ、VS環境ではレポート用途として利用できるため、同じPlaybookを用途に応じて使い分けられる設計となっています。

続く「Change Playbook」では、実際の設定変更を実行します。

sonic-cliの-cオプションで、1コマンドを1タスクに分割しています。そして、既存のdefault VRFやVLAN10には一切手を加えず、必要な構成のみを追加することで変更範囲を最小限に抑えています。また設定投入後にはCONFIG_DBを再度参照し、Playbook自身が変更結果を検証する仕組みも組み込まれています。

最後の「Test Playbook」は、設定反映後の動作確認を自動化します。

showコマンドによる確認とCONFIG_DBの内容確認を組み合わせることで、VRFによるルーティング分離までチェックします。さらに、VRFのテーブルにVLAN10が漏れていないか、テナントVRF側にVLAN20があるかまで自動で確認することができます。

これら4つのPlaybookを順番に実行することで、「実機設定の再現」「事前確認」「設定変更」「動作検証」という一連の作業を自動化できます。

こちらが実際のTest結果です。

狙い通り、同じテナントVRF内でのみPingが通り、VRFをまたいだ通信は遮断されています。設計したルーティング分離が、実機できちんと効いていることが確認できました。VSで検証した通りの結果が、実機でもそのまま再現できたということになります。
この仕組みによって、AIが生成したPlaybookや設定内容も安全に検証できるようになり、「AIを信じるのではなく、仕組みで検証する」という運用モデルを実現しています。

今回の検証結果のより具体的な資料はこちらからダウンロード可能です。

生成AIエージェントの活用

今回の取り組みでは、複数の生成AIサービスを用途別に活用しました。

Google Antigravity
GNS3環境構築やSSH設定などのインフラ構築支援に活用。 普段は手順が多くて面倒なGNS3のセットアップを、AIに指示しながら進行。

Claude Code
Ansible環境構築、Playbookの実装、デバッグ支援に利用。今回紹介したPlaybook群もAIによって生成され、VS環境での動作確認結果をフィードバックしてデバックを進行。

Microsoft Copilot
プレゼンテーション構成やシナリオ作成支援に活用。

AIを信じるのではなく、使い倒す

最後に、今回の検証で実際に発生したAIのハルシネーションによる設定エラー例と、それでもAIが活用できる理由をご紹介します。

今回実際に出たエラー例として、下記が確認されました。
・SONiCのVRF命名規則を理解していないVRF名の提案
・SONiCで必要なCIDR表記ではなくサブネットマスク表記の提案

しかし、これらはいずれもSONiC VS環境で事前に検出され、本番環境へ影響を与えることはありませんでした。
この事例は、VSが「AIと実機の間に存在する安全弁」として機能することを証明しています。これにより、AIが設定エラーを起こしても、安心して活用することができます。

お問い合わせ

マクニカは、今までOpenNetworkingの課題となっていたものを解決し、お客様のメリットを最大化するソリューションとしてお届けします。
SONiCに関するお問い合わせや、その他ホワイトボックススイッチなど、マクニカのOpenNetworking製品に関するお問い合わせや技術的なご相談がございましたら、こちらのフォームからお気軽にお問い合わせください。

関連する情報

【講演レポートPart1】放送ネットワーク用スイッチハンズオンセミナー～ホワイトボックススイッチで学ぶネットワークの基礎と放送ネットワークの特徴　ネットワーク基礎編～

【講演レポートPart1】SONiC実践ハンズオンセミナー～ホワイトボックススイッチで学ぶ、オープンネットワーク OS の基本操作～

SONiC Workshop～SONiCソースコードについて生成AIに聞いてみた編～