この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
この章では、Cisco ONS 15454 SDH に実装されている Simple Network Management Protocol(SNMP; 簡易ネットワーク管理プロトコル)について説明します。
SNMP のセットアップの詳細については、『 Cisco ONS 15454 SDH Procedure Guide 』を参照してください。
SNMP は、ONS 15454 SDH ネットワーク装置による、システム内またはネットワーク外の他の装置との管理情報の交換を可能にするアプリケーション層の通信プロトコルです。ネットワーク管理者は、SNMP を使用して、ネットワーク パフォーマンスの管理、ネットワークの問題の発見と解決、およびネットワーク拡張計画を行うことができます。
ONS 15454 SDH では SNMP を使用して Network Management System(NMS; ネットワーク管理システム)に非同期のイベント通知を行います。ONS SNMP の実装では、標準の Internet Engineering Task Force(IETF; インターネット技術特別調査委員会)MIB(管理情報ベース)を使用して、電気、SDH、およびイーサネット技術の一般的な読み取り専用管理のための、ノード レベルのインベントリ、障害、およびパフォーマンス管理情報を伝達します。SNMP により、HP OpenView Network Node Manager(NNM)または Open Systems Interconnection(OSI; 開放型システム間相互接続)NetExpert などの汎用 SNMP マネージャを使用して、ONS 15454 SDH の一定の管理が可能になります。
Cisco ONS 15454 SDHは、SNMP バージョン 1(SNMPv1)と SNMP バージョン 2c(SNMPv2c)をサポートします。どちらのバージョンでも多くの機能が同じように使用できますが、SNMPv2c ではさらにいくつかのプロトコル動作が追加されており、64 ビット Perfomance Monitoring(PM; パフォーマンス モニタリング)機能をサポートします。この章では、この 2 つのバージョンについて説明し、ONS 15454 SDH での SNMP の設定方法を説明します。
(注) CiscoV2 ディレクトリの CERENT-MSDWDM-MIB.mib、CERENT-FC-MIB.mib、および
CERENT-GENERIC-PM-MIB.mib は、64 ビットの PM カウンタをサポートします。CiscoV1 ディレクトリの SNMPv1 MIB は 64 ビットの PM カウントを含んでいませんが、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 SDHなどのネットワーク要素があり、SNMP エージェントを介してアクセスされます。管理対象装置では、管理情報を収集、保管し、SNMP を使用して、これらの情報を、SNMP を使用する管理システムで利用できるようにします。
すべての SNMP 要求はサードパーティのアプリケーションから発生するので、サードパーティの SNMP クライアント アプリケーションが etherStatsHighCapacityTable、
etherHistoryHighCapacityTable 、または mediaIndependentTable の RFC 3273 SNMP MIB 変数をアップロードできることが唯一の外部インターフェイス条件です。
ONS 15454 SDH は、SNMPv1 および SNMPv2c の trap 要求と get 要求をサポートします。SNMP MIB では、アラーム、トラップ、および状態を定義します。SNMP を介して、NMS アプリケーションは、サポートされている MIB を使用して、イーサネット スイッチや SDH マルチプレクサのような機能エンティティからのデータを管理エージェントに問い合わせます。
(注) CiscoV1 および CiscoV2 ディレクトリにある ONS 15454 SDH MIB ファイルは、64 ビットの PM 機能を除いて、内容的には同一です。CiscoV2 ディレクトリには、CERENT-MSDWDM-MIB.mib、CERENT-FC-MIB.mib、および CERENT-GENERIC-PM-MIB.mib という 64 ビットの PM カウンタを持つ 3 つの MIB が含まれています。CiscoV1 ディレクトリには 64 ビット カウンタは含まれていませんが、64 ビット カウンタで使用されるより低いワード値とより高いワード値をサポートします。2 つのディレクトリは、異なったフォーマットになっています。
ONS 15454 SDH SNMP エージェントは、SNMP メッセージを使用して SNMP 管理アプリケーションと情報をやり取りします。 表6-1 に、これらのメッセージを 示します。
6.6.1 に、ONS 15454 SDH で実装される IETF 標準 MIB とそれらのコンパイル順序を示します。 6.6.2 では、ONS 15454 SDH 独自の MIB とそれらのコンパイル順序を示します。 6.6.3 では、ネットワークに含まれているネットワーク要素(NE)の監視に使用できる汎用スレッシュホールドおよび PM MIB について説明します。
表6-2 に、ONS 15454 SDH SNMP エージェントに実装された IETF 標準 MIB の一覧を示します。
まず、表6-2 の MIB をコンパイルしてください。次に、表6-3 の MIB をコンパイルしてください。
|
|
|
---|---|---|
Management of TCP/IP-based Internets: MIB-IIManagement Information Base for Version 2 of the Simple Network Management Protocol(SNMPv2) |
||
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 システムに適用できる独自の MIB が、各 ONS システムに付属のソフトウェア CD に収録されています。 表6-3 に、ONS 15454 SDH 独自の 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)が最初に調整可能な波長で動作することを意味します。
リリース 6.0 では、CERENT-GENERIC-PM-MIB という名前の新しい MIB により、NMS で単一の汎用 MIB を使用して、さまざまなタイプのインターフェイスのスレッシュホールドと PM データにアクセスすることができます。この MIB は、特定のタイプのインターフェイスに限定されないという意味で汎用です。MIB オブジェクトを使用して、近端および遠端の各種のモニタとサポートされる任意の間隔で、スレッシュホールド、現在の PM カウント、および PM 履歴統計を入手することができます。
ONS 15454 SDH システムに以前からある MIB は、これらのカウントの一部を備えています。たとえば、SDH インターフェイスの 15 分ごとの現在 PM カウントと PM 履歴統計は、SDH-MIB を使用して入手できます。DS-1 および DS-3 のカウントと統計は、それぞれ DS1-MIB と DS-3 MIB から入手できます。汎用 MIB は、これらのタイプの情報を提供し、スレッシュホールドと 1 日間の統計も取得します。さらに、この MIB は、光および Dense Wavelength Division Multiplexing(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 で使用できます。 表6-4 に、cerentGenericPmThresholdTable でコンパイルされるオブジェクトを示します。
|
|
---|---|
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 で使用できます。 表6-5 に、cerentGenericPmStatsCurrentTable を示します。
|
|
---|---|
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 で使用できます。 表6-6 に、
cerentGenericPmStatsIntervalTable を示します。
|
|
---|---|
ONS 15454 SDH は、raise や clear など、すべてのアラームやイベントをSNMP トラップとして生成します。これらには、次の情報が含まれます。
• 生成したエンティティ(スロット、ポート、Synchronous Transport Signal[STS; 同期転送信号]、Virtual Tributary[VT; 仮想トリビュタリ]、Bidirectional Line Switched Ring[BLSR; 双方向回線交換リング]、Spanning Tree Protocol[STP; スパンニング ツリー プロトコル]など)情報によって、イベントを一意に識別するオブジェクト ID
• アラームの重大度とサービスへの影響(クリティカル、メジャー、マイナー、イベント、または、サービスに影響あり、サービスに影響なし)
ONS 15454 SDH は 表6-7 に示す IETF トラップをサポートします。
各 SNMP トラップには、MIB テーブルを生成するために使用される変数バインディングがあります。 表6-8 に、ONS 15454 SDH トラップと変数バインディングを示します。各グループ(たとえば、グループ A)について、そのグループ内のすべてのトラップがそのすべての変数バインディングと関連付けられています。
コミュニティ名は SNMP トラップの宛先のグループ化に使用されます。すべての ONS 15454 SDH トラップの宛先は、Cisco Transport Controller(CTC)で SNMP コミュニティの一部としてプロビジョニングできます。コミュニティ名がトラップに割り当てられると、ONS 15454 SDH は、そのコミュニティ名がCTC でプロビジョニングしたものと一致する場合、その要求を有効として扱います。この場合、すべてのエージェント管理の MIB 変数がその要求に対してアクセス可能になります。コミュニティ名がプロビジョニングされたリストと一致しない場合、SNMP はその要求を無視します。
ネットワークの内部や外部からのセキュリティ リスクを切り離すために使用されるファイアウォールでは、従来、SNMP および NMS アプリケーションがファイアウォールを越えて NE にアクセスすることはできませんでした。リリース 6.0 の CTC では、Network Operations Center(NOC)がファイアウォールにインストールされた SNMP プロキシ要素を使用して、ファイアウォールを越えて Remote Monitoring(RMON)の統計情報や自律メッセージのようなパフォーマンス モニタリング データにアクセスできるようになりました。
アプリケーション レベルのプロキシは SNMP Protocol Data Unit(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 SDH Procedure Guide 』を参照してください。
ONS 15454 SDHでは、RMON を取り入れているので、ネットワーク オペレータはイーサネット カードのパフォーマンスとイベントを監視することができます。RMON スレッシュホールドは CTC を使用してプロビジョニングすることができます。手順については、『 Cisco ONS 15454 SDH Procedure Guide』を参照してください。 ただし、RMON 操作は一般の CTC ユーザには表示されないことに注意してください。
ONS 15454 SDH システムの RMON は、IETF 標準 MIB RFC 2819 に基づき、標準 MIB の 5 つのグループ(イーサネット統計、履歴制御、イーサネット履歴、アラーム、およびイベント)を含んでいます。
ONS 15454 SDH 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 とその適切な値
• 値が createRequest(2)である mediaIndependentStatus
SetRequest PDU が上記の規則に従っている場合に、mediaIndependentTable に 1 行作成されます。行が作成されると、SNMP エージェントは mediaIndependentIndex の値を決定します。この値は順次には割り当てられず、連番にはなりません。イーサネット インターフェイスが追加または削除されると、この値は変化します。新しく作成された行は有効な mediaIndependentTable 値(1)を持ちます。
行がすでに存在する場合、または SetRequest PDU の値に不備があるか無意味の場合、SNMP エージェントによってエラーコードが返されます。
(注) mediaIndependentTable のエントリは、SNMP エージェントの再起動では保持されません。
SetRequest PDU に値が invalid(4)の mediaIndependentStatus が含まれていた場合、
mediaIndependentTable から 1 行削除されます。削除する行は、varbind の OID インスタンス値によって示されます。必要な場合は、削除されたテーブル行を再作成できます。
cMediaIndependentHistoryControlTable での SNMP 行の作成と削除は、MediaIndependentTable と同じプロセスで行われます。違うのは変数だけです。
1 つの行を作成するためには、SetRequest PDU に次の値が必要です。
• cMediaIndependentHistoryControlDataSource とその適切な値
• cMediaIndependentHistoryControlOwner とその適切な値
• 値が createRequest(2)である cMediaIndependentHistoryControlStatus
ONS 15454 SDHでは、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 に次の値が必要です。
• etherStatsDataSource とその適切な値
• 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 SDH イーサネット カードでサポートされていないので、値 0 を返します。
etherStatsTable の行を削除するには、SetRequest PDU に etherStatsStatus の値 invalid(4)を設定する必要があります。OID ではその行に削除のマークを付けます。必要であれば、削除した行は再作成できます。
イーサネット統計グループには、etherStatsHighCapacityTable に 64 ビットの統計情報があります。これは、HC-RMON-MIB の 64 ビット RMON をサポートします。etherStatsHighCapacityTable は、64 ビット形式の PM データに 16 個の新しい列を追加した、etherStatsTable の拡張版です。etherStatsTable と etherStatsHighCapacityTable は1 対 1 の関係を持っていて、一方のテーブルの列が作成または削除されるともう一方のテーブルでも作成または削除されます。
履歴制御グループは、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 とその適切な値
• createRequest(2) の値を持つ historyControlStatus
historyControlBucketsRequested OID 値は、各サンプリング期間で使用できるバケット数が historyControlInterval 値に基づいて、表6-9のように固定されているので無視されます。
historyControlInterval の値は 4 つの可能な選択肢からは変更できません。他の値を使用すると、バケット数の選択肢の中で最も近い小さい方の値が選択されます。たとえば、設定した値が 25 分間隔だとすると、この値は変数の 15 分(32 バケット)と 60 分(24 バケット)の間に入ります。SNMP エージェントは、低い方の近い値を自動的に選択します。この場合、15 分、32 バケットになります。
SetRequest PDU が有効であれば、historyControlTable に 1 行作成されます。その行が既に存在する場合、あるいは SetRequest PDU の値に不備があるか無意味の場合、SNMP エージェントは行を作成せずにエラーコードを返します。
このテーブルから行を削除するには、SetRequest PDU は historyControlStatus 値として 4(無効)を設定する必要があります。削除された行は再作成できます。
ONS 15454 SDHは、RFC 2819 の定義に従って etherHistoryTable を実装しています。グループは historyControlTable の境界内で、RFC の設計内で作成されます。
HC-RMON-MIB の 64 ビット イーサネット履歴は、etherHistoryHighCapacityTable に実装されています。これは、etherHistoryTable の拡張版です。etherHistoryHighCapacityTable では、64 ビットのパフォーマンス モニタリングのデータのために、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 に 1 行作成されます。その行がすでに存在する場合、あるいは 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(invalid)を設定する必要があります。削除された行は再作成できます。このテーブルのエントリは SNMP エージェントが再起動されても保持されます。
イベント グループは、イベントの生成と通知を制御します。イベント グループは、生成するイベントの読み取り専用のリストである eventTable と、ログ イベントを記述する書き込み可能なデータである logTable の 2 つのテーブルで構成されます。ONS 15454 SDH では RFC 2819 の規定に従って、logTable を実装しています。
eventTable は読み取り専用で、プロビジョニングできません。このテーブルには、アラーム発生用の行とアラーム解除用の行があります。このテーブルには、次の制約があります。
• eventType は常に log-and-trap(4)です。
• eventCommunity 値は常に 0 文字長の文字列であり、このイベントによって、すべてのプロビジョニングされた宛先にトラップが送信されることを示します。
logTable は RFC 2819 に従って実装されています。logTable は、コントローラ カードでローカルにキャッシュされるデータに基づいています。コントローラ カードの保護切り替えがあると、既存の logTable はクリアされ、新しいテーブルが新しいアクティブ コントローラ カードで開始されます。このテーブルは、アラーム コントローラで指定された数の行からなります。