ルーティングインスタンスのSNMPの設定

Junos OSでは、すべてのルーティングインスタンスのSNMPマネージャーが、対応するルーティングインスタンスと論理システムネットワークに関連するSNMPデータを要求および管理できます。

Junos OS では、

• デフォルト以外のルーティングインスタンスや論理システムからのクライアントは、MIBオブジェクトにアクセスし、属するルーティングインスタンスや論理システムネットワークでのみSNMP操作を実行できます。

• デフォルトのルーティング インスタンスのクライアントは、すべてのルーティング インスタンスと論理システム ネットワークに関連する情報にアクセスできます。

• Junos管理ルーティングインスタンス(mgmt_junos)は、特別なインスタンスです。管理ルーティングインスタンスからのクライアントは、デフォルトのルーティングインスタンスにあるかのように扱われ、すべてのルーティングインスタンスと論理システムネットワークに関連する情報にアクセスできます。

Junos OSリリース8.4以前は、デフォルトルーティングインスタンス(inet.0)のSNMPマネージャーのみがMIBオブジェクトにアクセスできました。

仮想プライベートネットワーク(VPN)サービスの増加に伴い、この機能は、特定のルーティングインスタンスに対してSNMPデータを取得する必要があるサービスプロバイダに特に役立ちます(を参照 図 1)。サービス プロバイダは、この情報を自社の管理ニーズに使用したり、顧客が使用するデータをエクスポートしたりできます。

図 1: ルーティングインスタンスのSNMPデータ

リクエストでルーティングインスタンスが指定されていない場合、SNMPエージェントは以前と同様に動作します。

• 非ルーティング テーブル オブジェクトの場合、すべてのインスタンスが公開されます。

• ルーティング・テーブル・オブジェクトの場合、デフォルトのルーティング・インスタンスに関連付けられたオブジェクトのみが公開されます。

  注:

  実際のプロトコルデータユニット(PDU)は、依然としてデフォルト(inet.0)ルーティングインスタンスで交換されますが、返されるデータコンテンツは、リクエストPDUで指定されたルーティングインスタンスによって決定されます。

Junos OS 19.4R1以降、必要なルーティングインスタンスでSNMPv3管理インターフェイスを設定することで、すべてのルーティングインスタンスと論理システムネットワークに関連する情報にアクセスでき、イングレスルーティングインスタンスに固有の情報にはアクセスできません。階層レベルで管理インスタンス設定ステートメントを [edit snmp v3] 設定できます。

• メリット
• 管理ルーティングインスタンスの有効化
• 管理ルーティング インスタンスの削除

表 1 は、Junos OSでサポートされているエンタープライズ固有のMIBオブジェクトを示し、SNMPリクエストでルーティングインスタンスが指定された場合の処理方法の詳細なメモを提供します。ダッシュ(–)は、アイテムが適用されていないことを示します。

表 2 は、Junos OSでサポートされているクラス1 MIBオブジェクト(標準およびエンタープライズ固有のMIB)を示しています。クラス 1 オブジェクトでは、特定のルーティング インスタンスに属する論理インターフェイス(およびその親物理インターフェイス)のみが公開されます。

表 3 は、Junos OSでサポートされているクラス2 MIBオブジェクト(標準およびエンタープライズ固有のMIB)を示しています。クラス 2 オブジェクトを使用すると、論理システム内のすべてのインスタンスが公開されます。データはルーティング インスタンス レベルに分離されません。

表 4 は、Junos OSでサポートされているクラス3 MIBオブジェクト(標準およびエンタープライズ固有のMIB)を示しています。クラス 3 では、オブジェクトはデフォルトの論理システムでのみ公開されます。

表 5 は、Junos OSでサポートされているクラス4 MIBオブジェクト(標準およびエンタープライズ固有のMIB)を示しています。クラス 4 オブジェクトでは、データはルーティング インスタンスによって分離されません。すべてのインスタンスが公開されます。

ルーティングインスタンスが指定された場合、すべてのルーティング関連MIBオブジェクトは、リクエスト内のルーティングインスタンスが維持するデータを返します。その他の MIB オブジェクトの場合、返されるデータはそのルーティング インスタンスに応じて分離されます。例えば、そのルーティングインスタンスに割り当てられたインターフェイス(論理インターフェイス[ifls]および対応する物理インターフェイス[ifds]など)のみがSNMPエージェントによって公開されます。同様に、インターフェイス(アドレスなど)に明確に添付されたオブジェクトも分離されます。

添付ファイルが不明瞭なオブジェクト(sysApplMIB 内のオブジェクトなど)では、分離は行われず、すべてのインスタンスがすべての場合に表示されます。

オブジェクトの別のカテゴリーは、デフォルト論理システム内のルーティング・インスタンスに関係なく、論理システムが指定されていない(デフォルトの論理システム内でのみ)場合にのみ表示されます。このカテゴリーのオブジェクトは、シャーシMIBオブジェクト、SNMPグループ内のオブジェクト、RMONアラーム、イベントおよびロググループ、Ping MIBオブジェクト、設定管理オブジェクト、およびV3オブジェクトです。

要約すると、ルーティング インスタンスをサポートするために、MIB オブジェクトは次のいずれかのカテゴリに分類されます。

• クラス 1 — データはリクエストのルーティング インスタンスに従って分離されます。これは、分離クラスの中で最もきめ細かいです。

• クラス 2 — データは、要求で指定された論理システムに従って分離されます。特定の論理システムに属するすべてのルーティング インスタンスに対して、同じデータが返されます。通常、これはルーティング・インスタンス情報を抽出するのが難しい、またはルーティング・インスタンスが適用されないルーティング・テーブル・オブジェクトに適用されます。

• クラス 3 — データはデフォルトの論理システムでのみ公開されます。デフォルトの論理システムに属するすべてのルーティング インスタンスに対して、同じデータ セットが返されます。別の論理システムを指定した場合(デフォルトではありません)、データは返されません。通常、このクラスは、論理システムの変更を監視せず、デフォルトのコンテキスト(シャーシMIBオブジェクトなど)のみを使用してオブジェクトを登録しないサブエージェントに実装されたオブジェクトに適用されます。

• クラス 4 —データはルーティング インスタンスによって分離されません。すべてのルーティング インスタンスに対して同じデータが返されます。通常、これは、論理システムの変更を監視し、論理システムの変更ごとにすべてのオブジェクトを登録または登録解除するサブエージェントに実装されたオブジェクトに適用されます。ルーティング インスタンスによって値を分離できないオブジェクトは、このクラスに分類されます。

各クラスに関連するオブジェクトのリストについては、 ルーティングインスタンスでサポートされているSNMP MIB を参照してください。

トラップレシーバーが、属する論理システムネットワークに関連しないトラップの受信を制限できます。これを行うには、 階層レベルに logical-system-trap-filter ステートメントを [edit snmp] 含めます。

ステート メントが logical-system-trap-filter SNMP 設定に含まれていない場合、すべてのトラップが設定されたルーティング インスタンスの宛先に転送されます。ただし、このステートメントが設定されている場合でも、デフォルトルーティングインスタンスに関連付けられたトラップレシーバーはすべてのSNMPトラップを受信します。

トラップグループオブジェクトの下で設定された場合、ルーティングインスタンス(またはルーティングインスタンスに属するインターフェイス)に適用されるすべてのv1およびv2cトラップには、コミュニティ文字列でエンコードされたルーティングインスタンス名があります。エンコーディングは、リクエストPDUで使用されるエンコーディングと同じです。

v3フレームワークの下で設定されたトラップの場合、v3メッセージ処理モデルが設定されている場合、ルーティングインスタンス名はコンテキストフィールドで実行されます。他のメッセージ処理モデル(v1またはv2c)では、ルーティングインスタンス名はトラップメッセージヘッダーに含まれません(コミュニティ文字列でエンコードされていません)。

この機能により、ルーティングインスタンスはv3リクエストのコンテキストフィールドで識別されるか、v1リクエストまたはv2cリクエストのコミュニティ文字列でエンコードされます。

コミュニティ文字列でエンコードされた場合、ルーティングインスタンス名が最初に表示され、実際のコミュニティ文字列とは文字で @ 区切られます。

文字を含む有効なコミュニティ文字列との競合を @ 避けるために、典型的なコミュニティ文字列処理に失敗した場合にのみコミュニティが解析されます。例えば、 という名前 RI のルーティングインスタンスが設定されている場合、 の付いた RI@public SNMPリクエストはルーティングインスタンスのコンテキスト内で RI 処理されます。アクセス制御(ビュー、送信元アドレス制限、アクセス権限など)は、実際のコミュニティ文字列(文字の後 @ のデータ セット(ここでは public)に従って適用されます。ただし、コミュニティ文字列 RI@public が設定されている場合、プロトコル データ ユニット(PDU)はそのコミュニティに従って処理され、埋め込まれたルーティング インスタンス名は無視されます。

論理システムは、物理ルーターのアクションのサブセットを実行し、独自のルーティングテーブル、インターフェイス、ポリシー、ルーティングインスタンスを持っています。ルーティングインスタンスが論理システム内で定義されている場合、論理システム名は、2つを分離するためにスラッシュ( / )を使用してルーティングインスタンスと一緒にエンコードする必要があります。例えば、ルーティングインスタンス RI が論理システム LS内で設定されている場合、そのルーティングインスタンスはコミュニティ文字列内で として LS/RI@publicエンコードする必要があります。ルーティングインスタンスが論理システムの外部(デフォルトの論理システム内)で設定されている場合、論理システム名(または / 文字)は必要ありません。

また、論理システムを作成すると、論理システム内にデフォルトルーティングインスタンス(名前付き default)が常に作成されます。この名前は、そのルーティング インスタンスのデータ(例: LS/default@public)のクエリーに使用する必要があります。v3 リクエストの場合、名前 logical system/routing instance はコンテキスト フィールドで直接識別する必要があります。

この例では、INFrtdという名前のルーティングインスタンスに割り当てられた802.3ad ae0インターフェイス設定を示しています。

以下 snmpwalk のコマンドは、SNMPコミュニティ publicでルーティングインスタンスINTtdに属するルーター1および802.3aeバンドルインターフェイスからSNMP関連情報を取得する方法を示しています。