本番ネットワーク環境を安全に設定するため、BIGLOBE、NTTコミュニケーションズ、TISの3社が合同で取り組んでいる研究のご紹介です。既存環境から自動抽出したモデル上で、設定を事前に検証します。

1. はじめに

基盤本部ネットワーク技術部の滝口と、同じくネットワーク技術部の川口です。

BIGLOBEは2021年8月から沖縄オープンラボラトリ（Okinawa Open Laboratory: OOL）の「Model Driven Network DevOps Project」に参加しています。このPJはBIGLOBE、NTTコミュニケーションズ、TIS（アルファベット順）の3社が会社を横断してネットワーク（NW）自動化の研究に取り組んでおり、2022年2月25日にはOOLの成果発表会 ※1 にて活動の概要を報告しました。

今回は全体を3パートに分けて各社持ち回りで紹介するブログリレー形式で、より詳しい内容をお届けしていきます。

前編（本記事） BIGLOBE「検証環境の構築、NW装置のコンフィグ自動定期取得」
中編 NTTコミュニケーションズ「コンフィグからL1/L2/L3に分けてモデルデータを作成するステップ」
後編 TIS「モデルデータを評価するステップ」

※1 下記Project紹介ページの「2021年度活動紹介」に成果発表資料を掲載: www.okinawaopenlabs.org

プロジェクトの背景

ネットワーク運用の現場では、人力での運用は限界を迎えつつあります。設備増強により操作対象ノードが増加し、仮想化・オーバーレイなどの技術の導入によりネットワーク構成が複雑さを増しているためです。そのためAnsible などを活用したネットワーク運用の自動化が一般的になりつつあります。

しかし、Ansible が対象にするのはノード単体に対する操作の自動化です。ノード単体では正しい操作をしているつもりでもシステム全体では不整合になる場合があります。

このような背景から、現場のオペレーションはますます複雑になっています。「操作してみないとわからない」「本番環境で操作して初めて設定ミスに気がついた」といった、ヒヤリとする経験をお持ちの方もいらっしゃるのではないでしょうか。

プロジェクトのねらい

本PJは、障害につながりかねない「本番環境で初めて気づく」リスクを撲滅することを目指しています。それを実現するために、

仮想検証環境を使った安全な動作検証を可能にすること
既存のNW環境を忠実に模した仮想検証環境を自動的に構築すること

をねらっています。これらのねらいを実現するために、具体的には次の機能を実装していきます。

既存環境の構成情報を抽出し、モデルデータを構築
モデルデータを基にした、
- システムの構成や状態の可視化、時間変化のトラッキング（構成変化差分の取得）
- これまで人が見ていたレビューやチェック、設計ポリシーとの適合性検査などの実装
- 仮想の検証環境を自動構築、検証環境内での機能検証、リハーサルやトレーニング、自動テストの実行

これらの機能により、事前にモデルベースでシステムの整合性やポリシーをチェックし、さらに仮想検証環境で動作検証を自動化することが可能になります。その結果、テスト・検証を効率的に繰り返せるようになり、安全に本番環境でオペレーションできるようになると考えています。

システム構成と動作フロー

上記のねらいを達成するため、OOLでは3社合同で次のシステムを開発・検証しています。

開発中のシステムは、運用対象ネットワークの検証環境を構築後、以下の流れで動作します。

NW装置のコンフィグを自動定期取得するステップ
コンフィグからLayer1(物理層)/Layer2(データリンク層)/Layer3(ネットワーク層)に分けてモデルデータを作成するステップ
モデルデータを評価するステップ

この記事で紹介する内容

本記事ではBIGLOBEが、初回に実施する検証環境の構築と、システム動作の最初のステップで実行するコンフィグ自動取得について、2章に分けて紹介します：

運用対象ネットワークの検証環境構築
- 検証環境を本番模擬環境としてvrnetlabを使った効率的なVirtual Network Function（VNF）の構築方法
NW装置のコンフィグとステータスの自動定期取得
- ansible-runnerとGitHub Actionsを使って装置のコンフィグを定期取得する実装方法

2. 運用対象ネットワークの検証環境構築方法

この検証環境は、本番環境で使われている基本的なNW機能を盛り込みつつ、仮想化技術を活用したマルチノードのスケールアウトを実現し、スモールスタートでの構築を可能にしました。

検証環境のネットワーク構成

このPJでは検証環境として、シンプルながらもLAG、 BGP、 OSPF、 VLAN、 VRRPなど本番環境でも使われる基本機能を含んだ以下のNW構成を設計しました。

この構成は物理環境ではなく、OOLのテストベッド環境上にベンダーVNF等を延べ15台用意して実現しました。

vrnetlabによる検証環境の構築

検証環境を構築するにあたり、中心的な役割を果たしたツールが vrnetlab です。

vrnetlabとはdockerコンテナ上でqemu/kvmのネットワークOSの仮想マシンをデプロイするラボ・評価目的のオープンソースソフトウェア（OSS）になります。

vrnetlabにて起動するVNFのコンテナ内にはlaunch.pyと呼ばれる起動スクリプトが入っており、コンテナが起動する際にこのスクリプトが実行されます。起動スクリプトでVNFの作成～ゼロタッチコンフィグが行われ、自動でVNFが利用できるようになります。

下図がVNFのJuniper vMXとArista vEOSの構成例です。

VNF間にvr-xconと呼ばれるコンテナを入れることでVNF間のP2Pリンクが作成でき、お互いに通信できるようになります。このP2Pリンクのおかげで、VNF間でTrunk VLANやLACP構成を（物理機器の時と同じ使用感で）使うことができます。

参考ブログ： www.brianlinkletter.com

vrnetlabのマルチノード構成

このPJの検証構成では11台のVNFと4台の仮想マシン（VM）を用いており、ベアメタルサーバ1台ではスペックが不足していたため、複数台並べたマルチノードの構成を採用しました。

vrnetlabはノードを跨いだVNF間の通信も簡単に設定できます。具体的には、docker swarmモードを有効にして、dockerのoverlayネットワーク上にvrnetlabのVNFのコンテナおよびvr-xconコンテナをアタッチすれば実現できます（TrunkVLANやLACPもマルチノード上で機能します）。

マルチノード前提でvrnetlabを使う際は、VNFコンテナ全てにoverlayネットワークをアタッチさせておけば、どのノード上のどのVNFコンテナにおいてもvr-xconで繫げることができるので、物理ノードのスケールアウトも簡単にできます。

検証環境のまとめと今後の課題

マルチノードのvrnetlabを使って検証環境を効率的に構築することができました。この環境でデモコンフィグの作成、デモ構成のNW動作確認を実施します。さらに、デモ環境のコンフィグおよびステータスをデータソースとして、モデルデータおよび経路情報の解析にも活用しています。

今後の課題は、本番環境の理想(あるべき姿)の構成を検証環境で再現することです。ブログリレーの後編では、モデルデータをもとに静的・動的テストについて解説します。このテストによって発見した問題箇所を検証環境上で修正し、さらに別の問題を発見して修正する、といったサイクルを繰り返すことで、理想の本番環境のNWモデルを構築できると考えています。

今回は、本番構成もデモ用に作った仮想環境だったため、テストしたあとに修正した構成を再現・検証することは簡単にできました。しかし、世間一般のどの企業でも実運用している基盤には数十台〜数百台以上のNW装置があります。この規模になると、今回使用したVMベースのvrnetlabではうまくスケールさせられません。より短時間で大量に起動できるコンテナ型の仮想ルータ(以後CNFと略称します)で経路シミュレーションを実現する必要が出てきます。

具体的には、vrnetlabは以下の2つの問題点があります。

VNFのみ対応のため、大規模構成に不向き
最近のベンダー提供のVNFは最低メモリ容量が16GB以上も消費する傾向があり、一台VNFを起動するだけでも、かなりのサーバリソースを消費します。CNFの動作については、vrnetlabは対応していません。
外部機器や非vrnetlabのVMと通信できない
vrnetlabはVNF間の通信はTCPソケットのオーバレイネットワーク上で行われているため、オーバレイを終端するツールが必要になりますが、公式では提供されていないので他の非vrnetlabのVMや外部の物理ノードとの疎通はできません。

この問題点の対応が厳しいため、新たにcontainerlabというOSSも導入することにしました。containerlabではCNFを前提としたOSSでvrnetlabとの統合もできるため、本番環境の理想(あるべき)の構成を検証環境で再現しやすくなりました（forkされたvrnetlabのため、originのvrnetlabとの互換性はない点にはご注意ください）。

今後はcontainerlabも組み込んだ検証環境でさらに本システムを拡張していこうと計画しています。

3. NW装置のコンフィグとステータスの自動定期取得

クラウドサービスを活用して小さく始められるように、コード管理やCI/CD、コンテナレジストリの機能を備えるGitHubを採用しました。GitHub Actions のワークフローで ansible-runnerを実行して NW装置のコンフィグやインターフェース、Link Layer Discovery Protocol（LLDP）のステータスを定期的に取得しています。

取得したコンフィグ・ステータスをスナップショットとして記録し、このシステムの後続のステップでトポロジなどのモデル・テスト解析に使います。

本番環境ではNW装置のコンフィグやステータスは日々変更されています。そこで、定期取得したスナップショットをバージョン管理することで、時間経過による構成変更を把握することができるようになります。

実際のワークフロー

GitHub Actionsのワークフローでは self-hosted runner を使用しAnsible 実行サーバをホストランナーとしています。

ワークフローの処理の流れは以下のようになっています。

NetBoxから対象ルーターの認証情報を取得
ルーターの show run config を取得
サーバーのnetplanの情報取得
各ルーターのステータスを取得
show interfaces
show lldp
コンフィグ・ステータスを共有ディレクトリにコピー
更新・差分があればGitHubにpush

ワークフローの処理の1番目で使用する NetBox というのは OSSの IPAM/DCIM（IPアドレス管理 / データセンターインフラ管理）ツールです。Ansibleとの相性もよく、あらかじめ装置のアクセス情報をNetboxに登録しておくことで、Ansible実行時にinventoryとして装置の認証情報を取得しています。

こうすることで、Netboxに装置のアクセス情報を一元管理したまま、Ansibleのinventory上に装置情報を取得することが可能となります。

ワークフローの処理の2〜4ではワークフロー上で ansible-runnerを実行して、各ルーターのコンフィグの情報・ステータスやサーバーのnetplan情報を取得し、ファイルとして保存しています。これらのコンフィグ・ステータスのデータがスナップショットとなります。

ワークフローの起動設定はcronで定期的に実行されるように設定し、定期的に取得したコンフィグ情報やステータスに変更があれば、自動でGitHubにpushすることで、スナップショットの更新を実現しています。

現状の検証環境の規模ではワークフローの実行時間は90秒程度です。パブリックレポジトリのためGitHub Actionsは無料で制限なく利用できますが、プライベートレポジトリでも2000分/月まで無料で利用できるため、1時間に1回程度の実行であっても十分余裕があります。

今後の課題

この後に続くモデルデータを評価するステップでは、テスト・検証の網羅性が重要になります。網羅性を向上させるために必要なのが、ステータス情報の解析機能です。例えば、LLDPのステータス情報から物理リンクの対向インターフェースの状態を自動で生成するなどの解析を可能にします。しかし現時点のワークフローではこの解析機能は実装できていません。今後はワークフローを拡充して対応する予定です。

作成したAnsibleのPlaybookやGitHub Actionsワークフローは、次のリポジトリーで公開しています。ご参考になれば幸いです。

使用したPlaybookの内容： github.com

コンフィグおよびステータスと GitHub Actions ワークフロー： github.com