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

© NTT Communications Corporation All Rights Reserved. 1
NW運用におけるモデル定義と
Reconciliation Loopへの挑戦
田島照久
[email protected]
NTT Communications / Innovation Center
2022/03/23 NTT Tech Conference 2022

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

本当にモデルは使えるのか検証：SPoF検出
◼ NW設計時にSPoF(単一障害点)を調べることが多い
⚫ 構成機器に多様性があるので複数の機器の意味を知る必要がある
⚫ 人間のレビューでは網羅性に難がありそう
→モデルによる実装をしてみる
◼ モデルデータを用いた試験～修正後の再試験まで

View Slide

検証環境
本番環境
自動テスト
App
Server
NW
Ops
Ops
ターゲット
Reconciliation Loopに必要な技術要素
モデル作成・更新
モデル上での操作
モデルの評価
適用

View Slide

システム構成
運用対象NW
device
config &
state
layer1
topology
topology
data
L1-L3
トポロジ
生成
各種
テスト
検査
テスト・検査結果に応じて
コンフィグの修正
必要なら環境へのフィードバック
(ここは従来のやり方で)
config, stateは
定期的に取得
operator
L1
リンク情報
抽出
WebUI
(可視化)
API
Wrapper
Parser,
Simulator
NetBox
Batfish
Ansible
push(定期・手動)時に
一連の検査を自動実行

View Slide

運用対象ネットワーク
◼ 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物理サーバ上に構築

View Slide

仕込んだ単一障害点：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間がリンク
ダウンすると・・・

View Slide

トポロジデータ作成
運用対象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”

View Slide

トポロジデータを使ったテスト
運用対象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到達性チェック

View Slide

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

View Slide

E2EのL3到達性チェック
テストが通らなかった
(到達 = ACCEPTEDを期待していたがNO_ROUTEになった)
12/144 で Fail
144 = 36 snapshots(links) * 4 flows
テストケース (No.19)
RegionA-PE01～CE01間のリンクダウン

View Slide

E2EのL3到達性チェック（続き）
No.19 が怪しい
テストケース(4flows)すべてでFailしている
Hops列
Server → CE (default gateway) で止まっている?
PE01 PE02
CE01 CE02
Acc01
RegionA
NO_ROUTE
Layer1 Layer3

View Slide

原因調査後、config pushしてトポロジデータ再作成
◼ configを修正しpush
◼ 修正したconfigに基づいて
トポロジデータが再作成される
◼ 再度テストを行って先ほどの
問題の解決を確認
テスト再実行
NO_ROUTEは出なくなった

View Slide

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

View Slide

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

View Slide

まとめ
◼ 各レイヤーのグラフをモデルとしNW全体構成を把握した
→ SPoF検出というタスクに関しては実用できそうなことがわかった
◼ work-in-progressなプロジェクト
⚫ 読み取り部分だけなので書き込みの部分の実装
⚫ IPv6対応が足りていないので実装
⚫ 各社でドッグフーディングしていく
◼ 沖縄オープンラボラトリでの3社協同検証プロジェクト
⚫ FYI 2021活動報告 https://www.okinawaopenlabs.org/mdnd
⚫ 各種リポジトリ（整備中） https://github.com/ool-mddo
⚫ 3月末ごろ各社から紹介ブログ記事を出す予定

View Slide

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

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

tjmtrhs

More Decks by tjmtrhs

Other Decks in Technology

Featured

Transcript