特許 6939718 ネットワーク機器及びネットワーク機器の設定方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6939718

(24)【登録日】2021年9月6日

(45)【発行日】2021年9月22日

(54)【発明の名称】ネットワーク機器及びネットワーク機器の設定方法

(51)【国際特許分類】

   H04L 12/70 20130101AFI20210909BHJP

【ＦＩ】

   H04L12/70 100A

【請求項の数】8

【全頁数】15

(21)【出願番号】特願2018-120469(P2018-120469)

(22)【出願日】2018年6月26日

(65)【公開番号】特開2020-5042(P2020-5042A)

(43)【公開日】2020年1月9日

【審査請求日】2020年10月2日

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】100119677

【弁理士】

【氏名又は名称】岡田 賢治

(74)【代理人】

【識別番号】100115794

【弁理士】

【氏名又は名称】今下 勝博

(72)【発明者】

【氏名】日比 智也

(72)【発明者】

【氏名】益谷 仁士

(72)【発明者】

【氏名】高橋 宏和

(72)【発明者】

【氏名】市川 潤紀

(72)【発明者】

【氏名】間野 暢

【審査官】 安藤 一道

(56)【参考文献】

【文献】 特開２０１５−１６２７１７（ＪＰ，Ａ）

【文献】 特開２０１７−１６９０８３（ＪＰ，Ａ）

【文献】 特開平８−３２６４９（ＪＰ，Ａ）

【文献】 特表２００６−５１９５１８（ＪＰ，Ａ）

【文献】 米国特許出願公開第２０１１／００１６１９９（ＵＳ，Ａ１）

【文献】 米国特許出願公開第２０１４／０１９４１０３（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｌ １２／７０

(57)【特許請求の範囲】

【請求項1】

複数のプロトコルのそれぞれを処理するための複数の機能モジュールを備えるネットワーク機器であって、
前記機能モジュールに登録されている既存設定及び前記機能モジュールに新たに登録される新規設定を共通言語で管理する設定管理部と、
前記機能モジュールに関連するモジュール関連状態の統計情報を取得し、前記共通言語で管理する統計情報管理部と、
前記機能モジュール間の依存関係及びネットワークのポリシーを前記共通言語で管理しており、前記新規設定に対して、前記依存関係、前記既存設定及び前記統計情報との関係において前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にあるときに、前記新規設定を前記機能モジュールに投入する設定検証部と、
を備えることを特徴とするネットワーク機器。

【請求項2】

前記設定検証部は、前記依存関係が新たに登録されたとき、新たに登録された前記依存関係の下、前記既存設定及び前記統計情報が前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にないときに前記既存設定又は前記統計情報が異常であることを報知することを特徴とする請求項１に記載のネットワーク機器。

【請求項3】

前記設定検証部は、前記ポリシーが新たに登録されたとき、前記依存関係の下、前記既存設定及び前記統計情報が新たに登録された前記ポリシーの正常な範囲にあることを確認する検証作業を行い、新たに登録された前記ポリシーの正常な範囲にないときに前記既存設定又は前記統計情報が異常であることを報知することを特徴とする請求項１に記載のネットワーク機器。

【請求項4】

前記設定検証部は、前記統計情報管理部から前記モジュール関連状態の変化を検知したことの通知を受けたとき、前記設定管理部に前記機能モジュールに登録されている既存設定を取得させ、前記依存関係の下、前記既存設定及び変化した前記統計情報が前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にないときに前記モジュール関連状態が異常であることを報知することを特徴とする請求項１に記載のネットワーク機器。

【請求項5】

複数のプロトコルのそれぞれを処理するための複数の機能モジュールを備えるネットワーク機器の設定方法であって、
前記機能モジュールに登録されている既存設定及び前記機能モジュールに新たに登録される新規設定を共通言語で管理する設定管理手順と、
前記機能モジュールに関連するモジュール関連状態の統計情報を取得し、前記共通言語で管理する統計情報管理手順と、
前記機能モジュール間の依存関係及びネットワークのポリシーを前記共通言語で管理しており、前記新規設定に対して、前記依存関係、前記既存設定及び前記統計情報との関係において前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にあるときに、前記新規設定を前記機能モジュールに投入する設定検証手順と、
を行うことを特徴とするネットワーク機器の設定方法。

【請求項6】

前記設定検証手順では、前記依存関係が新たに登録されたとき、新たに登録された前記依存関係の下、前記既存設定及び前記統計情報が前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にないときに前記既存設定又は前記統計情報が異常であることを報知することを特徴とする請求項５に記載のネットワーク機器の設定方法。

【請求項7】

前記設定検証手順では、前記ポリシーが新たに登録されたとき、前記依存関係の下、前記既存設定及び前記統計情報が新たに登録された前記ポリシーの正常な範囲にあることを確認する検証作業を行い、新たに登録された前記ポリシーの正常な範囲にないときに前記既存設定又は前記統計情報が異常であることを報知することを特徴とする請求項５に記載のネットワーク機器の設定方法。

【請求項8】

前記設定検証手順では、前記統計情報管理手順で前記モジュール関連状態の変化を検知したことの通知を受けたとき、前記機能モジュールに登録されている既存設定を取得させ、前記依存関係の下、前記既存設定及び変化した前記統計情報が前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にないときに前記モジュール関連状態が異常であることを報知することを特徴とする請求項５に記載のネットワーク機器の設定方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、複数のプロトコルを処理するために複数のモジュールを持つ構成のネットワーク機器及びその設定方法に関する。

【背景技術】

【0002】

複数のプロトコルを処理するために複数のモジュールを持つ構成のネットワーク機器では、設定情報の管理や異常検知のために、統一の設定管理部や統計情報処理部を持つか、各機能モジュール毎に設定・統計情報の管理機構を持つ。このような構成において、各モジュールにおける依存関係や統計情報も加味した設定検証を行うには、統一の管理モジュールで行うか、それぞれの機能モジュールで他のモジュールの情報を集め依存関係を解決する必要があり、複雑である。また、昨今のユースケースの多様化に伴い、システム単体だけでなく、気温や位置情報も含む外部環境との依存関係も加味した検証、異常検知が必要である。

【先行技術文献】

【非特許文献】

【0003】

【非特許文献1】Ｋｕｎｉｈｉｒｏ Ｉｓｈｉｇｕｒｏ， Ｙｏｓｈｉｈｉｒｏ Ｎａｋａｊｉｍａ， Ｍａｓａｒｕ Ｏｋｉ， Ｈｉｒｏｋａｚｕ Ｔａｋａｈａｓｈｉ， “Ｚｅｂｒａ２．０ ａｎｄ Ｌａｇｏｐｕｓ： ｎｅｗｌｙ−ｄｅｓｉｇｎｅｄ ｒｏｕｔｉｎｇ ｓｔａｃｋ ｏｎ ｈｉｇｈ−ｐｅｒｆｏｒｍａｎｃｅ ｐａｃｋｅｔ ｆｏｒｗａｒｄｅｒ”， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ＮｅｔＤｅｖ １．１： Ｔｈｅ Ｔｅｃｈｎｉｃａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｌｉｎｕｘ Ｎｅｔｗｏｒｋｉｎｇ （Ｆｅｂ． ２０１６， Ｓｅｖｉｌｌｅ， Ｓｐａｉｎ）．

【非特許文献2】Ｆｏｇｅｌ， Ａ．， Ｆｕｎｇ， Ｓ．， Ｐｅｄｒｏｓａ， Ｌ．， Ｗａｌｒａｅｄ−Ｓｕｌｌｉｖａｎ， Ｍ．， Ｇｏｖｉｎｄａｎ， Ｒ．， Ｍａｈａｊａｎ， Ｒ．， ＆ Ｍｉｌｌｓｔｅｉｎ， Ｔ． Ｄ．， “Ａ Ｇｅｎｅｒａｌ Ａｐｐｒｏａｃｈ ｔｏ Ｎｅｔｗｏｒｋ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ａｎａｌｙｓｉｓ”， Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔｈｅ １２ｔｈ ＵＳＥＮＩＸ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｎｅｔｗｏｒｋｅｄ Ｓｙｓｔｅｍｓ Ｄｅｓｉｇｎ ａｎｄ Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ （ＮＳＤＩ ’１５） （Ｍａｙ ２０１５， Ｏａｋｌａｎｄ， ＣＡ， ＵＳＡ）．

【非特許文献3】Ｏｐｅｎｓｔａｃｋ Ｃｏｎｇｒｅｓｓ， ｈｔｔｐｓ：／／ｗｉｋｉ．ｏｐｅｎｓｔａｃｋ．ｏｒｇ／ｗｉｋｉ／Ｃｏｎｇｒｅｓｓ（２０１８年６月１１日検索）

【非特許文献4】Ｄａｔａｌｏｇ Ｕｓｅｒ Ｍａｎｕａｌ， ｈｔｔｐ：／／ｗｗｗ．ｃｃｓ．ｎｅｕ．ｅｄｕ／ｈｏｍｅ／ｒａｍｓｄｅｌｌ／ｔｏｏｌｓ／ｄａｔａｌｏｇ／ｄａｔａｌｏｇ．ｈｔｍｌ（２０１８年６月１１日検索）

【発明の概要】

【発明が解決しようとする課題】

【0004】

例えば、ＯｐｅｎＣｏｎｆｉｇｄ ｐｒｏｊｅｃｔ（非特許文献１を参照）ではＯｐｅｎｃｏｎｆｉｇｄモジュールが複数の機能モジュールの設定情報を代表して管理している。しかし、ＯｐｅｎＣｏｎｆｉｇｄでは設定異常の検証はＹＡＮＧと呼ばれるデータモデル記述言語で記述できる範囲でしか検証できず、実装上において各機能モジュールの設定妥当性検証や異常検知を行う際、複数の異なる機能モジュールの依存関係や統計情報を考慮していない。このため、ＯｐｅｎＣｏｎｆｉｇｄ ｐｒｏｊｅｃｔにおいてモジュール間の依存関係を考慮する場合には、各モジュール内で独自にモジュール間の依存関係を解決する手段を含める必要があり、モジュールの構成が複雑になるという第１の課題があった。

【0005】

一方、設定内容の整合性検証においては、特に複数の機器からなるネットワークの検証としてＦｏｇｅｌらが各機器からＣｏｎｆｉｇ情報とネットワークトポロジ情報を集め、Ｄａｔａｌｏｇを用いて、ネットワーク全体の設定の正しさを検証する手法を提案している（例えば、非特許文献２を参照。）。また、同様の手法はＯｐｅｎＳｔａｃｋのＣｏｎｇｒｅｓｓにおいても適用されている（例えば、非特許文献３を参照。）。ＣｏｎｇｒｅｓｓではＯｐｅｎＳｔａｃｋ内の複数の機能コンポーネントの設定要素を収集し、それがＤａｔａｌｏｇで記載されたポリシーに従っているか否かを検証している。
しかし、これらの手法はネットワーク全体あるいはＯｐｅｎＳｔａｃｋ全体に対する手法であり、単一の機器に対して適用できず、また検証対象は設定情報のみに限られている。つまり、非特許文献２や３の技術には、個々の機器やモジュールについて設定内容を検証することができないという第２の課題があった。

【0006】

ネットワーク機器の監視において、様々な統計情報を集め、ある統計情報が閾値を超えた場合にトラフィック制御をかけるなどの制御を行っている。しかし、複数の機能モジュールで構成される機器の場合、それぞれの機能モジュールからの統計情報の異常には対応できるが、複数の機能モジュールが関連する統計情報の異常については検出することが難しい。また他の機器の統計情報も異常検知する値として重要であるが、現在のところ他の機器の統計情報も異常検知する機能は存在していない。つまり、現在の技術では、複数の機能モジュールが関連する統計情報や他の機器の統計情報に基づいて異常検知ができないという第３の課題があった。

【0007】

上述した第１から第３の課題で説明したように、現在の技術では、各機能モジュールを開発する際、各機能モジュールにおける依存関係や統計情報を加味した設定検証や統計情報からの異常検知を行うことができない。特に設定検証のポリシーの変更や異常検知の条件変更については関連する複数のモジュールに手を加える必要があり、実現が困難である。そこで、本発明は、上記課題を解決し、機能モジュールを開発する際、各機能モジュールにおける依存関係や統計情報を加味した設定検証や統計情報からの異常検知を行うことができ、且つ設定検証のポリシーの変更や異常検知の条件変更にも対応できるネットワーク機器及びネットワーク機器の設定方法を提供することを目的とする。

【課題を解決するための手段】

【0008】

上記目的を達成するために、本発明に係るネットワーク機器は、各モジュールの既存設定、外部情報、依存関係及びポリシーを共通言語（例えば、Ｄａｔａｌｏｇ）で１箇所（設定検証部）にまとめておき、新規にモジュールに対して設定を行うとき、新たな依存関係を設定するとき、あるいは、外部情報を新たに取得したとき、当該新規設定を設定検証部へ送り、既存設定、外部情報及び依存関係と照らし合わし、当該新規設定がポリシーの正常範囲内に収まる場合に当該新規設定をモジュールに設定することとした。

【0009】

具体的には、本発明に係るネットワーク機器は、複数のプロトコルのそれぞれを処理するための複数の機能モジュールを備えるネットワーク機器であって、
前記機能モジュールに登録されている既存設定及び前記機能モジュールに新たに登録される新規設定を共通言語で管理する設定管理部と、
前記機能モジュールに関連するモジュール関連状態の統計情報を取得し、前記共通言語で管理する統計情報管理部と、
前記機能モジュール間の依存関係及びネットワークのポリシーを前記共通言語で管理しており、前記新規設定に対して、前記依存関係、前記既存設定及び前記統計情報との関係において前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にあるときに、前記新規設定を前記機能モジュールに投入する設定検証部と、
を備えることを特徴とする。

【0010】

また、本発明に係るネットワーク機器の設定方法は、複数のプロトコルのそれぞれを処理するための複数の機能モジュールを備えるネットワーク機器の設定方法であって、
前記機能モジュールに登録されている既存設定及び前記機能モジュールに新たに登録される新規設定を共通言語で管理する設定管理手順と、
前記機能モジュールに関連するモジュール関連状態の統計情報を取得し、前記共通言語で管理する統計情報管理手順と、
前記機能モジュール間の依存関係及びネットワークのポリシーを前記共通言語で管理しており、前記新規設定に対して、前記依存関係、前記既存設定及び前記統計情報との関係において前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にあるときに、前記新規設定を前記機能モジュールに投入する設定検証手順と、
を行うことを特徴とする。

【0011】

本ネットワーク機器は、各機能モジュールの設定情報を代表して管理する「設定管理部」（従来のＯｐｅｎｃｏｎｆｉｇｄに相当するもの）、各機能モジュールの統計情報および自ネットワーク機器の各種統計情報を取得する「統計情報管理部」、並びに入力された依存関係に基づいて各機能モジュールの設定妥当性を検証し、かつ異常を検知して通知する「設定検証部」を備えている。そして、設定検証部が、設定管理部から取得した各機能モジュールの設定情報と、統計情報管理部から取得した統計情報を用いて、各機能モジュールの設定が妥当か否かを判断する。このように、本ネットワーク機器は、個々の機能モジュールの設定について他の機能モジュールとの関連性や統計情報を考慮して妥当か否かを判定できる。

【0012】

従って、本発明は、機能モジュールを開発する際、各機能モジュールにおける依存関係や統計情報を加味した設定検証や統計情報からの異常検知を行うことができ、且つ設定検証のポリシーの変更や異常検知の条件変更にも対応できるネットワーク機器及びネットワーク機器の設定方法を提供することができる。

【0013】

本発明に係るネットワーク機器の前記設定検証部は、前記依存関係が新たに登録されたとき、新たに登録された前記依存関係の下、前記既存設定及び前記統計情報が前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にないときに前記既存設定又は前記統計情報が異常であることを報知することを特徴とする。
本ネットワーク機器は、機能モジュール間の依存関係の変更にも対応することができる。

【0014】

本発明に係るネットワーク機器の前記設定検証部は、前記ポリシーが新たに登録されたとき、前記依存関係の下、前記既存設定及び前記統計情報が新たに登録された前記ポリシーの正常な範囲にあることを確認する検証作業を行い、新たに登録された前記ポリシーの正常な範囲にないときに前記既存設定又は前記統計情報が異常であることを報知することを特徴とする。
本ネットワーク機器は、ネットワークポリシーの変更にも対応することができる。

【0015】

本発明に係るネットワーク機器の前記設定検証部は、前記統計情報管理部から前記モジュール関連状態の変化を検知したことの通知を受けたとき、前記設定管理部に前記機能モジュールに登録されている既存設定を取得させ、前記依存関係の下、前記既存設定及び変化した前記統計情報が前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にないときに前記モジュール関連状態が異常であることを報知することを特徴とする。
本ネットワーク機器は、機能モジュール間の依存関係や統計情報に基づいて異常検知を行うことができる。

【発明の効果】

【0016】

本発明に係るネットワーク機器は、このような構成により、機能モジュールの依存関係や統計情報を考慮した設定妥当性検証や異常検知を行うことができる。また、本発明に係るネットワーク機器は、各機能モジュール間の依存関係や、設定妥当性検証／異常検知を行うためのルールを容易に変更することができ、柔軟な運用が可能となる。

【0017】

以上のように、本発明は、機能モジュールを開発する際、各機能モジュールにおける依存関係や統計情報を加味した設定検証や統計情報からの異常検知を行うことができ、且つ設定検証のポリシーの変更や異常検知の条件変更にも対応できるネットワーク機器及びネットワーク機器の設定方法を提供することができる。

【図面の簡単な説明】

【0018】

【図1】本発明に係るネットワーク機器を説明するブロック図である。

【図2】本発明に係るネットワーク機器の動作を説明するシーケンス図である。

【図3】本発明に係るネットワーク機器の動作を説明するシーケンス図である。

【図4】本発明に係るネットワーク機器の動作を説明するシーケンス図である。

【図5】本発明に係るネットワーク機器の動作を説明するシーケンス図である。

【図6】本発明に係るネットワーク機器を説明するブロック図である。

【図7】本発明に係るネットワーク機器を説明するブロック図である。

【図8】機能モジュールへ投入する設定の例を説明する図である。

【図9】機能モジュールへ投入する設定の例を説明する図である。

【図10】機能モジュールへ投入する設定の例を説明する図である。

【発明を実施するための形態】

【0019】

添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

【0020】

［定義］
・機能モジュール：
ネットワーク機器は、様々なプロトコルを処理するためモジュラ構成を取ることが多い。機能モジュールはその様々なプロトコルの処理を担当する部分を指す。物理的な回路の場合もあるし、仮想的に形成される場合もある。モジュールの例としては、ＤＨＣＰを処理するモジュール、ＢＧＰを処理するモジュールなどが挙げられる。
・Ｄａｔａｌｏｇ：
Ｐｒｏｌｏｇ等と同じく、一階述語論理に基づいた宣言型の論理プログラミング言語である。ＤａｔａｂａｓｅのＳＱＬのようなＱｕｅｒｙ Ｌａｎｇｕａｇｅとしても使われている。Ｐｒｏｌｏｇとほぼ同じだが、停止性などを保証するためにいくつかの機能に制限がある。
・トラップ：
異常検知と同義である。観測している箇所で異常が発生した（設定値を超えた、下回った、あるいは異常なパケットが流れた）場合にそれを通知するような仕組みである。
・ロールバック：
設定変更に失敗したときに、設定を変更しようとした直前の状態にまで戻すことである。
・機能モジュールの統計情報：
各機能モジュールで処理した数や遅延、接続状況、ＳＮＭＰ等各種プロトコルで取得されるカウンタなどがある。例えば、Ｅｔｈｅｒｎｅｔ（登録商標）のＬｉｎｋ ＵＰ／Ｄｏｗｎの状況、特定装置・通信経路のスループット・遅延、設定の最終更新日時、ｋｅｅｐ ａｌｉｖｅの状況、遅延、ＩＰのルーティングテーブルやＡＲＰテーブル等のエントリ数と各エントリでのカウンタ、エントリの生存時間、ＢＧＰなどのｎｅｉｇｈｂｏｒ情報などがある。

【0021】

［ネットワーク機器の構成］
図１は、本実施形態のネットワーク機器を説明するブロック図である。本ネットワーク機器は、複数のプロトコルのそれぞれを処理するための複数の機能モジュール１５を備えるネットワーク機器であって、
機能モジュール１５に登録されている既存設定及び機能モジュール１５に新たに登録される新規設定を共通言語で管理する設定管理部１２と、
機能モジュール１５に関連するモジュール関連状態の統計情報を取得し、前記共通言語で管理する統計情報管理部１３と、
機能モジュール１５間の依存関係及びネットワークのポリシーを前記共通言語で管理しており、前記新規設定に対して、前記依存関係、前記既存設定及び前記統計情報との関係において前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にあるときに、前記新規設定を機能モジュール１５に投入する設定検証部１４と、
を備える。

【0022】

本ネットワーク機器は、他にも、オペレータが各機能モジュール１５へ新たな設定を入力するための設定入力部１１、オペレータが本ネットワーク機器へ新たな依存関係やポリシーを入力するための依存関係入力部１７、後述する外部情報取得部１６、並びに設定異常通知部１８を備える。

【0023】

また、設定検証部１４は、設定検証管理部１４ａと検証部１４ｂを有している。設定検証管理部１４ａは、設定情報、依存関係、統計情報を受け取り、検証部１４ｂへ入力したり、検証結果を各部へ通知する。検証部１４ｂは、実際に共通言語（Ｄａｔａｌｏｇなど）で検証を行い、設定情報、統計情報、外部情報あるいはポリシーが正しいか否かを検証する。

【0024】

本ネットワーク機器は、複数の異なる機能モジュール１５の依存関係や統計情報を加味した設定検証や異常検知を行うために、図１（ａ）のように設定管理部１２と統計情報管理部１３を備える。図１（ｂ）のように、設定は各機能モージュール１５に直接投入され、設定管理部１２及び統計情報管理部１３が各機能モジュール１５からそれぞれ設定情報及び統計情報を収集する構成であってもよい。

【0025】

統計情報として、各機能モジュール１５の統計情報だけでなく、外部情報取得部１６から以下のようなデータを収集しても良い。
例１）ネットワーク機器のマシンの統計情報（ＯＳなどから取得する統計情報など。認証情報、ＣＰＵ使用率、メモリ使用率、ディスクＩ／Ｏの速度、ネットワーク帯域の使用量、各種エラーなど）
例２）ネットワーク機器が仮想マシンであった場合、ホストマシンの統計情報（ＯＳなどから取得する統計情報。他に動作している仮想マシン・コンテナの数・使用容量など、ＣＰＵ使用率、メモリ使用率、メモリエラー、ディスクＩ／Ｏの速度、ディスクのエラー、ネットワーク使用量など）
例３）ネットワーク機器が動作する物理マシンの統計情報（温度、湿度、消費電力など）

【0026】

［設定の投入と検証］
図２は、機能モジュール１５への設定投入時のシーケンスを説明する図である。図２（ａ）は図１（ａ）のネットワーク機器のシーケンス図であり、図２（ｂ）は図１（ｂ）のネットワーク機器のシーケンス図である。
各機能モジュール１５への設定の入力は設定入力部１１から入力される。図１（ａ）のネットワーク機器の場合、入力された設定は設定管理部１２で管理される。図１（ｂ）のネットワーク機器の場合、入力された設定は各機能モジュール１５に入力され、その後各機能モジュール１５から設定管理部１２へ当該設定が通知される。設定管理部１２に入力された設定は設定検証部１４に送られる。設定検証部１４は、統計情報管理部１６から統計情報を受け取り、当該統計情報を加味し、依存関係による当該設定の異常やポリシー違反などの設定検証を行う（設定検証については後述する。）。その結果が設定異常通知部１８と設定管理部１２に返される。設定異常通知部１８は、設定異常の通知や他のシステムと連携し、システムの停止や設定のロールバック等を行う。設定管理部１２は、設定の異常が判明すると設定の投入を行わない。ここで、設定管理部１２は、機能モジュール１５に設定が投入がされないことをオペレータに伝えてもよい。

【0027】

例えば、図１（ａ）のような構成で、ＯｐｅｎＣｏｎｆｉｇｄのような事前に設定検証を行う設定管理部１２を持つシステムに対しては、必要な時に設定検証部１４を接続することができる。

【0028】

また、複数の機能モジュールで構成され、それらへの設定作業を設定管理部がコントロールするシステムの場合、設定の検証を行う際、設定管理部が関係あるすべての機能モジュールに対して設定内容を検証させる機能を有する場合がある。そして、当該設定管理部は、一つでもエラーを返す機能モジュールがあれば、その投入しようとした設定は誤りでありバリデーションエラーと判定する。

【0029】

本ネットワーク機器では、このような機能も利用できる。つまり、本ネットワーク機器は、いずれか一つでもエラーがあれば、設定管理部がエラーと判断することを利用し、各機能モジュール単体については各機能モジュール１５自身で検証させ、依存関係や運用ポリシー、及び統計情報に関わる設定検証については設定検証部１４で検証させる。このような検証を行うときのシーケンスを図３に示す。

【0030】

また、本ネットワーク機器は、設定の検証作業や異常検知のルール（依存関係やポリシー）を任意に変更や追加することができる。新しくルールが追加された際には、その時の各機能モジュールの設定や統計情報が新ルールの下で正常か否かを判断してもよい。

【0031】

具体的には、設定検証部１４は、前記依存関係が新たに登録されたとき、新たに登録された前記依存関係の下、前記既存設定及び前記統計情報が前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にないときに前記既存設定又は前記統計情報が異常であることを報知することを特徴とする。
また、設定検証部１４は、前記ポリシーが新たに登録されたとき、前記依存関係の下、前記既存設定及び前記統計情報が新たに登録された前記ポリシーの正常な範囲にあることを確認する検証作業を行い、新たに登録された前記ポリシーの正常な範囲にないときに前記既存設定又は前記統計情報が異常であることを報知することを特徴とする。

【0032】

図４は、新ルールが投入された時のシーケンス図である。依存関係入力部１７から設定検証部１４に投入される依存関係やポリシーはＤａｔａｌｏｇのような容易に拡張可能である言語で記述することが望ましい。ＯｐｅｎＳｔａｃｋのＣｏｎｇｒｅｓｓやＦｕｎｇらの取り組みではＤａｔａｌｏｇという言語で依存関係やポリシーを記述することで設定エラーやポリシー違反を検索する仕組みを言語処理系の機構に任せることができ、設定ルールの記述が容易になる。つまり、設定検証部１４は、統計情報、依存関係、ポリシー、入力された設定が共通言語で記載されているので、当該設定の異常やポリシー違反などの検証作業をＤａｔａｌｏｇ等の言語処理系が有する検証機能に実行させる。

【0033】

例えば依存関係やポリシーをＤａｔａｌｏｇで記載した場合、設定検証管理部１４ａで依存関係としてＤａｔａｌｏｇのプログラムを受け取り、検証部１４ｂに送る。設定管理部１２から設定が入力された際、検証部１４ｂは当該設定に対してＤａｔａｌｏｇのプログラムを実行し、エラーの状態（ポリシーの正常範囲にない）になっていないかを確認する。

【0034】

［異常検知］
本ネットワーク機器は、複数の機能モジュール１５の依存関係や統計情報を加味した異常検知を行うことができる。設定検証部１４は、統計情報管理部１３から前記モジュール関連状態の変化を検知したことの通知を受けたとき、設定管理部１２に前記機能モジュールに登録されている既存設定を取得させ、前記依存関係の下、前記既存設定及び変化した前記統計情報が前記ポリシーの正常な範囲にあることを確認する検証作業を行い、前記ポリシーの正常な範囲にないときに前記モジュール関連状態が異常であることを報知することを特徴とする。図５は、本ネットワーク機器が行う異常検知のシーケンス図である。

【0035】

統計情報管理部１３は、各機能モジュール１５や外部情報取得部１６から統計情報を取得し、その情報が変化をしたら、もしくは定期的に統計情報を取得して設定検証部１４へ統計情報を送信する。設定検証部１４は、設定管理部１２から現在の各機能モジュールの設定を取得し、依存関係を考慮して統計情報がポリシーの正常な範囲内にあるか否かの正常性検証を行う。設定検証部１４は、統計情報がポリシーの正常な範囲内にない場合を異常とし、異常を検知した場合には設定異常通知部１８にて異常をオペレータへ通知する。異常を検知したときには、設定検証部１４は、別システムとの連携や、設定の修正、ロールバックなどを行ってもよい。なお、外部情報取得部１６からの統計情報とは、前述した例１から例３のデータである。

【0036】

（実施例１）
図６は、ネットワーク機器の具体例を説明する図である。本ネットワーク機器は複数のプロトコルを処理するために機能モジュール構成（機能モジュール群１５）となっている。機能モジュール群１５の各モジュールは、例えば、パケット入出力部１５ａ、パケット処理部１５ｂ、及びネットワーク機能部１５ｃである。パケット処理部１５ｂは複数のモジュールで連携することもある。これらの機能モジュール群１５への設定は、設定管理部１２からネットワーク機能部１５ｃに対し設定の管理を行う。パケット入出力部１５ａとパケット処理部１５ｂへの設定はネットワーク機能部１５ｃを介してなされる。

【0037】

統計情報管理部１３は、機能モジュール群１５の各モジュール（パケット入出力部１５ａ、パケット処理部１５ｂ、及びネットワーク機能部１５ｃ）の統計情報を収集する。また、統計情報管理部１３は、外部情報取得部１６からも上記例１から例３のデータを統計情報として取得する。さらに、統計情報管理部１３は、外部情報取得部１６から次のデータを統計情報として取得してもよい。
例４）ネットワーク機器が動作する物理マシン周辺の統計情報（位置情報、天気、電源やネットワークなど周辺設備など）

【0038】

例えば、本ネットワーク機器は、位置情報を用いるとその機器を指定の場所からどこかに移動させた時、それを異常として検知することができる。共通言語はＤａｔａｌｏｇとする。また、ネットワーク機器がルータであるとする。
まず、設定検証部１４にポリシーとして下記のようなルールを記述する。ただし、書式はｄａｔａｌｏｇ２．２に従う（例えば、非特許文献４を参照。）。
ｅｒｒｏｒ（Ｘ） ：− ｎｏｔ＿ｐｌａｃｅ（Ｘ、 ｃｅｎｔｒａｌ＿ｏｆｆｉｃｅ）、 ｒｏｕｔｅｒ＿ｎａｍｅ（Ｘ）．

【0039】

検証するルータの名前をｒと設定するとき、設定管理部１４からＤａｔａｌｏｇを扱う設定検証管理部１４ａに以下のようなＦａｃｔが入る。
ｒｏｕｔｅｒ＿ｎａｍｅ（ｒ）

【0040】

外部情報取得部１６は公知の技術を用いてルータｒの位置情報を取得する。統計情報管理部１３は、ルータｒが指定の場所（ｃｅｎｔｒａｌ＿ｏｆｆｉｃｅ）にないことの位置情報を検知している間のみ、下記のようなＦａｃｔを設定検証管理部１４ａに投入する。
ｎｏｔ＿ｐｌａｃｅ（ｒ、 ｃｅｎｔｒａｌ＿ｏｆｆｉｃｅ）

【0041】

これにより、ルータｒがＣｅｎｔｒａｌＯｆｆｉｃｅに無いとき、
ｎｏｔ＿ｐｌａｃｅ（ｒ、 ｃｅｎｔｒａｌ＿ｏｆｆｉｃｅ）
が真であるため、検証部１４ｂが下記のクエリを投入するとｅｒｒｏｒ（ｒ）が異常として検出できる。
ｅｒｒｏｒ（Ｘ）？
なお、「クエリを投入」とは、設定検証管理部１４ａが設定、統計情報、またはポリシーに変更があったことを把握したときに、検証部１４ｂが当該クエリを実行することである。

【0042】

また、「ルータｒがインターネットとパケットの送受信ができる」という設定が投入された時、下記のｆａｃｔが設定検証管理部１４ａに投入される。
ｉｎｔｅｒｎｅｔ＿ａｃｃｅｓｓ（ｒ）．

【0043】

さらに、依存関係入力部１７に依存関係として、「ｃｅｎｔｒａｌ＿ｏｆｆｉｃｅにないルータｒがインターネットにアクセス可能な状態を違反」とするポリシーを依存関係入力部１７から設定検証部１４に投入する。検証部１４ｂは、次のようなルールによって、異常を検知することができる。
ｅｒｒｏｒ（Ｘ） ：− ｎｏｔ＿ｐｌａｃｅ（Ｘ、 ｃｅｎｔｒａｌ＿ｏｆｆｉｃｅ）、 ｉｎｔｅｒｎｅｔ＿ａｃｃｅｓｓ（Ｘ）．

【0044】

他にも、ｎｏｔ＿ｐｌａｃｅの代わりにｃｐｕ＿ｕｓａｇｅ＿ｏｖｅｒ６０やｍｅｍｏｒｙ＿ｕｓａｇｅ＿８０など、ＣＰＵの使用率やメモリの使用率によって統計情報管理部１３が特定のＦａｃｔを発生させ、任意のポリシーに当たるｄａｔａｌｏｇのルールを依存関係入力部１７から設定検証部１４に投入することによって異常を検出できる。
同様に、特定のＦａｃｔがあるときに、特定の設定（ＤＨＣＰやＢＧＰなどを有効にするなど）でポリシー違反として取り扱うことができる。

【0045】

（実施例２）
図７は、他の実施形態の具体例を説明する図である。設定管理部１２や設定検証部１４がネットワーク機器の外部にあってもよい。このような場合、ネットワーク機器にはネットワーク処理部１５ｂやネットワーク機能部１５ｃの他に設定・統計送信部１５ｄが備わる。設定は設定・統計送信部１５ｄを介して各モジュールに設定され、各モジュールの統計情報は設定・統計送信部１５ｄを介して統計情報管理部１３に送信される。本実施例においても、実施例１で説明したように検証作業がなされる。

【0046】

（実施例３）
設定管理部１２から各機能モジュール１５に設定される設定情報の例を説明する。設定情報は、ネットワーク機器やその他サーバなどの機器に対する動作設定である。例えば、設定情報は、グループポリシー（ＧＢＰ；Ｇｒｏｕｐ Ｂａｓｅｄ Ｐｏｌｉｃｙ）、ＤＨＣＰ（Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）、ＯＳＰＦ（Ｏｐｅｎ Ｓｈｏｒｔｅｓｔ Ｐａｔｈ Ｆｉｒｓｔ）、あるいはＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）といったネットワークプロトコルの各種パラメタとインターフェースやパケットの転送を行うネットワークインスタンスの各種パラメタである。

【0047】

依存関係は、ある機能モジュールの機能を実行するためには、他の機能モジュールである設定をしなければならない関係や、ある機能モジュールと別の機能モジュールを同時に実行できない関係、利用する機能モジュールの実装状況、機能のアクティベーション状況などである。例えば、ＩｎｔｅｒｆａｃｅにＶＬＡＮの設定をしなければ、ＶＬＡＮを識別したパケット転送を担う機能モジュールは正しく動作できない。またＯＳＰＦとＲＩＰ（Ｒｏｕｔｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）などは同時に実行するべきではない。

【0048】

ポリシーは、ある機器、あるインターフェースからインターネットに抜けるべきではない、本社・支社間の通信はＶＰＮで通信する、ある組織のあるネットワークには別の組織から通信できないようにするなど、ネットワーク運用上のポリシーである。本発明ではポリシー違反かどうかをＤａｔａｌｏｇなどで記述する。

【0049】

図８はＬａｇｏｐｕｓ Ｒｏｕｔｅｒの設定の例である。１段落目がインターフェースｉｆ０についての設定、２段落目がインターフェースｉｆ１についての設定、３段落目がネットワークインスタンスｖｒｆ１についての設定である。

【0050】

ここで、設定の不整合がある場合を説明する。例えば、図９のような設定が投入されるとする。図９は、図８の設定の２段落目（ｉｆ１）が記載されていない設定例である。図９のようにｉｆ１にＩｎｔｅｒｆａｃｅを宣言していないにもかかわらず、Ｎｅｔｗｏｒｋ−ｉｎｓｔａｎｃｅにＩｎｔｅｒｆａｃｅをつける（太字下線で示す）ような設定を機能モジュールに投入しようとすると、設定検証部１４は、検証作業において作成されていないＩｎｔｅｒｆａｃｅがＮｅｔｗｏｒｋ−ｉｎｓｔａｎｃｅに設定されることを把握し、設定異常として設定異常通知部１８に通知する。また、設定検証部１４は、モジュールにおいて機能を実現するための設定が揃っていない場合なども設定異常として設定異常通知部１８に通知する。

【0051】

（実施例４）
設定管理部１２から各機能モジュール１５に設定される設定情報が依存関係と照らし合わせて異常と判断される例を図１０で説明する。本例では「機器の種類（ｔｙｐｅ）により設定の可否がある」という依存関係を用いている。
図１０もＬａｇｏｐｕｓ Ｒｏｕｔｅｒの設定の例である。図１０の設定の３段落目で「ｓｅｔ ｎｅｔｗｏｒｋ−ｉｎｓｔａｎｃｅｓ ｎｅｔｗｏｒｋ−ｉｎｓｔａｎｃｅ ｖｒｆ１ ｃｏｎｆｉｇ ｔｙｐｅ Ｌ３ＶＲＦ」とｔｙｐｅにＬ３ＶＲＦを設定している。Ｌ３ＶＲＦのｔｙｐｅはネットワークインスタンスでＶＬＡＮ設定ができないという依存関係がある。しかし、当該段落の４行目に「ｓｅｔ ｎｅｔｗｏｒｋ−ｉｎｓｔａｎｃｅｓ ｎｅｔｗｏｒｋ−ｉｎｓｔａｎｃｅ ｖｒｆ１ ｖｌａｎｓ ｖｌａｎ １００ ｃｏｎｆｉｇ ｓｔａｔｕｓ ＡＣＴＩＶＥ」というこのｔｙｐｅのネットワークインスタンスでは処理できないＶＬＡＮの設定が入ってしまっている。

【0052】

図１０のようにネットワークインスタンスのｔｙｐｅにあわない設定（依存関係として認められない設定）を機能モジュールに投入しようとすると、設定検証部１４は、検証作業においてｔｙｐｅにあわない機能がネットワークインスタンスに設定されることを把握し、設定異常（設定の依存関係の誤り）として設定異常通知部１８に通知する。また、設定検証部１４は、設定に関わる機能モジュールにＢＧＰやＯＳＰＦなど設定される機能が実装されていない、料金プランなどでアクティベーションされていない、設定を行うオペレータに権限がないなども依存関係として保持し、これに認められない設定を異常として設定異常部１８に通知する。

【0053】

（本発明によって生ずる効果）
本発明に係るネットワーク機器は、投入する設定内容だけでなく、機能モジュール間の依存関係や統計情報、及び外部環境を考慮した、設定の妥当性を検証することができる。
本発明に係るネットワーク機器は、Ｄａｔａｌｏｇなど簡易な言語を利用することでポリシー記述が容易である。
本発明に係るネットワーク機器は、動的にポリシーを追加することができる。

【0054】

（発明のポイント）
本発明は、複数の異なる機能モジュールの依存関係や統計情報を加味した設定検証と異常検知を行うために、設定管理部と統計情報管理部を備えたことを特徴とする。複数の異なる機能モジュールの依存関係や統計情報を加味した設定検証や異常検知のルール（ポリシー）を容易に、動的に追加することが可能である。このため、本発明の手法を用いれば、新しいモジュール開発の手間を削減することができる。なお、統計情報は各機能モジュールの統計情報だけでなく、外部情報取得部から周囲環境の情報を考慮して、設定検証や異常検知を行うことで、設定ミスだけでなくセキュリティの向上や機器の異常防止につながる。さらに、認証情報や位置情報を付与することで、致命的な設定の排除を可能とし、温度や湿度を取得することで過負荷などに対処することもできる。

【産業上の利用可能性】

【0055】

本発明に係るネットワーク機器は、上述した検証作業に、機械学習やディープラーニングのような技術を適用してもよい。

【符号の説明】

【0056】

１１：設定入力部
１２：設定管理部
１３：統計情報管理部
１４：設定検証部
１４ａ：設定検証管理部
１４ｂ：検証部
１５：機能モジュール、機能モジュール群
１５ａ：パケット入出力部
１５ｂ：パケット処理部
１５ｃ：ネットワーク機能部
１５ｄ：設定・統計送受信部
１６：外部情報取得部
１７：依存関係入力部
１８：設定異常通知部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】