ルーティングインスタンスの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 を参照してください。

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

[edit snmp]
logical-system-trap-filter;

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)はそのコミュニティに従って処理され、埋め込まれたルーティングインスタンス名は無視されます。

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

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

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

[edit chassis]
aggregated-devices {
    ethernet {
        device-count 5;
    }
}
[edit interfaces ae0]
vlan-tagging;
aggregated-ether-options {
    minimum-links 2;
    link-speed 100m;
}
unit 0 {
    vlan-id 100;
    family inet {
        address 10.1.0.1/24;
    }
}
[edit interfaces fe-1/1/0]
fastether-options {
    802.3ad ae0;
}
[edit interfaces fe-1/1/1]
fastether-options {
    802.3ad ae0;
}
[edit routing-instances]
INFrtd {
    instance-type virtual-router;
    interface fe-1/1/0.0;
    interface fe-1/1/1.0;
    interface fe-1/1/5.0;
    interface ae0.0;
    protocols {
        ospf {
            area 0.0.0.0 {
                interface all;
            }
        }
    }
}

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

router# snmpwalk -Os router1 INFrtd@public dot3adAggTable
dot3adAggMACAddress.59 = 0:90:69:92:93:f0
dot3adAggMACAddress.65 = 0:90:69:92:93:f0
dot3adAggActorSystemPriority.59 = 0
dot3adAggActorSystemPriority.65 = 0
dot3adAggActorSystemID.59 = 0:0:0:0:0:0
dot3adAggActorSystemID.65 = 0:0:0:0:0:0
dot3adAggAggregateOrIndividual.59 = true(1)
dot3adAggAggregateOrIndividual.65 = true(1)
dot3adAggActorAdminKey.59 = 0
dot3adAggActorAdminKey.65 = 0
dot3adAggActorOperKey.59 = 0
dot3adAggActorOperKey.65 = 0
dot3adAggPartnerSystemID.59 = 0:0:0:0:0:0
dot3adAggPartnerSystemID.65 = 0:0:0:0:0:0
dot3adAggPartnerSystemPriority.59 = 0
dot3adAggPartnerSystemPriority.65 = 0
dot3adAggPartnerOperKey.59 = 0
dot3adAggPartnerOperKey.65 = 0
dot3adAggCollectorMaxDelay.59 = 0
dot3adAggCollectorMaxDelay.65 = 0

この例では、コミュニティmyCommunity1向けのルーティングインスタンスInBandManagementの設定を示します。

ルーティング インスタンスは、インターフェイス et-0/0/16に制限されます。制限付きクライアントは、ポリシー オプションで SNMPClients として構成されます。

user@host# show interfaces
      et-0/0/16:0 {
        unit 0 {
            family inet {
                address 192.168.1.3/24;
            }
        }
    }
user@host# show policy-options
            prefix-list SNMPClients {
                10.0.10.2/32;
                192.168.1.2/32;
    }
user@host# show snmp
 {
            community myCommunity1 {                   
                authorization read-only;
                routing-instance InBandManagement {
                    client-list-name SNMPClients;
                }
            }
              routing-instance-access;
        }

user@host# show routing-instances
routing-instances {
    InBandManagement {
        instance-type virtual-router;
        interface et-0/0/16:0.0;
    }
}

次の snmpwalk コマンドは、設定されたクライアントからインターフェイス et-0/0/16 に routinginstance@community として SNMP 要求を送信する方法を示しています。

user@ubuntu:~# snmpwalk -v2c -c InBandManagement@myCommunity1 -On 192.168.1.3 SNMPv2-MIB::sysDescr