Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

ネットワーク (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.

tjmtrhs

July 08, 2022
Tweet

More Decks by tjmtrhs

Other Decks in Technology

Transcript

  1. 機器設定ファイルからの
    トポロジモデル抽出による机上検査を含めた
    ネットワーク設計支援システム
    田島 照久 NTTコミュニケーションズ株式会社
    川口 永一郎 ビッグローブ株式会社
    滝口 敏行 ビッグローブ株式会社
    萩原 学 TIS株式会社
    新里 康晃 一般社団法人 沖縄オープンラボラトリ
    1
    2022/07/08 情報通信マネジメント研究会
    @とかちプラザ

    View Slide

  2. ネットワークの検証作業の複雑さ
    ◼NWを構築運用する際の流れ
    ◼ 設計 → 検証 → 設計修正 → 再検証 → … → 本番構築
    ◼実機検証と前段の机上検証
    ◼ 実機検証には時間がかかるが、実機のみ発現するものがある
    ◼ 実機の挙動に集中するため、それ以外を事前に机上検証する
    2
    いかに効率的に行うか
    End-to-Endでは
    理論上通信できない

    機器単体の設定は
    動作可能という意味で正しい
    特定のバージョンで
    挙動が変
    すべて同時に
    両立しうる

    View Slide

  3. 事前の机上検証とは
    ◼実機検証は実施に時間が必要で貴重(数日~数週)
    ◼ 事前に不確実性を減らし、環境構築回数を下げるべき
    ◼机上で可能な検証は机上で実施(数時間~数日)
    ◼ 設計 → 机上検証 → 設計修正 → … → 実機検証 → …
    3
    End-to-Endでは
    理論上通信できない

    機器単体の設定は
    動作可能という意味で正しい
    特定のバージョンで
    挙動が変
    この部分を高度化・高速化
    =不確実性が減る

    View Slide

  4. 机上検証で確認するポイント
    ◼設定が実装バグ無く動けば設計意図が反映される状態
    ◼ NWの設計意図を「正しく」設定できているか
    ◼ End-to-Endを模擬して通信できるか
    ◼「正しい」ことのチェック
    ◼ 各レイヤで齟齬の無いトポロジ図が書けるはずだ
    ◼ 既存設定ファイルからもそのトポロジは再構築できるはずだ
    → これらを支援するシステムが必要
    4

    View Slide

  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

    View Slide

  6. 設計支援システム
    ◼人を中心とする設計検証からトポロジモデル中心へ
    ◼モデルに基づいたデータの作成と確認を支援
    6
    検証環境
    本番環境
    自動テスト
    確認
    トポロジモデル
    config

    View Slide

  7. トポロジモデルの使用
    ◼人間と機械が役割分担できるよう、共通の言語が必要
    → トポロジモデルという共通表現の導入
    7
    人間のレビュー
    可能範囲
    機械化
    可能
    実機での検証
    ◼人間によるレビューの特徴
    ◼ 全体を見て大域的判断、経験
    による判断が可能
    ◼ 時間コストや網羅性が不得意
    ◼機械によるレビューの特徴
    ◼ 実装されたルールを網羅的に
    素早く評価可能
    ◼ 知らないことは判断できない
    不確実性をできるだけ
    事前に取り除く

    View Slide

  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/

    View Slide

  9. 設計のステップと支援箇所
    1. 候補configの作成
    ◼ (人間による設計)
    2. トポロジ構築と静的検査
    ◼ システムによる支援
    3. NWのふるまいを確認
    ◼ システムによる支援
    4. 検査OKであれば検証環境に
    デプロイ
    ◼ (本システムの対象外)
    9
    2.
    3.

    View Slide

  10. システム詳細
    10
    運用対象NW
    device
    config &
    state
    layer1
    topology
    topology
    data
    L1-L3
    トポロジ
    生成
    各種
    テスト
    検査
    テスト・検査結果に応じて
    コンフィグの修正
    必要なら環境へのフィードバック
    (ここは従来のやり方で)
    config, stateは
    定期的に取得
    operator
    L1
    リンク情報
    抽出
    WebUI
    (可視化)
    API
    Wrapper
    Parser,
    Simulator
    NetBox
    Batfish
    Ansible
    2.トポロジ構築と静的検査
    3. NWのふるまいを確認

    View Slide

  11. 2. トポロジデータ構築と静的検査
    ◼各レイヤでトポロジデータを構築
    ◼各レイヤ内、およびレイヤ間で
    整合性がとれているかをチェック
    ◼ 例)L1リンクが接続しているが、L2セグメントが分離
    ◼ 人間が確認する際の「つながっているか」「正しいか」を
    見るようにレイヤ間の関連性もチェックする
    ◼ L1から順番に積み上げていく
    ◼データ記述はRFC8345の定義を使用
    11

    View Slide

  12. L1データ作成
    ◼descriptionからリンクのペアを抽出
    ◼ 後述の障害テストパターン作成時にも使用
    ◼物理的なリンクを示すので
    孤立はしないはず
    =全体として連結なグラフになる
    ◼冗長なリンクは冗長に表現される
    12
    Layer 1

    View Slide

  13. L2データ作成
    ◼LAGも考慮した論理インターフェースのグラフ
    ◼インターフェースの各VLANは
    それぞれのブロードキャストドメインとして表現
    ◼ブロードキャストドメイン名でも
    間にL1リンクが無いと孤立
    ◼ 例)vlanミスマッチの発見
    13

    View Slide

  14. L3データの作成
    ◼L3ノードとネットワークセグメントのグラフ
    ◼ L3ノードとはIPアドレスを持つ論理インターフェース
    ◼同じブロードキャストドメインのノードは
    一つのセグメントを作る
    ◼セグメントが異なると孤立
    ◼ 例)prefix間違いの発見
    14

    View Slide

  15. トポロジデータ構築と静的検査
    ◼これまでの各stepを経ることで
    各レイヤごとのモデルデータが生成
    ◼エラーがあった場合は都度config修正のち再実施
    ◼トポロジデータの確認用に各レイヤを対応づけて表示
    できるUIを用意した
    15

    View Slide

  16. 設計のステップと支援箇所
    1. 候補configの作成
    ◼ (人間による設計)
    2. トポロジ構築と静的検査
    ◼ システムによる支援
    3. NWのふるまいを確認
    ◼ システムによる支援
    4. 検査OKであれば検証環境に
    デプロイ
    ◼ (本システムの対象外)
    16
    2.
    3.

    View Slide

  17. 3. ネットワークのふるまいを確認
    ◼ふるまい=要件通りに動くかどうかを検査
    ◼ 要件で定められたE2Eの通信ができる
    ◼ 耐障害性などの可用性要件
    ◼それぞれの確認方法
    ◼ E2Eのシミュレータ Batfish を使う
    ◼ 障害模擬したトポロジを再構築し、影響調査
    17

    View Slide

  18. 障害模擬とモデルの再評価
    1. L1リンクやノードを1つ欠落させる
    2. 再度L2以上のトポロジデータを作成する
    3. 欠落の無い場合のグラフと比較
    ◼ 差異の箇所の重み付け和を評価点とした
    ◼ 評価点が高いものほど単一の障害で重篤なエラーを引き起こ
    していると見なせる
    18
    Layer 1
    Layer 2 Layer 3

    View Slide

  19. システムを用いた設計作業例:SPoF検出
    1. ある障害模擬ケースに高い点数の差異(システム)
    ◼ NWが分断されL3で多数のセグメントが非連結に
    2. configを確認し詳しく見て原因究明(人間)
    ◼ 当該リンク周辺を調査
    3. configを修正(人間)
    4. 再度評価(システム)
    5. 修正を確認(人間)
    ◼ 再実行し差異が減ったことを確認
    19
    1.
    2.
    3.
    4.
    5.

    View Slide

  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

    View Slide

  21. 今後の展望
    ◼L1~L3だけでなく、上位レイヤの検査追加
    ◼デプロイ部分まで実装し、トポロジデータ中心の運用
    効果を検証
    21
    検証環境
    本番環境
    自動テスト
    確認
    トポロジモデル
    config

    View Slide

  22. まとめ
    ◼設計支援システムを実装
    ◼ 実機検証に入る前に十分に机上検証することが目的
    ◼ 設定ファイルから各レイヤのトポロジを抽出
    ◼ 人手で考えるような静的解析による設定誤りの検出を実装
    ◼ トポロジの障害模擬を実装しSPoFの検出が可能
    ◼ 全パターン検査は機器240台リンク720本の規模でも
    2.3時間で実行完了
    ◼今後の展望
    ◼ 各種プロトコル対応
    ◼ トポロジデータの自動デプロイ
    22
    コードは公開されています https://github.com/ool-mddo/playground
    本研究は著者らの所属会社が、沖縄オープンラボラトリにて協同研究を行った成果です

    View Slide