アベイラビリティ : ハイ アベイラビリティ

SNMP による OSPF の構成管理

2004 年 10 月 28 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2008 年 9 月 15 日) | フィードバック

目次

概要
OSPF の背景
プロセス定義
      プロセス オーナー
      プロセスの目的
      プロセス パフォーマンス インジケータ
      プロセスの入力
      プロセスの出力
タスク定義
      初期化タスク
      反復タスク
データの識別
      一般的なデータの特徴
      SNMP データの識別
      RMON データの識別
      Syslog データの識別
      Cisco IOS CLI データの識別
データの収集
      SNMP データ収集
      RMON データの収集
      Syslog データの収集
      Cisco IOS CLI データの収集
データ表示
      OSPF エリアのレポート
      OSPF インターフェイスのレポート
      OSPF 隣接ルータのレポート
商用および一般用のインターネット モニタリング ツール
SNMP ポーリング データ
データ収集アルゴリズムの例
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

Open Shortest Path First(OSPF)ルーティング プロトコルは、RFC 2328 OSPF Version 2 leavingcisco.comで定義されています。 この文書の目的は、OSPF の配備状態を OSPF 設計計画に照らし合わせて確認し、さらに OSPF の配備状態を定期的に監査して、意図した設計が長期にわたって維持されていることを確認するといった、設計管理手順の実装を可能にするための手順フレームワークを提供することです。

この文書では、ITU-T が定義した FCAPS(Fault、Configuration、Accounting/inventory、Performance、Security)モデルに基づいた構成管理機能に重点が置かれています。 構成管理は、ITU-T M.3400 によって、Network Element(NE; ネットワーク要素)の管理、識別、関連するデータの収集、データの出力などを実行する機能を備えるものとして定義されています。

この文書の内容は、次のセクションに分けて記載されています。

OSPF の背景」のセクションでは、OSPF の背景となる情報や、配備に関する重要な点など、技術的な情報を説明しています。

プロセス定義」セクションでは、OSPF 構成管理を実現するために使用するプロセス定義の概要について説明します。また、目的、パフォーマンス インジケータ、入力、出力、および個々のタスクという観点から、プロセスの詳細について説明します。

タスク定義」セクションでは、プロセス タスク定義について詳細に説明します。 タスクごとに、目的、タスクの入力、タスクの出力、タスクの実行に必要なリソース、およびタスクの実行に必要なジョブ スキルについて説明します。

データの識別」セクションでは、OSPF のデータ識別について説明します。 データの識別では、情報のソース、または情報の場所が考慮されます。 たとえば、情報はシステムによって、Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)の Management Information Base(MIB; 管理情報ベース)や、Syslog によって生成されるログ ファイル、または Command Line Interface(CLI; コマンド ライン インターフェイス)からしかアクセスできない内部データ構造などに格納されています。

この文書の「データの収集」セクションでは、OSPF データの収集について説明します。データの収集は、データの検索と近い関係にあります。たとえば、SNMP MIB のデータは、トラップ、Remote Monitoring(RMON)アラームおよびイベント、またはポーリングなど、さまざまなメカニズムによって収集されます。 内部データ構造内に格納されるデータは、自動スクリプトによって収集される場合と、ユーザが手動でシステムにログインして CLI コマンドを発行し、その出力を記録することによって収集される場合があります。

データ表示」セクションでは、データがレポート形式で表現されるしくみを示す例を紹介します。 データは識別および収集された後、分析されます。 この文書では、OSPF 構成データの記録や比較に使用できるレポートの例を紹介します。

商用および一般用のインターネット モニタリング ツール」、「SNMP ポーリング データ」、および「データ収集アルゴリズムの例」の各セクションでは、OSPF 構成管理手順を実装するためのツールの作成に関する情報を説明します。

OSPF の背景

OSPF は単一の自律システム内での使用を前提に設計された、内部ゲートウェイ プロトコルです。 OSPF では、リンクステートまたは shortest-path first(SPF; 最短パス優先)をベースとしたテクノロジーが使用されています。これに対し、Routing Information Protocol(RIP; ルーティング情報プロトコル)などのルーティング プロトコルでは、ディスタンスベクターや Bellman-Ford のテクノロジーが使用されています。 個々の link-state advertisement(LSA; リンクステート アドバタイズメント)では、自律システムの全体など、OSPF ルーティング ドメインを部分的に記述します。 このような LSA がルーティング ドメイン全体にフラッドされ、リンクステート データベースを形成します。 ドメイン内の各ルータでは、同一のリンクステート データベースが保持されます。 リンクステート データベースの同期は、信頼性の高いフラッディング アルゴリズムによって維持されています。 各ルータでは、このリンクステート データベースから最短パス ツリーが計算され、計算を行っているルータ自身をツリーのルートとしたルーティング テーブルが構築されます。 この計算は、一般には Dijkstra アルゴリズムと呼ばれています。

LSA は小さなものであり、各 LSA には OSPF ルーティング ドメインの小さな一部分が記述されています。具体的には、1 台のルータの隣接情報、1 つのトランジット ネットワークの隣接情報、1 つのエリア間ルート、または 1 つの外部ルートなどです。

次の表では、OSPF の主要な機能が説明されています。

機能

説明

隣接関係

OSPF ルータのペアが隣接関係になったとき、この 2 つのルータではデータベースのサマリーを OSPF データベース交換パケットの形式で交換し、それぞれのリンクステート データベースを同期させます。 その後、隣接関係ルータは、信頼性の高いフラッディング アルゴリズムを使用して、それぞれのリンクステート データベースの同期を維持します。 シリアル回線で接続されているルータは、常に隣接関係にあります。 マルチアクセス ネットワーク(イーサネット)では、そのネットワークに接続されているルータは、すべて designated router(DR; 代表ルータ)および backup designated router(BDR; バックアップ代表ルータ)の両方と隣接関係を持ちます。

代表ルータ

すべてのマルチアクセス ネットワークに対して 1 台の DR が選ばれている場合には、ネットワークのローカル環境を記述するネットワーク LSA がその代表ルータから発信されます。 また、代表ルータはフラッディング アルゴリズムにおいても特別な役割を持っています。フラッディング処理中、ネットワーク上のすべてのルータが代表ルータに対して LSA を送受信することにより、リンクステート データベースが同期されています。

バックアップ代表ルータ

現在の DR が消失した場合には、マルチアクセス ネットワーク上で BDR が選ばれ、DR の移行を速やかに行います。 BDR が処理を引き継いだ場合、その local-area network(LAN; ローカルエリア ネットワーク)で隣接関係処理を行う必要はありません。 また、DR の消失が通知される以前での DR 不在の状態でも、BDR により信頼性の高いフラッディング アルゴリズムが続行できます。

非ブロードキャスト
マルチアクセス
ネットワークのサポート

OSPF では、フレームリレーの public data network(PDN; 公衆データ網)などのネットワークが LAN のように扱われます。 ただし、これらのネットワークに接続しているルータが初めて相互に認識するためには、追加の構成情報が必要です。

OSPF 構成管理エリア

OSPF では、自律システムをエリアに分割できます。 これにより、さらに高いレベルのルーティング保護が行えるため、エリア内のルーティングはエリア外のすべての情報から保護されるようになります。 また、自律システムをエリアに分割することで、CPU サイクルの面で Dijkstra 処理の負担が軽減されます。

仮想リンク

OSPF では、仮想リンクの設定を可能にすることで、自律システムのエリアのレイアウトに関するトポロジ上の制限が解消されています。

ルーティング プロトコル交換の認証

OSPF ルータがルーティング プロトコルのパケットを受信するたびに、オプションで、そのパケットの処理を進める前に認証を行うことができます。

柔軟性に富んだ
ルーティング メトリック

OSPF では、発信ルータのインターフェイスにメトリックが割り当てられています。 そのパスのコンポーネント インターフェイスの合計が、パスのコストになります。 デフォルトでは、ルーティング メトリックはそのリンクの帯域幅から導かれます。 ルーティング メトリックは、遅延、帯域幅、およびコストなど、ネットワークの特性の任意の組み合わせを表すように、ネットワーク管理者によって割り当てられます。

等コスト マルチパス

1 つの宛先に対して最適コストの経路が複数ある場合、OSPF ではこれらを検出し、その宛先へのトラフィックの負荷分散に使用します。

可変長サブネットの
サポート

ネットワーク マスクとそれぞれのアドバタイズされる宛先を搬送することにより、可変長のサブネット マスクをサポートしています。

スタブ エリアのサポート

メモリ量が不十分なルータをサポートするために、エリアをスタブとして設定できます。 外部 LSA は、スタブ エリアへはフラッドされません。 スタブ エリアでの外部宛先へのルーティングは、完全にデフォルトがベースとなっています。

プロセス定義

プロセス定義とは、特定の目的を達成するためにエージェントによって実行される一連の動作、活動、および変更を意味します。

プロセス制御とは、プロセスを効果的かつ効率的に実行することを目的とした計画および調整の過程を意味します。

これを視覚的に表すと、次の図のようになります。

ospf_a.gif

プロセスの出力は、組織によって定義された運用基準と、ビジネス上の目的に準拠している必要があります。一連の基準に準拠しているプロセスは、反復、測定、および管理が可能であり、ビジネス上の目的の達成に貢献するため、効果的であると考えられます。また、最小限の労力で活動を実行できるプロセスは、効率的であると考えられます。

プロセス オーナー

プロセスは、組織内のさまざまな区分にまたがります。したがって、各プロセスの定義に関して責任を負うプロセス オーナーは 1 人だけにする必要があります。オーナーは、そのプロセスが効果的で効率的かどうかの判断および報告の中心になります。プロセスが効果的または効率的でない場合は、プロセス オーナーが中心となってそのプロセスを修正します。プロセスを修正する際には、変更管理とチェックの手順が原則となります。

プロセスの目的

プロセスの目的は、プロセス定義の方向性と範囲を定めるために設定されます。また、プロセスの効果を測定するための基準としても使用されます。

このプロセスの目的は、展開した OSPF 実装の構成を意図した設計に照らし合わせて検証するためのフレームワークを提供し、さらに OSPF の展開を定期的に監査して、意図した設計と長期にわたって整合性が保たれるようにするためのメカニズムを提供することです。

プロセス パフォーマンス インジケータ

プロセス パフォーマンス インジケータは、プロセス定義の効果を評価するために使用されます。パフォーマンス インジケータは、測定および定量化が可能な基準である必要があります。 次のパフォーマンス インジケータは、数値化されているか、あるいは時間で計測されます。 OSPF 構成管理プロセスのパフォーマンス インジケータは、次のように定義されています。

  • プロセス全体を一巡するために必要な時間の長さ

  • OSPF の問題を、ユーザに影響が及ぶ前に事前に発見するために必要な実施頻度

  • プロセスの実施に伴うネットワークの負荷

  • プロセスで推奨されている修正操作の数

  • プロセスの結果として実施された修正操作の数

  • 修正操作を実施するために必要な時間の長さ

  • 修正操作を実施するために必要な時間の長さ

  • 修正操作の未処理件数

  • OSPF 関連の問題に起因するダウンタイム

  • シード ファイル内で追加、削除、または修正された項目の数。これは、精度と安定性を示す指標になります。

プロセスの入力

プロセスの入力は、プロセスの基準と前提条件を定義するために使用されます。 プロセスの入力を確認することで、外的要因への依存性に関する情報がしばしば得られます。 OSPF 管理に関係する入力のリストを以下に示します。

  • OSPF 設計文書

  • SNMP ポーリングによって収集された OSPF MIB データ

  • syslog 情報

プロセスの出力

プロセスの出力は、次のように定義されます。

  • この文書の「データ表示」セクションで定義されている OSPF 設定レポート

  • 実行する修正処理のための OSPF 構成に関する推奨事項

タスク定義

以後のセクションでは、OSPF 管理に関係する初期化タスクおよび反復タスクについて説明します。

初期化タスク

初期化タスクは、そのプロセスの実施中に一回だけ実行します。そのプロセスを繰り返すたびに実行しないようにしてください。

必須タスクの確認

必須タスクの確認中に、いずれかのタスクが実施されていないことが判明した場合や、この手順のニーズを効果的に達成するための情報が十分に得られていないことが判明した場合は、プロセス オーナーがその事実を文書化して、管理者に提出する必要があります。次の表で、必須の初期化タスクを説明します。

必須タスク

説明

タスクの目的と入力

  1. OSPF 設計文書が存在し、ネットワーク設計文書の中に次の情報が明確に記されていることを確認します。

    1. エリアの定義 - 名前、アドレス範囲、およびエリアのタイプ

    2. エリア境界ルータおよび自律システム境界ルータ
      (ABR/ASBR)の識別

    3. DR/BDR の識別

    4. エリアに割り当てられているインターネット レジストリ(IR)
      ノードとインターフェイス

  2. SNMP 標準構成のテンプレートを使用して、ネットワークに SNMP が設定されていることを確認します。

    注:これは、後ほどシード ファイルを作成するための入力として使用します。 

  3. Syslog 標準構成のテンプレートを使用して、ネットワークに Syslog が展開されていることを確認します。

タスクの出力

タスクの出力は、必須タスクの条件に関するステータス レポートです。 サポートされているタスクのいずれかが効率的でないと思われる場合は、プロセス所有者が要求を発行し、サポートされているプロセスが更新されるようにします。 サポートされているプロセスを更新できない場合は、このプロセスへの影響について評価を行います。

タスクに関係する
役割

ネットワーク エンジニアのスキル セット

シード ファイルを作成する

OSPF 構成管理プロセスでは、ネットワーク検出機能の必要性を排除するために、シード ファイルを使用する必要があります。 シード ファイルには、OSPF プロセスによって管理されているルータのセットが記録されており、組織内の変更管理プロセスとの調整を行う際に中心的な役割を担います。 たとえば、ネットワークに新しいノードを追加した場合は、OSPF シード ファイルにそれらのノードを追加する必要があります。セキュリティ上の理由で SNMP コミュニティ名に変更を加えた場合は、それらの変更をシード ファイルに反映する必要があります。次の表で、シード ファイルの作成手順を説明します。

プロセス

説明

タスクの目的

OSPF 構成管理ソフトウェアを初期化するために使用するシード ファイルを作成します。 シード ファイルの形式は、OSPF 構成管理プロセスの実装に使用するリソースによって異なります。 カスタム スクリプトを
作成する場合は、シード ファイルの形式は、ソフトウェアの設計によって
決まります。 ネットワーク管理システム(NMS)を使用している場合は、
シード ファイルの形式は、NMS の文書によって定義されています。

タスクの入力

  1. シード ファイルの形式を決めます。

  2. OSPF 設計文書を参照して、次のデータについて調べます。

    • 全ノードの IP アドレス

    • SNMP コミュニティ ストリング

    • Telnet および CLI ログインのアカウントとパスワード

  3. ネットワーク変更管理プロセスをスケジュールし、名前を問い合せます。

タスクの出力

OSPF 構成管理プロセスのためのシード ファイル。

タスクのリソース

  • 商用 NMS システム

  • カスタム開発されたソフトウェア システム

  • 手動プロセス - 各ネットワーク要素にログインし、コマンド ラインを発行して、その出力を記録します。

タスクに関係する
役割

  • NMS - ネットワーク エンジニア、NMS 管理者、および NMS
    スクリプト のスキル セット。

  • カスタム スクリプト - ネットワーク エンジニアおよび NMS スクリ
    プト のスキル セット。

  • 手動プロセス ー ネットワーク エンジニア。

反復タスク

反復タスクは、プロセスを反復するたびに実行され、その頻度はパフォーマンス インジケータの改善を考慮して決定または変更されます。

シード ファイルを管理する

シード ファイルは、OSPF 管理プロセスを効果的に実施する上で、きわめて重要です。したがって、シード ファイルの現在の状態を積極的に管理する必要があります。 シード ファイルの内容に影響する変更がネットワークに加えられた場合は、OSPF 構成管理プロセスのオーナーがそれらの変更を記録する必要があります。

プロセス

説明

タスクの目的

  1. ネットワークの移動、追加、変更、およびネットワーク構成の変更を管理する組織的な機能を使用する追跡や、これらの機能との相互対話を通じて、現在のシード ファイルの有効性を維持します。

  2. シード ファイルに対するバージョン管理とバックアップ管理を行います。

タスクの入力

  1. 移動、追加、変更など、シード ファイルの内容に影響を及ぼすものに関する変更管理からの情報。

  2. シード ファイルの内容に影響を及ぼすエンジニアリングおよび設計からの情報。

タスクの出力

  1. 現在のシード ファイルの状態に関する週単位のレポート。

  2. シード ファイルのバックアップの場所と復元手順に関する定義と文書。

タスクのリソース

  • 商用 NMS システム

  • カスタム開発されたソフトウェア システム

  • 手動プロセス - 各ネットワーク要素にログインし、コマンド ラインを発行して、その出力を記録します。

タスクに関係する
役割

  • NMS - ネットワーク エンジニア、NMS 管理者、および NMS スクリプト のスキル セット。

  • カスタム スクリプト - ネットワーク エンジニアおよび NMS スクリプト のスキル セット。

  • 手動プロセス ー ネットワーク エンジニア。

OSPF スキャンの実行

OSPF スキャンの実行には、次の 2 つの手順が使用されます。

  1. データの収集。

  2. データの解析。

プロセスの使用方法によって、これら 2 つの手順の頻度が変わります。 たとえば、このプロセスをインストールの変更の確認に使用できますが、 この場合は、変更の前後にデータ収集を実行し、変更後にデータの解析を実行して、変更が正しく行われたかどうかを判断します。

このプロセスを OSPF 構成管理の設計記録を検証するために使用する場合は、データ収集と解析の頻度は、ネットワークで変更が行われる頻度によって変わります。 たとえば、ネットワーク上で行われる変更の数が非常に多い場合は、設計の検証を 1 週間に一回行います。 ネットワーク上での変更の数が非常に少ない場合は、設計の検証は 1 か月に一回行う程度で済みます。

OSPF レポートの検討

OSPF 構成管理レポートの形式は、OSPF 構成管理プロセスの実装に使用されるリソースによって異なります。 次の表では、カスタム開発されたレポートに対する推奨形式について説明しています。

レポート

形式

タスクの入力

OSPF 構成管理レポートについては、この文書の「データ表示」セクションを参照してください。

タスクの出力

スキャン レポートと論理設計レコードとの間で問題が見つかった場合は、どちらの項目が正しく、どちらの項目が誤っているか、判断を下す必要があります。 誤っている項目は修正します。 これには、設計レコードの変更やネットワークの変更順序が関係している場合があります。

タスクのリソース

  • 商用 NMS システム

  • カスタム開発されたソフトウェア システム

  • 手動 - 各ネットワーク要素にログインし、コマンド ラインを発行して、その出力を記録します。

タスクに関係する
役割

  • NMS - ネットワーク エンジニア、NMS 管理者、および NMS スクリプト のスキル セット。

  • カスタム スクリプト - ネットワーク エンジニアおよび NMS スクリプト のスキル セット。

  • 手動プロセス ー ネットワーク エンジニア。

データの識別

一般的なデータの特徴

次の表では、OSPF 構成管理に適用されるデータについて説明します。

データ

説明

OSPF エリア

ルータが接続されているエリア関する情報。次のものが含まれます。

  • エリア ID

  • エリア認証

  • SPF の実行

  • エリア内の ABR の数

  • エリア内の ASBR の数

  • エリア LSA カウント - エリア内のルータ全体の整合性

  • エリア LSA チェックサム - エリア内のルータ全体の整合性

  • アドレッシング エラーによるパケット廃棄の頻度(エリアごと)

  • ルーティング処理によるプロトコル パケットの廃棄の頻度
    (エリアごと)

  • no route found 状態によるルーテッド パケットの廃棄の頻度
    (エリアごと)

OSPF
インターフェイス

OSPF の観点から見たインターフェイスの説明。次の項目が含まれます。

  • IP address

  • エリア ID

  • 管理ステータス

  • このインターフェイスに割り当てられている OSPF メトリック

  • このインターフェイスに割り当てられている OSPF タイマー

  • OSPF の状態

OSPF 隣接ルータの状態

OSPF 隣接ルータの説明

  • 隣接ルータの ID

  • 隣接ルータの状態

  • 隣接ルータのイベント - 隣接関係の状態が変わるか、エラーが発生した回数

  • 隣接ルータの再送信キュー - 再送信キューの現在の長さ

SNMP データの識別

シスコでは、現在 RFC 1253 OSPF Version 2 MIB leavingcisco.com をサポートしています。 RFC 1253 には、OSPF に対する SNMP トラップの定義は含まれていません。 OSPF MIB の最新バージョンは、RFC 1850 OSPF Version 2 leavingcisco.com です。 SNMP トラップは、OSPF 用には RFC 1850 で定義されています。シスコの OSPF MIB の実装では、RFC 1850 はサポートされていません。

詳細については、この文書の「SNMP ポーリング データ」のセクションを参照してください。

プラットフォームおよびコードバージョンでサポートされている MIB に関する詳細なリストについては、『Cisco ネットワーク管理用ソフトウェア』のページを参照してください。

RMON データの識別

この手順で必要な RMON 特有のデータはありません。

Syslog データの識別

一般的には、syslog によって、各種のテクノロジーに対するサービス固有のメッセージが生成されます。 syslog 情報は障害やパフォーマンスの管理に適していますが、ここで提供される情報は参照用です。 シスコ デバイスで生成された OSPF Syslog 情報の例については、『OSPF のエラー メッセージ』を参照してください。

ファシリティによるシステム メッセージの詳細なリストについては、『メッセージおよび回復手順』を参照してください。

Cisco IOS CLI データの識別

OSPF 構成管理手順のこのバージョンでは、CLI データは必要ありません。

データの収集

SNMP データ収集

次の表では、SNMP データの収集に関する各種のコンポーネントについて説明します。

SNMP データの
コンポーネント

定義

一般的な SNMP 設定

SNMP 設定のベスト プラクティスに関する一般的な情報については、『SNMP の設定』を参照してください。

サービスに特定の SNMP 設定

この手順で必要なサービス特定の SNMP 設定はありません。

SNMP MIB の要件

前述の「データの識別」セクションを参照してください。

SNMP MIB ポーリングの収集

SNMP でポールされたデータは、hp OpenView leavingcisco.com のような商用システムか、カスタム スクリプトによって収集されます。 収集アルゴリズムの詳細については、この文書の「データ収集アルゴリズムの例」の
セクションを参照してください。

SNMP MIB トラップの
収集

シスコ デバイスで現在サポートしている OSPF MIB のバージョンでは、SNMP トラップはサポートされていません。 この手順で必要な SNMP トラップはありません。

RMON データの収集

この手順の現在のバージョンでは、RMON 設定とデータは必要ありません。

Syslog データの収集

一般的な syslog 設定のガイドラインは、この文書の対象範囲外です。 詳細については、『単一の内部ネットワークでの Cisco Secure PIX Firewall の設定とトラブルシューティング』を参照してください。

OSPF 特有の要件は、次のコマンドを使用して、隣接ルータの変更を syslog メッセージとともに記録するように OSPF ルータを設定することで対応できます。

OSPF_ROUTER(config)# ospf log-adj-changes

Cisco IOS CLI データの収集

一般的に見て、Cisco IOS CLI は、NE によって蓄積された未加工の情報に最も直接的にアクセスできる機能を備えています。 しかし、CLI によるアクセスは、この手順で定義されているグローバルな構成管理よりも、トラブルシューティングや変更管理の処理の方に適しています。 CLI によるアクセスは、大規模なネットワークの管理には適していません。 その場合は自動情報アクセスが必要になります。

OSPF 構成管理手順のこのバージョンでは、CLI の設定やデータは必要ありません。

データ表示

OSPF エリアのレポート

OSPF エリアのレポートの形式の例を次に示します。 このレポートの形式は、いずれかの商用 NMS が使用されていればその機能によって、あるいはカスタム スクリプトで設計されている出力によって決まります。

エリア

データ フィールド

直前の実行

今回の実行

エリア ID #1

認証

   

SPF の実行

   

ABR の数

   

ASBR の数

   

LSA の数

   

LSA のチェックサム

   

アドレス エラー

   

ルーティングの破棄

   

ルートが見つからない

   

エリア ID #n

認証

   

SPF の実行

   

ABR の数

   

ASBR の数

   

LSA の数

   

LSA のチェックサム

   

アドレス エラー

   

ルーティングの破棄

   

ルートが見つからない

   

OSPF インターフェイスのレポート

OSPF インターフェイスのレポートの形式の例を次に示します。 実際には、このレポートの形式は、いずれかの商用 NMS が使用されていればその機能によって、あるいはカスタム スクリプトで設計されている出力によって決まります。

エリア

デバイス

インターフェイス

データ フィールド

直前の実行

今回の実行

エリア ID #1

ノード ID #1

インターフェイス ID #1

IP アドレス

   

エリア ID

   

管理状態

   

OSPF の状態

   

メトリック/コスト/タイマー

   

インターフェイス ID #n

IP アドレス

   

エリア ID

   

管理状態

   

OSPF の状態

   

メトリック/コスト/タイマー

   

ノード ID #n

インターフェイス ID #1

IP アドレス

   

エリア ID

   

管理状態

   

OSPF の状態

   

メトリック/コスト/タイマー

   

インターフェイス ID #n

IP アドレス

   

エリア ID

   

管理状態

   

OSPF の状態

   

メトリック/コスト/タイマー

   

エリア ID #n

ノード ID #1

インターフェイス ID #1

IP アドレス

   

エリア ID

   

管理状態

   

OSPF の状態

   

メトリック/コスト/タイマー

   

インターフェイス ID #n

IP アドレス

   

エリア ID

   

管理状態

   

OSPF の状態

   

メトリック/コスト/タイマー

   

ノード ID #n

インターフェイス ID #1

IP アドレス

   

エリア ID

   

管理状態

   

OSPF の状態

   

メトリック/コスト/タイマー

   

インターフェイス ID #n

IP アドレス

   

エリア ID

   

管理状態

   

OSPF の状態

   

メトリック/コスト/タイマー

   

OSPF 隣接ルータのレポート

OSPF 隣接ルータのレポートの形式の例を次に示します。 実際には、このレポートの形式は、いずれかの商用 NMS が使用されていればその機能によって、あるいはカスタム スクリプトで設計されている出力によって決まります。

エリア

デバイス

隣接ルータ

データ フィールド

直前の実行

今回の実行

エリア ID #1

ノード ID #1

隣接ルータ ID #1

ルータ ID

   

ルータの IP アドレス

   

状態

   

イベント

   

再送信キュー

   

隣接ルータ ID #n

ルータ ID

   

ルータの IP アドレス

   

状態

   

イベント

   

再送信キュー

   

ノード ID #n

隣接ルータ ID #1

ルータ ID

   

ルータの IP アドレス

   

状態

   

イベント

   

再送信キュー

   

隣接ルータ ID #n

ルータ ID

   

ルータの IP アドレス

   

状態

   

イベント

   

再送信キュー

   

エリア ID #n

ノード ID #1

隣接ルータ ID #1

ルータ ID

   

ルータの IP アドレス

   

状態

   

イベント

   

再送信キュー

   

隣接ルータ ID #n

ルータ ID

   

ルータの IP アドレス

   

状態

   

イベント

   

再送信キュー

   

ノード ID #n

隣接ルータ ID #1

ルータ ID

   

ルータの IP アドレス

   

状態

   

イベント

   

再送信キュー

   

隣接ルータ ID #n

ルータ ID

   

ルータの IP アドレス

   

状態

   

イベント

   

再送信キュー

   

商用および一般用のインターネット モニタリング ツール

商用ツールの目的は、syslog 情報の収集と処理を支援することと、一般的な SNMP MIB 変数のポーリングを収集することです。

この手順で定義した OSPF 構成管理をサポートする商用または一般的なインターネット監視ツールは見当たりません。 したがって、ローカルなカスタム スクリプトや手順が必要になります。

SNMP ポーリング データ

ルート テーブル RFC 1213 leavingcisco.com

オブジェクト名

オブジェクトの説明

ipRouteDest

ルートの宛先 IP アドレス。 0.0.0.0 の値を持つエントリは、デフォルト ルートと見なされます。 1 つの宛先への複数のルートをテーブルに表すことができますが、そのような複数のエントリへのアクセスは、使用しているネットワーク管理プロトコルによって定義されるテーブルアクセスのメカニズムに依存しています。

::= { ipRouteEntry 1 }

オブジェクト識別子 = 1.3.6.1.2.1.4.21.1.1

ipRouteMask

ipRouteDest フィールドの値と比較する前に、宛先アドレスに対して論理的に適用するマスクを示します。 任意のサブネット マスクをサポートしていないシステムの場合は、エージェントによって、対応する ipRouteDest フィールドの値がクラス A、B、C のネットワークのいずれに属するかによって、ipRouteMask の値を設定します。このとき、次のマスク ネットワークのいずれかを使用します。

  • Class A = 255.0.0.0

  • Class B = 255.255.0.0

  • Class C = 255.255.255.0

ipRouteDest の値が 0.0.0.0、つまりデフォルト ルートの場合は、マスク値も 0.0.0.0 になります。

注:IP ルーティングのサブシステムは、すべて暗黙的にこのメカニズムを使用しています。 

::= { ipRouteEntry 11 }

オブジェクト識別子 = 1.3.6.1.2.1.4.21.1.11

ipRouteNextHop

このルートのネクスト ホップの IP アドレス。 ブロードキャスト メディアで実現されているインターフェイスへのルート境界の場合は、このフィールドの値はそのインターフェイスのエージェントの IP アドレスになります。

::= { ipRouteEntry 7 }

オブジェクト識別子 = 1.3.6.1.2.1.4.21.1.7

ipRouteIfIndex

このルートのネクスト ホップへ到達するために通過するローカル インターフェイスを一意に識別するインデックス値。 このインターフェイスは、IfIndex の値で識別されるインターフェイスと同一です。

::= { ipRouteEntry 2 }

オブジェクト識別子 = 1.3.6.1.2.1.4.21.1.2

RFC 1213 の各種オブジェクト

オブジェクト名

オブジェクトの説明

ipAdEntIfIndex

このエントリに適用できるインターフェイスを一意に識別するインデックス値。 このインターフェイスは、IfIndex の値で識別されるインターフェイスと同一です。

::= { ipAddrEntry 2 }

オブジェクト識別子 = 1.3.6.1.2.1.4.20.1.2

ipInAddrErrors

IP ヘッダー内の IP アドレスがエンティティに対して誤った宛先フィールドであったために廃棄された入力データグラムの数。 この数には、無効なアドレス(0.0.0.0)およびサポートされていないクラス アドレス(クラス E)も含まれます。 IP ゲートウェイでなく、データグラムを転送しないエンティティの場合、このカウンタには宛先アドレスがローカル アドレスでないために廃棄されたデータグラムが含まれます。

{ ip 5 }

オブジェクト識別子 = 1.3.6.1.2.1.4.5

ipRoutingDiscards

廃棄された有効なルーティング エントリの数。 このようなエントリを廃棄する理由の 1 つとして、他のルーティングエントリのためにバッファ領域を解放することが考えられます。

{ ip 23 }

オブジェクト識別子 = 1.3.6.1.2.1.4.23

ipOutNoRoutes

宛先に転送するためのルートが見つからなかったために廃棄された IP データグラムの数。

{ ip 12 }

オブジェクト識別子 = 1.3.6.1.2.1.4.12

RFC 1253 leavingcisco.comOSPF エリア テーブル

オブジェクト名

オブジェクトの説明

ospfAreaID

エリアを一意に識別する 32 ビットの整数。 エリア ID 0.0.0.0 は、OSPF バックボーン用に使用されます。

::= { ospfAreaEntry 1 }

オブジェクト識別子 = 1.3.6.1.2.1.14.2.1.1

ospfAuthType

このエリアに対して指定された認証タイプ。 追加の認証タイプは、エリアごとにローカルに割り当てることができます。 デフォルト値は 0 です。

::= { ospfAreaEntry 2 }

オブジェクト識別子 = 1.3.6.1.2.1.14.2.1.2

OspfSpfRuns

エリア内のルート テーブルが、このエリアのリンクステート データベースを使用して計算された回数。

オブジェクト識別子 = 1.3.6.1.2.1.14.2.1.4

ospfAreaBdrRtrCount

このエリア内で到達可能な ABR の数。 この値は最初はデフォルト値の 0 であり、SPF 転送ごとに計算されます。

::= { ospfAreaEntry 5 }

オブジェクト識別子 = 1.3.6.1.2.1.14.2.1.5

ospfASBdrRtrCount

このエリア内で到達可能な ABSR の数。 この値は最初はデフォルト値の 0 であり、SPF 転送ごとに計算されます。

::= { ospfAreaEntry 6 }

オブジェクト識別子 = 1.3.6.1.2.1.14.2.1.6

ospfAreaLSACount

エリアのリンクステート データベース内の LSA の合計数。外部 LSA は含まれません。 デフォルト値は 0 です。

::= { ospfAreaEntry 7 }

オブジェクト識別子 = 1.3.6.1.2.1.14.2.1.7

ospfAreaLSACksumSum

エリアのリンクステート データベースに含まれる LSA の LS チェックサムの合計を表す 32 ビット符号なしの値。 この合計値には外部(LS タイプ 5)の LSA は含まれません。 この合計値は、ルータのリンクステート データベースに変更があったかどうかを判断するためと、2 台のルータのリンクステート データベースを比較するために使用されます。 デフォルト値は 0 です。

::= { ospfAreaEntry 8 }

オブジェクト識別子 = 1.3.6.1.2.1.14.2.1.8

RFC 1253 OSPF インターフェイス テーブル

オブジェクト名

オブジェクトの説明

OspfIfIpAddress

OSPF インターフェイスの IP アドレス。

オブジェクト識別子 = 1.3.6.1.2.1.14.7.1.1

OspfIfEvents

OSPF インターフェイスの状態が変わるか、エラーが発生した回数

オブジェクト識別子 = 1.3.6.1.2.1.14.7.1.15

OspfIfState

OSPF インターフェイスの状態。

オブジェクト識別子 = 1.3.6.1.2.1.14.7.1.12

RFC 1253 OSPF 隣接ルータ テーブル

オブジェクト名

オブジェクトの説明

OspfNbrIpAddr

この隣接ルータの IP アドレス。

::= { ospfNbrEntry 1 }

オブジェクト識別子 = 1.3.6.1.2.1.14.10.1.1

ospfNbrAddressLessIndex

インターネットの標準 MIB で、IP アドレスを持たないインデックスに対する IfIndex の値。 列を作成するときに、そのインスタンスから得ることができます。

::= { ospfNbrEntry 2 }

オブジェクト識別子 = 1.3.6.1.2.1.14.10.1.2

ospfNbrRtrId

IpAddress として表現される 32 ビットの整数で、自律システム内の隣接ルータを一意に識別します。 デフォルト値は 0.0.0.0 です。

::= { ospfNbrEntry 3 }

オブジェクト識別子 = 1.3.6.1.2.1.14.10.1.3

ospfNbrState

隣接ルータとの関係の状態。 状態には次のものがあります。

  • down (1)

  • attempt (2)

  • init (3)

  • twoWay (4)

  • exchangeStart (5)

  • exchange (6)

  • loading (7)

  • full (8)

::= { ospfNbrEntry 6 }

オブジェクト識別子 = 1.3.6.1.2.1.14.10.1.6

ospfNbrEvents

隣接関係の状態が変わるか、エラーが発生した回数 デフォルト値は 0 です。

::= { ospfNbrEntry 7 }

オブジェクト識別子 = 1.3.6.1.2.1.14.10.1.7

ospfNbrLSRetransQLen

再送信キューの現在の長さ。 デフォルト値は 0 です。

::= { ospfNbrEntry 8 }

オブジェクト識別子 = 1.3.6.1.2.1.14.10.1.8

データ収集アルゴリズムの例

この文書での調査中に、プロトタイプの C プログラムが作成されました。 このプログラムは oscan といい、作成には Microsoft Developer Studio 97 と Visual C++ バージョン 5.0 を使用しています。 SNMP 関数 API を提供する 2 種類のライブラリが用意されています。 ライブラリ名は snmpapi.lib および mgmtapi.lib です。

Microsoft の API で提供される関数は、3 つの大きなカテゴリにグループ化されています。次の表に一覧を掲載します。

エージェント関数

マネージャ関数

ユーティリティ関数

SnmpExtensionInit

SnmpExtensionInitEx

SnmpExtensionQuery

SnmpExtensionTrap

SnmpMgrClose

SnmpMgrGetTrap

SnmpMgrOidToStr

SnmpMgrOpen

SnmpMgrRequest

SnmpMgrStrToOid

SnmpMgrTrapListen

SnmpUtilMemAlloc

SnmpUtilMemFree

SnmpUtilMemReAlloc

SnmpUtilOidAppend

SnmpUtilOidCmp

SnmpUtilOidCpy

SnmpUtilOidFree

SnmpUtilOidNCmp

SnmpUtilPrintAsnAny

SnmpUtilVarBindCpy

SnmpUtilVarBindListCpy

SnmpUtilVarBindFree

SnmpUtilVarBindListFree

この oscan プロトタイプ コードでは、次に示す関数に Microsoft の API がカプセル化されています。

  • snmpWalkStrOid

  • snmpWalkAsnOid

  • snmpWalkVarBind

  • snmpWalkVarBindList

これらの関数は、OSPF 設定データを維持するために使用する各種の SNMP MIB テーブルにアクセスできるようにするための、一般的な API を提供しています。 アクセスされるテーブルの object identifier(OID; オブジェクト識別子)は、テーブル固有のコール バック関数を使用して oscan の API に渡されます。 コール バック関数は、テーブルから返されたデータを処理する機能を備えています。

メイン ルーチン

最初のタスクは、oscan プログラムの対象となるノードの一覧を作成することです。 「デバイスの検出」に関する問題を回避するには、スキャンするノードを識別するためのシード ファイルが必要です。 シード ファイルは、IP アドレスや SNMP 読み取り専用コミュニティ ストリングのような情報を提供します。

oscan プログラムでは、ルータによって収集された SNMP 情報を保存するために、いくつかの内部データ構造を保持する必要があります。 一般的には、収集されたそれぞれの SNMP MIB テーブル用に内部データ構造を用意します。

Main
  	load node array based on information in the seed file.
  	while more entries in the node array
  		start SNMP session for this node
  		collect IP route table for this node
  		collect OSPF area table for this node
  		collect OSPF Neighbor table for this node
  		collect  sysName for this node
  		collect OSPF Interface table for this node
  		end SNMP session for this node
  	end while
  

IP ルート テーブル

SNMP を使用して IP ルート テーブルにアクセスする際には、この処理の際にルータの CPU が過負荷になりやすいので注意が必要です。 このため、oscan プログラムではユーザ設定が可能な遅延パラメータを使用しています。 このパラメータでは、各 SNMP 要求の間の遅延を設定できます。 しかし、大規模な環境の場合には、これにより情報の収集にかかる全体の時間が、非常に長くなる場合があります。

ルート テーブルには、oscan に関係する 4 つの情報があります。

  • ipRouteDest

  • ipRouteMask

  • ipRouteNextHop

  • ipRouteIfIndex

ルート テーブルを指し示すインデックスとなるのは、ipRouteDest です。 したがって、SNMP の get-request から返された各オブジェクトには、ipRouteDest が OID に付加されています。

ipRouteIfIndex オブジェクトは、IP アドレス テーブル(ipAddrTable)の指示するインデックスとなる整数値です。 ipAddrTable は、ipAdEntAddr オブジェクト(そのインターフェイスの IP アドレス)をインデックスとして指示されます。 インターフェイスの IP アドレスを取得するには、次の 4 段階の処理が必要です。

  1. ルーティング テーブルから ipRouteIfIndex を収集する。

  2. ipRouteIfIndex を使用して ipAddrTable にアクセスし、パターン マッチングを行う。

  3. パターンが見つかったら、OID をストリングに変換し、そのインターフェイスの IP アドレスとなるドットで分割された 10 進数の最後の 4 つのフィールドを収集する。

  4. インターフェイスの IP アドレスを IP ルート テーブルに戻す。

IP ルート テーブルにアクセスするための一般的なアルゴリズムを次に示します。 このとき、ipRouteIfIndex の整数値だけが保存されます。 この処理の後の方で、インターフェイス情報を収集するとき、ipAddrTable にアクセスが行われ、残りの情報が収集されて、内部 IP ルート テーブルに配置されます。

OID List =
  	ipRouteDestOID,
  	ipRouteMaskOID,
  	ipRouteNextHopOID,
  	ipRouteIfIndexOID;
  For each object returned by  SNMP route table walk
  	Sleep // user configurable polling delay.
  	check varbind oid against OID list
  	if OID is ipRouteDestOID
  		add new entry in the internal route table array
  	if OID is one of the others
  		search internal route array for matching index value
  		store information in array
  

収集された情報は、次のように、今までにも馴染みのあるルータの CLI からの出力に似た表で表現されます。

ROUTE TABLE
  **********************************************************
  Destination     Mask                GW              Interface       
  10.10.10.4      255.255.255.252     10.10.10.5      10.10.10.5      
  10.10.10.16     255.255.255.252     10.10.10.6      10.10.10.5      
  10.10.10.24     255.255.255.252     10.10.10.25     10.10.10.25     
  10.10.10.28     255.255.255.252     10.10.11.2      10.10.11.1      
  10.10.10.36     255.255.255.252     10.10.10.6      10.10.10.5      
  10.10.11.0      255.255.255.0       10.10.11.1      10.10.11.1      
  10.10.13.0      255.255.255.0       10.10.11.2      10.10.11.1 

OSPF エリア テーブル

OSPF エリア テーブルからの情報の収集は、OSPF エリア テーブル(ospfAreaTable)のスキャンと、返されたデータを処理することによって行われます。 ospfAreaTable を指し示すインデックスとなるのは osfpAreaId です。 ospfAreaId は、IP アドレスと同様の、ドットで区分された 10 進数の形式で保存されます。 したがって、ipRouteTable と ipRouteIfIndex を処理および検索するためのサブルーチンと同じサブルーチンをここで再利用できます。

このセクションには、実際には OSPF エリア テーブルには含まれていないデータ アイテムがいくつかあります。 たとえば、ipInAddrErrors、IpRoutingDiscards、および ipOutNoRoute オブジェクトは、MIB-2 の定義に含まれていますが、OSPF エリアとは関連がありません。 これらのオブジェクトは、ルータに関連するものです。 したがって、これらのカウンタは、エリアの各ノードの値をエリア カウンタに追加することによって、エリアのメトリックとして使用されます。 たとえば、OSPF エリア レポートでは、ルートが見つからないために廃棄されたパケットの数は、実際には、そのエリア内の全ルータで廃棄されたパケットの合計数になります。 これはエリア内のルーティングの状態の概要を提供する、高度なレベルのメトリックになります。

OID List =
  	ipInAddrErrorsOID,
  	ipRoutingDiscardsOID,
  	ipOutNoRouteOID,
  	areaIdOID,
  	authTypeOID,
  	spfRunsOID,
  	abrCountOID,
  	asbrCountOID,
  	lsaCountOID,
  	lsaCksumSumOID;
  	For object returned from the SNMP walk of  the Area Table
  		Sleep // user configurable polling delay.
  		check varbind oid against OID list.
  		if OID is ospfAreaId
  			add new entry in the internal route table array
  		if OID one of the others
  			search internal array for matching index value
  			store information in array
  	end of for loop
  	get ipInAddrErrors, ipRoutingDiscards, ipOutNoRoute
  	add values to overall Area counters
  

収集された情報は、次の ASCII 形式の表で表現されます

AREAS
  **********************************************************
  AREA = 0.0.0.0			AREA = 0.0.0.2
  authType = 0			authType = 0
  spfRuns = 38			spfRuns = 18
  abrCount = 2			abrCount = 1
  asbrCount = 0			asbrCount = 0
  lsaCount = 11			lsaCount = 7
  lsaCksumSum = 340985		lsaCksumSum = 319204
  ipInAddrErrors = 0		   ipInAddrErrors = 0
  ipRoutingDiscards = 0		ipRoutingDiscards = 0
  ipOutNoRoutes = 0		ipOutNoRoutes = 0
  

OSPF 隣接ルータ テーブル

隣接ルータ テーブルのインデックスには、次の 2 つの値があります。

  • ospfNbrIpAddr - ospfNbrIpAddr は、隣接ルータの IP アドレスです。

  • ospfNbrAddressLessIndex - ospfNbrAddressLessIndex は、次の 2 つの値のいずれかになります。

    • IP アドレスが割り当てられているインターフェイスの場合は 0。

    • IP アドレスが割り当てられていないインターフェイスの場合は、インターネットの標準 MIB から IfIndex として変換された値。

このインデックスには 2 つの値があるため、これより前に使用した、返された OID に追加情報を付加するためのアルゴリズムを調整する必要があります。 調整を行った後、ipRouteTable と ipRouteIfIndex を処理および検索するためのサブルーチンと同じサブルーチンをここで再利用できます。

OID List =
  	ospfNbrIpAddrOID,
  	ospfNbrAddressLessIndexOID,
  	ospfNbrRtrIdOID,
  	ospfNbrStateOID,
  	ospfNbrEventsOID,
  	ospfNbrLSRetransQLenOID,
  	For object returned from the SNMP walk of the Neighbor Table
  		Sleep // user configurable polling delay.
  		check varbind OID against OID list.
  		if OID matches ospfNbrIpAddr
  			add new entry in the internal neighbor table array
  		if OID matches one of the others
  			search array for matching index value
  			store information in array

収集された情報は、次の ASCII 形式の表で表現されます

NEIGHBORS
  ************************************************************
  NEIGHBOR #0				NEIGHBOR #1
  Nbr Ip Addr = 10.10.10.6		Nbr Ip Addr = 10.10.11.2
  Nbr Rtr Id = 10.10.10.17		Nbr Rtr Id = 10.10.10.29
  Nbr State = 8				Nbr State = 8
  Nbr Events = 6				Nbr Events = 30
  Nbr Retrans = 0				Nbr Retrans = 0

関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 15408