ネットワークのデジタルツインに求める要件は何ですか？/janog57

トップページ - JANOG57 Meeting in Osaka https://www.janog.gr.jp/meeting/janog57/

ネットワークのデジタルツインに求める要件は何ですか？～理想的な仮想環境への期待と現状～ - JANOG57 Meeting in Osaka https://www.janog.gr.jp/meeting/janog57/digital-twin/

Transcript

1. ネットワークのデジタルツインに 求める要件は何ですか？ ～理想的な仮想環境への期待と現状～ © 2026 Okinawa Open Laboratory 1 2026/02/11-13, JANOG57 in OSAKA TIS株式会社 萩原 学 NTTドコモビジネス株式会社 田島 照久 伊藤忠テクノソリューションズ株式会社 山口 大樹 沖縄オープンラボラトリ
2. 登壇者紹介 © 2026 Okinawa Open Laboratory 2 田島 照久 Teruhisa Tajima NTTドコモビジネス 株式会社 萩原 学 Manabu Hagiwara TIS株式会社 山口 大樹 Daiki Yamaguchi 伊藤忠テクノソリューションズ 株式会社 net – dev - night ↑ 有志勉強会やっています 次回#3は 2/25 (もうすぐ締切) 本を書いたよ！ (12/22-発売中) NW自動化・運用高度化を担当 JANOG54:ネットワーク機器の 試験自動化BoF 初登壇
3. タイムテーブル 10:40～11:40 5分 セッション概要 12分 ネットワークデジタルツインの実用に向けた課題 12分 課題に対するアプローチ・デモ解説 30分 質疑/ディスカッション © 2026 Okinawa Open Laboratory 3
4. 議論ポイント • 従来のラボ環境にせよ、NDTにせよ、 100%商用環境を再現可能な技術はない • (コストが許す範囲で)既存のラボ環境で やれることはおおむねやってるはず • それだけでは足りないこと、 NDTに期待できるのはどこまでか? © 2026 Okinawa Open Laboratory 4 Hype Cycle for Enterprise Networking, 2024 - Telefónica Global Solutions https://globalsolutions.telefonica.com/en/news/hyp e-cycle-for-enterprise-networking-2024/ 試してみた ギャップ 現実的な利用シーン (従来のラボ環境の基準で) 「◦◦が検証できないならNDTなんて意味ない」 なぜ? 本当にそう? • All-or-Nothingで話をしてしまうと今のやり方から抜け出せない • 何が言えればどんなことが実現できるのかをみんなで考えたい あと何を・どこまでできれば、 今のシンドイやり方を、部分的にでも 変えられると思いますか? 4
5. フォーカスしないこと • べき論、理想論、NDTの定義 • 例）NDTはこうあるべきだ • 具体的な使い方、導入～実用上の課題点、これから実際にやれるこ とについて議論したい • 個々の機能の差分 • 例）XXでは◦◦ができるのか、できないのか • なぜ・どんな状況で・何を実現したいから"◦◦が必要だ"という話 をしたい © 2026 Okinawa Open Laboratory 5
6. なぜNDTが必要なのか? © 2026 Okinawa Open Laboratory 6
7. モデル中心運用 • Excel台帳から構造化データを基にした運用システムへ • 「高度な運用」を実現するために何が必要か? © 2026 Okinawa Open Laboratory 7 人がやっていることを システム(and/or AI)にオフロードしないと 「高度にする」のは難しい そのための「モデル中心」 運用対象 システム 運用者 AI コード・ 構造化データ (DB) 自動化ツール・ 運用サービス 人力作業にシステムが介入・ 支援できるようにする システムができることは データに依存する
8. モデルによって解決したいこと • 実際に運用しているネットワーク(商用環境)とその「状況」を データとして表現する • 脳内メモリに納まりきらない「複雑さ」をシステムでフォローする • 複雑さのフォロー • 過去事象の分析 • 障害原因分析(RCA) • 将来事象の予測 • 構成変更作業、オペレーションの妥当性検証、サービス影響確認 • 小規模な検証環境では見通すのが難しい動きの検知・発見 • KKD(勘・経験・度胸)運用の低減 • 「本番一発勝負」の回避 © 2026 Okinawa Open Laboratory 8 ネットワーク デジタルツイン その手段, 実現方法
9. 参考: 過去報告 • これまで…NDTが実際に作れるかどうかを中心 • JANOG51: もし商用ネットワークをまるごと仮想環境に”コピー”できたらうれしい ですか? (2023年1月) • JANOG53: BIGLOBE AS2518をまるごと仮想環境へ”コピー”してみた (2024年1月) • OOD2024: 運用者の試行錯誤を想定した NWモデル上での並列検証システム (2024年 12月) • 今回は「作れる」から「実際に運用の中で応用できる」に視点を移動 © 2026 Okinawa Open Laboratory 9
10. そもそも 「デジタルツイン」って何? デジタルツインに対する解像度を上げる © 2026 Okinawa Open Laboratory 10
11. デジタルツイン © 2026 Okinawa Open Laboratory 11 情報通信白書 for Kids：インターネットの活用：デジタルツインって何？ https://www.soumu.go.jp/hakusho-kids/use/economy/economy_11.html 総務省｜令和6年版 情報通信白書｜デジタルツイン https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r06/html/nd217530.html デジタルツイン（Digital Twin）とは 現実世界から集めたデータを基に デジタルな仮想空間上に双子（ツイン）を構築し、 さまざまなシミュレーションを行う技術である。 デジタルツイン シミュレーション 再現環境の違い 現実世界をコンピュータ上の仮 想空間に再現する コンピュータ以外(模型など)で も実行されることがある リアルタイム性 の違い 現実世界の状況に合わせて、そ の都度変化するためリアルタイ ム性が高い 「ある時点でのモデル」を活用 する 精度の違い 実在する現実世界を再現する いくつかの仮説をベースに実行 する デジタルツインとは？わかりやすく最新技術を徹底解説。メリットや導入事例も！｜SCSK IT Platform Navigator https://www.scsk.jp/sp/itpnavi/article/2024/11/digitaltwin.html ネットワーク・デジタルツイン(NDT)は、 これをネットワークシステムに対して 応用するもの IETF(NMRG)やITUのNDT関連資 料では現実-仮想「マッピング」 みたいな言い方
12. NDT: どこから・何のために? © 2026 Okinawa Open Laboratory 12 ～2000 2000 2010 2020 2025 関連技術 (一般) 応用分野 (ネットワーク) 関連技術 (ネットワーク) 「デジタルツイン」 提唱(2002) ネットワーク シミュレーション技術 Programmable Network SDN, NW仮想化/NFV IoT クラウド AI(DL) GPU 5G 生成AI/LLM CAD/CAE Computer Aided Design/Engineering ネットワーク テレメトリ IBN Intent Based Network いくつかの技術系譜がある • モデル化・シミュレーション • プログラマブルネットワーク • 状態把握技術の発展 現実世界を仮想空間(計算機内)で再 現・模擬して、品質向上・リスク低 減等を狙う (多くの応用では物理現象・ 物理法則のシミュレーション) それを支えるための様々な技術 …データの収集(通信)・分析 その実現手段であるNW自体にも デジタルツインの考え方を適用しよう Industory4.0 (製造業,2011) Society5.0 (社会,2016) NWモデル モデル駆動 構成解析 ・検証 ネットワーク・ デジタルツイン (2019-2020)
13. NDT: 実装の分類 © 2026 Okinawa Open Laboratory 13 方式 数理モデル型 仮想NW型 概要 商用NWからある時点のトポロジ・ノード設定・状態を 収集(snapshot)し、それらのデータを基に実NWの動 作シミュレーション・問題分析をする。 データモデルとしてのNDT 商用NWのある時点のトポロジ・ノード設定を (snapshot)を基に、仮想NWを構築する。 実NWをエミュレーションする。 実働する仮想NWとしてのNDT 特徴 環境 サイズ ◎ 扱える環境サイズ(ノード数)が大きい △ 扱える環境サイズに限界がある (物理NWよりは大きくしやすい) 状態 再現 ◎ 元環境の状態に沿って分析可能 × 元環境の状態を直接再現できない (構成を合わせて状態を近づけることしかできない) 将来 構成 × NWトポロジ変更など、現在の状態を基にできな い将来構成での動作を予測できない ◎ 実働するNWノードを立てるので、トポロジ変更 等による将来構成での動作を予測できる プロダクト Forward Networks, NetworkBrain Cisco Modeling Labs, OSS(GNS3, Containerlab) etc 従来の「ラボ環境」とのちがいは? 過去状況の再現・問題分析に強い これからの予測(構成変更)に強い
14. 参考: NDT事例 © 2026 Okinawa Open Laboratory 14 2025/11/25 デジタルツインを活用したメトロネットワークの運用自動化システムを全国展 開～ゼロタッチ運用を実現し、国内で初めてTM Forumの「Autonomous Networks」レベル3認定を取得～ | 企業・IR | ソフトバンク https://www.softbank.jp/corp/news/press/sbkk/2025/20251125_02/ 2025/3/11 【開催報告 & 資料公開】テレコム業界向け AWS re:Invent 2024 Recap – インダストリー 編 | Amazon Web Services ブログ https://aws.amazon.com/jp/blogs/news/reinvent2024-recap-telecom/
15. 我々が求めるNDT 実装としての前提と、期待する効果 © 2026 Okinawa Open Laboratory 15
16. NDTを用いた検証への期待 © 2026 Okinawa Open Laboratory 16 物理検証環境 • 必然的にサイズ限定 • (ある程度)同じモノを使える • 範囲を限定するために都度設 計する 仮想検証環境 • サイズは物理より増やしやすい • 使うモノが同じとは言い切れない • 同じく都度設計して環境を作る 商用環境のNDTに対する期待 • 大規模・複雑で、人力では把握しきれない ところで深刻なトラブルが起きる …そもそも「把握しきれない」ことが前提 • 都度設計しない(現状をそのまま再現する) • 試行錯誤を速くする 従来のラボ環境の「外側」にある ことにリーチしようとしている 従来のラボ環境での検証
17. NDT: 従来の"ラボ環境"との違い? © 2026 Okinawa Open Laboratory 17 クラウドネイティブ的な考え方・運用プラクティス • CI/CDプロセス • Reconciliation Loop • 一時的(ephemeral)な検証環境 (仮想NW型) • APIベースのリソース操作 データモデリング・データを基にした効率化 • 対象を詳細に表現するデータモデル • モデル上での検証(verify)・シミュレーション・分析 • 自動化・宣言的アプローチ (仮想NW型) 商用 NW NDT システム構成等の データ NDT: 想定しきれない現実世界の構造・状態に基づく • 「現実世界」の構造や動き(ふるまい)の再現を基準にする • 現実世界の時間軸(リアルタイム性)を考慮する 従来: 設計上想定される機能、動作パターンの確認
18. NDT: われわれのターゲット 現実世界のモノ 既存の物理ネットワーク 現実世界の人 ネットワークオペレータ 現実世界で困っていること・ NDTに対する期待 • 複雑な商用NWの動きまでを含めて確認することで、作業ミスや 設定の見落としなどを防止する="本番一発勝負"をなくす • NWオペレータが商用環境で行っている作業を再現したい • 操作手順 • その時のネットワークのふるまい • 試行錯誤を素早く・手軽にやりたい そのために必要なもの • 実際に動かせる・試行錯誤ができるNW • 商用同等のオペレーションができる仮想NWとしてのNDT © 2026 Okinawa Open Laboratory 18 前のセクションで説明
19. NDTの難しさ 運用導入トライアルでわかったこと © 2026 Okinawa Open Laboratory 19
20. 前提: NW検証の難しさ…完全複製は不可能 © 2026 Okinawa Open Laboratory 20 Code (IaC) 検証環境用 パラメタ 商用環境用 パラメタ (例)クラウド上のシステム ネットワーク (既存・物理) 同じ構成 同じ計算機リソース 同じコードベース の検証環境が作れる 検証環境の問題 =商用環境で起きうる問題 と言いやすい 商用環境 検証環境 商用環境 基になる構成情報が分散 構造(トポロジ)を変えざるを得ない 計算機リソースが変わる 同じコードベースのものが使えない 専用H/W, 専用OSの機材 トポロジがNW(系全体)の状態に影響 従来の検証環境…OK Config 選択・加工 100%完全再現出ないのは従来の(物理)検証環境だって同じ NDTでは何に引っ掛かるのかを正しく認識する必要がある NDT…OKと言い切れない 商用を「再現」できているのか? 検証環境
21. 期待とギャップ © 2026 Okinawa Open Laboratory 21 商用環境 従来ラボ・NDT問わず常に発生するギャップ • NWの構造(トポロジ)、再現可能なレイヤ、ノードの設定 • NW全体(ノード)の状態 • 使うモノとそのオペレーション NDT固有・従来ラボにはない考え方に対するギャップ • 商用環境の状況に合わせて自動で起動する • 複雑な構成・状況をなるべくそのまま再現する • 一時的(ephemeral)な環境での試行錯誤 • 蓄積・メンテナンスすべきものは環境ではなくデータ • 目的…実現したいもの・期待 • "複雑さ"によって発生する問題へのアプローチ • "中身"の完全把握を前提としない …「把握しきれないもの」をどうコントロールするか 商用環境 設計上想定される機能、 動作パターンの確認 検証設計 基点になることもある 常に基点 データ ツール NDT (仮想NW) 設計・構築 検証作業 商用環境の、ある時点の構造・状況の再現 複雑なNW(多ノード構成)とその挙動の検証 試行錯誤サイクルの短縮 商用環境の「コピー」 状況の再現 従来ラボ環境では実現できなかった 検証・そのプロセスへのアプローチ 従来ラボ環境 (物理/仮想NW) 検証目的・実現したいことに応じて取捨選択が必要 NDTで実現したいことに対して何がどこまで必要か?
22. NDT利用の壁 © 2026 Okinawa Open Laboratory 22 NDTに対する期待 • NW環境が大規模化・複雑化 • 従来の検証環境では拾い切れない「複雑 さ」を何とかしたい • 「やってみないとわからない」 「やってみて初めて分かった」 • 本番一発勝負・KKD(勘・経験・度胸)運用 NDT利用の壁 • NWの構造・規模(ノード数)を再現する • 複雑な環境の中身すべてを個別にチェック しきれない ブラックボックス化 • 「このブラックボックスは本当に信じてい いのか」…信用問題の発生 従来の検証環境 • シンプル・少数ノード • 構成や設定を明示的に作る・都度設計する (=中身が分かる) • (物理環境では)商用環境と同じもの(H/W, OS等)が使える NDT環境(仮想NW) • 複雑・多数ノード • 構成や設定を人が網羅的に見ない・自動構 築するので都度設計しない • (仮想なので)使うものが異なる
23. 課題に対するアプローチ © 2026 Okinawa Open Laboratory 23
24. 方針 • ネットワークが「同じ」かどうかには多数の観点が絡むので指標化するのは困難 • ネットワークの同一性みたいな話を追うアプローチは難易度が高い • 仮に指標化ができたとしても、おそらく"テストカバレッジ"ぐらいの参考情報にとどまる • 結局見たいのは「複雑なNW環境の動き/ふるまい」 • 中身の詳細を追わなくても「商用と同じように動く」と示せれば、実用上問題ないはず • 過去(環境の複雑さが起因になって起きた)事象をNDT環境で発生させてみて、実際に同 じ動きを再現できることが分かれば、そこを「信用」の基点にできるはず • 過去障害の再現 • 過去に起きた事象が再現する この先やろうとしているオペレーションとそれに伴う事象も予 測できるはず © 2026 Okinawa Open Laboratory 24
25. NDTによる再現～切戻し～予測 プロセス © 2026 Okinawa Open Laboratory 25 商用環境 デジタル ツイン 1. トラブル 発生 5. トラブル 再現 7. 切り戻し 完了 12. 対処後 6.切戻し手順再現 デジタルツイン上で トラブルを再現 商用と同等な手順で切戻し実施 振る舞いが一致するはずだ 10.予測 過去事象を同じく再現できるなら 対応策(未来)の検証も信頼できるはず 事象の発生/再現 切り戻し 3. 切り戻し 完了 2.切戻し実施 4. コピー 予測 9.根本対処 リハーサル 11.リハーサルを元に 商用作業 13. 商用環境が デジタルツインと 同じふるまい をするはず 8. 5-7のふるまい 確認 過去事象(実施済み) 同じ振る舞いが再現できる? 同じ作業が再現できる? 別資料で詳細説明
26. 過去障害の再現トライアル © 2026 Okinawa Open Laboratory 26 増設箇所 再度接続 過去(トラブル)の再現 現在(切戻し)の再現 根本対処(予測) BGP接続箇所の増設時、増設ルータ側に 意図しない経路切り替えが発生 切戻し作業を行い、 元の通信経路へ復旧 NDT上で原因特定 根本対処の手順をNDTで実施し、 効果を判断 4-8: 設定ミス～予期しないトラフィックの発生、環境切 戻しまでのNWふるまいを再現 9-13: 原因特定～対策の実施 将来構成でのNWふるまい予測 別資料で詳細説明
27. NW操作(作業)の再現/ギャップ • ノードのH/W構成依存コマンド実行 回避不可能 手順スキップ • 物理トポロジ操作の読みかえ • 操作対象ノードのインタフェース名 仮想NWノード の問題 仮想NWノード実装依存 ツールで名前変換。読替を回避可能な機能を持つ仮想NW ノードも最近出始めている • L3トポロジ操作への読みかえ NDT実装上の 問題 今回は人力で読み替え (検証ターゲットはISP NW…L1/L3トポロジのギャップが少 ない環境になっているので要注意) • 仮想環境固有のノード状態操作 • Ad hocなリソース追加ができない 仮想環境 (仮想化技術)の 問題 • オペレーションで必要なリソースを最初からある程度定義 して仮想環境を起動することで回避 • 直接的なトポロジ変化ではなく、OVSブリッジでのリンク 操作を挟むことでトポロジ変更作業を実現 • NWノード(仮想ノード)からのインタフェースshutではな く、仮想環境の外(ホストOS)側のコマンド実行でインタ フェースshut実施で回避 • Ad hocなトポロジ変更ができない • インタフェースshutdownができない © 2026 Okinawa Open Laboratory 27 別資料で詳細説明
28. NWのふるまいの再現 • NDTでも商用環境と同様のふるまいが再現できた • 操作(作業)にギャップはあるものの致命的ではない • 狙ったNW全体の動きは確認できた • トラブル～切り戻し手順・NW動作の再現 • NDT上で根本対処(リハーサル)～動作予測も実施 • 後は商用作業(NDTで得られた結果のフィードバック) © 2026 Okinawa Open Laboratory 28 前頁
29. まとめ © 2026 Okinawa Open Laboratory 29
30. まとめ • ネットワーク・デジタルツインを実際の運用プロセスに入れよ うとしたときの壁……「信用」の基点がないこと • 信用を積み上げるプロセスを作る • デジタルツインを少しずつ信用できるようになる • 過去事象(障害)の再現 ～ 将来予測 プロセス • モデル育成フェーズ • トポロジーモデルから生成したデジタルツインの信用を積み上げる © 2026 Okinawa Open Laboratory 30 次頁 "のりしろ"がないと くっつかない
31. フェーズ 31 現行運用 • 手書き(人用)構成図・ドキュメント・台帳等を基にした人力運用 • 構成変更は実機(実環境)直接操作 モデル「育成」期 • 現行運用に対する判断材料の提供・支援等、情報参照での利用 • 構成変更は従来運用を維持 • モデルの精度・モデルを使ったオペレーションの信頼性向上 • モデルを信用できるようにする • モデルを「育てる」 モデル中心運用 • 構成変更の自動化・効率化へのモデル利用 • 操作対象をモデルデータに切り替える 従来: 検証環境そのものを「育てる」 環境を作る元ネタ(モデル)を育てる © 2026 Okinawa Open Laboratory
32. QA/議論 © 2026 Okinawa Open Laboratory 32
33. 議論したいこと • 何ができたらNDT使う? • NDTが広まる上での課題点は? • NDTを使う・実現するうえで今後ほしいモノ(道具/機能)は? • 状態ってどこまで再現できる/すべき? • ネットワークのモデル化(抽象化)って必要なの? • AI連携ってできる? AIopsとかAIによる運用を考えたときの学習データソースとして使える? • おそらく可能だけど現状やってないです ➡AI連携/AIopsでどんなことやりたい? どんなオペレーションを期待している? © 2026 Okinawa Open Laboratory 33
34. 補足資料 当日議論に対する追加公開資料 © 2026 Okinawa Open Laboratory 34
35. これが欲しいです、メーカーさん？(1/2 • 物理config・コマンドが読みかえなしにそのまま動く • Loが増やせない・vrfが増やせない・sub-ifが増やせない・表示が違う・マネジメン トプレーンのルーティングが入ってくる… • 商用で使用中のコンフィグがそのまま入れられるようになってほしい (物理/仮想、 商用/検証のコンフィグの違いをいちいち吸収しなおさないといけないのが面倒) • 状態のインポート/エクスポート • interface shut/no shut (admin/oper) • show tech-support(export)～import • ルータだけではなくスイッチなどのコンテナ • STP, LAG, …Stack (VirtualChassis) などの仮想では再現できないHA構成とかは再 現しようがない © 2026 Okinawa Open Laboratory 35
36. これが欲しいです、メーカーさん？(2/2 • コンテナ/VM オーケストレーション • 動的/ad-hocなリンク操作機能(環境起動後のリソース追加・APIによる自動化) • マルチノード対応、Helm/カスタムリソース定義の準備、public cloud(AKS等)への デプロイ、スケールアウト構成の提供 • 実機(物理)インタフェースへのCNIからのtap(物理ハイブリッド構成) • 状態を含めた複数ノードのsave/load (snapshot) = helm + state import/export • コンテナ/VMの挙動 • アーキテクチャ依存の排除 • 起動に時間がかからない・なるべく軽量であってほしい • ライセンスファイルの適用…自動化できる手法で指定可能に © 2026 Okinawa Open Laboratory 36
37. ネットワークのデジタルツイン に求める要件は何ですか？ ～理想的な仮想環境への期待と現状～ 過去障害の再現シナリオ 37 2026/02/11-13, JANOG57 in OSAKA
38. 各再現フェーズで起こる商用とNDT(Network Digital Twin)の GAPに関して、どのようなアプローチをすることで 信用を積み重ねられるのかを検証する NDT上での信用の積み重ねを検証 38 商用環境 デジタル ツイン 1. トラブル 発生 5. トラブル 再現 7. 切り戻し 完了 12. 商用 作業後 6.切戻し手順再現 10.未来 予測 3. 切り戻し 完了 2.切戻し実施 4. コピー 9.根本対処 リハーサル 11.リハーサルを元に商用作業 13. 商用環境が デジタルツインと 同じふるまい をするはず 8. 振る舞い をチェック GAP GAP GAP 過去(トラブル)の再現 現在(切戻し)の再現 根本対処(予測)
39. ISPネットワークにおける POIと接続するルータを 増設するシナリオ • 増設ルータ(edge-tk12) はコアスイッチ (core-sw01)および POI02と接続 • POIとの接続直後は 増設ルータ経由の 通信は流さない ※コンテナ基盤としては containerlab, CNFはjuniper社のcRPD 39 デモ構成 トポロジー 変更箇所 トラフィックの流れ
40. 過去障害の再現シナリオ デモシナリオ 増設する箇所 トラフィックの流れ トラフィックの流れ トラフィックの流れ 再度接続 過去(トラブル)の再現 現在(切戻し)の再現 根本対処(予測) POIとのBGP接続時に 増設ルータ側へ 意図しない 経路切り替えが発生 切戻し作業を行い、 元の通信経路へ復旧 NDT上で原因特定 根本対処の手順をNDTで実施し、 効果を判断
41. • 「1.トラブル発生」から「3.切戻し完了」までの フェーズはすでに作業完了済み。 • ４「コピー」のフェーズからデモを開始する。 41 商用環境 デジタル ツイン 1. トラブル 発生 5. トラブル 再現 7. 切り戻し 完了 12. 商用 作業後 6.切戻し手順再現 10.未来 予測 3. 切り戻し 完了 2.切戻し実施 4. コピー 9.根本対処 リハーサル 11.リハーサルを元に商用作業 13. 商用環境が デジタルツインと 同じふるまい をするはず 8. 振る舞い をチェック GAP GAP GAP 過去(トラブル)の再現 現在(切戻し)の再現 根本対処(予測) 前提条件
42. • コンテナ基盤上では 動的なリソース追加は できないため、事前に 増設分のリソース定義 をしてNDTを起動する。 42 ４.「コピー」 -事前定義- l3_preallocated_resources: - type: node name: as65520-edge01 asn: 65520 interfaces: - Ethernet3 - type: node name: edge-tk12 interfaces: - ge-0/0/0.0 - ge-0/0/1.0 増設先の対向ルータ情報 は本来では不明 NDTの検証構成として の補完ルールに則り、 対向ルータ名と対向IF名 を指定している
43. • NDT環境の起動 • 過去のトラブル時に影響 のあったEndtoEndの トラフィックを流し、 トラブル前の通信状態 を再現 43 ４.「コピー」 -環境の起動- mddo@mddo-srv02:~/playground/demo/candidate_model_ops$ bash 11_manual_steps.sh {"mddo-bgp":[{"physical":{"network":"mddo- bgp","snapshot":"original_asis","label":"original_asis"},"logical":[]}] } Network:mddo-bgp uses BGP, expand external-AS network and splice it into topology data {} { "status": 201 }
44. ４.「コピー」 -増設対象のルータをNDT上へ追加- • ここでGAPが発生 ①コンテナ基盤上で回線開通前の状態再現ができない ②商用IF名でトポロジー変更ができない 44 商用環境 デジタル ツイン 1. トラブル 発生 5. トラブル 再現 12. 商用 作業後 6.切戻し手順再現 3. 切り戻し 完了 2.切戻し実施 4. コピー 9.根本対処 リハーサル 11.リハーサルを元に商用作業 13. 商用環境が デジタルツインと 同じふるまい をするはず 8. 振る舞い をチェック GAP 過去(トラブル)の再現 現在(切戻し)の再現 根本対処(予測) 7. 切り戻し 完了 10.未来 予測
45. GAP • 開通前の状態を再現するには 増設するIFを通信できない状態で 保持する仕組みが必要 通信不可用のOVS Bridge (Seg_empty00)を用意し、これに 繋がるportをIF Shutdown状態にする 仕組みを実装して状態を再現 45 ①回線開通前の 状態再現ができない mddo@mddo-srv02:~/playground/demo/candidate_model_ops$ docker exec -it mddo-clab-docker /bin/bash mddo-srv02:/home/mddo/playground/repos/mddo-worker/clab# ip link | grep "ovs-system state DOWN" 659: br25p0@if658: <BROADCAST,MULTICAST,M-DOWN> mtu 9500 qdisc noqueue master ovs-system state DOWN 673: br25p1@if672: <BROADCAST,MULTICAST,M-DOWN> mtu 9500 qdisc noqueue master ovs-system state DOWN 685: br25p2@if684: <BROADCAST,MULTICAST,M-DOWN> mtu 9500 qdisc noqueue master ovs-system state DOWN 通信不可用 のBridge if shutdown if shutdown if shutdown ⇐増設対象 増設対象⇒
46. GAP 商用IF名でトポロジー変更するには 以下の課題があった。 • 商用のIF名はNDT上では コンテナルータのIF名(ethX) に置き換わってしまう。 • IFがつながるBridgeの対向ポート名 も商用IF名からは特定できない。 OVS・CNFのIFをマッピングする機能を実装 マッピング例： 46 ②商用IF名でトポロジー 変更ができない br25 br25p0 br25p1 br25p2 商用:ge-0/0/1 NDT: eth2 商用:ge-0/0/0 NDT: eth1 増設部分のNDTのトポロジー 商用(Original)のIF名 ge-0/0/0 NDT上のコンテナルータに対応するIF名 eth1 NDT上の接続先Bridgeの対向ポート名 br25p1
47. GAP アドホックな変更を実現するために、OVSの付け替えを自動化 • 操作①：POI側との接続 通信不可用のovs-brから POIとの通信用の新設したovs-brへ 対象のポートを付け替えする • 操作②：Backbone側との接続 通信不可用のovs-brから他Backbone ルータと通信できる既設のovs-brへ 対象ポートを付け替えする 47 ②商用IF名でトポロジー 変更ができない 増設ルータ POIルータ 通信不可br POI通信用br Port 付け 替え 増設ルータ 通信不可br Backbone 接続用br port付け替え
48. mddo@mddo- srv02:~/playground/demo/candidate_model_ops$ ./topo_frontend.py link --src as65520-edge01[Ethernet3] --dst edge-tk12[ge-0/0/0.0] • ①POI側トポロジー変更 ４.「コピー」 -トポロジーの変更- POI通信用の新設 Bridge(Seg_empty01) の方にportを繋ぎ変え、 増設対象(edge-tk12) とPOI側が 通信できる状態に • ②Backbone側トポロジー変更 Backbone側のBridgeへ portを繋ぎ変え、想定 構成図の(赤枠)を再現 mddo@mddo- srv02:~/playground/demo/candidate_model_ops$ ./topo_frontend.py link --src edge-tk12[ge-0/0/1.0] --dst core-tk01[ge-0/0/0.0] 48 商用IF名を使ってアドホックな構成変更を実現
49. • 商用作業同等の手順を NDT上で実行する 手順の実行後、 BGP接続は確立するが、、、 49 ５.「トラブル再現」 -BGP接続- root@edge-tk12# run show bgp summary Threading mode: BGP I/O Default eBGP mode: advertise - accept, receive - accept Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 40 37 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.168.200.2 65520 51 53 0 0 21:17 Establ inet.0: 8/9/9/0 192.168.255.101 65500 57 49 0 0 21:36 Establ inet.0: 29/31/31/0 手順の抜粋
50. • 商用手順をNDT上で実行するにあたりGAPが発生 ①物理とCNFの構成差分 ②オペレーション時の読み替え問題 ⇒次ページにて対応内容を解説 ５.「トラブル再現」 GAPの発生 50 商用環境 デジタル ツイン 1. トラブル 発生 5. トラブル 再現 7. 切り戻し 完了 12. 商用 作業後 6.切戻し手順再現 10.未来 予測 3. 切り戻し 完了 2.切戻し実施 4. コピー 9.根本対処 リハーサル 11.リハーサルを元に商用作業 13. 商用環境が デジタルツインと 同じふるまい をするはず 8. 振る舞い をチェック GAP 過去(トラブル)の再現 現在(切戻し)の再現 根本対処(予測)
51. • 物理とCNFの構成差分 による実行できないコマンド - シャーシ型・ボックス型 等の機種依存コマンド - CNFの製品コンセプトで オミットされた機能 ⇒この差分はいったんSKIPする。 トラブル再現時に必須な場合は 再現可能なCNF/VNFに対象を 置き換えする。 51 ①物理とCNFの 構成差分 root@edge-tk12> show chassis ^ syntax error, expecting <command>. root@edge-tk12> show chassishardware ^ シャーシ型機 種 依存コマンド の実行エラー GAP 機種依存コマンド root@edge-tk12# set interfaces eth1 disable ^ syntax error. オミットされたコマンド root@edge-tk12# set interfaces eth1 gigether- options802.3ad ^ syntax error. コンテナ上のlinux OSの機能で IF down/upなど 代替できる振る舞いもあった
52. • 商用のIF名でオペレーション： CNFでのIF名で操作することになる。 マッピング機能を元に商用IF名から NDT上のIF名への変換をした手順を 事前準備する必要が発生。 • トラフィック確認： 振る舞いの再現確認に使う トラフィック監視画面もマッピング 機能を基にOriginal IF名を埋め込み する対応が発生。 52 ②オペレーション時の読み替え問題 GAP 読み替えした手順
53. • edge-tk11⇒edge-tk12へ 通信の切替わりが発生 53 ５.「トラブル再現」 トラフィックの流れ
54. • 商用実績の切戻し作業をNDT上で再現。 ⇒発生したGAPの対処(オペレーション時 の読み替えの問題と同じ対応を実施) 54 6.切戻し手順再現 54 GAP 商用環境 デジタル ツイン 1. トラブル 発生 5. トラブル 再現 7. 切り戻し 完了 12. 商用 作業後 6.切戻し手順再現 10.未来 予測 3. 切り戻し 完了 2.切戻し実施 4. コピー 9.根本対処 リハーサル 11.リハーサルを元に商用作業 13. 商用環境が デジタルツインと 同じふるまい をするはず 8. 振る舞い をチェック GAP 過去(トラブル)の再現 現在(切戻し)の再現 根本対処(予測)
55. • 商用実績の切戻し作業をベース としたNDT変換手順で 切戻し作業は実績通り正常に完了 55 7.切り戻し完了 root@edge-tk12# load override 20251204-5.conf load complete [edit] root@edge-tk12# show | compare [edit protocols bgp] - group 192.168.200.2 { - type external; - hold-time 90; - family inet { - unicast; - } - peer-as 65520; - neighbor 192.168.200.2 { - local-address 192.168.200.1; - import POI-East_in; - } - } [edit] root@edge-tk12# commit check configuration check succeeds [edit] root@edge-tk12# commit commit complete ①POIとのBGP接続前の 切戻しポイントの コンフィグを正常にロー ド。 ②BGP開通のコンフィグ分がエ ラーなく 巻き戻る内容であることを確認 して、 ロールバック実行
56. Grafanaにて切戻し後の動作を確認 ⇒トラフィックが作業前の経路に戻り、 商用(切戻し)と同じ状態となった 56 8.振る舞いをチェック 商用環境 デジタル ツイン 1. トラブル 発生 5. トラブル 再現 7. 切り戻し 完了 12. 商用 作業後 6.切戻し手順再現 10.未来 予測 3. 切り戻し 完了 2.切戻し実施 4. コピー 9.根本対処 リハーサル 11.リハーサルを元に商用作業 13. 商用環境が デジタルツインと 同じふるまい をするはず 8. 振る舞い をチェック 過去(トラブル)の再現 現在(切戻し)の再現 根本対処(予測)
57. • 再度トラブル状態を再現して NDT上で状態を確認して、 想定外の経路の優先度に なっている箇所を特定。 そこから誤設定を検出し、 商用向けの修正手順を用意 57 10.未来予測① root@core-tk01> show route inet.0: 49 destinations, 94 routes (49 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both <省略> 10.100.0.0/24 *[BGP/170] 00:02:16, MED 100, localpref 100, from 192.168.254.12 AS path: 65520 I, validation-state: unverified > to 192.168.1.12 via eth1 [BGP/170] 23:34:30, MED 100, localpref 100, from 192.168.255.11 AS path: 65520 I, validation-state: unverified > to 192.168.1.11 via eth1 想定では赤字の経路が優先されてほしい が、 青字の経路が優先されている。 ⇒設定ミスの箇所を特定
58. • NDTで修正手順をリハーサルし、 増設後の構成でBGP接続しても 経路変更が起こらないことが わかった。 ⇒手順の妥当性を確認できた 58 10.未来予測② [edit] root@edge-tk12# delete interfaces lo0 unit 0 family inet address 192.168.254.12/32 set interfaces lo0 unit 0 family inet address 192.168.255.12/32 delete routing-options router-id 192.168.254.12 set routing-options router-id 192.168.255.12 root@edge-tk12# run show bgp summary Threading mode: BGP I/O Default eBGP mode: advertise - accept, receive - accept Groups: 2 Peers: 2 Down peers: 0 Table Tot Paths Act Paths Suppressed History Damp State Pending inet.0 47 37 0 0 0 0 Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 192.168.200.2 65520 4 6 0 0 1 Establ inet.0: 8/9/9/0 192.168.255.101 65500 10 3 0 0 17 Establ inet.0: 29/38/38/0 ↑想定経路で 通信できている 修正手順の実施 新設ルータはBGP接続している （現在から進んだ状態）
59. 考察
60. • ノードのH/W構成依存コマンド実行 • 物理トポロジ操作の読みかえ • 操作対象ノードのインタフェース名 • L3トポロジ操作への読みかえ • 仮想環境固有のノード状態操作 • Ad hocなリソース追加ができない • Ad hocなトポロジ変更ができない • インタフェースshutdownができない 直面したGAPのまとめ Page 51 Page 51 Page 52 Page 52 Page 46 Page 46 Page 47 Page 47 Page 45 Page 45 Page 51 Page 51
61. 過去(トラブル)、現在(切戻し)の各再現フェーズにて、NDT (Network Digital Twin)が商用と同様に振る舞うことが確認できた。 これによって、この過去と現在の間のGAPが存在しても NDT上の振る舞いが信用できるとわかった。 ⇒延長線上であればNDT上での未来の予測も信用できる 商用環境 デジタル ツイン 1. トラブル 発生 5. トラブル 再現 7. 切り戻し 完了 12. 商用 作業後 6.切戻し手順再現 10.未来 予測 3. 切り戻し 完了 2.切戻し実施 4. コピー 9.根本対処 リハーサル 11.リハーサルを元に商用作業 13. 商用環境が デジタルツインと 同じふるまい をするはず 8. 振る舞い をチェック GAP GAP GAP 過去(トラブル)の再現 現在(切戻し)の再現 根本対処(予測) 考察
62. • containerlab: コンテナルータ上のIF名でトポロジーの定義が可能に 最新のContainerlab上のトポロジー定義 vSRX#1: ge-0/0/1 <==> vEOS#1: Ethernet1/1 (旧来の)Containerlab上のトポロジー定義 vSRX#1: eth1 <==> vEOS#1: eth1 IFの読み替えが不要に vethXX vethYY vSRX#1 ge-0/0/1 vEOS#1 Ethernet1/1 仮想bridge vethXX vethYY vSRX#1 ge-0/0/1 vEOS#1 Ethernet1/1 仮想bridge [おまけ]物理とCNFの構成差分の解消も進んでいる
63. • Nokia社のCNFのSR-SIM：物理機器と同様のコマンド体系を実現 [おまけ]物理とCNFの構成差分の解消も進んでいる A:admin@edge-tk12-a# show port =============================================== Ports on Slot 1 =============================================== Port Admin Link Port Cfg Oper LAG/ Port Port Port C/QS/S/XFP/ Id State State MTU MTU Bndl Mode Encp Type MDIMDX ------------------------------------------------------------------------------- 1/1/c1 Down Down conn 100GBASE-LR4* ＜省略＞ 1/1/c12 Up Link Up conn 100GBASE-LR4* 1/1/c12/1 Up Yes Up 8704 8704 - netw null cgige ＜省略＞ 1/1/c21 Up Link Up conn 100GBASE-LR4* 1/1/c21/1 Up Yes Up 8704 8704 - netw null cgige A:admin@edge-tk12-a# show card 1 memory-pools ================================================ Card 1 Memory Pools ================================================ Name Max Allowed Current Size Max So Far In Use ------------------------------------------------------------------------------- IOM No limit 2,159,706,112 2,161,803,264 2,144,510,160 ＜省略＞ A:admin@edge-tk12-a# show card a memory-pools ================================================= Card a Memory Pools ================================================= Name Max Allowed Current Size Max So Far In Use ------------------------------------------------------------------------------- BFD No limit 9,444,656 9,444,656 8,318,528 BGP No limit 6,291,504 6,291,504 5,015,536 l3_preallocated_resources: - type: node name: as65520-edge01 asn: 65520 interfaces: - Ethernet3 - type: node name: edge-tk12 interfaces: - 1/1/c12/1 - 1/1/c21/1 emulated_params: license: ./sros_license.txt image: localhost/nokia/srsim:25.7.R1 kind: nokia_srsim type: SR-2s components: - slot: A - slot: 1 type: xcm-2s sfm: sfm-2s env: NOKIA_SROS_CARD: xcm-2s NOKIA_SROS_MDA_1: s36-100gb-qsfp28 増設リソース にSR-SIMを指 定して 利用できる よりGAPの少 ない操作が可 能に
64. root@HOSTNAME> show chassis routing-engine Routing Engine status: Slot 0: Current state Master Election priority Master (default) Temperature 0 degrees C / 32 degrees F DRAM 1353 MB (6292 MB installed) Memory utilization 78 percent 5 sec CPU utilization: User 2 percent Background 0 percent Kernel 2 percent Interrupt 0 percent Idle 96 percent 1 min CPU utilization: User 2 percent Background 0 percent Kernel 3 percent Interrupt 0 percent root@HOSTNAME> show chassis hardware Hardware inventory: Item Version Part number Serial number Description Chassis JN9989820AJD JNP10001-36MR [PTX10001-36MR] Routing Engine 0 BUILTIN BUILTIN RE-JNP10001-36MR CB 0 BUILTIN BUILTIN Control Board FPC 0 BUILTIN BUILTIN FPC-JNP10001-36MR PIC 0 BUILTIN BUILTIN 8X400GE-MR + 4X100GE-MR Xcvr 0 REV 01 740-058732 1DJQA042004 QSFP-100GBASE-LR4 Xcvr 1 REV 01 740-058732 1DJQA042004 QSFP-100GBASE-LR4 Xcvr 2 REV 01 740-058732 1DJQA042004 QSFP-100GBASE-LR4 Xcvr 3 REV 01 740-058732 1DJQA042004 QSFP-100GBASE-LR4 l3_preallocated_resources: - type: node name: as65520-edge01 asn: 65520 interfaces: - Ethernet3 - type: node name: edge-tk12 interfaces: - et-0/0/1 - et-0/0/2 emulated_params: kind: juniper_cjunosevolved image: cjunosevolved:25.2R1.8-EVO env: CPTX_COSIM: "BT" 増設リソース にcJunos Evolvedを利用 できる よりGAPの少 ない操作が可 能に root@HOSTNAME> show interfaces terse Interface Admin Link Proto Local Remote et-0/0/0 up up et-0/0/0.16386 up up multiservice pfh-0/0/0 up up pfh-0/0/0.16383 up up inet et-0/0/1 up up et-0/0/1.0 up up inet 192.168.200.1/30 multiservice et-0/0/2 up up et-0/0/2.0 up up inet 192.168.1.12/24 multiservice • Juniper社のcJunos Evolved：物理機器と同様のコマンド体系を実現 [おまけ]物理とCNFの構成差分の解消も進んでいる