どの SNMP テーブルが VPNv4 ルートをそのラベルに結び付けるのか
必要なラベルを選び、VRF ルートエントリをクロスコネクトとそのセグメントへ結び付けます。ウォークの前に、エージェントがそれらのオブジェクトを実装していることを確認してください。
一つの VPNv4 ルートには三つの異なるラベルが付いて回りますが、SNMP ウォークで見えるのはエージェントが実装しているものだけです。受信した BGP 属性、ローカルで割り当てられた受信側のサービスラベル、送信側の転送ラベルは、それぞれ別のインデックスの下、別のテーブルにあります。三つのうちどれを指すのかを先に選ばずに機器へラベルを問い合わせるのが、収集プロジェクトが最初のシャーシで行き詰まる原因です。
必要なラベルを選び、そこへ到達するインデックスの連鎖をたどります。連鎖がエージェント未実装のオブジェクトで途切れたら、それは記録すべき所見であり、でっち上げた OID で埋めるべき穴ではありません。
タスクが必要とするのは三つのうちどのラベルかを選ぶ
ピアから受け取るラベルは BGP パス属性として届き、そのピアがこちらに何を押し出してほしいと期待しているかを表します。受信側のサービスラベルはこの機器が VRF プレフィックスに対して割り当てるもので、LSP に入るトラフィックに印を付けます。送信側の上段ラベルは転送プレーンが実際に次ホップへ押し出すもので、次ホップが変われば必ず変わります。
転送状態としてポーリング対象の箱に属するのは二つ目と三つ目だけです。一つ目は隣接ノードの期待についての記述であり、このシャーシについてのものではありません。
標準の L3VPN MIB は VRF ルートとそのクロスコネクトへの関連をモデル化しており、ローカルのサービスラベルと転送ラベルに到達するには十分です。BGP セッションが受け取ったすべての属性のダンプを約束するものではありません。テーブルは問いがほのめかすものではなく、実際に保持しているものについて読みます。誤った前提で組んだコレクタはゼロを報告し、それを欠損データとして記録します。
| What you want | Where it lives | What a walk can return |
|---|---|---|
| Label advertised by a peer | BGP session state for that VRF | Usually outside the standard L3VPN MIB |
| Incoming service label for a prefix | VRF route entry joined to an incoming segment | Available when both tables are implemented |
| Label pushed toward the next hop | Outgoing segment with a push condition | Available, but only meaningful while a top label is pushed |
VRF ルートエントリをクロスコネクトへ結び付ける
RFC 4382 は mplsL3VpnVrfRteTable を定義しています。インデックスは六つの部分として読みます。VRF 名、宛先のアドレス種別、プレフィックス自体、ポリシー値、次ホップの種別、次ホップのアドレスです。IGP と BGP のエントリは同じテーブルを共有するので、プレフィックスの隣にルーティングプロトコルを記録します。同じプレフィックスを持つ二つの行が次ホップだけ違うことがあり、誤った行を選ぶと結合は別のクロスコネクトへ向かいます。
列 mplsL3VpnVrfRteXCPointer は名前とは裏腹に、完全な行 OID ではなくクロスコネクトのインデックスを保持します。一オクテットのゼロ値は関連するラベルスタックがないことを意味し、バインディングが落ち着く前や、そもそも必要としなかったルートで見られます。
ウォークする前に列を翻訳しておき、出力の数値サブツリーが曖昧でないようにします。以下の二つのコマンドは同じノードを別の表記で指しています。
snmptranslate -m +MPLS-L3VPN-STD-MIB -On mplsL3VpnVrfRteXCPointer snmpwalk -v2c -c monitor 192.0.2.10 mplsL3VpnVrfRteXCPointer
返ってきたインデックスをクロスコネクトのテーブルへ持ち込みます。エントリキーはクロスコネクトのインデックス、受信側セグメントのインデックス、送信側セグメントのインデックスという三つ組であり、この三つ組がルートをラベルに変える結合です。テーブル全体ではなく特定のインデックスについてクロスコネクトのサブツリーをウォークします。インデックス指定の読み取りが関連を保ち、一括ウォークは保たないからです。
ラベル番号ではなくインデックスを読む
セグメントのインデックスは行を特定し、ラベルはその行の中の値なので、一方を他方で置き換えると、もっともらしく見えるのに誤った LSP を指す答えになります。受信側では、行が別の場所のエントリを参照する場合にオブジェクトがラベルテーブルへのポインタを持つことがある点に注意しつつ、インターフェースとラベルのコンテキストを mplsInSegmentLabel と併せて確認します。
送信側では、送信インターフェースと、行が上段ラベルを押し出すと述べているかを mplsOutSegmentTopLabel を読む前に確認します。何も押し出さない行で上段ラベルの列が埋まっているのは、古い値か以前のパスの残りであり、現在の転送状態ではありません。より深いスタックには参照先のラベルスタックテーブルが必要で、その余分な段は正常であり、欠陥ではありません。
ゼロに関する特別な約束事は、ルータでローカルに始まる、または終わるパスに適用されます。ゼロのインデックスは空の結果ではなく文書化された動作として扱い、ローカルの転送状態と突き合わせて確認します。
スケールする前にエージェントの実装を確認する
実装済みのオブジェクトを、正確なプラットフォームとリリース、使用中のアドレスファミリ、サブツリーに対する運用上の制約について検証します。読み取り専用でそれらのサブツリーに限定した資格情報でポーリングし、オブジェクトが欠けていれば機能が未実装である可能性があり、MIB が誤っているわけではないと受け入れます。
コレクタをテーブル全体に向ける前に、既知の VRF ルートを機器自身の運用出力と突き合わせます。ウォークの間にルートとバインディングは動くので、各サンプルにはインデックスの構成要素と収集時刻をすべて添えます。数分差の二回のウォークを縫い合わせたスナップショットは、古いクロスコネクトのインデックスと新しいルートを混ぜてしまい、完全に整合しているように見えることがあります。
受信側 BGP のビューやベンダ固有のラベルオブジェクトが本当に欠けている場合は、プラットフォームが文書化しているテレメトリまたは運用インターフェースへ移ります。標準の結合が覆うのはローカルの転送ラベルとわずかなもので、収集設計の仕上げではなく最初の一歩として扱います。