VPN 越しの PIM-SM：BSR、RP マッピング、RPF 経路を確認する

トンネルは上がっており、ユニキャスト ping も通るのに、受信側はまだ黒い画面のままです。PIM-SM の配備では、この症状はほぼ常に四本の制御パスのうち一本が壊れていることを意味し、データパス自体が問題だったことはありません。下のリストを順にたどり、後続の手順はすべて前の手順に依存するため、失敗した最初の手順で止めてください。私はこの五つの確認を下書きファイルに保存しておき、マルチキャストの苦情が来たときに端末へ貼り付けることで、診断が当て推量になるのを防いでいます。

トンネルではなく受信側から始める

グループを一度も要求していない受信側は、どのルーターにも状態を作らないため、他の何かを調べる前に受信側向きのセグメントに参加が存在することを確認してください。Cisco 系のプラットフォームでは、最終ホップのルーターで show ip igmp groups を実行すると、参加したグループがそれを聞き取ったインターフェースの隣に表示されます。その出力にグループがない場合、トンネルは注意をそらす存在であり、要求はアクセススイッチ、ホストのソケット、または querier のいない VLAN で死んでいます。

私が見てきた参加の欠落のほとんどは、ホストとルーターの間の IGMP バージョンの不一致と、ルーティングしないスイッチで querier 選出が行われたという二つのありふれた原因で説明できます。三つ目はより微妙で、ホストにネットワークカードが二枚ありアプリケーションが誤った方に結び付いているため、グループには参加しているが誤った VLAN にいるというものです。IPv6 の受信側も MLD で同じ問題を抱え、そこでは show ipv6 mld groups が同じ問いに答えます。これらはいずれもトンネルに触れて直るものではなく、まさにそのために順序が重要です。

参加が見えるようになったら、受信側向きのインターフェースとランデブーポイントへ向かうインターフェースの両方で PIM が有効になっていることを確認してください。IGMP メンバーシップはあるが上流インターフェースで PIM がないルーターは、グループをローカルテーブルに保持したまま、どこにも何も送りません。

BSR セットは反対側に届いているか。

Bootstrap Router メッセージは 一つの PIM ドメイン内をホップごとに移動し、トンネル越しに壊れるのはまさにその方向です。候補 RP は自分の告知をユニキャストで選出された BSR に送るため、RP から BSR までの区間は動作中のトンネルでも通常はそのまま生き残ります。逆方向の Bootstrap メッセージのフラッドは、中間の各インターフェースで PIM が有効であることと、境界でメッセージを止めるものがないことに依存します。RFC 5059 はその配布と、それを短くすることを許される管理スコープの境界を定義しています。

ip pim bsr-border の記述、プロトコル 103 をフィルタリングする ACL、マルチキャストを運べないポリシーベースの IPsec トンネルのいずれもがフラッドを切り、ユニキャストは無傷のまま残ります。この組み合わせが、実際には到達性の問題であるのに障害を RP の問題に見せかける原因であり、だからこそ私は RP 設定より先に BSR の状態を読みます。

反対側のルーターでは、show ip pim bsr-router が選出された BSR と学習した RP セットを表示し、出力が空であれば反対側は自らのドメインに閉じこもっており、どれだけ RP を設定しても両者は一致しません。トンネルの両側で show ip pim rp mapping のグループ範囲と RP アドレスを比較してください。ローカルにしか存在しないマッピングは、誤った場所で終わる共有ツリーを生み、受信側は永遠に待ち続けます。

トンネルの両側で RP マッピングを一致させる

静的 RP、BSR、anycast-RP は同じ問いへの三つの答えであり、それらをトンネル越しに混ぜるのは決して収束しないドメインを作る確実な方法です。ヘッドエンドが BSR を使い、ブランチが別のアドレスを指す静的 ip pim rp-address を使うと、ブランチは受信側の存在を知らない RP に向けて共有ツリーを構築します。マッピングは、より具体的な範囲が広い範囲に勝つため、グループ範囲とアドレスの両方で一致している必要があります。

anycast-RP は二つの拠点が一つの RP アドレスを共有できるようにするために存在し、「同じ RP」の意味が変わるためここで名前を挙げる価値があります。一つのアドレスを告知する二つの RP は設計上一貫していますが、同じ範囲に対して異なるアドレスを告知する二つの RP は、各拠点が単独ではどれほど健全に見えても一貫していません。

232.0.0.0/8 内の送信元固有マルチキャストでは RP は決して参照されない ため、空の RP マッピングは自動的に異常ではありません。決して必要とされなかった RP を追う前に、アプリケーションがどのサービスモデルを使うかを決めてください。

送信元へ向かう RPF ルックアップを読む

PIM はユニキャスト経路を逆にたどってツリーを作るため、重要な確認は送信元への戻り経路、共有ツリーの場合は RP への戻り経路です。ルーターが上流とみなさないインターフェースに到着した参加は破棄され、その理由はトンネルの障害ではなく RPF の失敗として記録されます。トンネル越しの既定ルートと WAN 越しのより具体的なルートを持つブランチルーターでは、送信元にトンネル経由でしか到達できないにもかかわらず、RPF インターフェースが WAN になることは容易にあります。これが参加が黙って捨てられる最も一般的な唯一の理由です。

show ip rpf 192.0.2.10 は選択されたインターフェース、次ホップ、その判断を生んだ経路を表示し、通常はそれだけで不一致が分かります。ip mroute 192.0.2.0 255.255.255.0 tunnel0 のような静的マルチキャストルートはそのプレフィックスのユニキャストルックアップを上書きし、マルチキャストトポロジーがユニキャストトポロジーと本当に異なるときには正当な修正です。これは文書化すべき設定として扱い、障害対応中に当てて忘れるパッチとして扱わないでください。

ping ではなくコマンドで参加を確認する

ping はユニキャストが動くことを示しますが、それは既にご存じのはずです。端から端までの確認は、参加、マッピング、ネイバー、ツリーをこの順に示す一連の手順であり、各コマンドは異なる問いに答えます。

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

実際の入力インターフェースと空でない出力リストを持つ (S,G) エントリが埋まっていれば、制御プレーンは仕事を終えています。入力インターフェースが Null と表示されるエントリ、または増え続ける RPF failed というラベルのカウンターは、トンネルではなく前の節を指しています。

五つのコマンドがすべて正しく見えるのに受信側が何も見えない場合、残る容疑者は、ユニキャストルーティングプロトコルは許可するが PIM、IGMP、グループトラフィック自体は許可しない暗号 ACL やファイアウォール規則というトンネル自体のポリシーです。ポリシーベースの IPsec トンネルではマルチキャストはまったく運ばれないため、答えはフィルタの例外ではなく GRE か VTI の設計です。何かを変える前に五つの確認のどれが失敗したかを書き留め、そのレイヤーだけを変えてください。