このトピックでは、SNMP v1 および v2 で定義されているオブジェクト・タイプについて説明します。
「MIB モジュール」ビューでモジュールを選択し、「OID Tree」ビューの「検索」フィールドで「ifIndex」を検索することによって、以下のセクションで説明されているオブジェクト情報を見つけることができます。「OID ツリー」階層で ifIndex オブジェクトをクリックし、「詳細」ビューでオブジェクト情報およびテキスト規則情報を参照します。
OBJECT IDENTIFIER は SNMP v1 で定義されており、MIB ツリーの主要なビルディング・ブロックです。オブジェクト ID は、書籍の章見出しに似ており、実際のデータは含んでいませんが、下位層で中継される内容の種類に関する概念を示しています。
OBJECT-TYPE は SNMP v1 で定義されており、管理対象デバイスに関する情報またはデバイス上の一部の測定値を保管するコンテナーとして使用されます。
TEXTUAL-CONVENTION (TC) は、オブジェクト・タイプの定義ですが、実際のオブジェクトではありません。「MIB モジュール」ビューで、「ビュー」リストから「テキスト規則」を選択して、MIB ツリーに表示された解析済みのテキスト規則を参照できます。MIB ツリーで TC 名を選択して、TC の定義を 「詳細」ビューに表示します。
bgpEstablished TRAP-TYPE ENTERPRISE bgp VARIABLES { bgpPeerRemoteAddr, bgpPeerLastError,
bgpPeerState } DESCRIPTION "The BGP Established event is generated when the BGP FSM
enters the ESTABLISHED state." ::= 1 ENTERPRISE セクションでは、トラップの親であるオブジェクトを 定義します。ただし、MIB ツリー・オブジェクトは bgp を使用して親として定義でき、このオブジェクトは子番号 1 として定義されます。実際、bgpVersion は、 RFC1269-MIB モジュールで { bgp 1} として定義されます。このため、 親として ENTERPRISE を使用して、v1 トラップを MIB ツリーに リーフとして追加することはできません。
SNMP v2 では、 TRAP-TYPE の定義を NOTIFICATION-TYPE に変更するとともに、この新しい v2 トラップがその他の MIB オブジェクトのように定義されるように指定します。 v1 トラップの場合にのみ、親子の番号によって、これが問題になります。RFC1155 セクション 4.1 では、子番号としてのゼロ (0) の使用を無効と定義しており、0 を将来の使用のために予約しています。SNMP v2 では、この 0 を使用します。それには、0 をエンタープライズ名に追加 してから 0 の後にトラップ番号を追加することにより、ベンダーが v1 トラップを v2 MIB に 追加できるようにします。したがって、v2 では、0 の付いたオブジェクト ID をエンタープライズの子として定義し、次に、その 0 の子として v1 トラップを追加することは適正です。
この規則は、MIB 作成者による一般的な誤りの 原因になっています。RFC1155 セクション 4 では、以下のように述べています。
"An object type definition consists of five fields: OBJECT: ------- A textual name, termed the OBJECT DESCRIPTOR, for the object type, along with its corresponding OBJECT IDENTIFIER. Syntax: The abstract syntax for the object type. This must resolve to an instance of the ASN.1 type ObjectSyntax (defined below). Definition: A textual description of the semantics of the object type. Implementations should ensure that their instance of the object fulfills this definition since this MIB is intended for use in multi-vendor environments. As such it is vital that objects have consistent meaning across all machines. Access: One of read-only, read-write, write-only, or not-accessible. Status: One of mandatory, optional, or obsolete. Future memos may also specify other fields for the objects which they define."
adslAtucPerfLofsThreshTrap NOTIFICATION-TYPE OBJECTS { adslAtucPerfCurr15MinLofs,
adslAtucThresh15MinLofs } STATUS current DESCRIPTION "Loss of Framing 15-minute
interval threshold reached." ::= { adslAtucTraps 0 1 } v1 トラップまたは v2 通知で伝送されるオブジェクトは、varbind と呼ばれます。varbind には、報告されたイベントに関する追加情報が含まれています。varbind は、v1 トラップでは VARIABLES セクションで項目化されており、v2 通知では OBJECTS セクションでリストされています。これらは、すべてのバージョンの SNMP で同じように使用されます。varbind がリスト内に現れる順序は重要です。なぜなら、PDU (SNMP パケット) は、関連付けられた値を、それらの値が MIB 内でリストされるのと同じ順序でエンコードするからです。
例えば、OBJECTS セクションで、ifIndex、ifAdminStatus、および ifOperStatus の 3 つの varbind が指定されています。したがって、varbind のうち、ifIndex は最初にエンコードされ、ifAdminStatus は 2 番目にエンコードされ、ifOperStatus は 3 番目にエンコードされます。IF-MIB を確認すると、ifIndex オブジェクト・タイプが InterfaceIndex として定義されていることが分かります。これは SNMP 用の有効な ASN.1 プリミティブ型ではないので、テキスト規則である必要があります。テキスト規則を検索すると、InterfaceIndex は実際には、Integer32 (32 ビット整数) に解決されることが分かります。したがって、PDU が MIB マネージャーに到着する際、最初の varbind は整数となります。 この整数が何を意味するかを決定するため、MIB マネージャーは、IF-MIB モジュールを参照し、ifIndex を検索して、関連付けられたオブジェクト情報を読み取る必要があります。2 つ目の varbind を確認すると、以下のような整数の列挙型が見つかります。
SYNTAX INTEGER { up(1), -- ready to pass packets down(2),
testing(3) -- in some test mode }varbind が SNMP パケットからデコードされると、その値は整数となり、値はこの列挙リスト内のアイテムに基づいて解釈される必要があります。MIB マネージャーがルール・ファイルの作成に使用される際、MIB マネージャーはルックアップ表を作成して、列挙された整数をそのテキスト規則へ自動的にリンクします。3 つ目の varbind もまた、同じ値を持つ列挙型です。したがって、ifAdminStatusが 1 (アップ) で ifOperStatus が 2 (ダウン) の場合、イベントが生成された理由が分かり、引き続き、この障害の原因特定を試みることができます。
varbind は、ルール・ファイルにおいて、$1、$2、$3 などの形式でユーザーに表示され、各番号は varbind の番号を表します。MIB マネージャーは、varbind エレメントに基づいてエレメントを作成し、それらを使用して詳細テーブルに変数を設定します。例えば、詳細テーブルで使用されるエレメントは、$ifIndex = $1 (整数)、$ifAdminStatus = $2 (アップ (1) のような値)、および $ifOperStatus = $3 (ダウン (3) のような値) である場合があります。オブジェクト設定に行われたすべての変更は、Netcool Knowledge Library (NCKL) によって設定された規則を使用して、ルール・ファイルに自動的に設定されます。
テーブルは、データの行と列からなる 多次元配列と同等のものを表します。テーブル・オブジェクトは、 Entry オブジェクトの SEQUENCE OF として定義されます。次に、Entry オブジェクトは、 OBJECT-TYPE オブジェクトの SEQUENCE として定義されます。場合によって、ベンダーは、一般的でないシステム (例: Cisco 10k ルーター) を設計することがあります。 このデバイスは、アラーム条件の内部テーブルを保持して、テーブルが変更されると トラップや通知を生成します。そうすると、ユーザーは、テーブルの内容に 関する SNMP GET 要求を発行して、デバイスに関するアクティブ・アラームの最新状況を 判別する必要があります。これが原因で、SNMP マネージャーがアラームを取得するのが少し難しくなりますが、それに応じたツールを管理者が持っていれば不可能ではありません。
オクテットは、8 ビットで構成されるデータ構造 (通称、バイト) です。OCTET STRING は、バイトの配列 (またはバイト・ストリング) です。OCTET STRING という用語は、ストリング内のすべてのバイトが英数字であることを意味しません。バイナリー文字になることもあり、 ビット・マスクとして使用されます。