NX-OSを搭載したNexus 9000でのマルチキャストAuto-RPのトラブルシューティング

はじめに

このドキュメントでは、NX-OSを搭載したCisco Nexus 9000で自動RPがどのように動作するか、およびマルチキャストの動作を検証してトラブルシューティングする方法について説明します。

前提条件

要　件

• IPマルチキャストの基礎知識
• IGMPとPIMスパースモードに関する基礎知識
• Cisco Nexus 9000およびNX-OS CLIの使用経験
• ユニキャストルーティングとRPFの概念の理解

使用するコンポーネント

• Cisco Nexus 9000 シリーズ スイッチ ページ
• Cisco NX-OS ソフトウェア
• PIM Sparse モード（PIM sparse mode）＃PIM Sparse もーど＃
• スタティックRPおよびAuto-RP

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

マルチキャスト概要

マルチキャストは1対多の通信モデルで、送信元が1つのトラフィックストリームを対象の複数の受信者に送信します。宛先ごとに個別のコピーを作成する代わりに、ネットワークは転送パスが分岐する場所にのみトラフィックを複製します。これにより、ブロードキャストや繰り返されるユニキャスト送信よりもマルチキャストの方が効率的になります。IPv4では、マルチキャストトラフィックは224.0.0.0/4の範囲からの宛先アドレスを使用します。

PIMスパースモードは、NX-OSを実行するCisco Nexusスイッチでサポートされるマルチキャストルーティングモデルです。受信側の関心が明示的に学習された場合にのみ、トラフィックを転送する。Any-Source Multicast設計では、レシーバは最初にランデブーポイント(RP)に向けて共有ツリーに参加し、送信元はそのRPに登録されます。トラフィックが流れ始めると、最後のホップルータは共有ツリーから送信元に向かう最短パスツリーに移動できます。

正確なトラブルシューティングはコントロールプレーンイベント、ルーティングエントリ、および転送の決定がどのように表現されるかを理解することが重要であるため、マルチキャストで使用される用語を定義することが重要です。明確な用語は、コマンド出力を正しく解釈し、共有ツリーとソースツリーの動作を区別し、エンドツーエンドの転送プロセスにおける各マルチキャストコンポーネントの役割を特定するのに役立ちます。

用語	定義
マルチキャストグループアドレス	マルチキャストグループの識別に使用される224.0.0.0/4の範囲のIPv4宛先アドレス。
送信元アドレス	マルチキャストグループにトラフィックを送信する送信者のユニキャストIPアドレス。
mroute	グループまたはソースグループの組み合わせのマルチキャストトラフィックの処理方法を定義するマルチキャストルーティングエントリ。
IIF	着信インターフェイス.マルチキャストトラフィックが到達すると予想されるインターフェイス。
OIF	発信インターフェイス.受信者または下流近接デバイスにマルチキャストトラフィックを転送するために使用されるインターフェイス。
石油	Outgoing interface list.マルチキャストルーティングエントリに関連付けられた発信インターフェイスのセット。
RPF	Reverse Path Forwarding（リバースパス転送）。マルチキャストトラフィックが送信元またはRPへのユニキャストルートに基づいて正しいインターフェイスに到達したかどうかを検証するチェック。
MDT	マルチキャスト配信ツリー。送信元からすべての受信者にマルチキャストトラフィックを伝送する論理ツリー。
RPT	RPツリー。共有ツリーとも呼ばれます。レシーバをRPに接続し、(*,G)で表されます。
SPT	最短パスツリー。ソースツリーとも呼ばれます。レシーバを送信元に直接接続し、(S、G)で表される
FHR	ファーストホップルータ。マルチキャストルータは送信元に直接接続され、RPへの送信元の登録を行います。
LHR	ラストホップルータ。IGMPを介してレシーバの関心を学習した後、レシーバに直接接続され、マルチキャストステートの作成を担当するマルチキャストルータ。
RP	ランデブーポイント。送信元と受信者を最初に接続するためにASMおよびPIMスパースモードで使用される論理会議ポイント。
アーキテクチャ セールス マネージャ（ASM）	Any-Source Multicastの略。送信側を事前に指定せずに受信側がグループに参加するマルチキャストモデル。

マルチキャストのトラブルシューティングは、特定の宛先グループを使用しているコントロールプロトコルと、トラフィックがネットワーク内で処理している機能をすばやく特定できるかどうかによって異なるため、よく知られた予約済みマルチキャストアドレスを理解することが重要です。これらのアドレスは、正常なプロトコル動作と異常な動作を区別し、IGMP、PIM、およびAuto-RP交換の検証を容易にするために役立ちます。Auto-RPの場合に特に認識すべき最も重要なグループは、RPアナウンスの場合は224.0.1.39、RPディスカバリの場合は224.0.1.40です。これらのグループは、ルータがダイナミックRPマッピングを学習できるようにする情報を伝送するためです。

マルチキャスト アドレス	目的
224.0.0.1	ローカルサブネット上のすべてのホスト
224.0.0.2	ローカルサブネット上のすべてのルータ
224.0.0.13	すべてのPIMルータ
224.0.0.22	IGMPv3メッセージ
224.0.1.39	Auto-RPで使用されるCisco RP-Announceメッセージ
224.0.1.40	Auto-RPで使用されるCisco RP-Discoveryメッセージ

PIMスパースモードでのAuto-RPの動作（コントロールプレーンワークフロー）

Auto-RPは、Protocol Independent Multicast(PIM)スパースモードで使用されるシスコのメカニズムで、ランデブーポイント(RP)情報を動的に検出し、マルチキャストドメイン全体に配布します。マルチキャストベースのコントロールプレーンメッセージを使用してRPからグループへのマッピングをアドバタイズ、選択、および学習することで、スタティックRP設定の必要性がなくなります。主なコンポーネントは、特定のグループ範囲にRPサービスを提供する候補RPと、候補を収集し、グループごとにアクティブなRPを決定するマッピングエージェントです。

このプロセスは、各候補RPがRP-Announceメッセージを224.0.1.39に定期的に送信した時点から始まります。このメッセージには、候補RPのIPアドレス、優先順位、サポートされているマルチキャストグループの範囲が含まれます。これらのメッセージは、NX-OSのAuto-RPリスナーを使用してネットワーク全体にフラッディングされるため、ネットワークがスパースモードで完全に動作する前であっても、すべてのマッピングエージェントがメッセージを受信します。

マッピングエージェントはこれらのアナウンスをリッスンし、候補RPデータベースを構築して、グループごとに決定論的な選択プロセスを実行します（通常は最も高い優先順位、最も高いIPアドレスの順）。 最適なRPが選択されると、Mapping AgentはRPディスカバリメッセージを生成して224.0.1.40に送信し、最終的なRPとグループのマッピングをドメイン内のすべてのルータにアドバタイズします。

すべてのPIMルータはRP-Discoveryメッセージを受信し、マッピングをローカルのRPテーブルにインストールします。この情報を使用して、ラストホップルータ（レシーバに接続）はPIM Joinメッセージを選択したRPに送信し、共有ツリー(RPT)を構築します。一方、ファーストホップルータ（送信元に接続）は、マルチキャストトラフィックをPIM Registerメッセージにカプセル化して、アクティブな送信元をRPに通知します。

トラフィックがRPを通過する際、ルータはオプションで、追加のPIM Join/Pruneシグナリングを使用して、共有ツリー(RPT)から最短パスツリー(SPT)に送信元に向けて直接切り替えることができます。このプロセス全体を通じて、Auto-RPは定期的な制御メッセージによってマッピングを継続的に更新し、トポロジまたはRPの変更に対する復元力と自動適応を確保します。

PIMスパースモードでのAuto-RPの動作（コントロールプレーンワークフロー）

自動RPの制限と運用上の制約

• Auto-RPはIPv4マルチキャストでのみ動作し、IPv6(PIM6)ではサポートされていないため、IPv6を導入するには、別のRPディスカバリメカニズムが必要です。
• コントロールプレーンの競合を回避するために設定できるRPディスカバリメカニズムは1つだけであるため、Auto-RPは同じPIMドメイン内でBSRと共存できません。
• NX-OSデバイスでは、デフォルトでは自動RPメッセージの処理や転送は行われないため、適切に動作させるためには明示的な設定が必要です。
• Auto-RP制御メッセージの伝播は、Auto-RPリスナーの有効化に依存します。そうでない場合、RPマッピング情報はすべてのルータに到達しません。
• RPアナウンス間隔の最小しきい値は15秒です。この値によって、RPアップデートをアドバタイズする速度が制限され、コンバージェンス時間に影響が及びます。
• ルートマップによる自動RPメッセージフィルタリングは、不正なポリシーによってRPからグループへのマッピングがブロックされる可能性があるため、動作に影響を与える可能性があります。
• Auto-RPはVRFコンテキストではデフォルトで無効になっているため、マルチVRF展開では明示的に有効にする必要があります。

• ECMPベースのマルチパス転送はデフォルトで有効になっており、これによりマルチキャストトラフィックはロードバランシングに等コストパスを使用できます。

• IPsec AH-MD5を使用したPIMネイバー認証がサポートされています。

• PIMスヌーピングは使用できません。

Auto-RPを使用する利点

Auto-RPは、PIMスパースモードのマルチキャスト環境に対して、動的なRPディスカバリと集中型のRPマッピング分散を提供します。マルチキャストルータごとにスタティックRPを設定する必要がなくなり、運用の複雑さが軽減され、マルチキャストの拡張性が向上します。Auto-RPは複数のRP-Candidateもサポートしており、RPの自動フェールオーバーと冗長性を実現します。このメカニズムにより、マルチキャスト転送動作の一貫性が維持され、ネットワークの拡張が簡素化され、ドメイン全体でマルチキャストルータがRP情報を自動的に学習できるようになります。

Auto-RPマッピングエージェントとRP選択プロセス

Auto-RPの選択プロセスは決定論的で、主にIPアドレスに基づいています。他のプロトコル（PIMv2 BSRなど）とは異なり、Auto-RPは設定可能な「プライオリティ」値を使用しません。代わりに、IPアドレス階層に依存して競合を解決します。

マッピングエージェント(MA)の選択

Auto-RPでは、冗長性を確保するために、同じネットワーク内に複数のマッピングエージェントを共存させることができます。一方がオフになり、もう一方がオンになる正式な選出プロセスはなく、すべてが技術的にアクティブです。ただし、ネットワーク内のスイッチは、信頼する情報を決定する必要があります。

• 選択基準：最大のIPアドレス。
• プロセス:
  1. すべてのマッピングエージェントは、RPディスカバリメッセージをマルチキャストグループ224.0.1.40に送信します。
  2. クライアントスイッチはこれらのメッセージを受信します。
  3. 競合する情報が含まれている2つの異なるマッピング・エージェントから検出メッセージを受信した場合、スイッチは最も高いソースIPアドレスを持つマッピング・エージェントからの情報を受け入れます。
  4. Nexusの動作：ネットワーク内で制御トラフィックが重複しないようにするため、IPアドレスの小さいMapping Agentは、通常、IPアドレスの大きい別のMAを検出すると、「パッシブ」または「抑制」状態になります。

ランデブーポイント(RP)の選択

このプロセスは、候補からのすべてのRP-Announceメッセージ（グループ224.0.1.39に送信）をリッスンした後に、マッピングエージェントによって実行されます。

Mapping Agentは、同じマルチキャストグループの複数の候補を受信すると、次のルールを順番に適用します。

ルールA：最長プレフィクス照合（最も固有のマスク）

候補が重複する範囲をアナウンスすると、MAは最も小さい範囲（最長のサブネットマスク）をアナウンスしたRPにグループを割り当てます。

• 例：
  • 受験者Aが224.0.0.0/4 (theの全マルチキャスト範囲をアナウンス)。
  • 受験者Bが224.10.20.0/24を発表
  • 結果：グループ224.10.20.5に対して、範囲がより限定的な候補Bが優先されます。

ルールB：最も大きいIPアドレス（同順位の要因）

2つ以上の候補が同じグループ範囲をアナウンスする場合、Mapping Agentは1つだけを選択する必要があります。

• 基準：IPアドレスが最も大きい候補が選択されます。
• 例：
  • 候補1：範囲224.10.20.0/24の10.2.0.1。
  • 候補2：範囲224.10.20.0/24の10.2.0.4。
  • 結果：マッピングエージェントはその範囲の公式RPとして10.2.0.4を選択し、ディスカバリメッセージでこれをアドバタイズします。

レイヤ2の考慮事項：マルチキャストMACとスヌーピング

この記事ではPIMを使用したレイヤ3マルチキャストに焦点を当てていますが、レイヤ2の動作はトラブルシューティングと全体的な設計において重要な役割を果たします。レイヤ2では、デバイスはMACアドレスを使用して通信します。MACアドレスはネットワークインターフェイスに割り当てられる48ビットの識別子です。マルチキャストトラフィックをユニキャストおよびブロードキャストトラフィックと区別するには、特定のMACアドレッシング方式が必要です。

IPv4マルチキャストMACアドレスは、予約プレフィックス「01:00:5E」を使用して、レイヤ3マルチキャストグループアドレスから取得されます。ただし、IPマルチキャストアドレスの23ビットのみがMACアドレスにマッピングされるため、32:1のオーバーラップが作成されます。つまり、最大32個の異なるマルチキャストIPグループを同じMACアドレスにマッピングできます。その結果、特定のマルチキャストMACアドレスをリッスンしているホストは、複数のマルチキャストグループのトラフィックを1つしか受信できません。たとえば、224.1.1.1、225.1.1.1、226.1.1.1、227.1.1.1、228.1.1.1などです。

この重複は、ネットワークの効率性とトラブルシューティングに直接影響します。MACアドレスのみに基づくレイヤ2転送の決定では、重複するマルチキャストグループを区別できないため、スイッチはホストに不要なトラフィックを配信する可能性があります。これらのホストは、上位レイヤフィルタリング(IP/IGMP)を使用して不要なパケットを廃棄し、CPUとバッファリソースを消費します。

Cisco Nexus NX-OSでは、IGMPスヌーピングの動作によってこの制限が緩和されます。デフォルトでは、IGMPスヌーピングはMACのみの転送ではなく、IPベースのルックアップを実行します。これにより、複数のマルチキャストグループが同じMACアドレスを共有する場合でも、スイッチはより正確な転送の決定を行うことができます。これにより、レイヤ2の効率が大幅に向上し、不要なトラフィックの配信が減少します。

Auto-RPの設定

このセクションでは、簡単な実装を参照しながら、Auto-RPの設定について詳しく説明します。この設定では、マルチキャスト送信元がvPC経由で2台のNexusスイッチに接続され、トラフィックが受信者に配信されます。この設計では、N9K-1とN9K-2の両方がRP候補とマッピングエージェントとして同時に機能します。

マルチキャストトラフィックフロー

ファーストホップルータ

同じ設定にFHR-2があります。

FHR-1# show running-config pim
feature pim
ip pim auto-rp forward listen

interface Vlan1
  ip pim sparse-mode

interface Ethernet1/1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

コマンド	目的/説明
機能PIM	スイッチでPIM(Protocol Independent Multicast)プロセスを有効にします。
ip pim auto-rpフォワードリッスン	自動RPリスナーを有効にします。これにより、スイッチはRPのIDをまだ認識していなくても、Auto-RP制御メッセージ（224.0.1.39および224.0.1.40）を受信して転送できます。
ip pim sparse-mode	特定のインターフェイスでPIMスパースモードを有効にします。このモードでは、マルチキャストトラフィックは、PIM Joinメッセージを介して明示的に要求したセグメントにのみ転送されます。

マッピングエージェントおよびRP候補

N9K-1# show running-config pim
feature pim

ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15
ip pim auto-rp mapping-agent loopback1

interface loopback0
  ip pim sparse-mode

interface loopback1
  ip pim sparse-mode

interface Ethernet1/3
  ip pim sparse-mode

interface Ethernet1/4
  ip pim sparse-mode

interface Ethernet1/49
  ip pim sparse-mode

次の表に、N9K-1のPIM設定の技術的な詳細を示します。この設定はN9K-2で複製されます。両方のスイッチは、マルチキャストドメインのRP候補とマッピングエージェントの両方として機能する、デュアルロールで設定されます。

コマンド	詳細な技術説明
機能PIM	機能のアクティブ化：NexusスイッチでProtocol Independent Multicast(PIM)エンジンをグローバルに有効にします。
ip pim auto-rp-candidate loopback0 group-list 224.10.20.0/24インターバル15	RP Candidate Role：ランデブーポイント(RP)としてこのスイッチを「volunteer」に設定します。 送信元：loopback0のIPアドレスを使用 範囲：マルチキャストグループ範囲224.10.20.0/24を処理します。 インターバル：15秒ごとにマッピングエージェントに「アナウンス」メッセージを送信します。ホールドタイマーはこの値の3倍です。
ip pim auto-rp mapping-agent loopback1	Mapping Agent Role：スイッチをAuto-RPプロセスの「管理者」として設定します。 機能：すべてのRP候補をリッスンし、競合を解決し（最も大きいIPアドレスを選出として）、ネットワークの残りの部分に「Discovery」メッセージをブロードキャストして、アクティブなRPを通知します。
インターフェイスループバック0/ループバック1	論理インターフェイス：これらのインターフェイスでは、RP候補およびマッピングエージェントロールの送信元IPとして機能するため、PIMが有効になります。すべてのPIMルータからユニキャストルーティングテーブルを介して到達可能である必要があります。
インターフェイスEthernet1/3、1/4、1/49	Physical Forwarding：物理ポートでPIMスパースモードを有効にします。これにより、スイッチは他のルータとPIM隣接関係を形成し、これらの特定のリンクを介してマルチキャストトラフィックを転送できます。
ip pim sparse-mode	動作モード：上記のすべてのインターフェイスに適用されます。これにより、マルチキャストトラフィックはPIM Joinメッセージを介して明示的に要求した受信者にのみ送信され、不要なネットワークフラッディングが防止されます。

IPv4到達可能性のためのルーティング設定

• このトポロジでは、すべてのNexusスイッチがUNDERLAYという名前の単一のOSPFプロセスに参加し、エリア0(0.0.0.0)内で動作してネットワーク全体の完全なルーティング到達可能性を提供します。
• LHRでは、マルチキャスト受信側のゲートウェイとして機能するVLAN 2と、ポイントツーポイントとして設定されたアップリンクインターフェイスEthernet1/49およびEthernet1/50でOSPFが有効になっています。これにより、DR/BDR選定を行うことなく、アップストリームのN9Kスイッチへの効率的な隣接関係形成が可能になります。
• FHRレイヤ（FHR-1およびFHR-2）は同じ設定を共有します。OSPFは、マルチキャストソースのゲートウェイとして機能するVLAN 1と、アグリゲーションレイヤへのルーテッドアップリンク（Ethernet1/1およびEthernet1/3）で有効になっています。これらのリンクはポイントツーポイントとしても設定され、コンバージェンスと隣接関係の動作を最適化します。
• 同様に、N9K-1とN9K-2のOSPF設定は同じで、OSPFにLoopback0およびLoopback1アドバタイズメントが追加されています。
  • これらのループバックは、後でPIM RP候補およびマッピングエージェントのロールに使用されるため、重要です。

PIMネイバーとOSPFエリア0

N9K-1:OSPF設定

N9K-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY
  router-id 10.2.0.1

interface loopback0
  ip router ospf UNDERLAY area 0.0.0.0

interface loopback1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/4
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

FHR-1:OSPFの設定

FHR-1(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan1
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/1
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/3
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

LHR:OSPFの設定

LHR(config)# show running-config ospf
feature ospf

router ospf UNDERLAY

interface Vlan2
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/49
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

interface Ethernet1/50
  ip ospf network point-to-point
  ip router ospf UNDERLAY area 0.0.0.0

動作状態の確認とAuto-RPのトラブルシューティング

ステップ1：基本的なIP到達可能性の確認（ユニキャストアンダーレイ検証）

マルチキャストの動作を分析する前に、ユニキャストアンダーレイ（OSPFエリア0）が完全に動作していることを確認することが重要です。PIMやAuto-RPなどのマルチキャストコントロールプレーンプロトコルは、正常に機能するユニキャストの到達可能性に依存します。

最初の検証ステップは、送信元と受信側（または最も近いレイヤ3ゲートウェイ：FHRとLHR）が到達可能であることを確認することです。

トポロジから次の操作を実行します。

• FHR-1/FHR-2→マルチキャストソースに最も近い(10.150.1.37 - VLAN 1)

• マルチキャスト受信側に最も近いLHR →(192.168.2.37 - VLAN 2)

検証アプローチ

1. ICMP到達可能性テストを次の範囲で実行します。

• FHR ↔ LHR

• FHR ↔レシーバサブネット（VLAN 2ゲートウェイ）

• LHR ↔送信元サブネット（VLAN 1ゲートウェイ）

2. ルーティングテーブルの送信元と受信側の到達可能性を検証する。vPCの導入では、両方のNexusピアで一貫性を確保します。受信側にはECMPパスがありますが、送信元にはレイヤ2経由で到達できることに注意してください。

FHR-1：送信元へのルート

FHR-1# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 06:57:19, am

FHR-1：レシーバへのルート

FHR-1# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.6, Eth1/3, [110/45], 04:11:08, ospf-UNDERLAY, intra
    *via 10.4.0.10, Eth1/1, [110/45], 04:11:08, ospf-UNDERLAY, intra

FHR-2：送信元へのルート

FHR-2# show ip route 10.150.1.37

10.150.1.37/32, ubest/mbest: 1/0, attached
    *via 10.150.1.37, Vlan1, [250/0], 07:03:45, am

FHR-2：レシーバへのルート

FHR-2# show ip route 192.168.2.37

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 04:16:16, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 04:16:16, ospf-UNDERLAY, intra

LHR：送信元へのルート

LHR(config)# show ip route 10.150.1.37

10.150.1.0/24, ubest/mbest: 2/0
    *via 10.4.0.22, Eth1/49, [110/45], 04:14:52, ospf-UNDERLAY, intra
    *via 10.4.0.26, Eth1/50, [110/45], 04:14:52, ospf-UNDERLAY, intra

LHR：レシーバへのルート

LHR(config)# show ip route 192.168.2.37

192.168.2.37/32, ubest/mbest: 1/0, attached
    *via 192.168.2.37, Vlan2, [250/0], 06:47:21, am

重要な考慮事項

• このテストに失敗した場合は、アンダーレイに問題があることを強く示します。

• 次の理由から、マルチキャストはユニキャストの到達可能性がないと正常に機能しません。

  • PIMネイバーはユニキャストルーティングに依存する

  • RP（ループバック）アドレスに到達できる必要がある

  • RPF(Reverse Path Forwarding)チェックはルーティングテーブルによって異なります

• pingが成功しても、次の理由からマルチキャストが機能するとは限りません。

  • マルチキャストがブロックされている間、ICMPを許可できる

  • PIMまたはAuto-RPの設定に誤りがある

手順2：マルチキャストの役割とエンドツーエンドのトポロジを特定する

次のステップでは、マルチキャストトラフィックの転送に関係する各デバイスの役割を明確に特定します。マルチキャストのトラブルシューティングは、トポロジ全体のトラフィックフローと予想される動作の理解に完全に依存するため、これは必須の手順です。

少なくとも、次の要素を特定する必要があります。

• マルチキャストソース(S):10.150.1.37(VLAN 1)

• マルチキャストグループ(G):224.10.20.10

• レシーバ：192.168.2.37(VLAN 2)

• ファーストホップルータ(FHR):FHR-1/FHR-2（送信元に最も近い）

• ラストホップルータ(LHR):LHR（レシーバに最も近い）

さらに、コントロールプレーンのロールを特定する必要があります。

• RP候補：N9K-1およびN9K-2(Loopback0)

• マッピングエージェント：N9K-1およびN9K-2(Loopback1)

トポロジとコントロールプレーンの認識

マルチキャストのトラブルシューティングを続行するには、詳細なネットワークトポロジが必須です。これには、次のような特徴があります。

• 物理接続（デバイス間で使用されるインターフェイス）

• 論理トポロジ（VLAN、ルーテッドリンク、vPCの関係）

• 使用されているルーティングプロトコル（この設計ではOSPFエリア0）

• ルーティングドメインの境界（単一のIGPとOSPF、EIGRP、BGPなどの混合プロトコルの比較）

• RPおよびマッピングエージェントロールに使用されるループバックインターフェイス

• PIM対応インターフェイスおよびネイバー関係

明確に理解しておくべきこと

• 送信元からFHR、RP→LHR→レシーバ→の正確なパ→

• どのデバイスが原因か：

  • PIMレジスタ(FHR)の送信

  • 建物(*,G)または(S,G)の樹木(LHR)

  • RP情報のアドバタイジング(Mapping Agent)

• ルーティング(OSPF)によって到達可能性を確保する方法：

  • 送信元サブネット

  • 受信側サブネット

  • RPループバックアドレス

  • エージェントループバックアドレスのマッピング

ステップ3：デバイスロールに基づいた自動RP設定の検証

次の手順では、マルチキャストトポロジでの役割に従って、各デバイスでAuto-RPが正しく設定されていることを確認します。これには、以下の確認が含まれます。

• RP候補(N9K-1/N9K-2)は、マルチキャストグループ範囲のRPとしてLoopback0をアドバタイズするように適切に設定されています。

• マッピングエージェント(N9K-1/N9K-2)は、RP-Announceメッセージを収集し、Loopback1を使用してRP-Discoveryメッセージを生成するように設定されています。

• FHRおよびLHRでは、Auto-RPに参加してRPマッピングを受信するために、関連するすべてのインターフェイスでPIMスパースモードが有効になっています。

必要なすべてのインターフェイス（ループバックとルーテッドリンクを含む）がPIMスパースモードに対してイネーブルにされていることを確認し、RP-Announce(224.0.1.39)とRP-Discovery(224.0.1.40)メッセージの交換を妨げる設定が欠落していないことを確認する必要があります。

ステップ4：すべてのRP候補およびすべてのマッピングエージェントの動作を検証する

手順4.1 PIMネイバー/アジャセンシー関係の確認

最初の検証ステップは、想定されるすべてのPIMネイバーがマルチキャストトポロジ全体で正しく確立されていることを確認することです。

N9K-1:PIMネイバーの確認

N9K-1# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.5        Ethernet1/3          23:19:45  00:01:20  1        yes     n/a     no
10.4.0.14       Ethernet1/4          23:19:45  00:01:38  1        yes     n/a     no
10.4.0.21       Ethernet1/49         23:19:45  00:01:38  1        yes     n/a     no

N9K-2:PIMネイバーの確認

N9K-2# show ip pim neighbor

PIM Neighbor Status for VRF "default"
Neighbor        Interface            Uptime    Expires   DR       Bidir-  BFD    ECMP Redirect
                                                         Priority Capable State     Capable
10.4.0.9        Ethernet1/3          23:21:18  00:01:29  1        yes     n/a     no
10.4.0.17       Ethernet1/4          23:21:18  00:01:23  1        yes     n/a     no
10.4.0.25       Ethernet1/49         23:21:18  00:01:44  1        yes     n/a     no

検証ポイント

• 予想されるすべてのネイバーがすべてのルーテッドインターフェイスに表示されることを確認します。
• ネイバーの稼働時間が安定しており、継続的に増加していることを確認します。
• Expiresタイマーが定期的に更新されることを確認します。
• 予期しない隣接関係のフラップが発生していないことを確認します。
• 正しい代表ルータ(DR)の選定を確認します。
• マルチキャストインターフェイスがPIM隣接関係を正常に形成することを確認します。

このトポロジでは、次のようになります。

• N9K-1は3つのPIMネイバーを確立する
• N9K-2も3つのPIMネイバーを確立します。
• すべての隣接関係は23時間以上にわたって安定しており、マルチキャストコントロールプレーンが安定して動作していることを示しています。

---

手順4.2 PIM対応インターフェイスの確認

次のステップでは、Auto-RPに参加しているすべてのインターフェイスでPIMが有効になっていることを確認します。

この検証は、次の場合に特に重要です。

• RP候補ループバック
• Mapping Agentループバック

N9K-1:PIMインターフェイスの確認

N9K-1# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.6        10.4.0.6        1         no
Ethernet1/4          10.4.0.13       10.4.0.14       1         no
Ethernet1/49         10.4.0.22       10.4.0.22       1         no
loopback0            10.2.0.1        10.2.0.1        0         no
loopback1            10.2.1.5        10.2.1.5        0         no

N9K-2:PIMインターフェイスの確認

N9K-2# show ip pim interface brief

PIM Interface Status for VRF "default"
Interface            IP Address      PIM DR Address  Neighbor  Border
                                                     Count     Interface
Ethernet1/3          10.4.0.10       10.4.0.10       1         no
Ethernet1/4          10.4.0.18       10.4.0.18       1         no
Ethernet1/49         10.4.0.26       10.4.0.26       1         no
loopback0            10.2.0.4        10.2.0.4        0         no
loopback1            10.2.1.4        10.2.1.4        0         no

検証ポイント：

• ルーティングされたすべてのマルチキャストインターフェイスが出力に表示されることを確認します。
• RP候補ループバックがPIM対応であることを確認します。
• マッピングエージェントのループバックがPIM対応であることを確認します。
• 中継インターフェイスでネイバー数が正しいことを確認します。
• ループバックインターフェイスでNeighbor Count = 0が正しく表示されることを確認します。

ループバックロール割り当て：

デバイス	機能	ループバック
N9K-1	RP候補	10.2.0.1
N9K-1	マッピングエージェント	10.2.1.5
N9K-2	RP候補	10.2.0.4
N9K-2	マッピングエージェント	10.2.1.4

ループバックは、PIMネイバーを形成していなくても、アクティブPIMインターフェイスとして正しく表示されます。ループバックインターフェイスはマルチキャスト隣接関係を直接確立しないため、この動作が予想されます。

これらのループバックの存在は、次のことを確認します。

• PIMはAuto-RP制御メッセージを正しく送信できます。
• RPアドバタイズメントは正常に発信できます。
• マッピングエージェント機能は正常に動作できます。

---

手順4.3 show ip pim rpの分析

このコマンドでは、次の項目を検証します。

• RPディスカバリ
• 自動RPアドバタイズメント
• Mapping Agentのオペレーション
• グループとRPのマッピング

N9K-1:RP情報

N9K-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5*, next Discovery message in: 00:00:39
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.1*, (0),
 uptime: 22:18:44   priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:37 (A)

RP: 10.2.0.4, (0),
 uptime: 23:00:32   priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:00:44 (A)

行単位の説明

BSRが無効

BSR disabled

これにより、次のことが確認されます。

• ブートストラップルータ(BSR)は使用されません。
• マルチキャストドメインはAuto-RPにのみ依存します。

このトポロジでは、この動作が予想されます。

自動RP RPA:10.2.1.5*

Auto-RP RPA: 10.2.1.5*

• 10.2.1.5はN9K-1のloopback1に対応します。
• * は、ローカル・スイッチ自体がアクティブなMapping Agentであることを示します。

この場合、次を意味します。

• N9K-1がRP-Discoveryメッセージを発信します。
• N9K-1は、RP候補からRPアナウンスを収集します。
• N9K-1は、RPマッピング情報をマルチキャストドメインに配信します。

での次の検出メッセージ

next Discovery message in: 00:00:39

• タイマーが継続的に更新されることを確認します。
• ディスカバリメッセージが定期的に送信されることを確認します。

このタイマーが予期せずフリーズまたは期限切れになった場合、Auto-RPアドバタイズメントは正しく伝搬されません。

ポリシーフィールド

BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

• フィルタリングポリシーは適用されません。
• すべてのRPアナウンスとディスカバリアドバタイズメントが受け入れられます。

最初のRPエントリ

RP: 10.2.0.1*, (0),

• RPアドレス= 10.2.0.1
• * は、このRPがN9K-1に対してローカルであることを示します。
• 10.2.0.1はN9K-1のloopback0に対応します。

これにより、N9K-1がRP候補として設定されていることが確認できます。

稼働時間と優先度

uptime: 22:18:44   priority: 255,

• 安定した稼働時間は、安定したRPアドバタイズメント動作を示します。
• プライオリティ255は、デフォルトで最も高い優先度です。

RPソース

RP-source: 10.2.0.1 (A),

• RPアドバタイズメントは、RP自体から直接発信されています。
• (A)は、Auto-RPが学習した情報を示します。

グループ範囲

224.10.20.0/24

• 正しいマルチキャスト範囲がアドバタイズされることを確認します。
• グループ範囲が設定と一致していることを確認します。

2番目のRPエントリ

RP: 10.2.0.4, (0),

• 別のRPがトポロジに存在します。
• 10.2.0.4はN9K-2のloopback0に対応します。
• このRPはN9K-1からリモートであるため、*は表示されません。

N9K-2:RP情報

N9K-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 22:19:10, expires: 00:02:28

RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:28 (A)

N9K-2の主な違い

Auto-RP RPA: 10.2.1.5

• N9K-2がマッピングエージェントではないため、*は表示されません。
• N9K-2は、N9K-1からマッピングエージェント情報をリモート学習します。

重要なRPの違い

RP-source: 10.2.1.5 (A),

• N9K-2は、RP情報をマッピングエージェントから学習します。
• Mapping Agentは10.2.1.5です。

これにより、次のことが確認されます。

• 自動RP検出メッセージは正常に機能しています。
• マッピングエージェントアドバタイズメントは、マルチキャストドメインを介して正常に伝搬されます。

手順4.4 Auto-RP選択プロセスとRP選択の検証

Auto-RPは、2つの異なるマルチキャストコントロールプレーン機能を使用します。

• RP候補
• マッピングエージェント

PIMスパースモード環境でマルチキャストの動作を検証する際には、これらの関数の相互作用を理解することが重要です。

このトポロジでは、次のようになります。

• N9K-1とN9K-2はRP候補として動作します。
• N9K-1はアクティブなマッピングエージェントとして動作します。

RP候補の動作

RP候補は、1つ以上のマルチキャストグループ範囲の有効なランデブーポイント(RP)として自身をアドバタイズします。

各RP候補は、定期的にAuto-RP Announceメッセージを次の宛先に送信します。

• 224.0.1.39 — Auto-RP Announceグループ
  
  

これらのアナウンスには次のものが含まれます。

• RPアドレス
• グループ範囲
• Priority
• ホールドタイム

このトポロジでは、次のようになります。

• N9K-1の10.2.0.1は自身をRPとしてアドバタイズします。
• N9K-2の10.2.0.4は自身をRPとしてアドバタイズします。

N9K-1:RP候補情報

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
 uptime: 23:11:22 priority: 255,
 RP-source: 10.2.0.1 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:38 (A)

RP: 10.2.0.4, (0),
 uptime: 23:53:09 priority: 255,
 RP-source: 10.2.0.4 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:00:43 (A)

N9K-2:RP候補情報

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 1d00h priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24 , expires: 00:02:52 (A)

両方のデバイスが同じマルチキャストグループ範囲をアドバタイズします。

• 224.10.20.0/24

両方のRP候補は、次のコマンドも使用します。

• priority 255

Auto-RPはRPの選択時にプライオリティとRPアドレスを使用するため、これは重要です。

アクティブなマッピングエージェントID

Mapping Agentは、次のロジックで始まるマルチキャストグループのアクティブRPを選択します。

1. 最も高いRPプライオリティが優先されます。
2. 優先順位が等しい場合は、最も大きいRP IPアドレスが優先されます。

このトポロジでは、次のようになります。

• N9K-1 RPアドレス= 10.2.0.1
• N9K-2 RPアドレス= 10.2.0.4
• 両方のRP候補はプライオリティ255を使用します。

両方のRP候補が同じプライオリティを持つため：

• 最大のRP IPアドレスが選択されたRPになります。

したがって

• 10.2.0.4が224.10.20.0/24のアクティブRPになります。

選択したRPの検証

N9K-2：選択されたRP

N9K-2# show ip pim rp
<snip>
RP: 10.2.0.4*, (0),
 uptime: 23:14:14   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24

N9K-1が両方のRPエントリを表示し続ける理由

N9K-1の場合：

N9K-1# show ip pim rp
<snip>
RP: 10.2.0.1*, (0),
RP: 10.2.0.4, (0),

この動作が予期される理由は次のとおりです。

• N9K-1はマッピングエージェントとして動作します。
• Mapping Agentは、すべてのRP候補の可視性を維持します。
• 出力には、最終的なRP選択が配布される前に学習されたすべてのRPアナウンスが表示されます。

ステップ5:RP候補とマッピングエージェントへの到達可能性の確認

PIMスパースモードドメインに参加するすべてのマルチキャストルータは、安定したIP到達可能性を維持して、次のことを実行する必要があります。

• すべてのRP候補
• すべてのマッピングエージェント

PIMスパースモードはユニキャストルーティングに依存して次のことを行うため、この検証は非常に重要です。

• ランデブーポイント(RP)に到達する
• 共有マルチキャストツリー(RPT)の構築
• ファーストホップルータ(FHR)からのPIM登録メッセージの配信
• 自動RP検出アドバタイズメントの受信
• リバースパス転送(RPF)検証の実行

RPまたはマッピングエージェントへの到達可能性が失敗した場合：

• マルチキャストソースは正常に登録されない可能性があります。
• レシーバがマルチキャストグループへの参加に失敗する可能性があります。
• 自動RPアドバタイズメントが正しく伝達されませんでした。
• RPF障害が発生する可能性があります。
• マルチキャストトラフィックの転送が不安定になったり、断続的になったりします。

---

安定したルーティングエントリの確認

ルーティングテーブルには、次の宛先への安定したユニキャストルートが含まれている必要があります。

• すべてのRPループバック
• すべてのMapping Agentループバック
• すべてのマルチキャスト中継インターフェイス

ルートは、ルートフラッピングや過剰な再コンバージェンスイベントを発生させることなく、継続的にインストールされている必要があります。

確認：

• 正しいネクストホップ選択
• 正しい発信インターフェイス
• 安定したルート稼働時間
• 予想されるルーティングプロトコルソース
• マルチキャストドメイン全体で一貫したユニキャスト到達可能性

---

FHR-1:RP候補10.2.0.1へのルート

FHR-1# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1:RP候補10.2.0.4へのルート

FHR-1# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1：マッピングエージェント10.2.1.5へのルート

FHR-1# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-1：マッピングエージェント10.2.1.4へのルート

FHR-1# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra

---

FHR-2:RP候補10.2.0.1へのルート

FHR-2# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2:RP候補10.2.0.4へのルート

FHR-2# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2：マッピングエージェント10.2.1.5へのルート

FHR-2# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra

FHR-2：マッピングエージェント10.2.1.4へのルート

FHR-2# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra

---

LHR:RP候補10.2.0.1へのルート

LHR# show ip route 10.2.0.1

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.1/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR:RP候補10.2.0.4へのルート

LHR# show ip route 10.2.0.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.0.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR：マッピングエージェント10.2.1.5へのルート

LHR# show ip route 10.2.1.5

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.5/32, ubest/mbest: 1/0
    *via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra

LHR：マッピングエージェント10.2.1.4へのルート

LHR# show ip route 10.2.1.4

IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

10.2.1.4/32, ubest/mbest: 1/0
    *via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra

---

PIMインターフェイスからのping到達可能性の確認

ルーティングテーブルを検証した後、次の宛先へのエンドツーエンドIP到達可能性を確認します。

• すべてのRP候補
• すべてのマッピングエージェント

pingの送信元は次の条件を満たしている必要があります。

• PIM対応インターフェイス
• マルチキャストルーティングに参加しているループバックインターフェイス

この検証は重要です。マルチキャストルータでは、次の期間にこれらの発信元アドレスが使用されるためです。

• PIMネイバー確立
• RPFの計算
• PIMレジスタカプセル化
• 自動RP通信

Ping検証の概要

デバイス	送信元 IP	宛先	機能	結果
FHR-1	10.4.0.5	10.2.0.1	RP候補	成功
FHR-1	10.4.0.5	10.2.0.4	RP候補	成功
FHR-1	10.4.0.5	10.2.1.5	マッピングエージェント	成功
FHR-1	10.4.0.5	10.2.1.4	マッピングエージェント	成功
FHR-2	10.4.0.9	10.2.0.1	RP候補	成功
FHR-2	10.4.0.9	10.2.0.4	RP候補	成功
FHR-2	10.4.0.9	10.2.1.5	マッピングエージェント	成功
FHR-2	10.4.0.9	10.2.1.4	マッピングエージェント	成功
LHR	10.4.0.5	10.2.0.1	RP候補	成功
LHR	10.4.0.5	10.2.0.4	RP候補	成功
LHR	10.4.0.5	10.2.1.5	マッピングエージェント	成功
LHR	10.4.0.5	10.2.1.4	マッピングエージェント	成功

FHRおよびLHRでの動作状態およびマルチキャストトラフィック転送の確認

次の検証ステップでは、次のことを確認します。

• FHRとLHRは、予期されたRPを正常に学習しました。
• マルチキャストルーティングテーブルには、予想されるマルチキャスト状態が含まれます。
• マルチキャストコントロールプレーンは、マルチキャストトラフィックの送信が開始される前に正しく動作します。
• PIMスパースモードは、期待される共有ツリー状態を構築します。

---

ステップ1 FHRおよびLHRでのRPラーニングの確認

マルチキャストの転送状態を検証する前に、すべてのマルチキャストルータが、検証中のマルチキャストグループに予期されるRPを学習したことを確認します。

この手順が重要な理由は次のとおりです。

• FHRはPIM Registerメッセージの送信先を認識している必要があります。
• LHRは、共有ツリーを構築するときに使用するRPを認識している必要があります。
• マルチキャストドメインでは、一貫したRPマッピングを維持する必要があります。

このトポロジでは、次のようになります。

• 選択されたRPは10.2.0.4です。
• Mapping Agentは10.2.1.5です。
• マルチキャストグループ範囲は224.10.20.0/24です。

---

FHR-1：学習されたRPの確認

FHR-1# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:30
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:30 (A)

FHR-2：学習されたRPの確認

FHR-2# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:15
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:15 (A)

LHR：学習されたRPの確認

LHR# show ip pim rp

PIM RP Status Information for VRF "default"
BSR disabled
Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:07
BSR RP Candidate policy: None
BSR RP policy: None
Auto-RP Announce policy: None
Auto-RP Discovery policy: None

RP: 10.2.0.4, (0),
 uptime: 1d03h   priority: 255,
 RP-source: 10.2.1.5 (A),
 group ranges:
 224.10.20.0/24   , expires: 00:02:07 (A)

---

RPラーニング分析

出力は次のことを確認します。

• すべてのマルチキャストルータは一貫して同じRPを学習しました。
• 選択されたRPは10.2.0.4です。
• RPマッピングはAuto-RPを通じて学習されました。
• RP情報を配布するMapping Agentは10.2.1.5です。
• RPマッピングは1日以上安定しています。
• ディスカバリの有効期限タイマーが正しく更新されます。

この動作が予期される理由は次のとおりです。

• 10.2.0.4がAuto-RPの選択プロセスでアクティブRPとして選択されました。
• 10.2.1.5はマッピングエージェントとして動作します。
• すべてのマルチキャストルータは、Auto-RPディスカバリアドバタイズメントを正常に受信します。

この段階で、マルチキャストコントロールプレーンは正しく動作しており、すべてのルータは224.10.20.0/24に対して一貫したRPマッピングを持っています

---

手順2アクティブなマルチキャストトラフィックの前にマルチキャストルーティング状態を確認する

次の手順では、マルチキャストトラフィックの送信が開始される前に、マルチキャストルーティングテーブルを検証します。

このシナリオでは次のようになっています。

• マルチキャスト受信者は既にマルチキャストグループに参加しています。
• アクティブなマルチキャスト送信元トラフィックがまだ流れていません。

この状態は、次の項目を検証するために重要です。

• IGMPメンバーシップ操作
• PIM共有ツリーの作成
• 初期(*,G)マルチキャストステート
• 受取人利息の伝播

FHR-1：マルチキャストルーティングテーブル

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:34, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2：マルチキャストルーティングテーブル

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 23:07:37, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

---

FHRマルチキャスト状態分析

FHRには、まだ次の情報が含まれていません。

• 224.10.20.10の(* ,G)状態
• (S、G)状態を示します

この動作が予期される理由は次のとおりです。

• マルチキャスト送信元トラフィックがまだアクティブではありません。
• PIM登録メッセージは生成されていません。
• FHRはマルチキャスト転送をまだ開始していません。

存在するマルチキャストエントリは次だけです。

• 232.0.0.0/8

これはデフォルトのSSM範囲に対応し、システムによって自動的にインストールされます。

次の値が必要です。

• 着信インターフェイス：Null
• RPFネイバー：0.0.0.0
• 発信インターフェイス数：0

このエントリは、アクティブなマルチキャスト転送を示しているわけではありません。

---

LHR：マルチキャストルーティングテーブル

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 23:07:39, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 23:07:39, igmp

(*, 232.0.0.0/8), uptime: 23:07:39, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

LHRマルチキャスト状態分析

FHRとは異なり、LHRには次の項目に対するアクティブな(*,G)エントリが含まれます。

• 224.10.20.10

この動作が予期される理由は次のとおりです。

• マルチキャストの受信者は既にグループに参加しています。
• IGMPメンバーシップ情報がVlan2で学習されました。
• LHRがRPへの共有ツリー参加を開始しました。

マルチキャストルーティングテーブルによって次のことが確認されます。

• 着信インターフェイス(IIF)はEthernet1/50です。
• RPFネイバーは10.4.0.26です。
• 発信インターフェイスリスト(OIL)にはVlan2が含まれています。

これは、次のことを示します。

• LHRはRPに向けて共有ツリーを正しく構築しました。
• マルチキャスト受信側の関心事項がアップストリームに正常に伝搬されました。
• PIM Joinメッセージが正しく送信されました。

この段階で：

• マルチキャスト送信元トラフィックがまだアクティブではありません。
• (S,G)状態はまだ存在しません。
• 共有ツリーの状態のみが存在します。

---

N9K-1：マッピングエージェントマルチキャストルーティングテーブル

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

マッピングエージェントマルチキャスト状態分析

N9K-1はマッピングエージェントとしてのみ動作し、224.10.20.10のマルチキャスト転送には参加しません

したがって、(* ,G)エントリと(S,G)エントリは想定されていません。

Mapping AgentはRPマッピング情報のみを配布し、マルチキャストトラフィックがデバイスを直接通過しない限り、マルチキャストデータ転送に必ずしも参加しません。

---

N9K-2:RPマルチキャストルーティングテーブル

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d01h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d01h, pim

(*, 232.0.0.0/8), uptime: 1d03h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

RPマルチキャストステート分析

N9K-2は、次の場合にアクティブRPとして動作します。

• 224.10.20.0/24

したがって、RPには224.10.20.10の共有ツリー(*,G)ステートが含まれています

次の値が必要です。

• 着信インターフェイス= loopback0
• RPFネイバー= 10.2.0.4
• 発信インターフェイス= Ethernet1/49

これは、次のことを示します。

• RPは共有ツリー状態を正常にインストールしました。
• RPが下流のルータからPIM Joinメッセージを受信しました。
• 受信側への共有マルチキャストツリーが正しく構築されている。

この段階で：

• RPには共有ツリー状態だけが含まれます。
• マルチキャスト送信元トラフィックがまだアクティブではありません。
• (S,G)エントリはまだ存在しません。

---

手順3アクティブなマルチキャストトラフィックでのマルチキャストルーティング状態の確認

マルチキャストトラフィックの送信が開始されると、マルチキャストルーティングテーブルは共有ツリー状態からアクティブな送信元固有の転送状態に移行します。

このシナリオでは次のようになっています。

• マルチキャストソースは10.150.1.37です。
• マルチキャストグループは224.10.20.10です。
• アクティブなRPは、N9K-2では10.2.0.4です。
• マルチキャストソースはvPCポートチャネル78を介して接続されます。

---

vPCマルチキャストに関する重要な考慮事項

マルチキャストソースは、FHR-1とFHR-2で形成されるvPCドメインを介して接続されます。

送信元はvPCメンバーのポートチャネルを介して接続されるため、次のようになります。

• トラフィックハッシングにより、いずれかのNexusスイッチにマルチキャストパケットを転送できます。
• 両方のFHRで同一のマルチキャスト設定が必要です。
• 両方のFHRには、一貫したユニキャストルーティング情報が必要です。
• 両方のFHRは同一のRPマッピングを維持する必要があります。
• 両方のFHRは安定したPIM隣接関係を維持する必要があります。

この特定のシナリオでは、次のようになります。

• マルチキャストフローはFHR-2に向けてハッシュされます。
• FHR-2が、マルチキャストソースのアクティブな転送FHRになります。

FHR-1：マルチキャストルーティングテーブル

FHR-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:03:58, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-1:vPCロール

FHR-1# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : primary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 00:6b:f1:84:02:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 6c:b2:ae:ee:5a:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

FHR-1マルチキャスト状態分析

FHR-1には、次のアクティブ(S,G)エントリが含まれています。

• 送信元= 10.150.1.37
• グループ= 224.10.20.10

マルチキャストルーティングエントリにより、次のことが確認されます。

• 送信元はVlan1で学習されました。
• RPFネイバーは、直接接続されたマルチキャストソースです。
• OILには発信インターフェイスが存在しません。

この動作は、マルチキャストフローがアウトバウンド転送のためにFHR-1に向けてハッシュしなかったために発生します。

その結果、

• FHR-1では、ローカルソースの状態のみがインストールされます。
• FHR-1はPIM経由でマルチキャストトラフィックをアップストリームに転送しません。

FHR-2：マルチキャストルーティングテーブル

FHR-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:16:35, ip pim
  Incoming interface: Vlan1, RPF nbr: 10.150.1.37
  Outgoing interface list: (count: 1)
    Ethernet1/3, uptime: 00:16:35, pim

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

FHR-2:vPCロール

FHR-2# show vpc role

vPC Role status
----------------------------------------------------
vPC role                        : secondary <<<
Dual Active Detection Status    : 0
vPC system-mac                  : 00:23:04:ee:be:01
vPC system-priority             : 32667
vPC local system-mac            : 6c:b2:ae:ee:5a:97
vPC local role-priority         : 32667
vPC local config role-priority  : 32667
vPC peer system-mac             : 00:6b:f1:84:02:97
vPC peer role-priority          : 32667
vPC peer config role-priority   : 32667

FHR-2マルチキャスト状態分析

FHR-1とは異なり、FHR-2には次が含まれます。

• アクティブな発信インターフェイスリスト
• アクティブなPIM転送パス

これは、次のことを示します。

• FHR-2は、マルチキャストフローのOperational Forwarding FHRになりました。
• マルチキャストパケットは、vPCメンバーポートチャネルを介してFHR-2に向けてハッシュ処理されます。
• FHR-2は、マルチキャストトラフィックをPIMレジスタメッセージにカプセル化しました。
• FHR-2はマルチキャストトラフィックをRPに向けてアップストリームに転送しました。

ECMPおよびマルチキャスト転送動作

発信インターフェイスEthernet1/3は、受信側192.168.2.37へのユニキャストルーティングテーブルに一致します

FHR-2：マルチキャスト受信側へのルート

FHR-2# show ip route 192.168.2.37

IP Route Table for VRF "default"

'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

192.168.2.0/24, ubest/mbest: 2/0
    *via 10.4.0.13, Eth1/3, [110/45], 1d02h, ospf-UNDERLAY, intra
    *via 10.4.0.18, Eth1/4, [110/45], 1d02h, ospf-UNDERLAY, intra

FHR-2には、マルチキャスト受信側サブネットへの等コストルートが2つ含まれています。

• 10.4.0.13からEthernet1/3
• 10.4.0.18 ～ Ethernet1/4

これにより、次のことが確認されます。

• ECMPルーティングは、マルチキャスト転送トポロジでアクティブです。
• 受信側ネットワークへの有効なユニキャスト転送パスが複数存在します。
• PIMは、マルチキャスト転送決定にMRIBが選択したRPFパスを使用できます。
• パラレルECMPパス間でのパケットの重複は発生しません。

2つの等コストルートが存在しますが、マルチキャスト転送ではマルチキャストフローごとに1つのRPFパスを使用します。

このトポロジでは、マルチキャストフローは次を使用します。

• Ethernet1/3から10.4.0.13へ

この動作は、前述のマルチキャストルーティングテーブルと一致します。

(10.150.1.37/32, 224.10.20.10/32)
  Outgoing interface list:
    Ethernet1/3

---

vPCの動作のプライマリおよびセカンダリの動作

vPCの動作ロールは、次の点でマルチキャスト転送動作に異なる影響を与えます。

• PIMトラフィック
• IGMP処理

このトポロジでは、次のようになります。

• FHR-1は、稼働中のvPCプライマリです。
• FHR-2は動作中のvPCセカンダリです。

両方のNexusスイッチで次のことが可能です。

• PIMコントロールプレーントラフィックの処理
• マルチキャストルーティング状態の構築
• PIMによるマルチキャストトラフィックの転送

ただし:

• 動作しているvPCプライマリだけが、アクセスレイヤへのIGMPレシーバトラフィックを処理します。

この違いは次の理由から重要です。

• ルーテッドネットワークへのPIM転送は、両方のピアでアクティブのままになります。
• レイヤ2レシーバセグメントへのIGMP転送は、稼働しているプライマリで中央集中型のままになります。

したがって

• 送信元からルーテッドマルチキャストドメインに向かうマルチキャストトラフィックは、いずれかのvPCピアを経由して発信できます。
• IGMPレシーバへのマルチキャストトラフィックは、動作のプライマリ動作に依存します。

---

LHR：マルチキャストルーティングテーブル

LHR# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d00h, igmp ip pim
  Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 1d00h, igmp

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:31, ip mrib pim
  Incoming interface: Ethernet1/49, RPF nbr: 10.4.0.22
  Outgoing interface list: (count: 1)
    Vlan2, uptime: 00:06:31, mrib

(*, 232.0.0.0/8), uptime: 1d00h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

LHRマルチキャスト状態分析

LHRには現在、次の両方が含まれています。

• (* ,G)共有ツリーの状態
• (S,G)ソースツリーの状態

これにより、次のことが確認されます。

• マルチキャスト受信者は正常に参加しました。
• マルチキャストソースがアクティブになりました。
• LHRは共有ツリー転送からソースツリー転送に移行しました。

(S,G)エントリによって、次のことが確認されます。

• マルチキャストソースパスが正常に学習されました。
• RPFネイバーは10.4.0.22です。
• マルチキャストトラフィックはEthernet1/49経由で着信します。
• マルチキャストトラフィックはVlan2レシーバに転送されます。

この動作により、成功したことが確認されます。

• PIM転送
• RPF検証
• ソースツリー構築
• マルチキャストトラフィック配信

---

N9K-1：中継マルチキャストルーティングテーブル

N9K-1# show ip mroute

IP Multicast Routing Table for VRF "default"

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:42, pim ip
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.14
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 00:06:42, pim

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

N9K-1トランジットステート分析

N9K-1は、アクティブなマルチキャストフローの中継マルチキャストルータとして動作します。

マルチキャストルーティングエントリにより、次のことが確認されます。

• マルチキャストトラフィックはEthernet1/4から着信します。
• マルチキャストトラフィックはEthernet1/49に転送されます。
• LHRへのマルチキャスト転送パスは動作しています。

成功を確認します。

• PIMネイバー動作
• RPF検証
• 中継ネットワークを介したマルチキャスト転送

---

N9K-2:RPマルチキャストルーティングテーブル

N9K-2# show ip mroute

IP Multicast Routing Table for VRF "default"

(*, 224.10.20.10/32), uptime: 1d02h, pim ip
  Incoming interface: loopback0, RPF nbr: 10.2.0.4
  Outgoing interface list: (count: 1)
    Ethernet1/49, uptime: 1d02h, pim

(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:50, ip pim mrib
  Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.17, internal
  Outgoing interface list: (count: 0)

(*, 232.0.0.0/8), uptime: 1d04h, pim ip
  Incoming interface: Null, RPF nbr: 0.0.0.0
  Outgoing interface list: (count: 0)

RPマルチキャストステート分析

N9K-2は、マルチキャストグループのアクティブRPとして動作します。

RPには次の両方が含まれています。

• (* ,G)共有ツリーの状態
• (S,G)ソースツリーの状態

(S,G)エントリに発信インターフェイスがないことは、次の理由から予期されます。

• RPはすでに受信側を最短パスツリーに切り替えています。
• 共有ツリー転送パスは、アクティブなマルチキャスト転送には必要なくなりました。

RCAおよび正常性診断に必要な最小限のマルチキャスト情報

コマンドのリストには、NX-OSが稼働しているCisco Nexus 9000シリーズスイッチで適切な根本原因分析(RCA)またはマルチキャストの状態診断を実行するために必要な、最小限の推奨マルチキャストデータ収集が記載されています。これらの出力は、マルチキャストコントロールプレーンの状態、MRIBのプログラミング、転送情報、vPCの動作状態、およびハードウェア転送の詳細をキャプチャします。ただし、障害のシナリオによっては、追加情報が必要になる場合があります。たとえば、マルチキャストパケット損失、断続的なトラフィックドロップ、パケットレプリケーションの問題、ハードウェア転送の不整合、不正なマルチキャスト転送では、Ethanalyzer、SPAN、またはハードウェアレベルのキャプチャを使用して、Nexusスイッチで直接パケットキャプチャを行う必要があります。同様に、永続的なログを生成しなくても、一時的なRPFの不整合、ECMP転送変更、ASICプログラミングの失敗、またはIGMP抑制イベントが発生する可能性があります。

その結果、show techの出力をパケットキャプチャおよび転送検証と組み合わせることで、診断精度とRCA品質が大幅に向上します。この情報は、マルチキャストトラブルシューティングの強力な運用ベースラインを提供しますが、これらの出力からRCAを常に排他的に識別できるとは限りません。特定のマルチキャスト障害では、正確な根本原因を切り分けるために、追加のトラブルシューティング、ライブトラフィック分析、ハードウェアレベルの検証、トポロジ相関、または拡張パケットキャプチャが必要です。

最小限のマルチキャストデータ収集コマンド

N9K-1# show tech-support multicast >> bootflash:$(SWITCHNAME)-sh-tech-multicast.txt

N9K-1# show tech-support details >> bootflash:$(SWITCHNAME)-sh-tech-det.txt

N9K-1# show tech-support vpc >> bootflash:$(SWITCHNAME)-sh-tech-vpc.txt

N9K-1# show tech-support forwarding multicast >> bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt

N9K-1# show tech-support forwarding l3 multicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt

N9K-1# show tech-support forwarding l3 unicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

エクスポート用のTARアーカイブの作成

show techファイルを生成した後、エクスポートと分析のためにファイルを1つのTARアーカイブに統合します。このコマンドは1行で記述します。

N9K-1# tar create bootflash:$(SWITCHNAME)-multicast-logs
bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-det.txt
bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt

単一のTARアーカイブをエクスポートすると、次のことが容易になります。

• TACケースのアップロード
• RCAワークフロー
• 一元化されたログ分析
• マルチキャスト転送相関
• 障害履歴の保持

更新履歴

改定	発行日	コメント
1.0	13-May-2026	初版