コンテナを用いたISPネットワーク検証システムと トラヒックシミュレーションによる 作業事前検証の実施 2024/09/12 2024年電子情報通信学会 ソサイエティ大会 BI-3-03 1 田島 照久 (NTTコミュニケーションズ株式会社), 萩原 学 (TIS株式会社), 滝口 敏行, 前野 洋史 (ビッグ ローブ株式会社), 山口 大樹, 武藤 匠汰 (伊藤忠テクノソリューションズ株式会社), 新里 康晃 (一般社団 法人 沖縄オープンラボラトリ)

NW運用における検証作業 • 本番NW環境作業のリスクが大きい → 机上予測には限界があり、事前の確認が重要 • ISPのようなマルチベンダ・大規模・複雑なNW → 機器単体の局所的な検証では全体への影響がわからない 2 本番環境 検証環境 XXを作りたい ・変更したい 検証環境を 立ち上げよう 試行錯誤 結果を 反映しよう

検証作業の成果物＝環境と手順書 • 操作対象の周辺も含めて意図した状態変化になるか確かめる （不確実性の低減） 1. 検証環境を立ち上げる 2. 適切な状態変化を起こせるか試行錯誤する（作業内容に依存） 3. 実施すべきタスクを手順書として確定させる → 検証環境を本番環境に近づけ 品質の良い手順書を作る 3 検証環境 検証環境を 立ち上げよう 試行錯誤

現在の運用プロセスと課題 • 十分な検証環境が無く、手順書が机上検討の場合がある • 実行するとどうなるのか、が読み手の解釈に委ねられている • レビュー品質がレビュワーの経験に依存（属人的で不確実） • 特定要員への負荷集中でボトルネックが発生 4

品質向上＝不確実性を減らす • 不確実なところ • 手順書のコマンドそのもの → トレーニング等、本提案の対象外 • 手順書実施後の系の状態 → こちらを解決する → コンテナで検証環境を用意 • 環境準備速度向上、スケールアウトにより手順書作成支援 • 可搬性担保によりレビューが動作検証を兼ねられる 5

コンテナで自NW全体を再現 • メリット • 全体が再現できる → 一部では系としての不確実性を減らし切れない。 そもそも「一部」を切り出すこと自体が難しい（人に依存する） • リソース効率がよい • 可搬性と再現性がある • デメリット • configを変換しないといけない → config変換を備えた検証環境自動構築システムを作る 6

システム化による利点 • 作業者視点 • 勘で作業を組み立てるのでは無く、実際に動かしながら検証できる • レビュー者視点 • 机上検討ではなく実際の結果を見て判断できる • 管理者視点 • 作業の並列化が可能になる 7

検証システムへの要求まとめ • マルチベンダで構成されるbrown fieldの検証環境を作成 • ネットワーク全体を模擬 • 検証環境でトラヒックが流せる • 何度でも同じ検証ができる 8

トポロジ表現で抽象化し可搬性を確保 NWの構造を抽象化 • 環境に依存する文法ではなく トポロジとしてとらえる • 各レイヤのトポロジを グラフとして表現する 各環境へ翻訳 • 単純にデータ変換ではなく 「同等なもの」にする • 各環境の文法をテンプレ エンジンで生成する 9 Hardware Container 本番環境と検証環境で アーキテクチャ・OS・コンフィグいずれも異なる 本番環境 検証環境 Topology Data

関連する取り組み 10 IIJ Engineers Blog, IXP 管理のフルスタック自動化, https://eng-blog.iij.ad.jp/archives/8668 白紙から構成情報を作る： トポロジをGUIで入力すると configが出力されるシステム 設定から構成情報を再構築する： AWS上の既存コンポーネントの 依存関係を図示するシステム AWS ソリューションライブラリ, AWS でのワークロード検出, https://aws.amazon.com/jp/solutions/implementati ons/workload-discovery-on-aws/ グラフ形式ではない構成情報： Cisco Configをクラスのインスタ ンスの依存関係で示すシステム 他、Intent Based Networking 多数 藤田ら, 静的解析によるネットワーク構成モデルの 自動検証, IPSJ SIG Technical Reports Vol.2024-IOT-64 No.5

構成情報を中心に本番環境と検証環境を 相互に変換するシステム 11 Original Env. Emulated Env. Convert Hardware Container Config Topology Data Config ① ② Operator Operator ① 本番configをパースし 構成情報を作成 ② 構成情報から検証環境 を構築 ③ 検証環境でトラヒック 再現など試行錯誤 ③

再現する対象のNWとシナリオ • AS65518を自ASとし、PNIとしてAS65550、POIとして AS65520に接続するISP • PNIとは3台の境界ルータで接続 • PNIとの流量が増えてきたので 広告するprefixを調整したい 12

システム構成 13 Original Env. Emulated Env. Config (Given) L1 topology (Given) BGP Policy Parser External AS Topology (Given) Config Direct operation Direct operation Cisco Juniper cRPD Converter (convert table) Multilayer Topology Data Step1-1 コンフィグから トポロジデータ生成 Step1-2 トポロジデータの拡張 (データ追加) Step2-2 仮想環境設定 Step2-1 トポロジデータから 仮想環境構築 Operation (手動)検証作業 ターゲットユースケースに合わせた拡張 実行時状態の調整

デモ動画 14

Step1-1 トポロジデータ生成 • 与えられたコンフィグから仮想環境の構築に使用する トポロジデータを生成 • BGPとOSPFの情報はBatfishを通して抽出 • Batfishが対応していない箇所は独自パッチで対応 • 各機材間のL1接続情報はBatfish+NetBox+スクリプトで抽出 • インターフェース情報のデスクリプションから抽出 • デスクリプションの例: Switch-01 Ethernet1 15 Config (Given) L1 topology (Given) BGP Policy Parser External AS Topology (Given) Direct operation Cisco Juniper Step1-1 コンフィグからトポロジデータ生成 Step1-2 トポロジデータの拡張(データ追加)

Step1-2 トポロジデータの拡張 • その1. 外部ASノードの補完 • 外部ASはコンフィグがない • ピア情報からトポロジを拡張する • その2. BGPポリシーの共通モデルへの変換 • 仮想環境ではIOS-XRのノードをJunos(cRPD)で再現 • JunosとIOS-XRのポリシーを共通のデータ構造に変換 16 Config (Given) L1 topology (Given) BGP Policy Parser External AS Topology (Given) Direct operation Cisco Juniper Step1-1 コンフィグからトポロジデータ生成 Step1-2 トポロジデータの拡張(データ追加) ASレイヤ BGPレイヤ

Step2-1 トポロジデータからの仮想環境構築 • ここまで生成したトポロジデータを使用して仮想環境を構築 • 仮想環境の構築にはconatinerlabを使用 • ネットワーク機器はcRPDで再現 • L2ドメインはOVSで再現 • トポロジデータからコンフィグを生成して各ノードに投入 • jinja2を使用してモデルデータから生成 17 Config Direct operation cRPD Step2-2 仮想環境設定 Step2-1 トポロジデータから 仮想環境構築 実行時状態の調整

Step2-2 仮想環境設定 • 実施するオペレーションに合わせて仮想環境の設定を変更 • 外部ASから見た優先ピアの変更 • 自ASのトラフィック受信インターフェースを本番環境と合わせる • 内部的には外部ASノードに対してLPを変えたコンフィグを投入 • トラフィックの模擬 • 外部ASのノードの奥にiperfを実行するノードを用意 • 流す際にはプリフィックスごとの帯域が実環境 (実測したフロー情報)と同等の比率になるように調整 18 Config Direct operation cRPD Step2-2 仮想環境設定 Step2-1 トポロジデータから 仮想環境構築 実行時状態の調整

仮想環境での検証作業 • オペレーションがトラフィックに与える影響を一目で 判断できるように可視化の仕組みを用意 • 仮想環境のノードは全てコンテナなのでコンテナのメトリクスを 取得するcAdvisorとGrafana+Prometheusで可視化 19 Config Direct operation cRPD Step2-2 仮想環境設定 Step2-1 トポロジデータから 仮想環境構築 実行時状態の調整

評価 • 検証システムとして ルータは計5+2台, スイッチ1台, EBGP ピア6本, OSPF Area 2つ コンテナは合計1.57GBのメモリ使用量 configパース～コンテナ起動に3分半 • レビューワークフローとして • 再現試験で機械的にチェックでき 正確性が上がった • 経験の浅い人でもpeer作業できる ようになった • 今まで確認できなかった、対向か らの経路確認などのチェック項目 を作れた • Prefixを移植するベテランの感覚 をロジカルにシミュレートできて いる • 手順書作成がまだ手動なので時間 短縮にはならない 20

future work 「トポロジデータ」の評価 • 本番環境で起こりうるケースをどれだけカバーできているか コンテナにより検証の速度や並列度があがる → より広い範囲の模擬や検討が可能 • ピア先の模倣 (サイズ方面への拡張) • 未来シミュレーション (時間軸方面への拡張) 21

まとめ 検証作業においてISPのトラヒックシミュレーションが可能な コンテナベースの環境構築自動化システムを提案 フィールドトライアルを通じて手順書の精度向上を確認 22