NW運用におけるモデル定義とReconciliation Loopへの挑戦

NWモデルを定義し、実機の設定とreconcile loopを回すことで設計意図を反映した収束を目指してOkinawa Open Labsの元でTIS、BIGLOBEと3社プロジェクトとして開発しています。価格や開発面でハードルが高くなりがちなベンダー製品ではなく、OSSをベースとしCI/CDパイプラインを作成中です。この仕組みを使うことで、実機の設定や状態を吸い上げモデルを作成し、机上でトレーニングや障害シミュレーションを行うデモを行います。

Transcript

1. © NTT Communications Corporation All Rights Reserved. 1 NW運用におけるモデル定義と Reconciliation Loopへの挑戦 田島 照久 teruhisa.tajima@ntt.com NTT Communications / Innovation Center 2022/03/23 NTT Tech Conference 2022
2. © NTT Communications Corporation All Rights Reserved. 2 あらまし ◼ ネットワークもモデルを起こして実環境と同期させれば 「何だか難しそうなネットワーク運用」から脱出できるのでは？？ ◼ モデルをベースとしたオペレーションの有用性確認・実装のために 3社が(一社)沖縄オープンラボラトリで協同検証中 ⚫ TIS株式会社 ⚫ ビッグローブ株式会社 ⚫ NTT Com
3. © NTT Communications Corporation All Rights Reserved. 3 ネットワーク運用につきまとう問題 その1 ◼ ノード単体だけではなく系としての関係性が重要 ⚫ =分散システムとしての問題で根本的にどうにかなる課題では無い ⚫ コンフィグベース・台帳ベースの人力運用では規模の増加に追いつけない ⚫ 複数ノード間の関係性が見えないと正しい操作ができないが 人間によるレビューだと品質の不安定さやスケールしない問題 ⚫ 自動化もノード間の関係性を把握する拡張が必要 機器単体の設定は 動作可能という意味で正しい End-to-Endでは 通信できない ？ 両立しうる
4. © NTT Communications Corporation All Rights Reserved. 4 ネットワーク運用につきまとう問題 その2 ◼ 既存の仕組みを補完し、目の前の課題に合せて小さく始めたい ⚫ 大きなソリューションがフィットする環境ばかりではない ⚫ 従来のやり方を大幅に変えるのは難しく、抵抗感も大きい ⚫ 汎用的な製品とシステム固有の制約のギャップを埋める必要 既存環境(brown field) の構成情報・ノード間の関係性をうまく抽出し 次のオペレーションに活用する方法はあるか？ 🤔 😊
5. © NTT Communications Corporation All Rights Reserved. 5 検証環境 本番環境 自動テスト App Server NW Ops 「構成図」としての表現で 複雑なシステム全体像の俯瞰 ↓ 担当範囲の異なる担当者間での共通理解 ”どこで何をすべきか” わかること システムの”モデル”を核としたオペレーション 「あるべき姿(理想)」と現状のギャップを把握可能 ↓ 宣言的なシステム運用 自動テストなどソフトウェア開発・クラウド開発の ベストプラクティスの取り込み 不確実性の低減 例）静的な検査・動的なテスト 練習・トレーニング・育成 Ops ターゲット (既存システム) 「モデル」で実現したいReconciliation Loop
6. © NTT Communications Corporation All Rights Reserved. 6 検証環境 本番環境 自動テスト App Server NW Ops Ops ターゲット (既存システム) ネットワーク運用の難しさをモデルで解決できないか 機種ごとに設定が正規化されていない → 抽象レイヤーとしてのモデル表現が使 えそう ノードが多く障害パターンが膨大になりがち → 全探索はまさに計算機が得意そう 物理を扱うことが多く時間がかかる → IaCで扱いやすくすることで仮想環境 の併用ができそう 設定を入れてみないとわからない雰囲気 → 形式的なバリデーション＆シミュレー ションができそう
7. © NTT Communications Corporation All Rights Reserved. 7 検証環境 本番環境 自動テスト App Server NW Ops Ops ターゲット (既存システム) なぜモデルが必要なのか？ これまでの「自動化」は設定投入の工数削減がメイン →投入ミスは確かに減るが、設計の正しさが次の課題 → 試行錯誤のサイクルを早く回せば、おのずと品質は上がるのではないか これを早く回す
8. © NTT Communications Corporation All Rights Reserved. 8 なぜモデルが必要なのか？ (続き) ◼ 人間によるレビューの特徴 ⚫ 全体を見て大域的判断、経験による判断が可能 ⚫ 時間コストや網羅性が不得意 ◼ 機械によるレビューの特徴 ⚫ 実装されたルールを網羅的に素早く評価可能 ⚫ 知らないことは判断できない 役割分担するのにモデルという 機械判読可能な共通表現の導入 人間のレビュー 可能範囲 機械化可能 やってみないとわからない を早く検出
9. © NTT Communications Corporation All Rights Reserved. 9 本当にモデルは使えるのか検証：SPoF検出 ◼ NW設計時にSPoF(単一障害点)を調べることが多い ⚫ 構成機器に多様性があるので複数の機器の意味を知る必要がある ⚫ 人間のレビューでは網羅性に難がありそう →モデルによる実装をしてみる ◼ モデルデータを用いた試験～修正後の再試験まで
10. © NTT Communications Corporation All Rights Reserved. 10 検証環境 本番環境 自動テスト App Server NW Ops Ops ターゲット (既存システム) Reconciliation Loopに必要な技術要素 モデル作成・更新 モデル上での操作 モデルの評価 適用
11. © NTT Communications Corporation All Rights Reserved. 11 システム構成 運用対象NW device config & state layer1 topology topology data L1-L3 トポロジ 生成 各種 テスト 検査 テスト・検査結果に応じて コンフィグの修正 必要なら環境へのフィードバック (ここは従来のやり方で) config, stateは 定期的に取得 operator L1 リンク情報 抽出 WebUI (可視化) API Wrapper Parser, Simulator NetBox Batfish Ansible push(定期・手動)時に 一連の検査を自動実行
12. © NTT Communications Corporation All Rights Reserved. 12 運用対象ネットワーク ◼ protocols ⚫ Simple BGP, OSPF ⚫ L2/L3 LAG ⚫ VRF ⚫ VLAN ⚫ VRRP ◼ 11 Virtual Appliance + 4 VM ⚫ (Cisco IOS XRv) ⚫ Juniper vMX (vQFX) ⚫ Arista vEOS ⚫ Ubuntu server ⚫ vrnetlabとDocker Swarmで 2物理サーバ上に構築
13. © NTT Communications Corporation All Rights Reserved. 13 仕込んだ単一障害点：CE間のOSPF設定を入れ忘れ PE01 PE02 CE01 CE02 Acc01 0/0 iBGP eBGP eBGP OSPF VRRP NO_ROUTE 本来はCE01-02間もOSPF Area CEがuplinkしかAreaに入っていないので 切れるとRegion内経路がはいってこない RegionA RegionB PE01 PE02 CE01 CE02 Acc01 0/0 iBGP eBGP eBGP OSPF VRRP RegionB PE/CE間がリンク ダウンすると・・・
14. © NTT Communications Corporation All Rights Reserved. 14 トポロジデータ作成 運用対象NW device config & state layer1 topology topology data L1-L3 トポロジ 生成 各種 テスト 検査 テスト・検査結果に応じて コンフィグの修正 必要なら環境へのフィードバック (ここは従来のやり方で) config, stateは 定期的に取得 operator L1 リンク情報 抽出 WebUI (可視化) API Wrapper Parser, Simulator • 定期的に保存されているconfigを基にL1/L2/L3を復元 • Original snapshotとする • Link-down snapshot (L1リンク障害の全パターン) 生成 • 差分情報・メタデータの生成 • データ構造はRFC8345を参考に実装 • “A YANG Data Model for Network Topologies”
15. © NTT Communications Corporation All Rights Reserved. 15 トポロジデータを使ったテスト 運用対象NW device config & state layer1 topology topology data L1-L3 トポロジ 生成 各種 テスト 検査 テスト・検査結果に応じて コンフィグの修正 必要なら環境へのフィードバック (ここは従来のやり方で) config, stateは 定期的に取得 operator L1 リンク情報 抽出 WebUI (可視化) API Wrapper Parser, Simulator • Original/Link-down snapshotの各レイヤを比較 • ノード・リンク等の増減 • ループの増減 • 非連結なNWの数の増減 • それらの重み付け + スコア化 • End-to-EndのL3到達性チェック
16. © NTT Communications Corporation All Rights Reserved. 16 各レイヤのNW構成変化をチェック OriginalとLink-downを比較し 非連結になった部分、新たに発生した(減少した)ループ構造の数など、 NW構造として明確な変化があるものをスコア化 ⚫ 最小スコア 2: リンクダウンによって減少した “オブジェクト” の数 ⚫ 最大スコア 23: 9パターンで出ていることから典型的な変化と推測 ⚫ スコア変化は相対的なもの : 構成や加えた変更などを基にある程度推測できる ようになるはず →レビューの確認項目等をスコアで重み付けし、インパクトを推測可能 スコア 個数 (link-down 全36パターン)
17. © NTT Communications Corporation All Rights Reserved. 17 E2EのL3到達性チェック テストが通らなかった (到達 = ACCEPTEDを期待していたがNO_ROUTEになった) 12/144 で Fail 144 = 36 snapshots(links) * 4 flows テストケース (No.19) RegionA-PE01～CE01間のリンクダウン
18. © NTT Communications Corporation All Rights Reserved. 18 E2EのL3到達性チェック （続き） No.19 が怪しい テストケース(4flows)すべてでFailしている Hops列 Server → CE (default gateway) で止まっている? PE01 PE02 CE01 CE02 Acc01 RegionA NO_ROUTE Layer1 Layer3
19. © NTT Communications Corporation All Rights Reserved. 19 原因調査後、config pushしてトポロジデータ再作成 ◼ configを修正しpush ◼ 修正したconfigに基づいて トポロジデータが再作成される ◼ 再度テストを行って先ほどの 問題の解決を確認 テスト再実行 NO_ROUTEは出なくなった
20. © NTT Communications Corporation All Rights Reserved. 20 検証：SPoF検出の結果（想定通りな点） ◼ 人手ではできないテストの実現 ⚫ 網羅テスト : 範囲(NW全体に対して)・組み合わせ(パターン) • 「やってみて初めて気づいた」の回避 ◼ こうした検討トライアルを分単位で実施可能 ⚫ 自動化、CI/テストドリブンな手法のとりこみ ⚫ 今回のデモの規模・内容だと数分～ • 検討段階でも試せる・実機/実環境がなくても試せる ⚫ 「やってみないとわからない」の回避 • 実機の調整→設定→動作確認よりもイテレーション間隔を短縮できる
21. © NTT Communications Corporation All Rights Reserved. 21 検証：SPoF検出の結果（課題点） ◼ Batfish依存問題 ⚫ 市販製品導入時の制約事項と同様の制約が起きうる ⚫ Config parserとしての機能は比較的簡単に代替できる ⚫ Network simulationをどうするか (IPv6対応問題) • Write方向技術との組み合わせ…実働NWからの状態取り込み ⚫ スケーラビリティ ◼ できあがったトポロジデータ、Query結果検証の難しさ ◼ データの読み取り・分析→デプロイまでのサイクル ⚫ 動的な検証環境との併用・組み合わせ、stateの取り込み ◼ 実ネットワークの構造や機能の取り込み・モデル化 ⚫ 動的ルーティングプロトコル、L4以上の機能/ノード、仮想ネットワーク
22. © NTT Communications Corporation All Rights Reserved. 22 まとめ ◼ 各レイヤーのグラフをモデルとしNW全体構成を把握した → SPoF検出というタスクに関しては実用できそうなことがわかった ◼ work-in-progressなプロジェクト ⚫ 読み取り部分だけなので書き込みの部分の実装 ⚫ IPv6対応が足りていないので実装 ⚫ 各社でドッグフーディングしていく ◼ 沖縄オープンラボラトリでの3社協同検証プロジェクト ⚫ FYI 2021活動報告 https://www.okinawaopenlabs.org/mdnd ⚫ 各種リポジトリ（整備中） https://github.com/ool-mddo ⚫ 3月末ごろ各社から紹介ブログ記事を出す予定