機器設定ファイルからのトポロジモデル抽出による机上検査を含めた設計支援システム

ネットワーク (NW) を意図通りに運用するためには各レイヤ間の設計で整合性を取るだけでなく, 障害時などトポロジが変化した際の動作を繰り返し予測し品質を高める必要がある.
それには高度な知識や経験が必要であり, NW の拡大・複雑化によりさらに難しくなった.
そのため設計から運用までを自動化する仕組みが求められる.
本稿ではまず設計段階に着目し NW をトポロジモデルとして扱うことで, 障害時を含めたふるまいを机上で検証した.
具体的には, 既存 NW 装置から設定ファイルを収集し, 各レイヤをトポロジモデルとして抽象化した. さらに各レイヤで設計ポリシをテストする設計支援システムを実装した.
これにより設計ポリシが NW に反映されているかの机上検証ができること, また規模が拡大しても使用できるシステムであることの評価結果を報告する.

Support System of Designing and Verifying Network by Abstracting Topology Model from Configuration Files

In network operation, designing relations between each network layer and estimating behavior at changing its topology by some failure are essentials to keeping its intent.
Since such network design and operation skills demand deep knowledge and well experienced, the larger scale of networks, the more difficult to get these skills and an automation system is required.
We focused on the designing phase, we tried to abstract networks as topology models and simulated that behavior at the failure test.
We implemented the system to check the design policies at each layer with topology models by collecting equipment configuration files, and to simulate the behavior in failures.
We evaluated the system has the feasibility of applying the design policies to a network, and it has scalability for large-scale networks.

Transcript

1. 機器設定ファイルからの トポロジモデル抽出による机上検査を含めた ネットワーク設計支援システム 田島 照久 NTTコミュニケーションズ株式会社 川口 永一郎 ビッグローブ株式会社 滝口 敏行 ビッグローブ株式会社 萩原 学 TIS株式会社 新里 康晃 一般社団法人 沖縄オープンラボラトリ 1 2022/07/08 情報通信マネジメント研究会 @とかちプラザ
2. ネットワークの検証作業の複雑さ ◼NWを構築運用する際の流れ ◼ 設計 → 検証 → 設計修正 → 再検証 → … → 本番構築 ◼実機検証と前段の机上検証 ◼ 実機検証には時間がかかるが、実機のみ発現するものがある ◼ 実機の挙動に集中するため、それ以外を事前に机上検証する 2 いかに効率的に行うか End-to-Endでは 理論上通信できない ？ 機器単体の設定は 動作可能という意味で正しい 特定のバージョンで 挙動が変 すべて同時に 両立しうる
3. 事前の机上検証とは ◼実機検証は実施に時間が必要で貴重（数日～数週） ◼ 事前に不確実性を減らし、環境構築回数を下げるべき ◼机上で可能な検証は机上で実施（数時間～数日） ◼ 設計 → 机上検証 → 設計修正 → … → 実機検証 → … 3 End-to-Endでは 理論上通信できない ？ 機器単体の設定は 動作可能という意味で正しい 特定のバージョンで 挙動が変 この部分を高度化・高速化 ＝不確実性が減る
4. 机上検証で確認するポイント ◼設定が実装バグ無く動けば設計意図が反映される状態 ◼ NWの設計意図を「正しく」設定できているか ◼ End-to-Endを模擬して通信できるか ◼「正しい」ことのチェック ◼ 各レイヤで齟齬の無いトポロジ図が書けるはずだ ◼ 既存設定ファイルからもそのトポロジは再構築できるはずだ → これらを支援するシステムが必要 4
5. 検証・デプロイの実用例：トポロジデータ ◼AWS Perspective[7] ◼ 通信ログなどから 構築済みシステムの アーキテクチャ図を作成 ◼IXPのデプロイ自動化[8] ◼ トポロジ編集による 構成変更を実装 → トポロジデータの表現は机上検証・デプロイに使用可 5 [7] AWS でのワークロード検出, https://aws.amazon.com/jp/solutions/implementations/aws-perspective/ [8] IXP管理のフルスタック自動化, https://eng-blog.iij.ad.jp/archives/8668
6. 設計支援システム ◼人を中心とする設計検証からトポロジモデル中心へ ◼モデルに基づいたデータの作成と確認を支援 6 検証環境 本番環境 自動テスト 確認 トポロジモデル config
7. トポロジモデルの使用 ◼人間と機械が役割分担できるよう、共通の言語が必要 → トポロジモデルという共通表現の導入 7 人間のレビュー 可能範囲 機械化 可能 実機での検証 ◼人間によるレビューの特徴 ◼ 全体を見て大域的判断、経験 による判断が可能 ◼ 時間コストや網羅性が不得意 ◼機械によるレビューの特徴 ◼ 実装されたルールを網羅的に 素早く評価可能 ◼ 知らないことは判断できない 不確実性をできるだけ 事前に取り除く
8. 既存の机上検証ツール：Batfish[10] ◼E2Eをシミュレートできるツール ◼ Src/DstのIPや5-Tupleから到達性を確認可能 ◼ 主にL3情報からシミュレーション ◼レイヤの整合性は考慮されない ◼ 特にL1で接続されているかどうかは外部から正解を与える 必要がある → ツール連携のためにもトポロジデータ記述が有効 8 [10] Batfish - an open source network configuration analysis tool, https://www.batfish.org/
9. 設計のステップと支援箇所 1. 候補configの作成 ◼ （人間による設計） 2. トポロジ構築と静的検査 ◼ システムによる支援 3. NWのふるまいを確認 ◼ システムによる支援 4. 検査OKであれば検証環境に デプロイ ◼ （本システムの対象外） 9 ２. 3.
10. システム詳細 10 運用対象NW device config & state layer1 topology topology data L1-L3 トポロジ 生成 各種 テスト 検査 テスト・検査結果に応じて コンフィグの修正 必要なら環境へのフィードバック (ここは従来のやり方で) config, stateは 定期的に取得 operator L1 リンク情報 抽出 WebUI (可視化) API Wrapper Parser, Simulator NetBox Batfish Ansible ２.トポロジ構築と静的検査 ３. NWのふるまいを確認
11. 2. トポロジデータ構築と静的検査 ◼各レイヤでトポロジデータを構築 ◼各レイヤ内、およびレイヤ間で 整合性がとれているかをチェック ◼ 例）L1リンクが接続しているが、L2セグメントが分離 ◼ 人間が確認する際の「つながっているか」「正しいか」を 見るようにレイヤ間の関連性もチェックする ◼ L1から順番に積み上げていく ◼データ記述はRFC8345の定義を使用 11
12. L1データ作成 ◼descriptionからリンクのペアを抽出 ◼ 後述の障害テストパターン作成時にも使用 ◼物理的なリンクを示すので 孤立はしないはず ＝全体として連結なグラフになる ◼冗長なリンクは冗長に表現される 12 Layer 1
13. L2データ作成 ◼LAGも考慮した論理インターフェースのグラフ ◼インターフェースの各VLANは それぞれのブロードキャストドメインとして表現 ◼ブロードキャストドメイン名でも 間にL1リンクが無いと孤立 ◼ 例）vlanミスマッチの発見 13
14. L3データの作成 ◼L3ノードとネットワークセグメントのグラフ ◼ L3ノードとはIPアドレスを持つ論理インターフェース ◼同じブロードキャストドメインのノードは 一つのセグメントを作る ◼セグメントが異なると孤立 ◼ 例）prefix間違いの発見 14
15. トポロジデータ構築と静的検査 ◼これまでの各stepを経ることで 各レイヤごとのモデルデータが生成 ◼エラーがあった場合は都度config修正のち再実施 ◼トポロジデータの確認用に各レイヤを対応づけて表示 できるUIを用意した 15
16. 設計のステップと支援箇所 1. 候補configの作成 ◼ （人間による設計） 2. トポロジ構築と静的検査 ◼ システムによる支援 3. NWのふるまいを確認 ◼ システムによる支援 4. 検査OKであれば検証環境に デプロイ ◼ （本システムの対象外） 16 ２. 3.
17. 3. ネットワークのふるまいを確認 ◼ふるまい＝要件通りに動くかどうかを検査 ◼ 要件で定められたE2Eの通信ができる ◼ 耐障害性などの可用性要件 ◼それぞれの確認方法 ◼ E2Eのシミュレータ Batfish を使う ◼ 障害模擬したトポロジを再構築し、影響調査 17
18. 障害模擬とモデルの再評価 1. L1リンクやノードを1つ欠落させる 2. 再度L2以上のトポロジデータを作成する 3. 欠落の無い場合のグラフと比較 ◼ 差異の箇所の重み付け和を評価点とした ◼ 評価点が高いものほど単一の障害で重篤なエラーを引き起こ していると見なせる 18 Layer 1 Layer 2 Layer 3
19. システムを用いた設計作業例：SPoF検出 1. ある障害模擬ケースに高い点数の差異（システム） ◼ NWが分断されL3で多数のセグメントが非連結に 2. configを確認し詳しく見て原因究明（人間） ◼ 当該リンク周辺を調査 3. configを修正（人間） 4. 再度評価（システム） 5. 修正を確認（人間） ◼ 再実行し差異が減ったことを確認 19 1. 2. 3. 4. 5.
20. 性能評価 ◼モデル作成と検査にかかる時間と必要なメモリを計測 ◼240台720リンクの大規模でも2.3時間で完了 → 机上検証サイクルは実機と比べ十分高速に実施可能 20 NWのサイズ (ノード数, リンク数) 実行時間 [sec] 最大使用メモリ [GiB] (12, 36) 78 2.5 (30, 90) 212 4.5 (60, 180) 648 6.0 (120, 360) 2001 12.8 (240, 720) 8182 31.3 実行時間 最大使用メモリ 使用機器 CPU: Intel Xeon Silver 4216 (16C/32T HT enabled) MEM: 64GiB OS: Ubuntu 20.04
21. 今後の展望 ◼L1~L3だけでなく、上位レイヤの検査追加 ◼デプロイ部分まで実装し、トポロジデータ中心の運用 効果を検証 21 検証環境 本番環境 自動テスト 確認 トポロジモデル config
22. まとめ ◼設計支援システムを実装 ◼ 実機検証に入る前に十分に机上検証することが目的 ◼ 設定ファイルから各レイヤのトポロジを抽出 ◼ 人手で考えるような静的解析による設定誤りの検出を実装 ◼ トポロジの障害模擬を実装しSPoFの検出が可能 ◼ 全パターン検査は機器240台リンク720本の規模でも 2.3時間で実行完了 ◼今後の展望 ◼ 各種プロトコル対応 ◼ トポロジデータの自動デプロイ 22 コードは公開されています https://github.com/ool-mddo/playground 本研究は著者らの所属会社が、沖縄オープンラボラトリにて協同研究を行った成果です