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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© NTT Communications Corporation All Rights Reserved. 2 あらまし ◼ ネットワークもモデルを起こして実環境と同期させれば「何だか難しそうなネットワーク運用」から脱出できるのでは？？ ◼ モデルをベースとしたオペレーションの有用性確認・実装のために 3社が(一社)沖縄オープンラボラトリで協同検証中 ⚫ TIS株式会社 ⚫ ビッグローブ株式会社 ⚫ NTT Com

Slide 3

Slide 3 text

© NTT Communications Corporation All Rights Reserved. 3 ネットワーク運用につきまとう問題その1 ◼ ノード単体だけではなく系としての関係性が重要 ⚫ =分散システムとしての問題で根本的にどうにかなる課題では無い ⚫ コンフィグベース・台帳ベースの人力運用では規模の増加に追いつけない ⚫ 複数ノード間の関係性が見えないと正しい操作ができないが人間によるレビューだと品質の不安定さやスケールしない問題 ⚫ 自動化もノード間の関係性を把握する拡張が必要機器単体の設定は動作可能という意味で正しい End-to-Endでは通信できない？両立しうる

Slide 4

Slide 4 text

© NTT Communications Corporation All Rights Reserved. 4 ネットワーク運用につきまとう問題その2 ◼ 既存の仕組みを補完し、目の前の課題に合せて小さく始めたい ⚫ 大きなソリューションがフィットする環境ばかりではない ⚫ 従来のやり方を大幅に変えるのは難しく、抵抗感も大きい ⚫ 汎用的な製品とシステム固有の制約のギャップを埋める必要既存環境(brown field) の構成情報・ノード間の関係性をうまく抽出し次のオペレーションに活用する方法はあるか？ 🤔 😊

Slide 5

Slide 5 text

© NTT Communications Corporation All Rights Reserved. 5 検証環境本番環境自動テスト App Server NW Ops 「構成図」としての表現で複雑なシステム全体像の俯瞰 ↓ 担当範囲の異なる担当者間での共通理解 ”どこで何をすべきか” わかることシステムの”モデル”を核としたオペレーション「あるべき姿(理想)」と現状のギャップを把握可能 ↓ 宣言的なシステム運用自動テストなどソフトウェア開発・クラウド開発のベストプラクティスの取り込み不確実性の低減例）静的な検査・動的なテスト練習・トレーニング・育成 Ops ターゲット (既存システム) 「モデル」で実現したいReconciliation Loop

Slide 6

Slide 6 text

© NTT Communications Corporation All Rights Reserved. 6 検証環境本番環境自動テスト App Server NW Ops Ops ターゲット (既存システム) ネットワーク運用の難しさをモデルで解決できないか機種ごとに設定が正規化されていない → 抽象レイヤーとしてのモデル表現が使えそうノードが多く障害パターンが膨大になりがち → 全探索はまさに計算機が得意そう物理を扱うことが多く時間がかかる → IaCで扱いやすくすることで仮想環境の併用ができそう設定を入れてみないとわからない雰囲気 → 形式的なバリデーション＆シミュレーションができそう

Slide 7

Slide 7 text

© NTT Communications Corporation All Rights Reserved. 7 検証環境本番環境自動テスト App Server NW Ops Ops ターゲット (既存システム) なぜモデルが必要なのか？これまでの「自動化」は設定投入の工数削減がメイン →投入ミスは確かに減るが、設計の正しさが次の課題 → 試行錯誤のサイクルを早く回せば、おのずと品質は上がるのではないかこれを早く回す

Slide 8

Slide 8 text

© NTT Communications Corporation All Rights Reserved. 8 なぜモデルが必要なのか？ (続き) ◼ 人間によるレビューの特徴 ⚫ 全体を見て大域的判断、経験による判断が可能 ⚫ 時間コストや網羅性が不得意 ◼ 機械によるレビューの特徴 ⚫ 実装されたルールを網羅的に素早く評価可能 ⚫ 知らないことは判断できない役割分担するのにモデルという機械判読可能な共通表現の導入人間のレビュー可能範囲機械化可能やってみないとわからないを早く検出

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

© 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(定期・手動)時に一連の検査を自動実行

Slide 12

Slide 12 text

© 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物理サーバ上に構築

Slide 13

Slide 13 text

© 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間がリンクダウンすると・・・

Slide 14

Slide 14 text

© 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”

Slide 15

Slide 15 text

© 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到達性チェック

Slide 16

Slide 16 text

© NTT Communications Corporation All Rights Reserved. 16 各レイヤのNW構成変化をチェック OriginalとLink-downを比較し非連結になった部分、新たに発生した(減少した)ループ構造の数など、 NW構造として明確な変化があるものをスコア化 ⚫ 最小スコア 2: リンクダウンによって減少した “オブジェクト” の数 ⚫ 最大スコア 23: 9パターンで出ていることから典型的な変化と推測 ⚫ スコア変化は相対的なもの : 構成や加えた変更などを基にある程度推測できるようになるはず →レビューの確認項目等をスコアで重み付けし、インパクトを推測可能スコア個数 (link-down 全36パターン)

Slide 17

Slide 17 text

© 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間のリンクダウン

Slide 18

Slide 18 text

© 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

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© NTT Communications Corporation All Rights Reserved. 20 検証：SPoF検出の結果（想定通りな点） ◼ 人手ではできないテストの実現 ⚫ 網羅テスト : 範囲(NW全体に対して)・組み合わせ(パターン) • 「やってみて初めて気づいた」の回避 ◼ こうした検討トライアルを分単位で実施可能 ⚫ 自動化、CI/テストドリブンな手法のとりこみ ⚫ 今回のデモの規模・内容だと数分～ • 検討段階でも試せる・実機/実環境がなくても試せる ⚫ 「やってみないとわからない」の回避 • 実機の調整→設定→動作確認よりもイテレーション間隔を短縮できる

Slide 21

Slide 21 text

© NTT Communications Corporation All Rights Reserved. 21 検証：SPoF検出の結果（課題点） ◼ Batfish依存問題 ⚫ 市販製品導入時の制約事項と同様の制約が起きうる ⚫ Config parserとしての機能は比較的簡単に代替できる ⚫ Network simulationをどうするか (IPv6対応問題) • Write方向技術との組み合わせ…実働NWからの状態取り込み ⚫ スケーラビリティ ◼ できあがったトポロジデータ、Query結果検証の難しさ ◼ データの読み取り・分析→デプロイまでのサイクル ⚫ 動的な検証環境との併用・組み合わせ、stateの取り込み ◼ 実ネットワークの構造や機能の取り込み・モデル化 ⚫ 動的ルーティングプロトコル、L4以上の機能/ノード、仮想ネットワーク

Slide 22

Slide 22 text

© 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月末ごろ各社から紹介ブログ記事を出す予定