沖縄オープンラボラトリ
Model Driven Network DevOps(MDDO) Projectの紹介
ENOG 74 2022/6/10
ビッグローブ株式会社
基盤本部ネットワーク技術部
滝口敏行
川口永一郎

BIGLOBE Inc.

自己紹介
・滝口 敏行
所属：ビッグローブ株式会社 基盤本部 ネットワーク技術部
経歴：2018年中途入社 社会人10年目 現在3社目
やっていること：Prometheusを使った運用監視システムの開発、保守。
MAPE・DNSインフラの運用改善、NW自動化の施策検討/推進など
・川口 永一郎
所属：ビッグローブ株式会社 基盤本部 ネットワーク技術部
経歴：2020年新卒 3年目やっていること：DNS、IPv4 over IPv6基盤の運用

2

BIGLOBE Inc.

本Projectについて
沖縄オープンラボラトリ※のProjectの一つで、ネットワーク(NW)運用の高度化を実現するためにNWのトポロジに着目してNW設計～運用を自動化する仕組みを作る試みを行っているProject※沖縄オープンラボラトリ(https://www.okinawaopenlabs.org/about-ool)とは、沖縄を活動基盤とした企業、団体と国や業界、組織の枠を超えて次世代ICT基盤技術の実用化、普及を推進するオープンに活動する団体

Project参加企業
・ TIS株式会社・ビッグローブ株式会社
・ NTTコミュニケーションズ

3

BIGLOBE Inc.

背景・課題感• コンフィグと台帳ベースの人力運用でNWの複雑化に対処するのは限界• ノード単体に対する操作の自動化は一般的になったが、ネットワークでは複数ノード間の関係性が見えないと正しい操作はできない• ノード間の関係性を把握した自動化への拡張が必要• 大きなソリューションを入れて従来のやり方を大幅に変えるのは難しく、抵抗感も大きい• 市販のNW管理製品等で、構成情報・ノード間接続情報などを基に管理・分析できるものもあるが、ある程度規模のあるシステムでないと合わない• 汎用的な製品 ⬄ システム固有の設計・制約・課題 : ギャップをどう埋めるか?
• 既存のしくみを補完し、課題に合せて小さく始めて積み上げるアプローチがほしい• NW自動化は作業時間の短縮だけでなく理解・判断の領域へのステップアップ⇛単体から全体の関係性へ• 宣言的な手法/Reconciliation Loop などのサーバサイドのCI/CDノウハウ・考え方を取り込めないか
4

BIGLOBE Inc.

Kubernetesの突合せ(Reconciliation)ループ• 理想状態の定義 : 宣言
• 現在状態との比較• 理想状態への移行→ 常に理想状態を維持

既存のNWインフラ環境はきれいにひとつのプラットフォームとして統合できるわけじゃない
ので、こういうオペレーションをネットワーク分野でやるのはすごく難しい。
しかし、基準点(理想的な構成)を定義して、そことのずれを出す、みたいなことができるだけでも効果的なユースケースはあると考えた。
5

データ永続化と構築運用の自動化を実現する「 PostgreSQL on Kubernetes」の仕組み：クラウドネ
イティブ時代のデータベース（ 2） - ＠IT
https://www.atmarkit.co.jp/ait/articles/2105/20/news006.html[参考]宣言的手法とReconciliation Loop

BIGLOBE Inc.

実現したいこと

既存システムにWrapする形で計算機による技術支援を拡充していく

デプロイ前のテストと予測可能性
静的な検査・動的なテスト
練習・トレーニング・育成

複雑なシステム全体像の俯瞰 :「構成(NWトポロジー)図」としての表現
担当範囲の異なる担当者間での共通理解”どこで何をすべきか” わかること

検証環境

OprApp
自動テスト

Server
本番環境

ターゲット(既存のシステム)

システムの”モデル”を核としたオペレーション「あるべき姿(理想)」と現状のギャップ

NW
宣言的なシステム運用
自動テストなどソフトウェア開発・クラウド開発のベストプラクティスの取り込み
6

Opr
BIGLOBE Inc.

具体的な構成イメージ

検証作業で実施している
確認事項のコード化・自動実行・CI化
動的テスト
テスト自動化

構成図として表現可能な構成情報(トポロジ)データ↓
やりたいこと・あるべき姿の定義

デプロイ前のテストと予測可能性

作業レビュー等で実施している確認事項のコード化・自動実行・CI化

検証環境

静的・動的テストの高頻度実行(CI)
全体構造の表現と理解・理想像の定義

静的検査
構成(図)情報をつかった
システムオペレーションの自動化
実態操作の抽象化

実環境
差分
比較
リポジトリ

実際の状態のマッピング
過去スナップショット・想定している構造とのモデルベースな差分比較↓
理想を定義して反映する・実状を取り込むの双方向性「ズレ」などを素早く検出・判断し修正していく
ロバストな運用作業・そのプロセスの自動化

過去スナップショット
7

BIGLOBE Inc.

今回実装した範囲• 既存システム・その運用の中にreconciliation loopを取り込む

今回(2022年5月まで)実装した範囲
・コンフィグからモデルデータを抽出し、静的検査および経路シミュレーションを自動で行う。
8

BIGLOBE Inc.

今回のシステムで実現できたことノードの関係性をNWトポロジーモデルで表現することによって、NW実機を用意せずともNW構成の間違いを検出できるようになった。
デモの流れ①L1-L3トポロジとレイヤ間の関係性を把握②ノード間の関係性をもとに静的テスト
a: 複数IPを持つセグメントb: ループ検出③経路シミュレーション

9

BIGLOBE Inc.

Ansible

今回実装したシステム構成push(定期・手動)時に一連の検査を自動実行

config, stateは定期的に取得. Push(or 担当者操作)

運用対象NW

L1
リンク情報抽出deviceconfig &stateBatfishNetBox

L1-L3
トポロジ
生成

topology
data

各種
テスト
検査

Parser,
Simulator
operator

API
Wrapperlayer1
topology

テスト・検査結果に応じてコンフィグの修正
必要なら環境へのフィードバック(ここは従来のやり方で)

WebUI
(可視化)
10

GitHubAction
で自動実行
BIGLOBE Inc.

①. L1-L3トポロジとレイヤ間の関係性を把握
デモNW1 Original

レイヤ間の関係性を持っているのでどのノードに何が乗っているのかをたどれる

Layer1

Layer2 (VLAN100)

Layer3(standaloneなセグメント=VLAN200以外)

L1トポロジ + Config を見て、何がどうつながっているのか(人が設定トレースするように)たどって構成データを組み立てている→ データ組み立て時に、接続されているポート・ノード同士の設定整合性もあわせて確認
11

BIGLOBE Inc.

②-a. 複数IPを持つセグメント
デモ用NW1a スイッチ間リンクダウン

Layer3(VLAN200部分)

hagiwara@dev02:~/ool-mddo/netomox-exp$ bundle exec ruby exe/mddo_toolbox.rb
get_subsets -f json netoviz_model/batfish-test-topology_l2l3_demo1a.json | jq'.[] | select(.network=="layer3") | .subsets[] |select(.flag.multiple_prefix_segments)'{"elements": ["layer3__Seg_192.168.2.0/24+","layer3__Seg_192.168.2.0/24+__switch1_GigabitEthernet1/0/5","layer3__host21","layer3__host21__eth0","layer3__Seg_192.168.2.0/24+__switch1_GigabitEthernet1/0/6","layer3__host22","layer3__host22__eth0","layer3__Seg_192.168.2.0/24+__switch2_GigabitEthernet1/0/7","layer3__host23","layer3__host23__eth0"],"flag": {セグメント名に "+""multiple_prefix_segments": 1
1つのセグメントに複数のIP prefixがある}(ここではhostのネットマスク設定ミス)}
hagiwara@dev02:~/ool-mddo/netomox-exp$

12

BIGLOBE Inc.

②-b. ループ検出
hagiwara@dev02:~/ool-mddo/netomox-exp$ bundle exec rubyexe/mddo_toolbox.rb get_subsets -f json
netoviz_model/batfish-test-topology_l2l3_demo1b.json | jq '.[]| select(.network=="layer2") | .subsets[] | select(.flag.loop)'{"elements": ["layer2__switch1_Vlan100","layer2__switch1_Vlan100__GigabitEthernet1/0/1","layer2__host11_eth0","layer2__host11_eth0__eth0","layer2__switch1_Vlan100__GigabitEthernet1/0/2","layer2__host12_eth0","layer2__host12_eth0__eth0","layer2__switch1_Vlan100__GigabitEthernet1/0/23","layer2__switch2_Vlan100","layer2__switch2_Vlan100__GigabitEthernet1/0/23","layer2__switch2_Vlan100__GigabitEthernet1/0/3","layer2__host13_eth0","layer2__host13_eth0__eth0","layer2__switch2_Vlan100__GigabitEthernet1/0/4","layer2__host14_eth0","layer2__host14_eth0__eth0","layer2__switch2_Vlan100__GigabitEthernet1/0/24","layer2__switch1_Vlan100__GigabitEthernet1/0/24"],"flag": {"loop": true}}
hagiwara@dev02:~/ool-mddo/netomox-exp$

デモ用NW1b スイッチ間TrunkLayer1, Layer3
Originalと同じ

Layer2 (VLAN100)

13BIGLOBE Inc.

③. 経路シミュレーション：L3到達性テスト
eBGP

L3到達性テスト構成
PE01

eBGP

iBGP

PE02

PE01

OSPF

PE02

OSPF

CE01

CE02

CE01

CE02
VRRP

VRRP
Acc01

Svr01

iBGP

RegionA

Acc01

Svr02

Svr01

Acc02
RegionB

Svr02※vrnetlabを利用してVM環境上で構築

14

BIGLOBE Inc.

③. L3到達性テスト
回線メンテナンス時に不具合のおこる構成のコンフィグを作り、L3到達性テストで問題が事前検出できるかを確認
eBGP

PE01
0/0

RegionB

eBGP

iBGP

eBGP

PE02

iBGP

PE01
0/0

OSPF

CE01

CE02

設定モレの検出CE間のOSPF設定を入れ忘れていた

VRRP

Acc01

本来はCE01-02間もOSPF Area

eBGP

PE02

OSPF

CE01

CE02

NO_ROUTE

VRRP

Acc01

CEがuplinkしかAreaに入っていないので切れるとRegion内経路がはいってこない

RegionA

Link-down snapshot

Original snapshot
15

BIGLOBE Inc.

③-1: コンフィグの変更(Given)push(定期・手動)時に一連の検査を自動実行

config, stateは定期的に取得. Push(or 担当者操作)

運用対象NW

deviceconfig &state• 本デモ用コンフィグの作成• Git push (CI)

L1
リンク情報
抽出

L1-L3
トポロジ
生成

topology
data

各種
テスト
検査

Parser,Simulator
API
Wrapperlayer1
topology

テスト・検査結果に応じてコンフィグの修正
必要なら環境へのフィードバック(ここは従来のやり方で)

WebUI
(可視化)
16

BIGLOBE Inc.

③-2: トポロジデータの生成
push(定期・手動)時に一連の検査を自動実行

config, stateは定期的に取得. Push(or 担当者操作)
L1
リンク情報
抽出

L1-L3
トポロジ
生成

device snapshot (全L1リ• Original snapshot + Link-down
config &ンク障害パターン)の生成state
運用対象NW• 差分情報の生成

topology
data

各種
テスト
検査

Parser,
Simulator
API
Wrapperlayer1
topology

テスト・検査結果に応じてコンフィグの修正
必要なら環境へのフィードバック(ここは従来のやり方で)

WebUI
(可視化)
17

BIGLOBE Inc.

③-2a: トポロジデータの生成(手動実行時)

hagiwara@dev02:~/ool-mddo/playground$ docker-compose up –dhagiwara@dev02:~/ool-mddo/playground$ docker-compose run netomox-exp bash
root@b7a6d542b4e0:/netomox-exp# bundle exec rake…
(省略)…
bundle exec netomox diff -o /mddo/netoviz_model/pushed_configs_linkdown_mddo_network_34.json.diff/mddo/netoviz_model/pushed_configs_drawoff_mddo_network.json /mddo/netoviz_model/pushed_configs_linkdown_mddo_network_34.json
mv /mddo/netoviz_model/pushed_configs_linkdown_mddo_network_34.json.diff/mddo/netoviz_model/pushed_configs_linkdown_mddo_network_34.json
bundle exec netomox diff -o /mddo/netoviz_model/pushed_configs_linkdown_mddo_network_35.json.diff/mddo/netoviz_model/pushed_configs_drawoff_mddo_network.json /mddo/netoviz_model/pushed_configs_linkdown_mddo_network_35.json
mv /mddo/netoviz_model/pushed_configs_linkdown_mddo_network_35.json.diff/mddo/netoviz_model/pushed_configs_linkdown_mddo_network_35.json
bundle exec netomox diff -o /mddo/netoviz_model/pushed_configs_linkdown_mddo_network_36.json.diff/mddo/netoviz_model/pushed_configs_drawoff_mddo_network.json /mddo/netoviz_model/pushed_configs_linkdown_mddo_network_36.json
mv /mddo/netoviz_model/pushed_configs_linkdown_mddo_network_36.json.diff/mddo/netoviz_model/pushed_configs_linkdown_mddo_network_36.json
rm -f /mddo/netoviz_model/*.diffbundle exec netomox diff -o /mddo/netoviz_model/pushed_configs_drawoff_mddo_network.json.diff/mddo/netoviz_model/pushed_configs_mddo_network.json /mddo/netoviz_model/pushed_configs_drawoff_mddo_network.json
mv /mddo/netoviz_model/pushed_configs_drawoff_mddo_network.json.diff /mddo/netoviz_model/pushed_configs_drawoff_mddo_network.json
cp model_defs/layout/*.json /mddo/netoviz_model
root@b7a6d542b4e0:/netomox-exp#• Original snapshot + Link-down snapshot (全L1リンク障害パターン)の生成• 差分情報の生成

18

BIGLOBE Inc.

③-3: 構成情報を使った検査・テスト
push(定期・手動)時に一連の検査を自動実行

config, stateは定期的に取得. Push(or 担当者操作)•

運用対象NW

L1
L1-L3
リンク情報
トポロジ
Original/Link-downの各レイヤ(L1-L3)を比較
抽出
生成• ノード・リンク等の増減
device• ループの増減
config &state• 非連結なNWの数の増減• それらの重みづけ + スコア化

topology
data

各種
テスト
検査

Parser,
Simulator
API
Wrapperlayer1
topology

テスト・検査結果に応じてコンフィグの修正
必要なら環境へのフィードバック(ここは従来のやり方で)

WebUI
(可視化)
19

BIGLOBE Inc.

③-3a: L3到達性テスト(テストパターン定義)
environment:
network: pushed_configs
snapshot: mddo_networkgroups:reg.a_VL10_hosts:- regiona-svr01__enp1s4- regiona-svr02__enp1s4
reg.b_VL1010_hosts:- regionb-svr01__enp1s4
reg.b_VL1020_hosts:- regionb-svr02__enp1s4

デモでは
Source group → Destination group の組
み合わせを生成グループ定義グループ間の双方向全組み合わせなど、テスト粒度に応じて実装は考えられる

同一ポリシで扱うEndpoint(IPを持つインタフェース)の集合

RegionANetwork
reg.a_VL10_hosts

patterns:- [reg.a_VL10_hosts, reg.b_VL1010_hosts]- [reg.a_VL10_hosts, reg.b_VL1020_hosts]

enp1s4svr01

enp1s4svr02

RegionBNetwork
reg.b_VL1010_
enp1s4hosts

svr01

reg.b_VL1020_
enp1s4 hosts

svr02

テストパターン定義
どのグループ間でL3到達性テストをするか?
20

BIGLOBE Inc.

③-3b: L3到達性テスト(Linkdown)

Link-down
snapshots

root@782dac92ba7c:/netomox-exp# bundle exec ruby exe/mddo_toolbox.rb test_reachability exe/traceroute_patterns.yaml -n pushed_configs_linkdown –r(省略)test: pushed_configs_linkdown/mddo_network_19 <No.19: down RegionA-PE01[ge-0/0/2] <=> RegionA-CE01[Ethernet1] in layer1>:
F==================================================================================================================================================Failure: test: pushed_configs_linkdown/mddo_network_19 <No.19: down RegionA-PE01[ge-0/0/2] <=> RegionA-CE01[Ethernet1] inlayer1>(TestTracerouteResult::PATTERN: reg.a_VL10_hosts->reg.b_VL1020_hosts::CASE: regiona-svr02[enp1s4](172.30.10.101) ->region-svr02[enp1s4](172.31.20.100)): assert_block failed.
/home/hagiwara/ool-mddo/netomox-exp/exe/reach_test/test_traceroute_result.rb:14:in `block (6 levels) in <class:TestTracerouteResult>'
11:sub_test_case "CASE: #{test_case['case'][0]} -> #{test_case['case'][1]}" do(L3通信うまくいかなかった)12:
test_case['traceroute'].each do |trace|13:
test "#{trace[0]}/#{trace[1]} <#{trace[2]}>" do=> 14:
assert_block { %w[ACCEPTED DISABLED NEIGHBOR_UNREACHABLE].include?(trace[3]) }
15:
end
16:
end
17:
end
==================================================================================================================================================: (0.000920)
test: pushed_configs_linkdown/mddo_network_20 <No.20: down RegionB-PE01[ge-0/0/1] <=> RegionB-PE02[ge-0/0/1] in layer1>:.: (0.000056)

Failしたテストケースがある

4/144 で Fail(省略)144 = 36 snapshots(links) * 4 flows

Finished in 0.02493022 seconds.
------------------------------------------------------------------------------------------------------------------------------------------------144 tests, 144 assertions, 4 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
97.2222% passed
BIGLOBE Inc.
21-------------------------------------------------------------------------------------------------------------------------------------------------

③-3c: L3到達性テスト(Linkdown)
テスト結果(サマリ/CSV)で失敗したテストケースを検索
root@782dac92ba7c:/netomox-exp# csvtool col 6-8 pushed_configs_linkdown.test_summary.csv
Description
Deposition
No.19: down RegionA-PE01[ge-0/0/2] <=> RegionA-CE01[Ethernet1] in layer1
NO_ROUTE
No.19: down RegionA-PE01[ge-0/0/2] <=> RegionA-CE01[Ethernet1] in layer1
NO_ROUTE
No.19: down RegionA-PE01[ge-0/0/2] <=> RegionA-CE01[Ethernet1] in layer1
NO_ROUTE
No.19: down RegionA-PE01[ge-0/0/2] <=> RegionA-CE01[Ethernet1] in layer1
NO_ROUTE
root@782dac92ba7c:/netomox-exp#| column -s, -t | egrep -vi '(accepted|disabled|neighbor_unreach)'Hopsregiona-svr01[enp1s4]->regiona-ce01[Vlan10]
regiona-svr02[enp1s4]->regiona-ce01[Vlan10]
regiona-svr01[enp1s4]->regiona-ce01[Vlan10]
regiona-svr02[enp1s4]->regiona-ce01[Vlan10]

テストケース No.19 でFailHops列

RegionA-PE01～CE01間のリンクダウン

Server → CE (default gateway) で止まっている?

22

BIGLOBE Inc.

③-4a: 各レイヤの構造チェック(No.19)
RegionB

Layer1

PE01

PE02

CE01

CE02

Layer3

NO_ROUTE

Acc01
RegionA

No.19
L3トポロジ的には迂回経路がありそう
なぜCE02側に迂回しない?
23

BIGLOBE Inc.

③-4b: デバイスの状態確認(No.19)• 検証環境で実際に調査する• Batfish上で調査する+ Config確認

hagiwara@dev02:~/ool-mddo/playground$ docker-compose exec batfish-wrapper python -i(省略)>>> from pybatfish.client.session import Session>>> bf = Session()>>> bf.set_network('pushed_configs_linkdown')'pushed_configs_linkdown'>>> bf.set_snapshot('mddo_network_19')'mddo_network_19'>>> bf.q.routes(nodes='regiona-ce01').answer().frame()
NodeVRF
Network
Next_Hop_IP Next_Hop_Interface
Protocol Metric Admin_Distance0 regiona-ce01 default
172.16.5.0/30 AUTO/NONE(-1l)
Port-Channel1 connected00
1 regiona-ce01 default
172.30.10.0/24 AUTO/NONE(-1l)
Vlan10 connected00
2 regiona-ce01 default
172.30.20.0/24 AUTO/NONE(-1l)
Vlan20 connected00
3 regiona-ce01
vrf1 172.30.110.0/24 AUTO/NONE(-1l)
Vlan110 connected00
4 regiona-ce01
vrf1 172.30.120.0/24 AUTO/NONE(-1l)
Vlan120 connected00>>> bf.q.ospfEdges(nodes='regiona-ce01').answer().frame()
Empty DataFrame
Columns: [Interface, Remote_Interface]
Index: []>>> bf.q.vrrpProperties(nodes='/regiona-ce*/', interfaces='/Vlan10/').answer().frame()
Interface Group_Id Virtual_Addresses Source_Address Priority Preempt0 regiona-ce02[Vlan10]
1['172.30.10.3'] 172.30.10.2/24
100
True
1 regiona-ce01[Vlan10]
1['172.30.10.3'] 172.30.10.1/24
110True>>>

No.19

CE01
CE02からOSPFで経路もらっていると思ったらない…
Tag
None
None
None
None
None

OSPF Neighborがない

VRRP Master = CE01

24

BIGLOBE Inc.

③-4c: 原因特定
eBGP

PE01
0/0

RegionB

eBGP

iBGP

eBGP

PE02

PE01
0/0

OSPF

CE01

CE02

設定モレ

Acc01

iBGP

PE02

OSPF

CE01

CE間のOSPF設定を入れ忘れていた

VRRP

eBGP

本来はCE01-02間もOSPF Area

NO_ROUTE

CE02
VRRP

Acc01

CEがuplinkしかAreaに入っていないので切れるとRegion内経路がはいってこない

RegionA

Link-down snapshot (No.19)

Original snapshot
25

BIGLOBE Inc.

③-5: 修正eBGP

PE010/0

RegionB

eBGP

iBGP

CE間にOSPF設定を追加
diff --git a/mddo_network/configs/RegionA-CE01_config.txt
b/mddo_network/configs/RegionA-CE01_config.txt
index ff715ba..4ee5958 100644--- a/mddo_network/configs/RegionA-CE01_config.txt+++ b/mddo_network/configs/RegionA-CE01_config.txt@@ -29,6 +29,7 @@ interface Port-Channel1
ip address 172.16.5.1/30
ipv6 address fc00:172:16:5::1/64
port-channel min-links 1+
ipv6 ospf 1 area 0.0.0.0!
interface Port-Channel2
load-interval 30@@ -165,6 +166,7 @@ router ospf 1
passive-interface default
no passive-interface Ethernet1
no passive-interface Ethernet2+
no passive-interface Port-Channel1
network 0.0.0.0/0 area 0.0.0.0
max-lsa 12000
!

PE02

OSPF

CE01

CE02
VRRP

Acc01
RegionA

Original snapshot

再度テストを実施(修正)

26

BIGLOBE Inc.

③-6: 修正後の再チェック

修正したコンフィグでトポロジデータ再作成
root@b7a6d542b4e0:/netomox-exp# bundle exec rake

テスト再実行(省略)

root@b7a6d542b4e0:/netomox-exp# bundle exec ruby exe/mddo_toolbox.rb test_reachability exe/traceroute_patterns.yaml -n pushed_configs_linkdown –r(省略)
Finished in 0.016242604 seconds.
--------------------------------------------------------------------------------------------------------------------------------------------------144 tests, 144 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed--------------------------------------------------------------------------------------------------------------------------------------------------8865.57 tests/s, 8865.57 assertions/s
hagiwara@dev02:~/ool-mddo/netomox-exp$

テストが全部通った

27

BIGLOBE Inc.

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

28

BIGLOBE Inc.

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

29

BIGLOBE Inc.

今後の発展性• ネットワークリソースの追加・変更・削除• トポロジの変更・変動, VLAN等仮想リソース, Overlay• Peer/Neighbor, 経路制御設定, Policy/Filter• 障害試験
• CI, カバレッジの拡大・向上• 模擬・シミュレーション, 経路切り替えなどの手順確認等• 特定のトラフィック(フロー)がどこを経由しているかの確認• 実態・リアルタイムステートの把握(STPやVRRPなど)• TEにおけるベストパス・セカンダリパスの確認• とりうるパスを優先順位別に確認・選択

30

BIGLOBE Inc.

最後に
沖縄オープンラボラトリのModel Driven Network DevOps Projectは一緒に活動してくれるプロジェクトメンバーを募集しています。
↓募集フォームは以下になります。↓
https://www.okinawaopenlabs.org/mdnd
また、直接話を聞きたい方は気軽にPJメンバーへ話しかけてください。
よろしくお願いいたします。

31

BIGLOBE Inc.

付録
・MDDOのGithubリポジトリ
https://github.com/ool-mddo・テックブログ
今回の内容を詳しく解説した3社でのブログリレー---BIGLOBE
https://style.biglobe.co.jp/entry/2022/03/30/090000?fbclid=IwAR35ZDUJUyURx1aOnY5lmZmG6f
0FhkXLU-Hcitp7nCue3r_7-dD-OgS--VM
NTTコミュニケーションズ
https://engineers.ntt.com/entry/2022/03/31/090000?fbclid=IwAR3oX2WPgUVJMEJEPgklMQUGdsNMfBbbIrVtvSdLOikVno75RV8agiw52YYTIS
https://www.tis.jp/special/platform_knowledge/nw02/

32

BIGLOBE Inc.

ご清聴ありがとうございました

33

BIGLOBE Inc.

Appendix

多リージョン試験（商用規模での動作確認）: NWの規模と処理時間

34

BIGLOBE Inc.

NWサイズによるパフォーマンス変化

RegionNW Device

HostLink

21143653010901060

2018020120

40

360

40240

80

720

5リージョン構成(L1)35

BIGLOBE Inc.

トポロジデータ作成にかかる時間(リンク障害パターンのトポロジ…L1リンク数分を含む)
データ生成(静的検査)にかかる時間

Intel Xeon 2.10GHz 16C/32T
ただしパーサ/シミュレータ(batfish)メモリ使用量を抑えるため
データ生成セクション(snapshot_to_model)
では並列処理していない

パーサ/シミュレータ(batfish)
最大メモリ使用量

2h

1h

15GB

0.5h

11 NW devices
4 Hosts
36 Links

120 NW devices
40 Hosts
360 Links

240 NW devices
80 Hosts
720 Links
36

BIGLOBE Inc.

処理単体にかかる時間

••
••
•

37

load_snapshot:
スナップショットのロード
check_loaded_snapshot:
ロードされているスナップショットのリスト取得single_snapshot_queries:
スナップショット(単体)に対して各種queryを実行してCSVに落とす
tracert_neighbor_region:
RegionA-B (隣接間のL3通信シミュレーション(traceroute)
tracert_facing_region:
RegionA-最も遠いAS間のL3通信シミュレーション(traceroute)

BIGLOBE Inc.

BIGLOBE Inc.