© NTT Communications Corporation All Rights Reserved. 1 ネットワーク設定の抽象化と コンテナルータを用いた検証環境の立ち上げ支援 田島 照久 [email protected] NTT Communications / Innovation Center 2023/03/24 NTT Tech Conference 2023

© NTT Communications Corporation All Rights Reserved. 2 ネットワーク設定の抽象化と コンテナルータを用いた検証環境の立ち上げ支援 の 要点3つ 1. 検証環境を早く立ち上げることでNWの運用を速くしたい 2. コンテナの設定に必要な変換ロジックを抽象化で解決 3. システムを作って実際にやってみた

© NTT Communications Corporation All Rights Reserved. 3 検証環境の用途は多岐：NTT Com 全社検証網の例 ◼ 足回りとしての回線 ⚫ 社内の何らかの案件の検証環境につかう ⚫ 拠点AのXXと拠点BのYYを接続したい=まさにキャリアネットワーク ◼ ネットワーク・クラウド・セキュリティ技術の検証 ⚫ Segment Routing, 伝送, Private Cloud, etc. ◼ 技術者育成・習熟環境

© NTT Communications Corporation All Rights Reserved. 4 ここが遅い？ ならば早いものを用意する 今回対象とする検証環境：本番環境の変更に向けた試行錯誤 本番環境 検証環境 XXを作りたい 検証環境を 立ち上げよう 試行錯誤 しよう 結果を 反映しよう

© NTT Communications Corporation All Rights Reserved. 5 今回の「検証環境」に求めるもの 実現できる事の事前確認 ＋ 本番デプロイのイテレーションを早く 1. 素早く立てられること ⚫ やってみないとわからない、を早期に解決する 2. 環境全体が検証できること ⚫ 本番と検証の違いは・・・の学習コストを下げる 3. 機能を絞って検証すること ⚫ 単体・統合のレイヤごとに検証を分割する 1 2 2 3

© NTT Communications Corporation All Rights Reserved. 6 なぜこの問題が重要なのか ◼ NW特有の事情 ハードウェアがベース ⚫ 可搬性が無い ⚫ 再現範囲を絞ってでも 仮想でスケールさせる必要あり ◼ 例えばWebアプリの場合 既に同じスタックで動作 ⚫ コンテナ技術等でそもそも本番と検 証の間に可搬性がある 本番環境 検証環境 本番環境 検証環境 （仮想）

© NTT Communications Corporation All Rights Reserved. 7 仮想環境立ち上げへのアプローチ：コンテナルータ 1. 素早く立てられること ⚫ コンテナルータを用いて環境作成することで時間短縮 2. 環境全体が検証できること ⚫ 軽量なルータで収容効率アップ ⚫ 仮想化レイヤーでスケールアウト 3. 機能を絞って検証すること ⚫ L3以上のルーティングに絞る ⚫ L2以下の挙動はエミュレーションしにくい → 可搬性が無い既存configをどうやって適用するのか

© NTT Communications Corporation All Rights Reserved. 8 問題の整理 右向き → • 検証環境を作るときに必要 • 環境に合わせて読み替える  左向き • 検証内容を適用するときに必要 • 元の環境のパラメタを補足する Hardware Container 本番環境と検証環境で アーキテクチャ・OS・Configいずれも異なる 本番環境 検証環境 直接置き換えすると、変換の組み合わせの多さや アドホックさがネックになる🤔

© NTT Communications Corporation All Rights Reserved. 9 翻訳に使用するモデルデータ ◼ 本来configには意図があるはず＝意味を解釈して変換すべき ⚫ 言語間の翻訳と同じ ◼ Configに依存しないモデルを経由 ⚫ 決定論的（not 確率論的）に変換する ⚫ 入出力「言語」が複数になっても変換テーブルが爆発しない Hardware Container 本番環境 検証環境 モデル データ NWの構造を抽象化 • 各レイヤのトポロジを グラフとして表現する 各環境へ翻訳 • 各環境の文法をテンプレ エンジンで生成する

© NTT Communications Corporation All Rights Reserved. 10 モデル化の功罪 Hardware Container 本番環境 検証環境 モデル データ diffが取れる → そこから意図を読み取れる → configのsuggestionができる Configパースが難しい （パーサのバグなど） → 何らかの確認が必要

© NTT Communications Corporation All Rights Reserved. 11 ここまでのまとめ：解決できそうなこと・できないこと ◼ 本番環境へ早くリリースするために、検証環境の立ち上げを早くする ⚫ もちろんそのほかにもボトルネックは多い ◼ コンテナを使って検証NWを作る ⚫ 早い＋スケールする ◼ 全体の設計にフォーカスする ⚫ L3以上 ⚫ 特定の機種の検証は棲み分け ◼ モデルを介して翻訳する ⚫ モデルに表現できない物は捨てられる

© NTT Communications Corporation All Rights Reserved. 12 システムを作って、いくつか検証環境を立ち上げてみた ◼ デモ用のNW ⚫ 6ノード＋9セグメント ◼ Com検証網NW ⚫ マルチベンダ ⚫ 12ノード＋12セグメント ⚫ OSPF部分だけを対象 サーバ移転 RegionC-RT1上で OSPFの経路再配布 設定ミスにより、 移転後の経路が 広報されない！

© NTT Communications Corporation All Rights Reserved. 13 変換の仕組み：モデルのデータ構造 ◼ 各レイヤをグラフとして表現したデータ（RFC 8345） ⚫ L1/L2/L3/OSPFそれぞれのレイヤごとにノードとエッジを持つ ⚫ レイヤ間の関係性をノードの参照・被参照で表現する Layer3 • L3(IPv4)のトポロジ • インターフェースや IP設定から構成される • L1/L2の冗長化は1つの Point-to-MultiPoint Node (Segment)とし て集約される OSPF (Area 0) • OSPF neighbor の トポロジ • L3情報とOSPF設定を 基に neighbor を判定 RFC 8345, A YANG Data Model for Network Topologies, https://datatracker.ietf.org/doc/rfc8345/ モデル データ

© NTT Communications Corporation All Rights Reserved. 14 変換の仕組み：名前空間の変換 ◼ それぞれの環境用にモデルデータを読み替え、相互に変換可能にする ⚫ 変換テーブルの自動作成 ⚫ ユニークに採番し 順方向・逆方向に対応 Hardware Container 本番環境 検証環境 モデル データ node: original: regiona-rt1 clab: regiona-rt1 iflist: - original: ge-0/0/0.0 clab: eth1.0 ifDescr: to_Seg-192.168.0.0-30_Ethernet1 - original: ge-0/0/1.0 clab: eth2.0 ifDescr: to_Seg-172.16.0.0-30_Ethernet1 original clab

© NTT Communications Corporation All Rights Reserved. 15 ここで補遺：正しく翻訳できているのかは確かめられる ◼ 検証環境で何も変更せず入力と出力を比較 ⚫ 何も変更していないので変更が無ければ 翻訳が正しいと言える ◼ 設定(config)ではなく状態(status)を比較 ⚫ 例えばRIB(routing table)の差が無い確認 ⚫ ただしそれなりに面倒 diff show xxx & diff 課題はこれ↓

© NTT Communications Corporation All Rights Reserved. 16 実際に環境を立ててみた ◼ 数分レベルで起動可能 デモ用NW NTT Com検証網 NW 規模 6ノード＋ 9セグメント 12ノード＋ 12セグメント コンテナルータ cRPD cRPD ピークCPU使用率 40% 42% メモリ使用量 2GB 2GB 起動までの合計時間 107sec 139sec （内）本番からモデル生成 14sec 14sec （内）仮想用config生成 93sec 125sec 仮想からモデル生成 41sec 43sec 実行環境はCPU Xeon Silver 4216 (16C/32T) + Mem 64GiB + Ubuntu 22.04 共通コンポーネントの使用量の 方が大きく、この規模だと差が 出ないレベルにスケールする config生成のansible+j2 templateの処理が支配的でさら なる高速化は可能

© NTT Communications Corporation All Rights Reserved. 17 やってみて詰まったところ・変換時の諸問題 ◼ インターフェースの命名規則 ⚫ 人間は理解可能だが、正確なマッチングを取るには泥臭い正規表現が必要 ⚫ lo0  lo.0  lo0.0 とか TenGigE  HundredGigabitEthernet とか ◼ 機能差分 ⚫ ルーティングプロトコルのprocess-idという概念の有無 ◼ L1特有の話 ⚫ 実世界のconfigには伝送装置などさらに複雑なレイヤ ◼ 各種実装作り込みハードル ⚫ Configパーサ(Batfish)のバグ解消 ⚫ Container-labのLinux Bridgeが本用途に不向きでOvSの導入 ⚫ management IFの扱い

© NTT Communications Corporation All Rights Reserved. 18 今後の発展 ◼ 1回起動するところはできた 次は「効率的に」複数回まわすところ ◼ コンテナルータとしての選択肢が乏しくOSS (VyOS) 対応へ 現状はcRPDというプロプライエタリに依存 ◼ 翻訳の中身の拡充 OSPFで動くことはわかったので、より複雑なBGPへ拡張中 ？ !

© NTT Communications Corporation All Rights Reserved. 19 まとめ 1. 検証環境を早く立ち上げることでNWの運用を速くしたい 2. コンテナの設定に必要な変換ロジックを抽象化で解決 3. システムを作って実際にやってみた 本PJは沖縄オープンラボラトリでのTIS株式会社・ビッグローブ株式会 社との協同検証PJとして実施中です 実際にシステムの動作様子などはデモ動画があります https://youtu.be/xRxpsly1kls