このドキュメントでは、NX-OSを搭載したCisco Nexus 9000で自動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メッセージ |
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の動作(コントロールプレーンワークフロー)
ECMPベースのマルチパス転送はデフォルトで有効になっており、これによりマルチキャストトラフィックはロードバランシングに等コストパスを使用できます。
IPsec AH-MD5を使用したPIMネイバー認証がサポートされています。
PIMスヌーピングは使用できません。
Auto-RPは、PIMスパースモードのマルチキャスト環境に対して、動的なRPディスカバリと集中型のRPマッピング分散を提供します。マルチキャストルータごとにスタティックRPを設定する必要がなくなり、運用の複雑さが軽減され、マルチキャストの拡張性が向上します。Auto-RPは複数のRP-Candidateもサポートしており、RPの自動フェールオーバーと冗長性を実現します。このメカニズムにより、マルチキャスト転送動作の一貫性が維持され、ネットワークの拡張が簡素化され、ドメイン全体でマルチキャストルータがRP情報を自動的に学習できるようになります。
Auto-RPの選択プロセスは決定論的で、主にIPアドレスに基づいています。他のプロトコル(PIMv2 BSRなど)とは異なり、Auto-RPは設定可能な「プライオリティ」値を使用しません。代わりに、IPアドレス階層に依存して競合を解決します。
Auto-RPでは、冗長性を確保するために、同じネットワーク内に複数のマッピングエージェントを共存させることができます。一方がオフになり、もう一方がオンになる正式な選出プロセスはなく、すべてが技術的にアクティブです。ただし、ネットワーク内のスイッチは、信頼する情報を決定する必要があります。
このプロセスは、候補からのすべてのRP-Announceメッセージ(グループ224.0.1.39に送信)をリッスンした後に、マッピングエージェントによって実行されます。
Mapping Agentは、同じマルチキャストグループの複数の候補を受信すると、次のルールを順番に適用します。
ルールA:最長プレフィクス照合(最も固有のマスク)
候補が重複する範囲をアナウンスすると、MAは最も小さい範囲(最長のサブネットマスク)をアナウンスしたRPにグループを割り当てます。
ルールB:最も大きいIPアドレス(同順位の要因)
2つ以上の候補が同じグループ範囲をアナウンスする場合、Mapping Agentは1つだけを選択する必要があります。
この記事では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の設定について詳しく説明します。この設定では、マルチキャスト送信元がvPC経由で2台のNexusスイッチに接続され、トラフィックが受信者に配信されます。この設計では、N9K-1とN9K-2の両方がRP候補とマッピングエージェントとして同時に機能します。
注意:PIMネイバーは、vPCポートチャネル経由ではサポートされません。
マルチキャストトラフィックフロー
同じ設定に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メッセージを介して明示的に要求したセグメントにのみ転送されます。 |
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メッセージを介して明示的に要求した受信者にのみ送信され、不要なネットワークフラッディングが防止されます。 |
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
マルチキャストの動作を分析する前に、ユニキャストアンダーレイ(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の設定に誤りがある
ヒント:自動RP、PIM隣接関係、またはRP選択を分析する前に、アンダーレイルーティングドメインが安定しており、一貫しており、完全に到達可能なエンドツーエンドであることを必ず確認してください。
次のステップでは、マルチキャストトラフィックの転送に関係する各デバイスの役割を明確に特定します。マルチキャストのトラブルシューティングは、トポロジ全体のトラフィックフローと予想される動作の理解に完全に依存するため、これは必須の手順です。
少なくとも、次の要素を特定する必要があります。
マルチキャストソース(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ループバックアドレス
注意:明確なトポロジがない状態でのマルチキャストトラブルシューティングは、可視性がない状態でのデバッグと同等です。これは、誤った仮定や誤診断の原因となります。
次の手順では、マルチキャストトポロジでの役割に従って、各デバイスで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)メッセージの交換を妨げる設定が欠落していないことを確認する必要があります。
注:N9K-1とN9K-2は、マルチキャストドメイン内でRP候補およびマッピングエージェントとして設定されています。
注意:Auto-RPの設定が欠落しているか不整合があると、ルータがRPを学習できなくなるため、マルチキャストトラフィックが正しく転送されなくなります。
最初の検証ステップは、想定されるすべての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
検証ポイント
このトポロジでは、次のようになります。
次のステップでは、Auto-RPに参加しているすべてのインターフェイスでPIMが有効になっていることを確認します。
この検証は、次の場合に特に重要です。
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
検証ポイント:
ループバックロール割り当て:
| デバイス | 機能 | ループバック |
|---|---|---|
| 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インターフェイスとして正しく表示されます。ループバックインターフェイスはマルチキャスト隣接関係を直接確立しないため、この動作が予想されます。
これらのループバックの存在は、次のことを確認します。
このコマンドでは、次の項目を検証します。
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
これにより、次のことが確認されます。
このトポロジでは、この動作が予想されます。
自動RP RPA:10.2.1.5*
Auto-RP RPA: 10.2.1.5*
この場合、次を意味します。
での次の検出メッセージ
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: 10.2.0.1*, (0),
これにより、N9K-1がRP候補として設定されていることが確認できます。
稼働時間と優先度
uptime: 22:18:44 priority: 255,
RPソース
RP-source: 10.2.0.1 (A),
グループ範囲
224.10.20.0/24
2番目のRPエントリ
RP: 10.2.0.4, (0),
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
重要なRPの違い
RP-source: 10.2.1.5 (A),
これにより、次のことが確認されます。
Auto-RPは、2つの異なるマルチキャストコントロールプレーン機能を使用します。
PIMスパースモード環境でマルチキャストの動作を検証する際には、これらの関数の相互作用を理解することが重要です。
このトポロジでは、次のようになります。
RP候補の動作
RP候補は、1つ以上のマルチキャストグループ範囲の有効なランデブーポイント(RP)として自身をアドバタイズします。
各RP候補は、定期的にAuto-RP Announceメッセージを次の宛先に送信します。
これらのアナウンスには次のものが含まれます。
このトポロジでは、次のようになります。
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)
両方のデバイスが同じマルチキャストグループ範囲をアドバタイズします。
両方のRP候補は、次のコマンドも使用します。
Auto-RPはRPの選択時にプライオリティとRPアドレスを使用するため、これは重要です。
アクティブなマッピングエージェントID
Mapping Agentは、次のロジックで始まるマルチキャストグループのアクティブRPを選択します。
このトポロジでは、次のようになります。
両方の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),
この動作が予期される理由は次のとおりです。
注意: Mapping Agentでは、同じマルチキャストドメイン内のすべてのRP候補が表示される必要があります。いずれかのRP候補が見つからない場合は、Mapping AgentのIPアドレス(通常はループバックインターフェイス)を送信元とするRP候補のIPアドレスにpingを送信して、到達可能性を確認します。
PIMスパースモードドメインに参加するすべてのマルチキャストルータは、安定したIP到達可能性を維持して、次のことを実行する必要があります。
PIMスパースモードはユニキャストルーティングに依存して次のことを行うため、この検証は非常に重要です。
RPまたはマッピングエージェントへの到達可能性が失敗した場合:
ルーティングテーブルには、次の宛先への安定したユニキャストルートが含まれている必要があります。
ルートは、ルートフラッピングや過剰な再コンバージェンスイベントを発生させることなく、継続的にインストールされている必要があります。
確認:
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
ルーティングテーブルを検証した後、次の宛先へのエンドツーエンドIP到達可能性を確認します。
pingの送信元は次の条件を満たしている必要があります。
この検証は重要です。マルチキャストルータでは、次の期間にこれらの発信元アドレスが使用されるためです。
ヒント:複数のレイヤ3インターフェイスがループバックインターフェイスから同じIPアドレスを共有する非番号インターフェイスを使用する場合、単一の送信元IPアドレスを一貫して使用できるため、到達可能性の検証が簡単になります。
| デバイス | 送信元 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 | マッピングエージェント | 成功 |
次の検証ステップでは、次のことを確認します。
マルチキャストの転送状態を検証する前に、すべてのマルチキャストルータが、検証中のマルチキャストグループに予期されるRPを学習したことを確認します。
この手順が重要な理由は次のとおりです。
このトポロジでは、次のようになります。
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ラーニング分析
出力は次のことを確認します。
この動作が予期される理由は次のとおりです。
この段階で、マルチキャストコントロールプレーンは正しく動作しており、すべてのルータは224.10.20.0/24に対して一貫したRPマッピングを持っています
次の手順では、マルチキャストトラフィックの送信が開始される前に、マルチキャストルーティングテーブルを検証します。
このシナリオでは次のようになっています。
この状態は、次の項目を検証するために重要です。
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には、まだ次の情報が含まれていません。
この動作が予期される理由は次のとおりです。
存在するマルチキャストエントリは次だけです。
これはデフォルトのSSM範囲に対応し、システムによって自動的にインストールされます。
次の値が必要です。
このエントリは、アクティブなマルチキャスト転送を示しているわけではありません。
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)エントリが含まれます。
この動作が予期される理由は次のとおりです。
マルチキャストルーティングテーブルによって次のことが確認されます。
これは、次のことを示します。
この段階で:
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として動作します。
したがって、RPには224.10.20.10の共有ツリー(*,G)ステートが含まれています
次の値が必要です。
これは、次のことを示します。
この段階で:
マルチキャストトラフィックの送信が開始されると、マルチキャストルーティングテーブルは共有ツリー状態からアクティブな送信元固有の転送状態に移行します。
このシナリオでは次のようになっています。
vPCマルチキャストに関する重要な考慮事項
マルチキャストソースは、FHR-1とFHR-2で形成されるvPCドメインを介して接続されます。
送信元はvPCメンバーのポートチャネルを介して接続されるため、次のようになります。
この特定のシナリオでは、次のようになります。
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)エントリが含まれています。
マルチキャストルーティングエントリにより、次のことが確認されます。
この動作は、マルチキャストフローがアウトバウンド転送のためにFHR-1に向けてハッシュしなかったために発生します。
その結果、
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には次が含まれます。
これは、次のことを示します。
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つ含まれています。
これにより、次のことが確認されます。
2つの等コストルートが存在しますが、マルチキャスト転送ではマルチキャストフローごとに1つのRPFパスを使用します。
このトポロジでは、マルチキャストフローは次を使用します。
この動作は、前述のマルチキャストルーティングテーブルと一致します。
(10.150.1.37/32, 224.10.20.10/32)
Outgoing interface list:
Ethernet1/3
vPCの動作ロールは、次の点でマルチキャスト転送動作に異なる影響を与えます。
このトポロジでは、次のようになります。
両方のNexusスイッチで次のことが可能です。
ただし:
この違いは次の理由から重要です。
したがって
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には現在、次の両方が含まれています。
これにより、次のことが確認されます。
(S,G)エントリによって、次のことが確認されます。
この動作により、成功したことが確認されます。
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は、アクティブなマルチキャストフローの中継マルチキャストルータとして動作します。
マルチキャストルーティングエントリにより、次のことが確認されます。
成功を確認します。
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)
N9K-2は、マルチキャストグループのアクティブRPとして動作します。
RPには次の両方が含まれています。
(S,G)エントリに発信インターフェイスがないことは、次の理由から予期されます。
コマンドのリストには、NX-OSが稼働しているCisco Nexus 9000シリーズスイッチで適切な根本原因分析(RCA)またはマルチキャストの状態診断を実行するために必要な、最小限の推奨マルチキャストデータ収集が記載されています。これらの出力は、マルチキャストコントロールプレーンの状態、MRIBのプログラミング、転送情報、vPCの動作状態、およびハードウェア転送の詳細をキャプチャします。ただし、障害のシナリオによっては、追加情報が必要になる場合があります。たとえば、マルチキャストパケット損失、断続的なトラフィックドロップ、パケットレプリケーションの問題、ハードウェア転送の不整合、不正なマルチキャスト転送では、Ethanalyzer、SPAN、またはハードウェアレベルのキャプチャを使用して、Nexusスイッチで直接パケットキャプチャを行う必要があります。同様に、永続的なログを生成しなくても、一時的なRPFの不整合、ECMP転送変更、ASICプログラミングの失敗、またはIGMP抑制イベントが発生する可能性があります。
その結果、show techの出力をパケットキャプチャおよび転送検証と組み合わせることで、診断精度とRCA品質が大幅に向上します。この情報は、マルチキャストトラブルシューティングの強力な運用ベースラインを提供しますが、これらの出力からRCAを常に排他的に識別できるとは限りません。特定のマルチキャスト障害では、正確な根本原因を切り分けるために、追加のトラブルシューティング、ライブトラフィック分析、ハードウェアレベルの検証、トポロジ相関、または拡張パケットキャプチャが必要です。
ヒント:動作中および非動作中に収集した情報から、Nexusの観点から見た問題の外観を明確に把握することができ、根本原因を特定する能力が大幅に向上します。
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
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アーカイブをエクスポートすると、次のことが容易になります。
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
13-May-2026
|
初版 |