(57)【特許請求の範囲】
【請求項１】
コンピュータにより実装される方法において、
ネットワークにおける複数のネットワークデバイスからの状態情報を受信することと、
構文解析されたネットワーク情報を作成するために、ネットワークデバイス特定の複数のパーサによって、前記ネットワーク情報を構文解析することと、
前記構文解析されたネットワーク情報に基づいて、ネットワークモデルを生成することと、ここにおいて、前記ネットワークモデルは、前記ネットワークによってデータがどのように処理されるかを記述する一連の転送テーブルに少なくとも部分的に基づき、
前記ネットワークモデルを通して押し出されたシンボリックパケットに少なくとも部分的に基づいて、１つ以上のフローパスを計算することと、ここにおいて、前記シンボリックパケットは、１つ以上のワイルドカードビットを含み、パケットまたはパケットのクラスが前記ネットワークを通して移動する場合に、前記パケットまたはパケットの前記クラスを特定し、
を備え、
前記１つ以上のフローパスに沿った前記パケットまたはパケットの前記クラスへの変更が、前記ネットワークモデルを通して前記シンボリックパケットを押し出すことによって計算される、
方法。
【請求項２】
前記状態情報は、前記複数のネットワークデバイスから受信される、転送状態および／またはコンフィギュレーションファイル、および、データのルーティングを決定するために使用されるインターネットプロトコル（ＩＰ）テーブルおよび／または転送ルール、のうちの１つ以上を含む、請求項１に記載の方法。
【請求項３】
前記状態情報は、ユーザから受信されたネットワークトポロジーデータをさらに含む、請求項１に記載の方法。
【請求項４】
前記１つ以上のフローパスの特性がユーザの期待に合っているか否かをチェックすることをさらに備える、請求項１に記載の方法。
【請求項５】
前記１つ以上のフローパスを、データ記憶装置中に記憶することと、
前記複数のパーサのうちの少なくとも１つを使用して、前記ネットワークにおける少なくとも１つのネットワークデバイスに関連付けられている前記状態情報に対する変化を検出することと、
前記変化に基づいて、前記１つ以上のフローパスを更新することと、
前記更新された１つ以上のフローパスを、前記データ記憶装置中に記憶することと、
をさらに備える、請求項１に記載の方法。
【請求項６】
前記１つ以上のフローパスを、データ記憶装置の中に記憶することと、
少なくとも１つのネットワーク特性についての基準に基づいて、前記データ記憶装置に問い合わせることと、
問い合わせられた前記基準に合う、前記データ記憶装置からの前記１つ以上のフローパスのサブセットを受信することと、
前記１つ以上のフローパスの前記サブセットを、前記少なくとも１つのネットワーク特性に関連付けられている少なくとも１つのポリシーに従って解析することと、
をさらに備える、
請求項１に記載の方法。
【請求項７】
前記１つ以上のフローパスの前記サブセットの前記少なくとも１つのポリシーとの比較に基づいて、報告を生成することをさらに備え、
前記報告は、１つ以上の提案されたネットワークコンフィギュレーション変更を含む、
請求項６に記載の方法。
【請求項８】
少なくとも１つのネットワーク特性の、１つ以上の違反を特定するために、前記１つ以上のフローパスを解析することをさらに備え、
前記少なくとも１つのネットワーク特性の前記１つ以上の違反は、前記ネットワークの状態情報が前記少なくとも１つのネットワーク特性について１つ以上の予め定められた状態に合わない場合に示される、
請求項１に記載の方法。
【請求項９】
前記１つ以上の特定された違反に関連付けられているネットワークデバイスのコンフィギュレーションを特定する報告を生成することをさらに備える、請求項８に記載の方法。
【請求項１０】
システムにおいて、
１つ以上のプロセッサと、
命令を含む１つ以上のメモリデバイスと、
を備え、
前記命令は、前記１つ以上のプロセッサによって実行されたとき、前記システムに、
ネットワークにおける複数のネットワークデバイスからの状態情報を受信させ、
構文解析されたネットワーク情報を作成するために、ネットワークデバイス特定の複数のパーサによって、前記ネットワーク情報を構文解析させ、
前記構文解析されたネットワーク情報に基づいて、ネットワークモデルを生成させ、ここにおいて、前記ネットワークモデルは、前記ネットワークによってデータがどのように処理されるかを記述する一連の転送テーブルに少なくとも部分的に基づき、
前記ネットワークモデルを通して押し出されるシンボリックパケットに少なくとも部分的に基づいて、前記ネットワークモデルを使用して、１つ以上のフローパスを計算させ、ここにおいて、前記シンボリックパケットは、１つ以上のワイルドカードビットを含み、パケットまたはパケットのクラスが前記ネットワークを通して移動する場合に、前記パケットまたはパケットの前記クラスを特定し、前記１つ以上のフローパスに沿った前記パケットまたはパケットの前記クラスへの変更が、前記ネットワークモデルを通して前記シンボリックパケットを押し出すことによって計算される、
システム。
【請求項１１】
前記状態情報は、前記複数のネットワークデバイスから受信される、転送状態および／またはコンフィギュレーションファイル、および、データのルーティングを決定するために使用されるインターネットプロトコル（ＩＰ）テーブルおよび／または転送ルール、のうちの１つ以上を含む、請求項１０に記載のシステム。
【請求項１２】
前記状態情報は、ユーザから受信されたネットワークトポロジーデータをさらに含む、請求項１０に記載のシステム。
【請求項１３】
前記１つ以上のフローパスを、データ記憶装置中に記憶することと、
前記複数のパーサのうちの少なくとも１つを使用して、前記ネットワークにおける少なくとも１つのネットワークデバイスに関連付けられている前記状態情報に対する変化を検出することと、
前記変化に基づいて、前記１つ以上のフローパスを更新することと、
前記更新された１つ以上のフローパスを、前記データ記憶装置中に記憶することと、
をさらに備える、請求項１０に記載のシステム。
【請求項１４】
前記１つ以上のフローパスを、データ記憶装置の中に記憶することと、
少なくとも１つのネットワーク特性についての基準に基づいて、前記データ記憶装置に問い合わせることと、
問い合わせられた前記基準に合う、前記データ記憶装置からの前記１つ以上のフローパスのサブセットを受信することと、
前記１つ以上のフローパスのサブセットを、少なくとも１つのネットワーク特性に関連付けられている少なくとも１つのポリシーに従って解析することと、
をさらに備える、請求項１０に記載のシステム。
【請求項１５】
前記１つ以上のフローパスのサブセットの前記少なくとも１つのポリシーとの比較に基づいて、報告を生成することをさらに備え、
前記報告は、１つ以上の提案されたネットワークコンフィギュレーション変更を含む、
請求項１４に記載のシステム。
【請求項１６】
命令を含む一時的でないコンピュータ読み取り可能な記憶媒体において、
前記命令は、１つ以上のプロセッサによって実行されたとき、システムに、
ネットワークにおける複数のネットワークデバイスからの状態情報を受信させ、
構文解析されたネットワーク情報を作成するために、ネットワークデバイス特定の複数のパーサによって、前記ネットワーク情報を構文解析させ、
前記構文解析されたネットワーク情報に基づいて、ネットワークモデルを生成させ、ここにおいて、前記ネットワークモデルは、前記ネットワークによってデータがどのように処理されるかを記述する一連の転送テーブルに少なくとも部分的に基づき、
前記ネットワークモデルを通して押し出されるシンボリックパケットに少なくとも部分的に基づいて、前記ネットワークモデルを使用して、１つ以上のフローパスを計算させ、ここにおいて、前記シンボリックパケットは、１つ以上のワイルドカードビットを含み、パケットまたはパケットのクラスが前記ネットワークを通して移動する場合、前記パケットまたはパケットの前記クラスを特定し、前記１つ以上のフローパスに沿った前記パケットまたはパケットの前記クラスへの変更が、前記ネットワークモデルを通して前記シンボリックパケットを押し出すことによって計算される、
一時的でないコンピュータ読み取り可能な記憶媒体。
【請求項１７】
前記状態情報は、
前記複数のネットワークデバイスから受信される、転送状態および／またはコンフィギュレーションファイル、および、データのルーティングを決定するために使用されるインターネットプロトコル（ＩＰ）テーブルおよび／または転送ルール、のうちの１つ以上と、
ユーザから受信されたネットワークトポロジーデータと、
を含む、
請求項１６に記載の一時的でないコンピュータ読み取り可能な記憶媒体。
【請求項１８】
前記１つ以上のフローパスを、データ記憶装置中に記憶することと、
前記複数のパーサのうちの少なくとも１つを使用して、前記ネットワークにおける少なくとも１つのネットワークデバイスに関連付けられている前記状態情報に対する変化を検出することと、
前記変化に基づいて、前記１つ以上のフローパスを更新することと、
前記更新された１つ以上のフローパスを、前記データ記憶装置中に記憶することと、
をさらに備える、請求項１７に記載の一時的でないコンピュータ読み取り可能な記憶媒体。
【請求項１９】
前記１つ以上のフローパスを、データ記憶装置の中に記憶することと、
少なくとも１つのネットワーク特性についての基準に基づいて、前記データ記憶装置に問い合わせることと、
問い合わせられた前記基準に合う、前記データ記憶装置からの前記１つ以上のフローパスのサブセットを受信することと、
前記１つ以上のフローパスの前記サブセットを、少なくとも１つのネットワーク特性に関連付けられている少なくとも１つのポリシーに従って解析することと、
をさらに備える、
請求項１７に記載の一時的でないコンピュータ読み取り可能な記憶媒体。
【請求項２０】
前記１つ以上のフローパスのサブセットの前記少なくとも１つのポリシーとの比較に基づいて、報告を生成することをさらに備え、
前記報告は、１つ以上の提案されたネットワークコンフィギュレーション変更を含む、
請求項１９に記載の一時的でないコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【関連出願への相互参照】
【０００１】
［０００１］  本願は、Ｄａｖｉｄ  Ｅｒｉｃｋｓｏｎらによる「ネットワーク管理のためのシステムおよび方法」と題された、２０１４年７月３０日に提出された米国仮出願番号６２／０３１、００９の優先権を主張し、すべての目的に対して、その全体が参照によってここに組み込まれる。
【背景技術】
【０００２】
［０００２］  ネットワークは、現代の情報技術システムのバックボーンとして、ますます複雑に成長している。典型的な大きな会社は、そのネットワークインフラストラクチャを形成するために、異なるベンダーからの数百または数千のデバイスおよびソフトウェアコンポーネントを用いるかもしれない。複雑性およびサイズにおける増大はまた、転送ループ、コンフィギュレーション誤り、到達可能性の課題、またはハードウェア故障の等の、より多くの障害となる点をもたらす。
【０００３】
［０００３］  ネットワーク障害を診断することは、いくつかの理由のために困難である。第１に、各ネットワークデバイスに関係付けられた転送状態は、ネットワーク全体を通して分散され、それらの対応する転送テーブルおよび他のコンフィギュレーションパラメータによって規定される。第２に、分散された転送状態は、デバイスに手動でログインして低レベルのテストを行うようにネットワーク管理者に要求することが多く、監視するのに困難である。第３に、複数の管理者またはユーザは、転送状態を同時に編集でき、結果として、矛盾した転送状態となる。
【０００４】
［０００４］  従来のネットワーク診断方法およびツールは、労働集約的であり、時間を消費するものであり、そして、しばしばプロトコル依存である。例えば、ネットワーク管理者は、ネットワーク障害を突きとめるために、初歩的なツール（例えば、ピング、トレースルート、および、単純なネットワーク管理プロトコル）を使用するかもしれない。このような方法は、ネットワーク状態スペースの小さな部分をカバーするだけである。診断プロセスは、増加しているネットワークサイズおよび複雑性の現在の傾向により、より困難にさえなる。
【０００５】
［０００５］  さらに、従来のネットワーク診断方法およびツールは、それらがネットワークにおける明らかな課題を解決するだけであるので、本質的にアドホックである。例えば、「ホストＡはホストＢと話すことができるか？」または「顧客Ｘは、会話を聞くことができるか？」等の単純な質問は、回答するのが困難である。したがって、従来のツールは、問題が生じる前に問題を見越すことができない、または、問題を防ぐことができない。
【０００６】
［０００６］  他方で、大きなソフトウェア会社は、配備より前にそれらのソフトウェア製品の挙動を包括的にテストする巨大な量のテストを有するので、新たなソフトウェア製品を迅速に、どんどん作り出すことができる。しかしながら、配備されたとき、特にネットワークに対して１日に何回か変更があるとき、ネットワークが働くだろうとの確信を与えるための十分なテスト能力を、現在のネットワーク管理およびテストは欠いている。
【０００７】
［０００７］  したがって、高速の、大規模な、自動化された、および系統的な方法で、ネットワークを管理して検証するための方法およびツールを開発する必要性がある。
【０００８】
［０００８］  発明のさまざまな実施形態または例が、以下の詳細な説明と付随する図面とにおいて開示される。
【図面の簡単な説明】
【０００９】
【図１】［０００９］  図１は、本発明の実施形態による、ネットワーク管理システムの高レベル図を示す。
【図２】［００１０］  図２は、本発明の実施形態による、ネットワーク管理システムの図を示す。
【図３】［００１１］  図３は、本発明の実施形態による、効力を失った転送ルールを特定する例を示す図である。
【図４】［００１２］  図４は、本発明の実施形態による、効力を失ったルールを調査する例を示す図である。
【図５】［００１３］  図５は、本発明の実施形態による、複数のデバイスに渡るネットワーク管理システムのアプリケーションを示す図である。
【図６】［００１４］  図６は、本発明の実施形態による、ネットワーク管理の方法を示す図である。
【図７】［００１５］  図７は、本発明の実施形態による、コンピュータシステムの高レベルブロック図である。
【詳細な説明】
【００１０】
［００１６］  さまざまな実施形態または例は、システム、プロセス、装置、ユーザインターフェース、あるいは、コンピュータ読み取り可能な記録媒体等のコンピュータ読み取り可能な媒体上の一連のプログラム命令、あるいは、光学の、電子的な、またはワイヤレスの通信リンクを通してプログラム命令が送られるコンピュータネットワークを含んでいる多数の方法で実現されてもよい。一般的に、開示されるプロセスの動作は、特許請求の範囲で特に提供されない限り、任意の順序で実行されてもよい。
【００１１】
［００１７］  １つ以上の例の詳細な説明が、付随する図面とともに以下に提供される。詳細な説明は、このような例に関連して提供されるが、任意の特定の例に限定されない。範囲は、特許請求の範囲によってのみ限定され、多数の代替や修正や均等物が含まれる。完全な理解を提供するために、以下の説明において、多数の特定の詳細が明らかにされる。これらの詳細は、例の目的のために提供されており、説明された技術は、これらの特定の詳細のうちのいくつかまたはすべてなしで、特許請求の範囲にしたがって実施されてもよい。明確さのために、例に関連する技術分野において知られる技術的なマテリアルは、不必要に記述を曖昧にするのを防ぐために、詳細に説明されていない。
【００１２】
［００１８］  いくつかの実施形態において、状態情報（例えば、コンフィギュレーションデータ、転送状態、ＩＰテーブル、ルール、ネットワークトポロジー情報等）は、ネットワークにおいてデバイスから受信されることができる。状態情報は、構文解析されて、データがネットワークによってどのように処理されるかを記述するネットワークモデルを発生するために使用されることができる。モデルを使用して、ネットワークを解析し、トラフィックのタイプや、ルールマッチングの頻度や、何の種類の変換がネットワークを通したトラフィックフローとして生じるのか、どこでトラフィックが急激に減少されたか、等のネットワーク挙動を特定するために、ネットワークを通したデータの可能性あるフローパス（flow path）が、特定され、使用されることができる。
【００１３】
［００１９］  ネットワークモデルを使用して、ネットワークマネージャーまたは他のこのようなエンティティは、ネットワークに対してさまざまな種類のテストを生成できる。例えば、ネットワークマネージャーは、「ユーザＸ、ＹおよびＺは、情報を互いに送ることができる」ことを、「ユーザは、ＩＰアドレスまたは伝送ポートのある範囲に渡ってのみ、情報を送ることができる」ことを、または、「ユーザＡは、ユーザＢと話すことができないはずである」ことを、または、エリアの幅広い範囲を検証するために、テストを生成できる。
【００１４】
［００２０］  本発明のさまざまな態様の利点をとることができるさまざまなアプリケーションがあり得る。例えば、開発の間のサービスビルダーについて、書き込まれたコードが、ネットワークが適切に機能するのを可能にすることを確実にするために、本発明は使用されることができる。代替的に、生成環境において、ネットワークの現在の挙動を有効性確認するか、または、提案された変更の効果をテストするために、本発明は使用されることができる。
【００１５】
［００２１］  さらに、いくつかの実施形態にしたがうと、いったんネットワーク挙動がネットワークマネージャーによって理解されると、ハードウェア機能不全を検出するように、モデルが予測する方法でハードウェアが挙動するのを確認するために、モデルからの出力にマッチングするように作られた物理パケットが生成され、物理ネットワーク中に送られることができる。
【００１６】
［００２２］  図１は、本発明の実施形態による、ネットワーク管理システムの高レベル図１００を示している。図１において示されるように、ネットワーク管理システム１０２は、複数のネットワークデバイス（例えば、スイッチ、ルータ、ファイアウォール、ロードバランサ、ゲートウェイ、ブリッジ、および他のネットワークデバイス）を含むネットワーク１０４に接続することができる。各ネットワークデバイスは、異なるベンダーによって作成される得、異なるオペレーティングシステムや、制御インターフェースや、プロトコル等を実装してもよい。したがって、ネットワーク管理システム１０２は複数のデバイスインターフェース１０６を含むことができ、これらは、ネットワーク管理システム１０２が介して各ネットワークデバイスと通信することができる、ベンダー特定の、デバイス特定の、および／または、プロトコル特定のインターフェースを含み得る。
【００１７】
［００２３］  いくつかの実施形態において、図２に関して以下でさらに説明されるように、ネットワーク管理システム１０２は、１つ以上の状態コレクタ１０８と、１つ以上のパーサ（parser）１１０とを含むことができる。状態コレクタ１０８およびパーサ１１０は、各ネットワークデバイスに対する状態情報を取得するために、デバイスインターフェース１０６を使用して、ネットワークデバイスと通信できる。状態情報は、ネットワークデバイスからネットワークデバイスにかけて変化し得、転送状態と、コンフィギュレーションファイルと、インターネットプロトコル（ＩＰ）テーブルと、トポロジー情報と、ルールとのうちの１つ以上を含むことができる。モデル化されたネットワークにおいて、データがどのように処理されるかを記述するネットワークモデル１１２を生成するために、状態情報は、パーサによって構文解析されることができる。データがネットワークモデル１１２中においてその上を移動し得る可能なパスフローを特定するために、計算エンジン１１４は、ネットワークモデル１１２を使用できる。いくつかの実施形態において、パスフローは、計算されたフローデータストア１１６等のデータストア中に記憶されてもよく、これは、ネットワーク管理システム１０２とのローカルに、または、遠隔に記憶されてよい。
【００１８】
［００２４］  いくつかの実施形態において、ネットワーク管理システム１０２は、チェックエンジン１１８と、問い合わせエンジン１２０とをさらに含むことができる。以下にさらに記述されるように、パス、ヘッダ、ホップカウント、サービスの品質（ＱｏＳ）、キュー、ポート、フローが通過する物理デバイス、デバイス内のテーブル、パケットの転送タイプ、パケットヘッダ変更、カプセル化されたパケットヘッダ特性、または、割り振られた帯域幅、または他の特性、等のさまざまな特性を特定するために、チェックエンジン１１８は、データストア１１６において記憶されたフローパスを解析することができる。これは、定められた基準（例えば、ネットワーク管理者、開発者、または他のエンティティによって設定される）にしたがってネットワークが機能していることを検証するために、モデル化されたネットワークが解析されることを可能にする。問い合わせエンジン１２０は、問い合わせられた基準を満たす特定のフローパス（例えば、特定されたポイント間のフェールオーバーフローパス、特定の順序で特定のネットワークデバイスを通過するフローパス等）を特定するために使用されることができる。
【００１９】
［００２５］  図２は、物理ネットワークの仮想化されたネットワークモデルを生成して利用することを介した、ネットワークの自動化されたおよび系統的な管理に対して提供するために利用されることができる、ネットワーク管理システムの例２００を図示している。いくつかの実施形態にしたがうと、本発明は、ネットワーク状態情報を収集して、ネットワークにおいて存在し得る異なるタイプのトラフィックを探索することを可能にするシステムを含む。図２において見られるように、いくつかの実施形態において、ネットワーク１０４は、Ｃｉｓｃｏ（登録商標）やＪｕｎｉｐｅｒ（登録商標）等の異なるベンダーからのスイッチやルータを含んでいる、多数のネットワークデバイスを備えることができる。これらのネットワークデバイスのうちのいずれかまたはすべては、制御プレーンによって書き込まれてもよく、１つ以上のＩＰテーブルおよび他の転送ルールによって規定されてもよいコンフィギュレーションデータを、および／または、転送状態を含んでいる、関係付けられた状態情報を有することができる。転送状態は、ネットワークの転送ポリシーを実装するのに使用されることができ、これは、トラフィックの異なるクラスがネットワークにおいてどのようにルーティングされるかとともに、どのくらいの帯域幅がトラフィックのそれらのクラスに割り当てられるかを特定する。
【００２０】
［００２６］  依然として図２を参照すると、ＳＳＨ、テルネット、ＳＮＭＰ、ＮＥＴＣＯＮＦ、ＯｐｅｎＦｌｏｗを通して、または、コレクタがデバイスからの情報を収集できるようにする他の任意のデバイスインターフェースを介して、デバイスへ接続することによって、転送状態の「スナップショット」等の状態情報を収集するために、ネットワーク管理システムは、１つ以上の状態コレクタ１０８を使用できる。収集された状態情報は、転送状態、コンフィギュレーションファイル、ＩＰテーブル、ＯｐｅｎＦｌｏｗルール、トポロジー情報、および、デバイスによって利用可能にされた任意の他のコンフィギュレーションまたは状態を含むことができる。トポロジーデータ等のユーザによって提供された情報で、各スナップショットは増強される。さらに、状態コレクタは、収集された状態情報を周期的に生成することができる。いくつかの実施形態において、状態コレクタ１０８は、少なくとも１つの転送状態における変化が検出されたときのみ、状態情報を収集することができる。
【００２１】
［００２７］  いくつかの実施形態において、ネットワーク管理システムは、ネットワークモデル１１２を構築するために、収集された状態情報２０２を解釈するために１つ以上のパーサ１１０を使用することができる。いくつかの実施形態において、パーサ１１０は、ベンダー特定またはプロトコル特定であり得る。例えば、システムは、ＩＯＳコマンド出力を読み取ることと、ＩＰ転送テーブルを圧縮することと、デバイスの機能をモデル化するベンダーから独立した転送記述を生成することとを含む、Ｃｉｓｃｏ  ＩＯＳを構文解析するためのＣｉｓｃｏパーサを使用できる。別の例において、システムは、Ｊｕｎｐｅｒデバイスに関係付けられた転送状態のためのＪｕｎｉｐｅｒ  Ｊｕｎｏｓ（登録商標）パーサを、または、ＯｐｅｎＦｌｏｗ（登録商標）デバイスに関係付けられた転送状態に対するＯｐｅｎＦｌｏｗパーサを使用できる。いくつかの実施形態において、収集された転送状態における変化を追跡し、ネットワークモデル１１２を迅速に更新するために、インクリメンタルパーサが使用されることができる。
【００２２】
［００２８］  ネットワークモデル１１２は、ネットワーク１０４におけるデータ処理（例えば、パケット処理）のための、ベンダー／プロトコルから独立したモデルであり得る。ネットワークモデルは、ネットワークにおいて、パケットがデバイスによってどのように処理されるかを決定するのに使用される転送ルール２０４を含むことができる。いくつかの実施形態において、ネットワークモデル１１２は、周期的に更新されることができる。いくつかの実施形態において、実際のネットワークの状態が変化するたびにネットワークモデル全体を再計算する代わりに、関係付けられた変更された転送状態を更新することのみによって、ネットワークモデル１１２は徐々に更新されることができ、これは、ルール依存追跡を通して実現されることができる。ルール依存追跡の際、入力ポートにおけるＶＬＡＮ変更等の、状態テーブルに対する個々の更新は、他の関連のないルールの再生成を要求することなく、更新に対する当該入力ポートにマッチングするルールを自動的に引き起こす。更新されたルールのリストは、その後、影響されないモデルの残りをそのままにして、ネットワークにおいて影響を受けたトラフィッククラスおよびパスのモデル化を更新するのに使用されてよい。
【００２３】
［００２９］  いくつかの実施形態において、ネットワーク管理システムは、ネットワークモデル１１２に関係付けられたバージョン管理された状態ダンプファイル２０６を含むことができる。バージョン管理された状態ダンプファイル２０６は、特定のトラフィックフローを、それらを引き起こしたコンフィギュレーションと状態のファイルに、および、コンフィギュレーションと状態のファイルの進路につなぐために、後戻り追跡をサポートすることができる。この方法において、観察された接続性およびポリシーエラーが、自動的に、それらのルート原因にリンクされることができる。
【００２４】
［００３０］  図２において示されるように、計算エンジン１１４は、シンボリックパケットを生成し、ネットワークモデルを介してシンボリックパケットを押し出すことを通じて、ポート対ポートの方法で、ネットワークにおいて、可能なフローパスを特定できる。伝統的なビット（０または１）に加えて、シンボリックパケットは、１つ以上のワイルドカード（＊）を存在させ得る。シンボリックパケットは、転送ルールに遭遇すると、ワイルドカードを０または１に置き換えることができる。したがって、パスに沿った伝送機能を構成することによって、パケットまたはパケットのクラスが、これが移動するにつれてどのように変更されるかを、シンボリックパケットが実証できる。
【００２５】
［００３１］  いくつかの実施形態において、計算エンジンは、転送ルール毎に、少なくとも１つの物理パケットによって実行され、カバーされるように、物理パケットの最小のセットを生成することができる。別の実施形態において、ネットワークの「クローリング（巡回検索）」が断片的である代わりに系統的であるように、物理パケットは、可能性な外部アウトレット毎に対して作成されることができる。
【００２６】
［００３２］  いくつかの実施形態において、計算エンジンは、可能なフローパスとホップとを含んでいる特定された可能なフローパスおよび転送ルール２０６を、フローパスデータベース１１６に、ヘッダ値の変化や、パケットがマッチングするルールや、各ホップでの変形等の、フローパス上を移動する所定のパケットに関係付けられたフローパス情報とともにセーブすることができる。
【００２７】
［００３３］  いくつかの実施形態において、計算エンジン１１４は、フローパスデータベースを周期的に更新できる。別の実施形態において、計算エンジンは、変更された転送ルールと更新されたフローとを反映するためだけに、フローパスデータベースを徐々に更新できる。
【００２８】
［００３４］  パス、ヘッダ、ホップカウント（フローが通過する物理ネットワークエレメントまたは仮想ネットワークエレメントの数、あるいは、フローが通過するそれらのデバイス内のテーブルの数）、優先権等のサービス特性の品質、キュー、ポート、フローが通過する物理デバイス、デバイス内のテーブル、位置または距離等の物理的特性、パケットの転送タイプ（Ｌ２、Ｌ３、ＭＰＬＳ、等）、パケットヘッダ変更、カプセル化されたパケットヘッダ特性、あるいは、割り当てられた帯域幅、等のネットワーク中の可能なフローの特性を検査するために、チェックエンジン１１８は、フローパスデータベース１１６を使用することができる。一例において、検査は、あるフローが存在するか否かを決定するために発行されることができる。別の例において、検査は、「ポート１から、ＩＰアドレス ＩＰ１を有するすべてのトラフィックが、ポート２に到達すべきである」ことを検証するために発行されることができる。別の例において、トラフィックおよびフローが、パス上の障害の場合における位置間を依然として通ることができることを確実にするために、十分なフェールオーバーパスが特定の位置間に存在することを検証するために、チェックが発行されることができる。チェックエンジン１１８は、特定の特性にマッチングするフローの不在に対してもチェックすることができる。「ユーザ１のエンドポイントが、十分に到達可能である」、または、「ユーザ１のエンドポイントが、十分に分離されている」、または、「ユーザ１が、ＰＣＩ準拠である」等のより高いレベルのポリシーについてチェックするメタチェックも作成されることができ、それらは、システム内で、以前に特定された特性に基づいて、１つ以上の基本的なチェックに対して分解される。いくつかの実施形態において、システムは、「すべてに到達できる（ｃａｎ−ｒｅａｃｈ−ａｌｌ）」チェック、または、「いずれにも到達できない（ｃａｎｎｏｔ−ｒｅａｃｈ−ａｎｙ）」チェックを発行することができる。例えば、２つのサブネットを仮定すると、発信元サブネット中の各ＩＰは、宛先サブネット中のＩＰ毎に到達できるか？  この例は、「ヘッダオブジェクト」に対して一般化されることができ、これは、１つ以上のワイルドカード値を含み得るパケットヘッダ値の記述である。対応する質問は、「発信元ヘッダオブジェクトにおける潜在的なパケット値毎に、宛先ヘッダオブジェクトにおける潜在的なパケット値毎に到達することができるか？」である。
【００２９】
［００３５］  いくつかの実施形態にしたがうと、あるチェックは、ネットワークを通して、定期的に実行するように規定されることができる。いくつかの実施形態において、チェックは、特定の時間で、または、特定の時間間隔で実行するように規定されることができる。いくつかの実施形態において、チェックは、特定のネットワークイベントの検出の際に実行するように規定されることができる。例えば、特定のパケットを使用する２つのポートの間に接続性があることが期待される場合、この特定のパケットは、ネットワークにおいて変更があるときにはいつでも、２つのポートの間の接続性をチェックするのに使用されることができる。
【００３０】
［００３６］  いくつかの実施形態において、問い合わせエンジン１２０は、あるパス、ヘッダ値、または、割り当てられた帯域幅を有するフローを見つけるために、フローパスデータベース１１６を使用できる。いくつかの実施形態において、問い合わせ言語は、フローパスデータベースに問い合わせるのに使用されることができる。例えば、問い合わせ２０８は、宛先ＩＰサブネット１０．１．０．０／１６を有するポート１からの可能なフローパスを探索することができる。別の例において、問い合わせは、特定のパケットが到達できる宛先ＩＰアドレスの範囲を探索することができる。さらに別の例において、問い合わせは、ルータＲ１、Ｒ２およびＲ３をその順序で通過するか、または発信元から宛先まで３ホップを超えないで通り抜ける、すべての可能なフローパスを探索することができる。別の例において、問い合わせは、ネットワークを通してあるパスにしたがうすべてのフローを探索することができる。
【００３１】
［００３７］  本発明は、ネットワークに対して問い合わせ機能を提供するための問い合わせインターフェースを含むことができる。例えば、ネットワークマネージャー２１０は、「特定のデバイスからのフロー」についての問い合わせ２１２を発行でき、問い合わせエンジンは、特定のデバイスからのすべての可能なフローを提供できる。問い合わせは、また、１つのデバイスから別のデバイスに行くパケットに何が起きるかを示すために発行されることができる。問い合わせは、また、特定のパケットヘッダを用いて、その宛先に到達するすべてのパケットを見つけることができる。
【００３２】
［００３８］  さらに、本発明の実施形態は、あるフローが存在するはずか否かを検証するためのチェックインターフェースを含むことができる。例えば、ネットワークマネージャー２１０は、「このデバイスから別のデバイスへの期待フロー」についてチェックを発行できる。本発明の実施形態は、２つのデバイス間になぜフローが存在しないのかを示すこと、または、何もないはずのときにフローを見つけること等の、なぜ特定のチェックが失敗したのかについての情報をさらに明らかにすることができる。例えば、「デバイス１からデバイス２への期待フロー」チェックが失敗したとき、本発明は、例えば、誤って構成されたファイアウォールデバイスにおいて、デバイス１からデバイス２へのフローが落とされている場所についての情報をユーザに提示できる。別の例において、「どのフローも、ポート１からポート２へは期待されない」チェックが失敗したとき、発明は、ポート１からポート２に進み、それによりチェックを失敗させた１つ以上のフローについての詳細を提供できる。ＩＰサブネットＡからＩＰサブネットＢへの、失敗されたｃａｎ−ｒｅａｃｈ−ａｌｌチェックの他の例において、発明は、サブネットＡにおけるどのＩＰアドレスがサブネットＢにおけるＩＰアドレスに到達できないかを示し、さらに、これらのそれぞれのフローがネットワークにおいてどこで落とされたかについての詳細を提供できる。
【００３３】
［００３９］  いくつかの実施形態にしたがうと、本発明は、ネットワーク上で解析報告を生成することができる。例えば、解析報告は、ネットワーク管理者に対して、ネットワークの性能をどのように改善するかについての示唆を与え、または、ネットワークが何らかのセキュリティ上の弱点を有するか否かを示すことができる。さらに、本発明は、ネットワーク管理者に対し、各デバイスにログインすることも、デバイスコンフィギュレーションを理解することも、どのようにそれらを取り出すかを理解することも、または、転送テーブル間の相互作用についての理由も、要求しないので、ネットワーク管理者の知識負担を低減することができる。解析報告は、ネットワークに渡る最適なルーティングパスや、最適なピアリング（peering）や、キャッシュロケーションを決定すること等の、ネットワーク間横断の決定のための示唆を含み得る。解析報告は、また、最も使用されるデバイスタイプや、ネットワークデバイスがどのように最も頻繁に使用されるか等の、カスタマー間横断の統計を含むことができる。
【００３４】
［００４０］  別の例において、本発明は、ネットワークの挙動歴についての区分チャートを提供できる。例えば、ネットワーク管理システムは、ネットワークの「スナップショット」をとり続けることができ、そして、異なるスナップショットのネットワークデータとともに、それらの挙動の間を比較し、区分することとを通じて、なぜ故障が生じたかを明らかにすることができる。
【００３５】
［００４１］  いくつかの実施形態にしたがうと、本発明は、時間または「スナップショット」の２つの異なるポイントにおける、ネットワークのコンフィギュレーションと状態との間の差を、計算し、問い合わせる方法を提供できる。いくつかの実施形態において、この差は、ネットワークの挙動に実際に影響したそれらの変化のみを示すことができる。例えば、ルータ１上のボーダーゲートウェイプロトコル（ＢＧＰ）コンフィギュレーションに対し、１０の異なる変化があったと仮定すると、このうちの８つは、ネットワークの転送挙動に影響しなかったが、２つの変更が、ネットワークを通して転送挙動に影響した。ネットワークマネージャーまたはユーザは、いくつかの例において、ネットワークコンフィギュレーションに対するどの変化が、生じたネットワーク障害に関係付けられ得るかを迅速に決定するために、この情報を使用し得る。
【００３６】
［００４２］  いくつかの実施形態において、システムは、２つのネットワークスナップショットの挙動の差を特定することができる。戻される結果が、追加され、または、削除されるフローパスを示し、探索において特定された特徴にマッチングするのみであるように、挙動差は探索されることができる。例えば、「ＩＰサブネット１０．１．０．０／１６に宛てられたポート１からの」フローの探索は、ＶＬＡＮ１０および１１でネットワークに入ることができる２つの追加されたフローパスと、以前にＶＬＡＮ９でネットワークに入ることができた、除去された１つのフローパスとを示し得る。
【００３７】
［００４３］  本発明は、また、ネットワークが進化するにつれて、トポロジーにおける任意の差を計算して、問い合わせるためのシステムを提供する。いくつかの例において、これは、ネットワークデバイスの追加または除去、デバイス間のリンクの追加または除去等を含むことができる。
【００３８】
［００４４］  いくつかの実施形態において、本発明は、ネットワークにおけるチェック障害の可能性ある原因を決定し、ネットワークマネージャーまたはユーザに対して可能な修復を提案するために、ネットワークにおける変化の履歴についての情報を自動的に使用するためのインターフェースを提供することができる。いくつかの例において、ネットワーク挙動を変化させたにちがいないイベントを含んでいる、ネットワークの進化における重要なイベントを示すことができる過去のネットワークイベントについての「タグ」またはノートを、ユーザはさらに追加し得る。
【００３９】
［００４５］  本発明の実施形態は、ネットワークコンフィギュレーションに対する変化のセット、または、ネットワークデバイスに対する変化のセットが、ネットワークに対する任意の挙動差を引き起こさない場合を特定できる。いくつかの実施形態において、ネットワークチェックは、意図されたネットワーク挙動または不変条件を示すために作成される。他の実施形態において、期待されるネットワーク挙動は、パスと、トラフィックタイプと、ネットワークを通した、または、ネットワークを通したシンボリックパケットのトレースを通じたそれらの変形との組み合わせを介して、自動的に推測されてもよい。さらに、また、ネットワークがトラフィックを取り扱うすべての可能な方法のセットからの追加および除去を特定するためだけでなく、何らかの方法でそれらの挙動が変更されたトラフィックまたはパスまたはシンボリックパケットの当該タイプを特定するためにも異なる基準に基づいて比較されて、シンボリックパケットは、時間の異なるポイントに渡ってマッチングされ得る。例えば、ＩＰアドレス１０．０．０．１からＩＰアドレス１０．１．０．１へのトラフィックは、第１のネットワーク「スナップショット」において、ルータ１からルータ２からルータ３にパス上を通過していたが、第２のネットワーク「スナップショット」において、ルータ１からルータ４からルータ３に渡るパス上を通過する。
【００４０】
［００４６］  いくつかの実施形態において、システムは、ネットワークの現在の転送ポリシーを自動的に導出して、それらをチェックに変換するのに使用されることができる。これらのポリシーの任意の違反を検出するために、これらのチェックは、将来のスナップショットに適用されることができる。例えば、現在のサブネットおよびポート接続性が導出され、チェックのセットに変換されることができる。
【００４１】
［００４７］  いくつかの実施形態にしたがうと、ネットワーク管理システムは、効力を失った転送ルールを検出し、調査することができる。効力を失ったルールは、実行されることができないルールとして規定され、したがって、ネットワークから安全に除去されることができる。図３は、本発明の実施形態による、効力を失った転送ルールを特定する例を示す図３００である。図３において示されるように、転送デバイス３０２は、例えば、転送テーブル１  ３０４、転送テーブル２  ３０６、および、転送テーブル３  ３０８を含むことができる。転送テーブル１、２、および３（３０４、３０６、および３０８）のそれぞれは、（ハッシュされたボックスとして示される）１つ以上の転送ルールを含むことができ、これらの中で、転送ルールのうちのいくつかは、実行されることも、または、ヒットされることもまったくできない、効力を失ったルール３１２である。これらの効力を失ったルールを見つけるために、計算エンジンは、いずれのパケットにもマッチングできない抗力を失ったルールを見つけるために、ヘッダビット毎の上にワイルドカード（＊）を有するシンボリックパケット３１０のセットを生成し、押し出すことができる。各可能な転送パスが特定されている場合、任意のパケットを転送するのに使用されていないそれらのルールは、ルール３１２等、効力を失ったルールとして特定されることができる。
【００４２】
［００４８］  本発明の実施形態は、ネットワークテストカバレッジ割合を決定できる。一例において、テストパケットのセットを与えられると、システムは、カバーされるネットワークポートや、リンクや、ルールや、問い合わせ等の一部分を計算できる。別の例において、システムは、テストパケットを計算できる、および／または、ネットワークテストカバレッジの所望のレベルを達成するのに必要とされる位置を調べることができる。
【００４３】
［００４９］  図４は、本発明の実施形態による、効力を失ったルールを調査する例を示す図４００である。図４において示されるように、本発明の実施形態は、効力を失ったルールを調査するためのシステムおよび方法を提供する。システムおよび方法は、なぜあるルールがヒットしないかを調査できる；  例えば、原因は、効力を失ったルールにトラフィックを送らない関連する転送テーブルであるにちがいない。例えば、図４において示されるように、フロータイプＡ４０２は、ルール４０６を通して、効力を失ったルール４０４にトラフィックを向ける。同様に、フロータイプＢ４０８は、ルール４１０を通して、効力を失ったルール４０４にトラフィックを誘導する。しかしながら、図３において示されるように、ルール４０６および４１０も効力を失ったルールであり、したがって、ルール４０４へのパスはない。
【００４４】
［００５０］  本発明の実施形態は、オーバーラップするマッチしたフィールドを有する同一のテーブルまたは異なるテーブル内でルールを検出し、これをユーザに提示するためのシステムおよび方法を提供する。
【００４５】
［００５１］  本発明の実施形態は、それらにマッチングするパケットが、また、所定のルールによってもマッチングされるように、所定の入力ルールに関連する同一のテーブルまたは異なるテーブル内でルールを検出するためのシステムおよび方法を提供する。
【００４６】
［００５２］  本発明の実施形態は、同一のマッチング優先権と、マッチしたフィールドにおけるいくらかのオーバーラップ、または、十分なオーバーラップとを有することが原因で曖昧である、同一のテーブルまたは異なるテーブル内でルールを検出するためのシステムおよび方法を提供する。
【００４７】
［００５３］  本発明の実施形態は、ルールおよびネットワークをより一般的に解析するためのシステムおよび方法を提供し、ルールの除去、ルールへの変更、または他のルールの追加、等の最適化のための提案を提供する。
【００４８】
［００５４］  本発明の実施形態は、ネットワーク内での問題を解析し、検出するためのシステムおよび方法を提供し、それらをどのように修復するかについての提案をユーザに提供する。これらの問題は、ネットワークチェック、問い合わせ、または、他の実施、最適化、または、正当性に関連する問題によって検出されたものを含む。発明は、また、このような問題を修復するために、変更を自動的に適用し得る。
【００４９】
［００５５］  本発明の実施形態は、実際の物理／仮想ネットワークに対して変更を行う前に、ネットワークに対する潜在的な変更をモデリングしてテストするための、ネットワークのスナップショットを修正するシステムおよび方法を提供する。例えば、１つ以上の変更がネットワークに対して行われている（例えば、コンフィギュレーション情報が、ネットワーク中の１つ以上のネットワークデバイス上で更新されている）場合、実際のネットワークデバイスに対してそれらの変更を押し出す以前に、あるいは、ネットワークに対してまたはネットワークから、ネットワークデバイスを追加するか、または、除去する以前に、ネットワークモデルを使用して、それらの変更がテストされることができる。この例において、変更は、ネットワークに対してまたはネットワークから、ネットワークデバイスを追加すること、または、除去すること、転送テーブルを更新すること、あるいは、ネットワークを通して転送挙動に影響し得る任意の他のコンフィギュレーション変更を含むことができる。上述されたようなチェックは、その後、ネットワークに対してなされた変更に関係付けられた潜在的な傷害を特定するために、更新されたネットワークモデル上で実行され得る。いったん、更新されたネットワークモデルがチェックをパスすると、ネットワーク中の対応するネットワークデバイスに対して、変更が押し出される。いくつかの実施形態において、ネットワーク管理システムは、更新されたコンフィギュレーション情報を、（例えば、１つ以上のデバイスインターフェースを使用して、）ネットワーク中の各ネットワークデバイスに対して自動的に送ることができる。いくつかの実施形態において、ネットワーク管理システムは、ネットワーク中のすべてのデバイスよりもむしろ、更新されているそれらのデバイスに対してのみ、更新されたコンフィギュレーション情報を送ることができる。いくつかの実施形態において、ネットワーク管理システムは、更新インターフェースを、（ネットワーク管理者またはネットワーク開発者、等の）ユーザに対して表示されるようにさせてもよく、これを通じて、ネットワーク管理システムは、ネットワーク中の１つ以上のデバイスにおいて、コンフィギュレーション情報を更新するための手動の命令を受信してもよい。
【００５０】
［００５６］  本発明の実施形態は、ネットワーク中の１つ以上のデバイスに対するコンフィギュレーション変更の影響を、および、このようなコンフィギュレーション変更が、他のデバイスに含まれるコンフィギュレーションまたは転送状態にどのように影響するかを、モデリングできる。一例は、１つのデバイス中のＢＧＰまたはＯＳＰＦ等の分散されたプロトコルのコンフィギュレーションを修正すること、および、ネットワーク中の他のデバイスおよび転送状態への影響をモデリングすることである。
【００５１】
［００５７］  本発明の実施形態は、ネットワークスナップショットからコンフィギュレーションをとって、それをネットワーク中のすべてのデバイスに適用するためのシステムおよび方法を提供する。
【００５２】
［００５８］  図５は、本発明の実施形態による、複数のデバイスに渡るネットワーク管理システムのアプリケーションを示す図５００である。図５において示されるように、ここで提供されるシステムおよび方法は、単一のネットワークデバイス内の代わりに、複数のネットワークデバイス（５０２、５０４、５０６）を含むネットワークに適用できる。図３と同様に、ワイルドカードヘッダビットを有するシンボリックパケット５０８が、これらのデバイスを通過する可能なパスを特定するために、複数のネットワークデバイス（５０２、５０４、５０６）に渡って送られることができる。３つのデバイスが、図５の例において示されるが、本発明の実施形態は、任意の数のネットワークデバイスとともに使用されることができる。
【００５３】
［００５９］  いくつかの実施形態において、特定のチェックを実行するための要求は、グラフィカルユーザインターフェース（ＧＵＩ）またはコマンドラインインターフェース（ＣＬＩ）等のユーザインターフェースを通して受信されることができる。いくつかの実施形態において、チェックエンジン１１８は、ネットワークのＣａｎＲｅａｃｈＡｌｌチェックを実行できる。チェックは、＜ＨＯ１＞ ＣａｎＲeａｃｈＡｌｌ ＜ＨＯ２＞等の入力ストリングを受信することによって開始されることができ、ここで、ＨＯ１とＨＯ２は、パケットヘッダオブジェクト（パケットヘッダフィールドに対する値の仕様）である。いくつかの実施形態において、ＨＯ１は、ヘッダフィールドＨＯ１．ｈＦｉｅｌｄｓのリストのための値ＨＯ１．ｈＶａｌｕｅｓを特定することができ、ＨＯ２は、ヘッダフィールドＨＯ２．ｈＦｉｅｌｄｓのリストのための値ＨＯ２．ｈＶａｌｕｅｓを特定することができる。いくつかの実施形態において、ＨＯ１．ｈＦｉｅｌｄｓによって特定されない任意のヘッダフィールドは、ネットワーク侵入においてワイルドカードとして設定されることができる。それぞれ、ＨＯ１．ｈＶａｌｕｅｓとＨＯ２．ｈＶａｌｕｅｓによって許可されて、ヘッダフィールドＨＯ１．ｈＦｉｅｌｄｓとＨＯ２．ｈＦｉｅｌｄｓのすべての可能な値について、ＨＯ１からＨＯ２への完全な到達可能性があり、すなわち、値の各可能なセットについて、ＨＯ１．ｈＦｉｅｌｄｓは、ＨＯ１．ｈＶａｌｕｅｓによって許可されたととることができ、ＨＯ１．ｈＦｉｅｌｄｓについての値の当該セットを用いてネットワークに入り、ＨＯ２．ｈＶａｌｕｅｓによって許可されたととることができるＨＯ２．ｈＦｉｅｌｄｓのすべての可能なセットを用いてネットワークを出るパケットが存在することを検証するために、このチェックが使用されることができる。ＨＯ１．ｈＦｉｅｌｄｓとＨＯ２．ｈＶａｌｕｅによって特定されない他の任意のヘッダフィールドは、完全な到達可能性を有し得ないことを注記する。
【００５４】
［００６０］  いくつかの実施形態において、上述されたＣａｎＲｅａｃｈＡｌｌ等のチェックは、オプション的なフィールドをさらに含むことができる。例えば、「ｆｒｏｍ」と「ｔｏ」のパケットヘッダオブジェクト（ＨＯ）フィルタ仕様は、オプション的に、フローパス探索を狭めるために、位置仕様（ポート／テーブル／デバイス）で増強されることができる。いったん、フローがデータベースから取り出されると、これらの位置フィルタは、ＨＯ到達可能性の妥当性検証のために使用されない。
【００５５】
［００６１］  ＣａｎＲｅａｃｈＡｌｌチェックの一例において、ストリング「ｉｐｖ４＿ｓｒｃ  ａｄｄｒ  １９２．１６８.２．０／２４  ＣａｎＲｅａｃｈＡｌｌ  ｉｐｖ４＿ｄｓｔ  ａｄｄｒ  １９２．１６８.３．０／２４」が受信され得る。このストリングは、サブネット中の各発信元ＩＰアドレス１９２．１６８．２．０／２４が、サブネット中のすべての宛先ＩＰアドレス１９２．１６８．３．０／２４に到達できるか否かを決定するための要求を示す。到達可能性は、プロトコル、ポート番号等のサブセットに対してのみ、潜在的に有効であり得る。ここでのチェック条件は、すべてのプロトコルに渡っては到達可能性を求めない。ネットワークにおける発信元ＨＯベースのフィルタリング／転送がない限り、ネットワークが特定の宛先ＩＰサブネットを含む限りは、この種の到達可能性は常に存在することになる可能性がある。
【００５６】
［００６２］  ＣａｎＲｅａｃｈＡｌｌチェックの他の例において、ストリング「ｒｏｕｔｅｒ１  ｐｏｒｔ１  ｉｐｖ４＿ｓｒｃ  ａｄｄｒ  １９２．１６８．２．０／２４  ｃａｎＲｅａｃｈＡｌｌ  ｉｐｖ４＿ｄｓｔ  ａｄｄｒ  １９２．１６８．３．０／２４」が受信され得、これは、ルータ１およびポート１でのサブネット中の各発信元ＩＰアドレス１９２．１６８．２．０／２４が、サブネット中のすべての宛先ＩＰアドレス１９２．１６８．３．０／２４に到達できるか否かをチェックするための要求を示す。ポートの番号または位置を指定することによって、当該特定の発信元ポート番号（位置）における発信元ＨＳが、特定された宛先ＩＰサブネットに到達できることを確実にするために、探索は狭められる。
【００５７】
［００６３］  ＣａｎＲｅａｃｈＡｌｌチェックの他の例において、ストリング「ｉｐ＿ｐｒｏｔｏ  ｔｃｐ  ｉｐｖ４＿ｓｒｃ  ａｄｄｒ  １９２．１６８．２．０／２４  ｃａｎＲｅａｃｈＡｌｌ  ｉｐｖ４＿ｄｓｔ  ａｄｄｒ  １９２．１６８．３．０／２４」が受信され得、これは、サブネット中の各発信元ＩＰアドレス１９２．１６８．２．０／２４が、ＴＣＰパケットを使用して、サブネット中のすべての宛先ＩＰアドレス１９２．１６８．３．０／２４に到達できるか否かをチェックするための要求を示す。このチェックは、アドレスに対する特定のプロトコルを明示的に検証する。
【００５８】
［００６４］  ＣａｎＲｅａｃｈＡｌｌチェックの一例において、ストリング「ｉｐ＿ｐｒｏｔｏ  ＡＬＬ  ｉｐｖ４＿ｓｒｃ  ａｄｄｒ  １９２．１６８.２．０／２４  ｃａｎＲｅａｃｈＡｌｌ  ｉｐｖ４＿ｄｓｔ  ａｄｄｒ  １９２．１６８.３．０／２４」が受信され得、これは、サブネット中の各発信元ＩＰアドレス１９２．１６８．２．０／２４が、すべてのＩＰプロトコルタイプを使用して、サブネット中のすべての宛先ＩＰアドレス１９２．１６８．３．０／２４に到達できるか否かをチェックするための要求を示す。
【００５９】
［００６５］  いくつかの実施形態において、いくつかの仮定が、チェックストリング入力上でなされ得る。例えば、いくつかの実施形態において、ＨＯ１とＨＯ２中のヘッダフィールドのセットは、直交でなければならないということが仮定され得る。例えば、同じヘッダフィールド（例えば、ｉｐｖ４＿ｄｓｔ）が、ＨＯ１およびＨＯ２両方において特定された場合、ＨＯ１およびＨＯ２のうちの少なくとも１つにおけるフィールドのための値は、いかなるワイルドカードビットも含まない。加えて、マッチングするフローパスのセットについて、ネットワーク中の任意のルールが、ＨＯ１において特定されたヘッダフィールドｈＦｉｅｌｄ１の値を見て、ＨＯ１におけるｈＦｉｅｌｄ１の値に基づいて、ＨＯ２において特定されたヘッダフィールドｈＦｉｅｌｄ２の値を動的に書き換え得る場合、以下の条件：１）ＨＯ１におけるｈＦｉｅｌｄ１の値はワイルドカードビットを有していない、および／または、２）ＨＯ２におけるｈＦｉｅｌｄ２の値はワイルドカードビットを有していない、のうちの少なくとも１つが当てはまらなければならない。
【００６０】
［００６６］  いくつかの実施形態において、所定のチェックは、複数の拡張を含むことができる。例えば、ＣａｎＲｅａｃｈＡｌｌチェックは、以下の拡張を含むことができる。
【００６１】
［００６７］  １． ＜ＨＯ１＞ ｃａｎＲｅａｃｈＡｌｌ ＜ｌｉｓｔ  ｏｆ  ｐｏｒｔｓ  Ｐ＞ −−ＨＯ１．ｈＦｉｅｌｄｓがＨＯ１．ｈＶａｌｕｅｓによって許可されるとしてとることができる値の可能なセットの各々について、リストＰ中のポートのそれぞれにおいてネットワークを出ることができる、ネットワークに入るパケットが存在する。
【００６２】
［００６８］  ２． ＜ｌｉｓｔ  ｏｆ  ｐｏｒｔｓ  Ｐ＞ ｃａｎＲｅａｃｈＡｌｌ ＜ＨＯ２＞ −−ＨＯ２．ｈＦｉｅｌｄｓがＨＯ２．ｈＶａｌｕｅｓによって許可されるとしてとることができる値の可能なセットをもってネットワークを出ることができる、リストＰ中の各進入ポートにおいてネットワークに入るパケットが存在する。
【００６３】
［００６９］  ３． ＜ＨＯ１＞ ｃａｎＯｎｌｙＲｅａｃｈ ＜ｌｉｓｔ  ｏｆ  ｐｏｒｔｓ  Ｐ＞ −−ＨＯ１．ｈＦｉｅｌｄｓがＨＯ１．ｈＶａｌｕｅｓによって許可されるとしてとることができる値の可能なセットの各々について、リストＰ中のポート以外の任意の進入ポートにおいてネットワークを出ることができるパケットは存在しない。
【００６４】
［００７０］  ４． ＜ＨＯ１＞ ｃａｎＲｅａｃｈＡｌｌ ＜ｌｉｓｔ  ｏｆ  Ｄｅｖｉｃｅｓ  Ｄ＞ および ＜ｌｉｓｔ  ｏｆ  Ｄｅｖｉｃｅｓ＞ ｃａｎＲｅａｃｈＡｌｌ ＜ＨＯ２＞ −− １および２に類似するが、ポートの代わりにデバイスを有する。
【００６５】
［００７１］  ５． ＜ｌｉｓｔ  ｏｆ  ｐｏｒｔｓ  Ｐ１＞ ｃａｎＲｅａｃｈＡｌｌ ＜ｌｉｓｔ  ｏｆ  ｐｏｒｔｓ  Ｐ２＞ −− リストＰ１中の各発信元ポートについて、リストＰ２中のポートのそれぞれに到達できるパケットが存在する。
【００６６】
［００７２］  ６． ＜ＨＯ１＞ ａｔＥａｃｈＯｆ ＜ｌｉｓｔ  ｏｆ  ｐｏｒｔｓ  Ｐ１＞ ｃａｎＲｅａｃｈＡｌｌ ＜ＨＯ２＞ ａｔＥａｃｈＯｆ ＜ｌｉｓｔ  ｏｆ  ｐｏｒｔｓ  Ｐ２＞ −− リストＰ１中の各発信元ポートｓｒｃＰと、リストＰ２中の各宛先ポートｄｓｔＰとについて、 ｓｒｃＰ ＜ＨＯ１＞ ｃａｎＲｅａｃｈＡｌｌ  ｄｓｔＰ ＜ＨＯ２＞ が有効である。例えば、Ｐ１とＰ２からのポートの可能な対の各々について、発信元ＨＳ  ＨＯ１から宛先ＨＳ  ＨＯ２への完全な到達可能性がある。
【００６７】
［００７３］  ７． ＜ＨＯ１＞ ｏｎｌｙＡｔ ＜ｌｉｓｔ  ｏｆ  ｐｏｒｔｓ  Ｐ１＞ ｃａｎＲｅａｃｈＡｌｌ ＜ＨＯ２＞ ｏｎｌｙＡｔ ＜ｌｉｓｔ  ｏｆ  ｐｏｒｔｓ  Ｐ２＞ −− ＜ＨＯ１＞ ｃａｎＲｅａｃｈＡｌｌ ＜ＨＯ２＞ は有効であるが、リストＰ１からの発信元ポートで始まり、リストＰ２からの宛先ポートで終わるそれらフローパスのために問い合わせるのみである。
【００６８】
［００７４］  上記の例示的なＣａｎＲｅａｃｈＡｌｌチェックは、テキストベースのインターフェースに関して説明されているが、また、同様の挙動を見せるＧＵＩまたは他のユーザインターフェースの後ろで、類似した機能性が取り出され得る。
【００６９】
［００７５］  本発明の実施形態は、マルチドメインの、または「真に分散された」、収集およびテストシステムを提供できる。このモードにおいて、（ネットワークのサブセットに各々が責任をもつ）ローカルエージェントと、（ネットワーク全体に責任をもつ）グローバルエージェントとの組み合わせの上で、検証プロセスは実行する。ローカルに確認されることができるルール変更は、適切なローカルエージェントによって直ちに処理され、そして、グローバルエージェントと同期化される。複数のローカルエージェントに影響するルール変更は、グローバルエージェントによって実装されなければならず、これは、すべてのルールイベント上での単一のグローバルオーダリングを強い得る。オプション的に、拡張性を強化するために、グローバル知識のうちのいくらかを集約するか、またそうでなければフィルタリングする方法において、トポロジーおよびルール知識が、各ローカルエージェントに提示されてもよい。
【００７０】
［００７６］
本発明の実施形態は、高い可用性モードを提供でき、ここで、複数の収集エージェントが実行され得、ネットワークコンフィギュレーションおよび状態を収集するために、それらはともに連携し得る。１つ以上が動かなくなるイベントにおいて、役に立たなくなったエージェントが収集していたデバイスからの状態を収集するために、他のエージェントが連携し得る。
【００７１】
［００７７］  本発明の実施形態は、ＩＰアドレス、ＩＰサブネット、またはＶＬＡＮ等の異なるネットワークエレメントが、ネットワークにおいて、どこに存在しているかを特定することができる。例えば、ネットワークモデルは、ネットワーク中のＩＰアドレス１９２．１６８．１０．２を、ｒｏｕｔｅｒ１  ｐｏｒｔ１に位置付けられ、ＶＬＡＮ １０上でアクセス可能であるとして位置付けるために使用されることができる。いくつかの実施形態において、これは、ネットワークを通して任意の現実のパケットを送ることなく行われ得る。発明は、また、ＩＰサブネットを位置付けるのに使用されることもできる。例えば、ネットワークモデルは、ＩＰサブネット１０．１．０．０／２４が、ＩＰが到達可能である特有のＶＬＡＮとともに、ネットワークにおける３つの異なるルータポートに渡って拡散されることを決定できる。
【００７２】
［００７８］  いくつかの実施形態において、問い合わせインターフェースは、ＩＰアドレス、ＩＰサブネット、ＶＬＡＮ、デバイス、ネットワークインターフェース、または他のネットワークエレメントを位置付けるために提供されてもよい。インターフェースは、ネットワークにおいてエレメントを位置付ける視覚による図解で、さらに増強され得る。
【００７３】
［００７９］  本発明の実施形態は、ネットワークを通してトラフィックのクラスまたはタイプを追跡するためのインターフェースを提供できる。例えば、発信元ＩＰアドレス１０．０．０．１０からＩＰサブネット１０．１．２．０／２４へのトラフィックトレースを探索することは、問い合わせられたトラフィックがネットワークを通してとることができるパスを示すことができ、探索結果に関連する付加的なフィルタを視覚的に提示することによって、探索をより良くする方法を提供することができる。
【００７４】
［００８０］  いくつかの実施形態において、トレース探索結果をより良くするのを助けることができるフィルタのうちのいくつかを生成するために、トレース結果は、パスや、ネットワーク中の異なるデバイスにおけるヘッダフィールドの値や、パス長等のさまざまな次元に沿って分類される。ネットワークマネージャーまたはシステムのユーザは、トレースをより良くして、関心のある関連するトラフィックに対して迅速に収斂するために、提案されたフィルタを使用できる。例えば、ネットワークマネージャーは、発信元ＩＰアドレス１０．０．０．１０からＩＰサブネット１０．１．２．０／２４へのトラフィックトレースを探索し得、システムは、トレース結果によって横切られたデバイス［ルータ１、ルータ２、ルータ３、ルータ４］のリストと、サーチに関連するいくつかのトレースがルータ２において落ちていることを、ネットワークマネージャーに提示する。ネットワークマネージャーは、その後、ルータ２を選択し、落ちているトラフィックを見ることのみを選ぶ。システムは、その後、これらの付加的なフィルタにも同様にマッチングするそれらのトレース結果のみをネットワークマネージャーに提示する。
【００７５】
［００８１］  本発明の実施形態は、ユーザが仮想パケットトレースを見ることができるインターフェースを提供できる。これらは、実際のパケットをネットワーク中に送ることなく、システムによって計算される。トレース自体は、単一のパケットのみを記述するよりもむしろ、異なるＶＬＡＮを通過するトラフィックを、または、いくつかの異なるＩＰアドレスを備え得る。いくつかの実施形態において、システムは、また、ネットワークにおいて見られることができる個々の実際のパケットに対応するトレースを、ユーザに提示することができる。
【００７６】
［００８２］  図６は、本発明の実施形態による、ネットワーク管理の方法６００を示す図である。６０２において、状態情報は、ネットワーク中の複数のネットワークデバイスから受信されることができる。上述したように、状態情報は、ネットワークにおいて、デバイスまたは複数のデバイスから受信された情報（例えば、転送状態、コンフィギュレーションファイル、インターネットプロトコル（ＩＰ）テーブル、およびルール）を、および／または、開発者や管理者等のユーザから受信された情報（例えば、ネットワークトポロジー情報）を含むことができる。状態情報は、１つ以上のデバイス、ネットワーク、および／または、プロトコル特定インターフェース（例えば、ＳＳＨ、テルネット、ＳＮＭＰ、ＮＥＴＣＯＮＦ、ＯｐｅｎＦｌｏｗ、または、コレクタがデバイスまたはネットワークからの情報を収集できるようにする他の任意のメカニズムを介して）を通して受信されることができる。
【００７７】
［００８３］  ６０４において、構文解析されたネットワーク情報を生成するために、ネットワークデバイス特定の複数のパーサは、ネットワーク情報を構文解析できる。いくつかの実施形態において、ネットワークデバイス特定のパーサは、ベンダー特定のパーサ、および／または、プロトコル特定のパーサを含むことができる。例えば、Ｃｉｓｃｏパーサは、Ｃｉｓｃｏ  ＩＯＳを使用して、デバイスを構文解析すること（例えば、ＩＯＳコマンド出力を読み取ること、ＩＰ転送テーブルを圧縮すること、および、転送記述を生成すること）のために使用されてもよく、Ｊｕｎｉｐｅｒ  Ｊｕｎｏｓパーサは、Ｊｕｎｉｐｅｒデバイスを構文解析するのに使用され得、ＯｐｅｎＦｌｏｗパーサは、ＯｐｅｎＦｌｏｗデバイスから受信された状態情報等を構文解析するために使用され得る。いくつかの実施形態において、ネットワークデバイス特定の複数のパーサは、複数のネットワークデバイスから受信された状態情報に対してなされた変更を追跡するのに使用される１つ以上のインクリメンタルなパーサを含むことができる。
【００７８】
［００８４］  ６０６において、ネットワークモデルは、構文解析されたネットワーク情報に基づいて生成されることができる。ネットワークモデルは、データがネットワークによってどのように処理されるかを記述できる。上述されたように、いくつかの実施形態において、ネットワークモデルは、データがネットワークを通してどのようにルーティングされるかを決定するために使用されることができる転送ルールを含むことができる。いくつかの実施形態において、ネットワークモデルは、所定の時間においてネットワークのスナップショットを表すことができ、複数のネットワークデバイスから受信された状態情報に対する変更を反映するために更新され得る。いくつかの実施形態において、ネットワークモデルを生成するために使用される状態情報は、バックアップされることができる。
【００７９】
［００８５］  ６０８において、１つ以上のフローパスは、ネットワークモデルを使用して計算されることができる。いくつかの実施形態において、１つ以上のフローパスは、ネットワーク中のすべての可能なポート対ポートパスを含むことができる。シンボリックパケットは、ネットワークモデルを通して押し出されることができ、これは、１つ以上のワイルドカードビットを含む。ワイルドカードビットは、各転送ルールが遭遇されたとき、更新される（例えば、「１」または「０」に置き換えられる）ことができる。ワイルドカードビットに対してなされた変更は、特定のフローパスに関連付けられた転送機能を特定するために使用されることができる。いくつかの実施形態において、１つ以上のフローパスは、データストア中に記憶されることができる。いくつかの実施形態において、（例えば、インクリメンタルなパーサを使用して）状態情報に対して変更が検出されたとき、１つ以上のフローパスが、変更に基づいて更新されることができ、更新された１つ以上のフローパスは、データストア中に記憶されることができる。
【００８０】
［００８６］  ６１０において、ネットワーク特性を特定するために、１つ以上のフローパスを解析する。上述されたように、ネットワーク中の可能なフローの特性は、パス、ヘッダ、ホップカウント（フローが通過する物理または仮想のネットワークエレメントの数、または、それが通過するそれらデバイス内のテーブルの数）、優先度等のサービス特性の品質、キュー、ポート、フローが通過する物理デバイス、デバイス内のテーブル、位置や距離等の物理的な特徴、パケットの転送タイプ（Ｌ２、Ｌ３、ＭＰＬＳ、等）、パケットヘッダ変更、カプセル化されたパケットヘッダ特性、または、割り当てられた帯域幅を含むことができる。
【００８１】
［００８７］  いくつかの実施形態において、フローパスは、特定のネットワーク特性に基づいてデータストアに問い合わせ、当該問い合わせにマッチングするフローパスを受信し、そして、受信されたフローパスを、特定のネットワーク特性に関連付けられたルールと比較することによって、解析されることができる。例えば、問い合わせは、特定の位置の間の多くの障害迂回パス（すなわち、特定のネットワーク特性）を特定するために提示されることができ、障害迂回パスにマッチングしているフローパスは戻され得る。戻されたフローパスの数は、その後、予め決定された数（すなわち、特定の特性に関連付けられたルール）に比較され得る。同様のチェックは、また、上述したように、他のネットワーク特性を検証するために実行されてもよい。いくつかの実施形態において、１つ以上のフローパスのサブセットの少なくとも１つのルールとの比較に基づいて、報告が生成されてもよく、報告は、１つ以上の提案されたネットワークコンフィギュレーション変更を含む。例えば、障害迂回パスの数が、予め決定された数よりも少ない場合、報告は、利用可能なパスの数を増加させるための提案された変更を含み得る。
【００８２】
［００８８］  いくつかの実施形態において、１つ以上のフローパスは、少なくとも１つのネットワーク特性の１つ以上の違反を特定するために解析されることができる。例えば、上述されたように、ネットワーク特性は、１つ以上のルールに関連付けられ得る。ネットワーク状態情報が１つ以上のルールにおいて規定された条件を満たさないとき、ネットワーク特性の違反が示され得る。ネットワーク特性および関連付けられたルールは、ネットワーク管理者や開発者や他のユーザ等のユーザから受信されるか、現在のネットワーク状態情報に基づいてネットワーク管理システムによって推量されるか、または、他の第３者発信元から導出され得る。いくつかの実施形態において、ネットワーク特性の違反が特定されたとき、１つ以上の特定された違反に関連付けられたネットワークデバイスのコンフィギュレーションを特定する報告が生成されることができる。生成された報告は、記憶されることができ、および／または、ユーザは、生成された報告を含む警報を送られることができる。
【００８３】
［００８９］  図７は、本発明の実施形態による、コンピュータシステムの高レベルブロック図７００である。図７において示されるように、コンピュータシステムは、ネットワークインターフェース７０２を含む、バスを介して接続されたハードウェアエレメントを含むことができ、これは、コンピュータシステムが、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、モバイルネットワーク（例えば、ＥＤＧＥ、３Ｇ、４Ｇ、または他のモバイルネットワーク）、または、他のネットワークを通して、他のコンピュータシステムに接続することを可能にする。コンピュータシステムは、さらに、中央処理ユニット（ＣＰＵ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）、ネットワークプロセッサ、または他のプロセッサ等の１つ以上のプロセッサ７０４を含むことができる。プロセッサは、単一コアのプロセッサまたはマルチコアのプロセッサを含み得る。
【００８４】
［００９０］  いくつかの実施形態において、コンピュータシステムは、グラフィカルユーザインターフェース（ＧＵＩ）７０６を含むことができる。ＧＵＩ７０６は、ユーザが見ることができるデータを出力するために、ディスプレイ（ＬＥＤ、ＬＣＤ、タブレット、タッチスクリーン、または、他のディスプレイ）に接続できる。いくつかの実施形態において、ＧＵＩ７０６は、（例えば、タッチスクリーンや他の対話型インターフェースを通して）命令を受信するように構成されることができる。いくつかの実施形態において、Ｉ／Ｏインターフェース７０８は、マウス、キーボード、タッチセンシティブ入力デバイス、および、他の入力または出力デバイス等の、１つ以上の入力および／または出力デバイスに接続するのに使用されることができる。Ｉ／Ｏインターフェース７０８は、赤外線の、Ｂｌｕｅｔｏｏｔｈ（登録商標）の、または、他の無線デバイスに接続するための有線または無線インターフェースを含むことができる。
【００８５】
［００９１］  いくつかの実施形態において、コンピュータシステムは、ローカルまたは遠隔のデータ記憶装置７１０を含み得る。データ記憶装置７１０は、当技術で知られているように、さまざまなコンピュータ読み取り可能な記録媒体、記憶システム、および、記憶サービス（例えば、ディスクドライブ、ＣＤ−ＲＯＭ（登録商標）、デジタルバーサタイルディスク（ＤＶＤ）、または他の光学記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置、または他の磁気記憶デバイス、リレーショナルデータベース、オブジェクト記憶システム、ローカルまたはクラウドベースの記憶サービス、または他の任意の記録媒体、システム、またはサービス）を含むことができる。データ記憶装置７１０は、ここで記述されたように、生成され、記憶され、またはその他利用されるデータを含むことができる。例えば、データ記憶装置７１０は、上述したように生成され、記憶された、計算されたフロー７１２とネットワークモデル７１４とを含むことができる。メモリ７１６は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、フラッシュメモリ、または他のメモリ技術を含む、さまざまなメモリ技術を含むことができる。メモリ７１６は、ここで説明されたような方法を実装するための実行可能なコードを含むことができる。例えば、メモリ７１６は、各々がここで記載された方法を実装するネットワークアナライザモジュール７１８と、報告ジェネレータモジュール７２０とを含むことができる。
【００８６】
［００９２］  先述の例は、理解を明確にする目的で、ある程度の詳細さで記載されているが、上述された発明技術は、提供された具体例に限定されるものではない。上述された発明技術を実装する多くの代替的な方法がある。開示された例は、例示であり、制限するものではない。
本願出願時の特許請求の範囲に記載された発明を以下に付記する。
［Ｃ１］
コンピュータにより実装される方法において、
ネットワークにおける複数のネットワークデバイスからの状態情報を受信することと、
構文解析されたネットワーク情報を作成するために、ネットワークデバイス特定の複数のパーサによって、前記ネットワーク情報を構文解析することと、
前記構文解析されたネットワーク情報に基づいて、ネットワークモデルを生成することと、ここにおいて、前記ネットワークモデルは、前記ネットワークによってデータがどのように処理されるかを記述し、
前記ネットワークモデルを使用して、１つ以上のフローパスを計算することと、
ネットワーク特性を特定するために、前記１つ以上のフローパスを解析することと、
を備える、コンピュータにより実装される方法。
［Ｃ２］
前記状態情報は、前記複数のネットワークデバイスから受信された転送状態と、コンフィギュレーションファイルと、インターネットプロトコル（ＩＰ）テーブルと、ルールとのうちの１つ以上を含む、［Ｃ１］に記載のコンピュータにより実装される方法。
［Ｃ３］
前記状態情報は、ユーザから受信されたネットワークトポロジーデータをさらに含む、［Ｃ１］に記載のコンピュータにより実装される方法。
［Ｃ４］
ネットワーク特性を特定するために、前記１つ以上のフローパスを解析することは、
ネットワーク正当性不変条件を検証することをさらに備える、［Ｃ１］に記載のコンピュータにより実装される方法。
［Ｃ５］
前記１つ以上のフローパスを、データ記憶装置中に記憶することと、
前記複数のパーサのうちの少なくとも１つを使用して、前記ネットワークにおける少なくとも１つのネットワークデバイスに関連付けられている前記状態情報に対する変化を検出することと、
前記変化に基づいて、前記１つ以上のフローパスを更新することと、
前記更新された１つ以上のフローパスを、前記データ記憶装置中に記憶することと、
をさらに備える、［Ｃ１］に記載のコンピュータにより実装される方法。
［Ｃ６］
前記１つ以上のフローパスを、データ記憶装置の中に記憶することをさらに備え、
ネットワーク特性を特定するために、前記１つ以上のフローパスを解析することは、
少なくとも１つのネットワーク特性に基づいて、前記データ記憶装置に問い合わせることと、
前記問い合わせに応答して、前記データ記憶装置から、前記１つ以上のフローパスのサブセットを受信することと、
前記１つ以上のフローパスの前記サブセットを、前記少なくとも１つのネットワーク特性に関連付けられている少なくとも１つのルールと比較することと、
をさらに備える、
［Ｃ１］に記載のコンピュータにより実装される方法。
［Ｃ７］
前記１つ以上のフローパスの前記サブセットの前記少なくとも１つのルールとの前記比較に基づいて、報告を生成することをさらに備え、
前記報告は、１つ以上の提案されたネットワークコンフィギュレーション変更を含む、
［Ｃ６］に記載のコンピュータにより実装される方法。
［Ｃ８］
少なくとも１つのネットワーク特性の、１つ以上の違反を特定するために、前記１つ以上のフローパスを解析することをさらに備える、［Ｃ１］に記載のコンピュータにより実装される方法。
［Ｃ９］
前記１つ以上の特定された違反に関連付けられているネットワークデバイスのコンフィギュレーションを特定する報告を生成することをさらに備える、［Ｃ８］に記載のコンピュータにより実装される方法。
［Ｃ１０］
システムにおいて、
１つ以上のプロセッサと、
命令を含む１つ以上のメモリデバイスと、
を備え、
前記命令は、前記１つ以上のプロセッサによって実行されたとき、前記システムに、
ネットワークにおける複数のネットワークデバイスからの状態情報を受信させるための命令と、
構文解析されたネットワーク情報を作成するために、ネットワークデバイス特定の複数のパーサによって、前記ネットワーク情報を構文解析させるための命令と、
前記構文解析されたネットワーク情報に基づいて、ネットワークモデルを生成させるための命令と、ここにおいて、前記ネットワークモデルは、前記ネットワークによってデータがどのように処理されるかを記述し、
前記ネットワークモデルを使用して、１つ以上のフローパスを計算させるための命令と、
ネットワーク特徴を特定するために、前記１つ以上のフローパスを解析させるための命令と、を含む、
システム。
［Ｃ１１］
前記状態情報は、前記複数のネットワークデバイスから受信された転送状態と、コンフィギュレーションファイルと、インターネットプロトコル（ＩＰ）テーブルと、ルールとのうちの１つ以上を含む、［Ｃ１０］に記載のシステム。
［Ｃ１２］
前記状態情報は、ユーザから受信されたネットワークトポロジーデータをさらに含む、［Ｃ１０］に記載のシステム。
［Ｃ１３］
前記１つ以上のフローパスを、データ記憶装置中に記憶することと、
前記複数のパーサのうちの少なくとも１つを使用して、前記ネットワークにおける少なくとも１つのネットワークデバイスに関連付けられている前記状態情報に対する変化を検出することと、
前記変化に基づいて、前記１つ以上のフローパスを更新することと、
前記更新された１つ以上のフローパスを、前記データ記憶装置中に記憶することと、
をさらに備える、［Ｃ１０］に記載のシステム。
［Ｃ１４］
前記１つ以上のフローパスを、データ記憶装置の中に記憶することをさらに備え、
ネットワーク特徴を特定するために、前記１つ以上のフローパスを解析することは、
少なくとも１つのネットワーク特性に基づいて、前記データ記憶装置に問い合わせることと、
前記問い合わせに応答して、前記データ記憶装置から、前記１つ以上のフローパスのサブセットを受信することと、
前記１つ以上のフローパスのサブセットを、少なくとも１つのネットワーク特性に関連付けられている少なくとも１つのルールと比較することと、
をさらに備える、［Ｃ１０］に記載のシステム。
［Ｃ１５］
前記１つ以上のフローパスのサブセットの前記少なくとも１つのルールとの前記比較に基づいて、報告を生成することをさらに備え、
前記報告は、１つ以上の提案されたネットワークコンフィギュレーション変更を含む、［Ｃ１４］に記載のシステム。
［Ｃ１６］
命令を含む一時的でないコンピュータ読み取り可能な記憶媒体において、
前記命令は、１つ以上のプロセッサによって実行されたとき、システムに、
ネットワークにおける複数のネットワークデバイスからの状態情報を受信させるための命令と、
構文解析されたネットワーク情報を作成するために、ネットワークデバイス特定の複数のパーサによって、前記ネットワーク情報を構文解析させるための命令と、
前記構文解析されたネットワーク情報に基づいて、ネットワークモデルを生成させるための命令と、ここにおいて、前記ネットワークモデルは、前記ネットワークによってデータがどのように処理されるかを記述し、
前記ネットワークモデルを使用して、１つ以上のフローパスを計算させるための命令と、
ネットワーク特徴を特定するために、前記１つ以上のフローパスを解析させるための命令と、
を含む、
一時的でないコンピュータ読み取り可能な記憶媒体。
［Ｃ１７］
前記状態情報は、
前記複数のネットワークデバイスから受信された転送状態と、コンフィギュレーションファイルと、インターネットプロトコル（ＩＰ）テーブルと、ルールとのうちの１つ以上と、
ユーザから受信されたネットワークトポロジーデータと、
を含む、
［Ｃ１６］に記載の一時的でないコンピュータ読み取り可能な記憶媒体。
［Ｃ１８］
前記１つ以上のフローパスを、データ記憶装置中に記憶することと、
前記複数のパーサのうちの少なくとも１つを使用して、前記ネットワークにおける少なくとも１つのネットワークデバイスに関連付けられている前記状態情報に対する変化を検出することと、
前記変化に基づいて、前記１つ以上のフローパスを更新することと、
前記更新された１つ以上のフローパスを、前記データ記憶装置中に記憶することと、
をさらに備える、［Ｃ１７］に記載の一時的でないコンピュータ読み取り可能な記憶媒体。
［Ｃ１９］
前記１つ以上のフローパスを、データ記憶装置の中に記憶することをさらに備え、
ネットワーク特徴を特定するために前記１つ以上のフローパスを解析することは、
少なくとも１つのネットワーク特性に基づいて、前記データ記憶装置に問い合わせることと、
前記問い合わせに応答して、前記データ記憶装置から、前記１つ以上のフローパスのサブセットを受信することと、
前記１つ以上のフローパスの前記サブセットを、少なくとも１つのネットワーク特性に関連付けられている少なくとも１つのルールと比較することと、
をさらに備える、
［Ｃ１７］に記載の一時的でないコンピュータ読み取り可能な記憶媒体。
［Ｃ２０］
前記１つ以上のフローパスのサブセットの前記少なくとも１つのルールとの前記比較に基づいて、報告を生成することをさらに備え、
前記報告は、１つ以上の提案されたネットワークコンフィギュレーション変更を含む、
［Ｃ１９］に記載の一時的でないコンピュータ読み取り可能な記憶媒体。
【図１】
0006419967.tif 000002
【図２】
0006419967.tif 000003
【図３】
0006419967.tif 000004
【図４】
0006419967.tif 000005
【図５】
0006419967.tif 000006
【図６】
0006419967.tif 000007
【図７】
0006419967.tif 000008