この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、Cisco ONS 15454 に実装されている Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)について説明します。
SNMP のセットアップの詳細については、『 Cisco ONS 15454 Procedure Guide 』を参照してください。
SNMP は、ONS 15454 ネットワーク装置による、システム内またはネットワーク外の他の装置との管理情報の交換を可能にするアプリケーション層の通信プロトコルです。ネットワーク管理者は、SNMP を使用して、ネットワーク パフォーマンスの管理、ネットワークの問題の発見と解決、およびネットワーク拡張計画を行うことができます。
ONS 15454 では SNMP を使用して Network Management System(NMS; ネットワーク管理システム)に非同期のイベント通知を行います。ONS SNMP の実装では、標準の Internet Engineering Task Force(IETF; インターネット技術特別調査委員会)Management Information Bases(MIB; 管理情報ベース)を使用して、DS-1、DS-3、SONET、およびイーサネット技術の一般的な読み取り専用管理のための、ノード レベルのインベントリ、障害、パフォーマンス管理情報を伝達します。SNMP により、HP OpenView Network Node Manager(NNM)または Open Systems Interconnection(OSI; オープン システム相互接続)NetExpert などの汎用 SNMP マネージャを使用して、ONS 15454 SDH の一定の管理が可能になります。
Cisco ONS 15454は、SNMP バージョン 1(SNMPv1)と SNMP バージョン 2c(SNMPv2c)をサポートします。これらのバージョンでも多くの機能が同じように使用できますが、SNMPv2c ではさらにいくつかのプロトコル動作が追加されており、64 ビット パフォーマンス モニタリング機能をサポートします。この章では、この 2 つのバージョンについて説明し、ONS 15454 での SNMP の設定方法を説明します。
(注) CiscoV2 ディレクトリの CERENT-MSDWDM-MIB.mib、CERENT-FC-MIB.mib、および
CERENT-GENERIC-PM-MIB.mib は、64 ビットの Performance Monitoring(PM; パフォーマンス モニタリング)カウンタをサポートします。CiscoV1 ディレクトリの SNMPv1 MIB は 64 ビットのパフォーマンス モニタリング カウントを含んでいませんが、64 ビット カウンタに対応する、より低いワード値とより高いワード値をサポートします。CiscoV1 および CiscoV2 ディレクトリのその他の MIB ファイルは、内容は同一であり、形式だけが異なります。
図6-1 に、SNMP によって管理される基本的なネットワークを示します。
SNMP で管理するネットワークは、主に、管理システム、エージェント、および管理対象装置で構成されます。
HP OpenView などの管理システムは、管理対象装置を監視し制御するアプリケーションを実行します。管理システムには、ネットワーク管理に必要な処理機能とメモリが備わっています。1 つ以上の管理システムが管理対象ネットワーク上で動作している必要があります。図6-2に、ネットワーク管理者、SNMP エージェントおよび管理対象装置の関係を示します。
各管理対象装置に常駐するエージェント(SNMP)は、管理情報をローカルで認識し、この情報を SNMP と互換性のある形式に変換します。図6-3 に、ネットワーク管理ソフトウェアにデータを転送する SNMP エージェントの get-request 動作を示します。
図6-3 MIB からデータを収集しトラップをマネージャに送信する SNMP エージェント
SNMP エージェントは、装置パラメータとネットワーク データのリポジトリである MIB から、またはエラーや変更などのトラップからデータを収集します。
管理要素には、ルータ、アクセス サーバ、スイッチ、ブリッジ、ハブ、コンピュータ ホスト、または ONS 15454 などのネットワーク要素があり、SNMP エージェントを介してアクセスされます。管理対象装置では、管理情報を収集、保管し、SNMP を使って、これらの情報を、SNMP を使用する管理システムで利用できるようにします。
すべての SNMP 要求はサードパーティのアプリケーションから発生するので、サードパーティの SNMP クライアント アプリケーションが etherStatsHighCapacityTable、
etherHistoryHighCapacityTable、または mediaIndependentTable の RFC 3273 SNMP MIB 変数をアップロードできることが唯一の外部インターフェイス条件です。
ONS 15454 は、SNMPv1 および SNMPv2c の trap 要求と get 要求をサポートします。ONS 15454 の SNMP MIB では、アラーム、トラップ、状態を定義します。SNMP を介して、NMS アプリケーションは、サポートされている MIB を使用して、イーサネット スイッチや SONET マルチプレクサのような機能エンティティからのデータを管理エージェントに問い合わせます。
(注) CiscoV1 および CiscoV2 ディレクトリにある ONS 15454 MIB ファイルは、64 ビットの PM 機能を除いて、内容的には同一です。CiscoV2 ディレクトリには、64 ビットの PM カウンタを含む 3 つの MIB があります。すなわち、CERENT-MSDWDM-MIB.mib、CERENT-FC-MIB.mib、および
CERENT-GENERIC-PM-MIB.mib です。CiscoV1 ディレクトリには 64 ビットの PM カウンタはありませんが、64 ビット カウンタで使用される、より低いワード値とより高いワード値をサポートします。2 つのディレクトリは、異なったフォーマットになっています。
ONS 15454 SNMP エージェントは、SNMP メッセージを使用して SNMP 管理アプリケーションと情報をやり取りします。これらのメッセージを 表6-1 に示します。
6.6.1 に、ONS 15454 で実装される IETF 標準 MIB とそれらのコンパイル順序を示します。 6.6.2 では、ONS 15454 の独自 MIB とそれらのコンパイル順序を示します。 6.6.3 では、ネットワークに含まれているネットワーク要素(NE)の監視に使用できる汎用スレッシュホールドおよび PM MIB について説明します。
表6-2 に、ONS 15454 SNMP エージェントに実装された IETF 標準 MIB の一覧を示します。
まず、表6-2 の MIB をコンパイルしてください。次に、表6-3 の MIB をコンパイルしてください。
|
|
|
---|---|---|
Management of TCP/IP-based Internets: MIB-II |
||
Definitions of Managed Objects for Bridges |
||
Definitions of Managed Objects for the Ethernet-like Interface Types |
||
Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals |
||
Definitions of Managed Objects for the DS1, E1, DS2 and E2 Interface Types |
||
Definitions of Managed Objects for the SONET/SDH Interface Type |
||
Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions |
||
リモートのモニタリング装置を管理する MIB モジュールで、RFC 2819 と RFC 1513 に定義されている RMON MIB と RFC 2021 に定義されている RMON-2 MIB を増加させます。 |
各 ONS 15454 には、適用可能な独自 MIB が収録されたソフトウェア CD が付属しています。 表6-3 に、ONS 15454 の独自 MIB を示します。
|
|
---|---|
(注) 独自 MIB を正しくコンパイルできない場合は、製品をお買い上げの弊社販売代理店にお問い合わせください。
(注) SNMP で波長が不明であることを示している場合は、そのカード(MXP_2.5G_10E、TXP_MR_10E、MXP_2.5G_10G、TXP_MR_10G、TXP_MR_2.5G、または TXPP_MR_2.5G)が最初に調整可能な波長で動作することを意味します。MXP および TXP カードのトラブルシューティングについては、『Cisco ONS 15454 DWDM Installation and Operations Guide』を参照してください。
リリース 6.0 では、CERENT-GENERIC-PM-MIB という名前の新しい MIB により、ネットワーク管理ステーション(NMS)で単一の汎用 MIB を使用して、さまざまなインターフェイス タイプのスレッシュホールドと PM データにアクセスすることができます。この MIB は、特定の種類のインターフェイスに限定されないという意味で汎用です。MIB オブジェクトを使用して、近端および遠端の各種のモニタとサポートされる任意の間隔で、スレッシュホールド、現在の PM カウント、および PM 履歴統計を入手することができます。
ONS 15454 システムに以前からある MIB は、これらのカウントの一部を備えています。たとえば、SONET インターフェイスの 15 分ごとの現在 PM カウントと PM 履歴統計は、SONET-MIB を使用して入手できます。DS-1 および DS-3 のカウントと統計は、それぞれ DS1-MIB と DS-3 MIB から入手できます。汎用 MIB は、これらのタイプの情報を提供し、スレッシュホールドと 1 日間の統計もフェッチします。さらに、この MIB は、光および高密度波長分割多重(DWDM)のスレッシュホールドと PM 情報もサポートします。
CERENT-GENERIC-PM-MIB は、3 つのテーブルで構成されます。
• cerentGenericPmThresholdTable
• cerentGenericPmStatsCurrentTable
• cerentGenericPmStatsIntervalTable
cerentGenericPmThresholdTable は、モニタ タイプのスレッシュホールドの取得に使用されます。インターフェイス インデックス(cerentGenericPmThresholdIndex)、モニタ タイプ
(cerentGenericPmThresholdMonType)、場所(cerentGenericPmThresholdLocation)、および時間
(cerentGenericPmThresholdPeriod)に基づいて索引化されます。cerentGenericPmThresholdMonTypeの構文は type cerentMonitorType であり、CERENT-TC.mib で定義されます。
cerentGenericPmThresholdLocation の構文は type cerentLocation であり、CERENT-TC.mib で定義されます。cerentGenericPmThresholdPeriod の構文は type cerentPeriod であり、CERENT-TC.mib で定義されます。
スレッシュホールドは、64 ビット形式と 32 ビット形式で指定できます。(64 ビット カウンタの詳細については、HC-RMON-MIB サポートを参照してください。)
cerentGenericPmThresholdHCValue の 64 ビット値は、SNMPv2 をサポートするエージェントで使用できます。2 つの 32 ビット値(cerentGenericPmThresholdValue と
cerentGenericPmThresholdOverFlowValue)は、SNMPv1 だけをサポートする NMS で使用できます。cerentGenericPmThresholdTable でコンパイルされるオブジェクトを 表6-4 に示します。
|
|
---|---|
MIB 内の 2 番めのテーブル cerentGenericPmStatsCurrentTable は、モニタ タイプの現在の PM 値をコンパイルします。このテーブルは、インターフェイス インデックス
(cerentGenericPmStatsCurrentIndex)、モニタ タイプ(cerentGenericPmStatsCurrentMonType)、場所(cerentGenericPmStatsCurrentLocation)、および時間(cerentGenericPmStatsCurrentPeriod)に基づいて索引化されます。cerentGenericPmStatsCurrentIndex の構文は type cerentLocation であり、
CERENT-TC.mib で定義されます。cerentGenericPmStatsCurrentMonType の構文は type cerentMonitor であり、CERENT-TC.mib で定義されます。cerentGenericPmStatsCurrentPeriod の構文は
type cerentPeriod であり、CERENT-TC.mib で定義されます。
cerentGenericPmStatsCurrentTable は、現在の PM 値を cerentGenericPmStatsCurrentValid オブジェクトを使用して検証して、有効なインターバルの数を cerentGenericPmStatsCurrentValidIntervals オブジェクトの PM 履歴統計に登録します。
PM 値は、64 ビット形式と 32 ビット形式で指定できます。cerentGenericPmStatsCurrentHCValue の 64 ビット値は、SNMPv2 をサポートするエージェントで使用できます。2 つの 32 ビット値
(cerentGenericPmStatsCurrentValue と cerentGenericPmStatsCurrentOverFlowValue)は、SNMPv1 だけをサポートする NMS で使用できます。cerentGenericPmStatsCurrentTable を 表6-5 に示します。
|
|
---|---|
MIB の 3 番めのテーブル cerentGenericPmStatsIntervalTable は、モニタ タイプの 履歴 PM 値を取得します。このテーブルは、インターフェイス インデックス、モニタ タイプ、場所、時間、およびインターバル数に基づいて索引化されます。cerentGenericPmStatsIntervalValid オブジェクト内の現在の PM 値を検証します。
このテーブルは、インターフェイス インデックス(cerentGenericPmStatsIntervalIndex)、モニタ タイプ(cerentGenericPMStatsIntervalMonType)、場所(cerentGenericPmStatsIntervalLocation)、および時間(cerentGenericPmStatsIntervalPeriod)に基づいて索引化されます。cerentGenericPmStatsIntervalIndex の構文は type cerentLocation であり、CERENT-TC.mib で定義されます。
cerentGenericPmStatsIntervalMonType の構文は type cerentMonitor であり、CERENT-TC.mib で定義されます。cerentGernicPmStatsIntervalPeriod の構文は type cerentPeriod であり、CERENT-TC.mib で定義されます。
このテーブルは、履歴 PM 値を 64 ビット形式と 32 ビット形式で示します。
cerentGenericPmStatsIntervalHCValue テーブルに含まれる 64 ビット値は、SNMPv2 エージェントで使用できます。2 つの 32 ビット値(cerentGenericPmStatsIntervalValue と
cerentGenericPmStatsIntervalOverFlowValue)は、SNMPv1 NMS で使用できます。
cerentGenericPmStatsIntervalTable を 表6-6 に示します。
|
|
---|---|
ONS 15454 は、raise や clear など、すべてのアラームやイベントをSNMP トラップとして生成します。これらには、次の情報が含まれます。
• 生成したエンティティ(スロット、ポート、Synchronous Transport Signal[STS; 同期転送信号]、Virtual Tributary[VT; 仮想トリビュタリ]、Bidirectional Line Switched Ring[BLSR; 双方向回線交換リング]、Spanning Tree Protocol[STP; スパンニング ツリー プロトコル]など)情報によって、イベントを一意に識別するオブジェクト ID
• アラームの重大度とサービスへの影響(クリティカル、メジャー、マイナー、イベント、または、サービスに影響あり、サービスに影響なし)
ONS 15454 は 表6-7 に示す IETF トラップをサポートします。
各 SNMP トラップには、MIB テーブルを生成するために使用される変数バインディングがあります。ONS 15454 トラップと変数バインディングを 表6-8 に示します。各グループ(たとえば、グループ A)について、そのグループ内のすべてのトラップがそのすべての変数バインディングと関連付けられています。
コミュニティ名は SNMP トラップの宛先のグループ化に使用されます。すべての ONS 15454 トラップの宛先は、Cisco Transport Controller(CTC)で SNMP コミュニティの一部としてプロビジョニングできます。コミュニティ名がトラップに割り当てられると、ONS 15454 は、そのコミュニティ名がCTC でプロビジョニングしたものと一致する場合、その要求を有効として扱います。この場合、すべてのエージェント管理の MIB 変数がその要求に対してアクセス可能になります。コミュニティ名がプロビジョニングされたリストと一致しない場合、SNMP はその要求を無視します。
SNMP と NMS ネットワークの内部や外部からのセキュリティ リスクを切り離すために使用されるファイアウォールでは、従来、アプリケーションがファイアウォールを越えて NE にアクセスすることはできませんでした。リリース 6.0 の CTC では、ネットワーク運用センター(NOC)がファイアウォールにインストールされた SNMP プロキシ要素を使用して、ファイアウォールを越えて RMON の統計情報や自律メッセージのような PM データにアクセスできるようになりました。
アプリケーション レベルのプロキシは SNMP プロトコル データ ユニット(PDU)を NMS と NE 間で転送し、NMS と NE 間で要求や応答を可能にし、NE 自律メッセージを NMS に転送します。プロキシ エージェントは、NOC でのプロビジョニングや NE での追加のプロビジョニングを必要としません。
ファイアウォール プロキシは、Gateway Network Element-End Network Element(GNE-ENE; ゲートウェイ ネットワーク要素-終端ネットワーク要素)トポロジで、単一の NE ゲートウェイを通じて多数のNE で使用されるように設計されています。最大 64 の SNMP 要求(get、getnext、または getbulk など)が、1 つまたは複数のファイアウォールの背後で随時サポートされます。プロキシは、HP-OpenView などの一般的な NMS と相互運用できます。
セキュリティ上の理由から、SNMP プロシキ機能は、受信および送信を実行可能なすべての NE で作動させる必要があります。手順については、『 Cisco ONS 15454 Procedure Guide 』を参照してください。
ONS 15454では、RMON を取り入れているので、ネットワーク オペレータはイーサネット カードのパフォーマンスとイベントを監視することができます。RMON スレッシュホールドは CTC を使用してプロビジョニングすることができます。手順については、『 Cisco ONS 15454 Procedure Guide 』を参照してください。ただし、RMON 操作は一般の CTC ユーザには表示されないことに注意してください。
ONS 15454 システムの RMON は、IETF 標準 MIB RFC 2819 に基づき、標準 MIB の 5 つのグループ(イーサネット統計、履歴制御、イーサネット履歴、アラーム、およびイベント)を含んでいます。
ONS 15454 DCC は、イーサネットとは互換性のない IP プロトコルによって実装されます。システムは DCC(ポイントツーポイント プロトコル[PPP]を実行)経由で収集された HDLC 統計を使用して、イーサネット装置の History および Statistics テーブルを構築します。このリリースでは、リモート DCC 接続の健全性を監視するために、RMON DCC モニタリング(IP とイーサネットの両方について)が追加されました。
R6.0 では、DCC インターフェイス用の 2 つの MIB が実装に含まれています。それらは、次のとおりです。
• cMediaIndependentTable ― 標準、rfc3273。統計の報告に使用される HC-RMON MIB の独自拡張
mediaIndependentTable の行を作成するために使用する SetRequest PDU は、1 つの単一セット操作で 1 行を有効にするために必要なすべての値と、createRequest(2) への状態変数の代入を含んでいなければなりません。エントリ作成のための SetRequest PDU では、すべてのオブジェクト ID(OID)のインスタンス値が 0 でなければなりません。すなわち、すべての OID がタイプ OID.0 でなければなりません。
1 つの行を作成するためには、SetRequest PDU に次の値が必要です。
• mediaIndependentDataSource とその対応する値
• mediaIndependentOwner とその対応する値(mediaIndependentOwner のサイズは 32 文字に制限)
• 値が createRequest(2) である mediaIndependentStatus
SetRequest PDU が上記の規則に従っている場合に、mediaIndependentTable に 1 行が作成されます。行が作成されると、SNMP エージェントは mediaIndependentIndex の値を決定します。この値は順次割り当てられず、連番にはなりません。イーサネット インターフェイスが追加、削除されると、この値は変化します。新しく作成された行は有効な mediaIndependentTable 値(1)を持ちます。
行がすでに存在する場合、または SetRequest PDU の値に不備があるか無意味の場合、SNMP エージェントによってエラーコードが戻されます。
(注) mediaIndependentTable のエントリは SNMP エージェントの再起動では保持されません。
SetRequest PDU に無効な値(4)の mediaIndependentStatus が含まれていた場合、mediaIndependentTable の行が削除されます。削除する行は、varbind の OID インスタンス値によって示されます。必要な場合は、削除されたテーブル行を再作成できます。
cMediaIndependentHistoryControlTable での SNMP 行の作成と削除は、MediaIndependentTable と同じプロセスで行われます。異なるのは変数だけです。
1 つの行を作成するためには、SetRequest PDU に次の値が必要です。
• cMediaIndependentHistoryControlDataSource とその対応する値
• cMediaIndependentHistoryControlOwner とその対応する値
• 値が createRequest(2) である cMediaIndependentHistoryControlStatus
ONS 15454では、High-Capacity Remote Monitoring Information Base(HC-RMON-MIB; 大容量リモート モニタリング情報ベース、または RFC 3273)の実装により、既存の RMON テーブルの 64 ビットサポートが可能になりました。このサポートでは etherStatsHighCapacityTable と
etherHistoryHighCapacityTable が提供されています。テーブル mediaIndependentTable とオブジェクト hcRMONCapabilities もこのサポートに追加されます。これらすべての要素には、RFC 3273 をサポートするすべてのサードパーティの SNMP クライアントがアクセス可能です。
イーサネット統計グループには、監視されるサブネットワークごとの基本統計を示す etherStatsTable という名前のテーブルが 1 つ含まれます。
このテーブルの行を作成するために使用する SetRequest PDU は、1 つの単一セット操作で 1 行を有効にするために必要なすべての値と、createRequest に割り当てた状態変数を含んでいなければなりません。SetRequest PDU オブジェクト ID(OID)のすべてのエントリには、0 のインスタンス値(タイプ OID)が設定されている必要があります。
1 つの行を作成するためには、SetRequest PDU に次の値が必要です。
• etherStatsOwner と対応する値(大きさは 32 文字に制限)
• createRequest の値(2)を持つ etherStatsStatus
SetRequest PDU が上記の規則に従っている場合に、etherStatsTable に 1 行が作成されます。行が作成されると、SNMP エージェントは etherStatsIndex の値を決定します。この値は順次割り当てられず、連番にはなりません。イーサネット インターフェイスが追加、削除されると、この値は変化します。新しく作成された行は有効な etherStatsStatus 値(1)を持ちます。
etherStatsTable のその行が既に存在する場合、あるいは SetRequest PDU の値に不備があるか無意味の場合、SNMP エージェントによってエラーコードが戻されます。
(注) EtherStatsTable のエントリは SNMP エージェントの再起動では保持されません。
etherStatsMulticastPkts と etherStatsBroadcastPkts 列に対する Get 要求と getNext 要求は、これらの変数が ONS 15454 イーサネット カードでサポートされていないので、値 0 を戻します。
etherStatsTable の行を削除するには、SetRequest PDU に etherStatsStatus の「無効」の値(4)を設定する必要があります。OID ではその行に削除のマークを付けます。必要であれば、削除した行は再作成できます。
イーサネット統計グループには、etherStatsHighCapacityTable に 64 ビットの統計情報があります。これは、HC-RMON-MIB の 64 ビット RMON をサポートします。etherStatsHighCapacityTable は、64 ビット形式の PM データに 16 個の新しい列を追加した、etherStatsTable の拡張版です。etherStatsTable と etherStatsHighCapacityTable は対応していて、いずれかのテーブルの列が作成または削除されるともう一方のテーブルでも作成または削除されます。
履歴制御グループは、historyControlTableの 1 つ以上のモニタ インターフェイスのサンプリング機能を定義します。このテーブルの値は、RFC 2819 で定義されているように、historyControlTable と etherHistoryTable から取り込まれます。
RMON は、4 つの可能な周期の内の 1 つでサンプリングされます。各周期(間隔)には個々の履歴の値(バケットとも呼ばれる)が含まれます。表6-9は 4 つのサンプリング周期と、対応するバケット数を示しています。
historyControlTable の最大サイズは、カード上のポート数とサンプリング間隔の数を掛けて求めます。たとえば、ONS 15454 E100 カードには 24 ポートをあり、サンプリング間隔数 4 を掛けると、テーブルは 96 行になります。E1000 カードには 14 ポートあり、4 間隔を掛けると 56 行になります。
(historyControlValue 変数) |
(historyControl 変数) |
---|---|
SetRequest PDU は、1 つの単一セット操作で historyControlTable の行を有効にできる必要があります。このため、この PDU にはすべての必要な値があり、状態変数値 2(createRequest)がある必要があります。SetRequest PDU のすべての OID は、エントリ作成でタイプ OID.0 でなければなりません。
historyControlTable に SetRequest PDU を作成するには、次の値が必要です。
• historyControlDataSource とその要求値
• historyControlBucketsRequested とその対応する値
• historyControlInterval とその対応する値
• historyControlOwner とその対応する値
• createRequest の値(2)を持つ historyControlStatus
historyControlBucketsRequested OID 値は、各サンプリング間隔で使用できるバケット数が historyControlInterval 値に基づいて、表6-9のように固定されているので無視されます。
historyControlInterval の値は 4 つの可能な選択肢からは変更できません。他の値を使用すると、バケット数の選択肢の中で最も近い小さい方の値が選択されます。たとえば、設定した値が 25 分間隔だとすると、この値は変数の 15 分(32 バケット)と 60 分(24 バケット)の間に入ります。SNMP エージェントは、それに近い低い方の値を自動的に選択します。これは、15 分、32 バケットです。
SetRequest PDU が有効であれば、historyControlTable の行が作成されます。その行が既に存在する場合、あるいは SetRequest PDU の値に不備があるか無意味の場合、SNMP エージェントは行を作成せずにエラーコードを返します。
このテーブルから行を削除するには、SetRequest PDU は historyControlStatus 値として 4(無効)を設定する必要があります。削除された行は再作成できます。
ONS 15454は、RFC 2819 の定義に従って etherHistoryTable を実装しています。グループは historyControlTable の境界内で、RFC の設計内で作成されます。
HC-RMON-MIB の 64 ビット Ethernet 履歴は、etherHistoryHighCapacityTable に実装されています。これは、etherHistoryTable の拡張版です。etherHistoryHighCapacityTable では、64 ビットの PM のデータのために、4 つの列を追加しています。この 2 つのテーブルは 1 対 1 の関係を持っています。一方のテーブルに行を追加、削除すると、もう一方のテーブルに反映されます。
アラーム グループは alarmTable で構成されます。このテーブルでは、定期的にサンプリングされた値をスレッシュホールドと比較し、スレッシュホールドを超えるとイベントを発生します。このグループには、この項で後述するイベント グループが実装されている必要があります。
NMS は alarmTable を使用して、ネットワークのパフォーマンス アラームのスレッシュホールドを決定し、設定します。
alarmTable に行を作成するには、SetRequest PDU によって 1 つの単一セット操作で行を作成できなければなりません。SetRequest PDU のすべての OID は、エントリ作成でタイプ OID.0 でなければなりません。テーブルは最大 256 行からなります。
alarmTable に SetRequest PDU を作成するには、次の値が必要です。
• createRequest の値を持つ alarmStatus(2)
SetRequest PDU が有効であれば、historyControlTable の行が作成されます。その行が既に存在する場合、あるいは SetRequest PDU の値に不備があるか無意味の場合、SNMP エージェントは行を作成せずにエラーコードを返します。
SetRequest PDU には必須の値に加えて、次のような制約事項があります。
• alarmRisingEventIndex は常に値 1 をとります。
• alarmFallingEventIndex は常に値 2 をとります。
• alarmStatus は、SET でサポートされている createRequest(2)と invalid(4)の 2 つの値のみをとります。
• AlarmVariable はタイプ OID.ifIndex で、ifIndex にはこのアラームが作成されるインターフェイスを指定します。OID は 表6-10でサポートされている OID の 1 つです。
|
|
|
|
---|---|---|---|
テーブルから行を削除するには、SetRequest PDU に historyControlStatus 値として 4(無効)を設定する必要があります。削除された行は再作成できます。このテーブルのエントリは SNMP エージェントの再起動で保持されます。
イベント グループは、イベントの生成と通知を制御します。イベント グループは、生成するイベントの読み取り専用のリストである eventTable と、ログ イベントを記述する書き込み可能なデータである logTable の 2 つのテーブルで構成されます。ONS 15454 では RFC 2819 の規定に従って、logTable を実装しています。
eventTable は読み取り専用で、プロビジョニングできません。このテーブルには、アラーム発生用の行とアラーム解除用の行があります。このテーブルには、次の制約があります。
• eventType は常に log-and-trap(4)です。
• eventCommunity 値は常に 0 文字長の文字列であり、このイベントによって、すべてのプロビジョニングされた宛先にトラップが送されることを示します。
logTable は RFC 2819 に従って実装されています。logTable は、コントローラ カードでローカルにキャッシュされるデータに基づいています。コントローラ カードの保護切り替えがあると、既存の logTable はクリアされ、新しいテーブルが新しいアクティブ コントローラ カードで開始されます。このテーブルは、アラーム コントローラで指定された数の行からなります。