内容

はじめに

前提条件

要件

使用するコンポーネント

背景説明

RPF の障害が原因で、ルータによってマルチキャスト パケットがホストに転送されない

問題の診断

考えられる解決方法

発信元の TTL 設定が原因で、ルータによってマルチキャスト パケットがホストに転送されない

問題の診断

考えられる解決方法

ルータの TTL しきい値が原因で、ルータによってマルチキャスト パケットが転送されない

問題の診断

考えられる解決方法

複数の等コストパスが原因で不要なRFBehaviorが発生する

問題の診断

考えられる解決方法

使用可能なすべての等コスト パス全体に対して、IP マルチキャストのロード バランスが行われない理由

考えられる解決方法

ルータでIPマルチキャストの「INVALID_RP_JOIN」エラーメッセージを受信する場合

問題の診断：第 1 部

考えられる解決方法

問題の診断：第 2 部

考えられる解決方法

重複したマルチキャスト パケット ストリームが受信される

原因 1

考えられる解決方法 1

原因 2

考えられる解決方法 2

原因 3

考えられる解決方法 3

マルチキャスト パケットがドロップされる

原因 1

考えられる解決方法 1

原因 2

考えられる解決方法 2

関連情報

はじめに

このドキュメントでは、IP マルチキャストの一般的な問題と解決方法について説明します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

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

背景説明

マルチキャスト ルーティングをトラブルシューティングする際の主な懸念事項は、送信元アドレスです。マルチキャストにはリバース パス フォワーディング（RPF）チェックという概念があります。マルチキャスト パケットがインターフェイスに到達すると、マルチキャスト パケットの送信元に到達するために、この着信インターフェイスがユニキャスト ルーティングで使用される発信インターフェイスであることが RPF プロセスによって確認されます。この RPF のチェック プロセスによってループが防止されます。マルチキャスト ルーティングでは、パケットの送信元が RPF チェックに適合しない限り、パケットを転送しません。パケットが RPF チェックにパスすると、マルチキャスト ルーティングによって、宛先アドレスだけに基づいてパケットが転送されます。

ユニキャスト ルーティングと同様に、マルチキャスト ルーティングでも複数のプロトコルが使用できます。たとえば、Protocol Independent Multicast dense mode（PIM-DM; 稠密モード PIM）、PIM sparse mode（PIM-SM; 希薄モード PIM）、Distance Vector Multicast Routing Protocol（DVMRP; ディスタンスベクター マルチキャスト ルーティング プロトコル）、Multicast Border Gateway Protocol（MBGP; マルチキャスト ボーダーゲートウェイ プロトコル）、および Multicast Source Discovery Protocol（MSDP; マルチキャスト発信元ディスカバリ プロトコル）などがあります。このドキュメントのケース スタディでは、さまざまな問題をトラブルシューティングするプロセスを紹介します。問題を迅速に特定し、その解決方法を学習するために使用されるコマンドを確認できます。ここで取り上げるケース スタディは、特別に記した場合を除き、プロトコル全体に該当します。

RPF の障害が原因で、ルータによってマルチキャスト パケットがホストに転送されない

このセクションでは、IP マルチキャスト RPF 障害という一般的な問題の解決策を説明します。例として、次のネットワーク ダイアグラムが使用されています。

ネットワーク図マルチキャストRPF障害の例

この図では、IPアドレスが10.1.1.1のサーバからルータ75aのE0/0にマルチキャストパケットが着信し、グループ224.1.1.1に送信されています。これを (S,G) または (10.1.1.1, 224.1.1.1) と記します。

問題の診断

ルータ 75a に直接接続されたホストではマルチキャストが受信されていますが、ルータ 72a に直接接続されたホストでは受信されていません。まず、show ip mrouteコマンドを入力して、75aルータのアクティビティを調べます。次のコマンドでは、グループ アドレス 224.1.1.1 に対するマルチキャスト ルート（mroute）が検査されます。

75a#show ip mroute 224.1.1.1

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned

R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT

M - MSDP created entry, X - Proxy Join Timer Running

A - Advertised via MSDP

Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D

Incoming interface: Null, RPF nbr 0.0.0.0

Outgoing interface list:

Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00

(10.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA

Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0

Outgoing interface list:

Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00

このルータは PIM デンス モードで動作しているため（D フラグにより、デンス モードであることがわかります）、*,G エントリを無視して S,G エントリに注目します。10.1.1.1 のアドレスを持つサーバからマルチキャスト パケットが発信されることが、このエントリから分かります。ここでは 224.1.1.1 のマルチキャスト グループに送信されます。パケットは Ethernet0/0 インターフェイスに着信して、Ethernet0/1 インターフェイスから転送されます。これは完全なシナリオです。

show ip pim neighbor コマンドを入力して、ルータ72aで上流のルータ(75a)がPIMネイバーとして表示されるかどうかを調べます。

ip22-72a#show ip pim neighbor

PIM Neighbor Table

Neighbor Address  Interface          Uptime    Expires   Ver  Mode

10.2.1.1           Ethernet3/1        2d00h     00:01:15  v2

show ip pim neighborコマンド出力では、PIMネイバー関係が良好であることが表示されています。

show ip mroute  コマンドを入力して、ルータ72aに正しいmrouteが設定されていることを確認します。

ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Dense, 00:10:42/00:00:00 Ethernet3/2, Forward/Dense, 00:10:42/00:00:00 (10.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags:  Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0  Outgoing interface list: Ethernet3/1, Forward/Dense, 00:01:10/00:00:00 Ethernet3/2, Forward/Dense, 00:00:16/00:00:00 ip22-72a#

show ip mroute 224.1.1.1  コマンドでは、予測されるEtheret3/1ではなく、着信インターフェイスがEthernet2/0であることが確認できます。

show ip mroute 224.1.1.1 countコマンドを入力して、このグループのマルチキャストトラフィックがルータ72aに到達したかどうか、さらに次に何が行われるかを調べます。

ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2032 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471 Source: 10.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0 ip22-72a#

Otherのカウントから、RPF障害が原因でトラフィックがドロップされていることがわかります。ドロップの総数は471、RPF障害が原因で471...

RPFエラーが発生しているかどうかを確認するには、show ip rpf <source>コマンドを入力します。

ip22-72a#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 10.1.1.1/32 RPF type: unicast (static) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-72a#

Cisco IOS(R) では、この方法で RPF インターフェイスを算出します。RPF 情報の送信元としては、ユニキャスト ルーティング テーブル、MBGP ルーティング テーブル、DVMRP ルーティング テーブル、静的 Mroute テーブルが考えられます。RPF インターフェイスを計算するときには、RPF 計算の基盤となる情報源を正確に判別する目的で、主にアドミニストレーティブ ディスタンスが使用されます。具体的なルールは次のとおりです。

- RPFデータの以前のすべてのソースが、ソースIPアドレスに一致するものを検索されます。共有ツリーを使用する場合は、送信元アドレスの代わりに RP アドレスが使用されます。

- 複数の一致するルートが見つかった場合は、アドミニストレーティブディスタンスが最も小さいルートが使用されます。

- アドミニストレーティブ ディスタンスが等しい場合は、以下の優先順位が適用されます。

1. スタティックな mroute

2. DVMRP ルート

3. MBGP ルート

4. ユニキャスト ルート

- 同じルート テーブル内でルートの複数のエントリが発生する場合、一致する最も長いルートが使用されます。
show ip mroute 224.1.1.1

コマンド出力では、RPFインターフェイスがE2/0であると示されていますが、着信インターフェイスはE3/1である必要があります。

show ip mroute 224.1.1.1 コマンドを入力して、RPFインターフェイスが予想されるRPFインターフェイスと異なる理由を確認します。

ip22-72a#show ip route 10.1.1.1 Routing entry for 10.1.1.1/32 Known via "static", distance 1, metric 0 (connected) Routing Descriptor Blocks: * directly connected, via Ethernet2/0 Route metric is 0, traffic share count is 1

この show ip route 10.1.1.1 コマンド出力からは、RPF インターフェイスとして誤ったインターフェイスが選択されるようにするスタティックな /32 ルートが存在していることがわかります。

さらに debug コマンドを入力します。

ip22-72a#debug ip mpacket 224.1.1.1

*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1)

d=224.1.1.1 len 60, not RPF interface

*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1)

d=224.1.1.1 len 60, not RPF interface

*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1)

d=224.1.1.1 len 60, not RPF interface

*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1)

d=224.1.1.1 len 60, not RPF interface

パケットは適切に E3/1 に着信しています。しかし、これはユニキャスト ルーティング テーブルで RPF チェックに使用するインターフェイスではないため、パケットがドロップされます。

注：パケットのデバッグは危険です。パケットのデバッグによってトリガーされるマルチキャスト パケットのプロセス スイッチングは、CPU を集約的に使用するためです。また、パケットのデバッグによって膨大な出力が作成され、コンソール ポートへの出力が低速なためルータが完全にハングする可能性があります。パケットをデバッグする前に、コンソールへのロギング出力を無効にして、メモリ バッファへのロギングを有効にするように、特に注意を払う必要があります。これを実行するには、no logging console コマンドと logging buffered debugging コマンドを設定します。show logging コマンドを使用して、デバッグの結果を確認できます。

考えられる解決方法

この要件を満たすためにユニキャスト ルーティング テーブルを変更できます。あるいは、ユニキャスト ルーティング テーブルの内容とは無関係に、特定のインターフェイスから RPF をマルチキャストに強制的に実行させる静的 mroute を追加することもできます。ここではスタティックな mroute を追加します。

ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1

このスタティックなmrouteは、RPF用にアドレス10.1.1.1に到達するには、インターフェイスE3/1のネクストホップとして10.2.1.1を使用することを示しています。

ip22-72a#show ip rpf 10.1.1.1

RPF information for ? (10.1.1.1)

RPF interface: Ethernet3/1

RPF neighbor: ? (10.2.1.1)

RPF route/mask: 10.1.1.1/32

RPF type: static mroute

RPF recursion count: 0

Doing distance-preferred lookups across tables

show ip mroute とdebug ip mpacket の出力には問題がなく、show ip mroute countでは送信されたパケット数が増加していて、パケットはホストAで受け取られています。

ip22-72a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 (10.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA Incoming interface: Ethernet3/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019 Source: 10.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0 ip22-72a#show ip mroute 224.1.1.1 count IP Multicast Statistics 3 routes using 2378 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026 Source: 10.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0 ip22-72a# ip22-72a#debug ip mpacket 224.1.1.1 *Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward

発信元の TTL 設定が原因で、ルータによってマルチキャスト パケットがホストに転送されない

このセクションでは、存続可能時間（TTL）値がゼロになったために IP マルチキャスト パケットが転送されないという一般的な問題の解決策を説明します。多くのマルチキャスト アプリケーションが存在するため、これは一般的な問題です。これらのマルチキャスト アプリケーションは、主に LAN を使用する設計になっているため、TTL を低い値に設定します（1 であっても設定可能）。次のネットワーク ダイアグラムを例として使用します。

主にLAN使用例向けに設計されたマルチキャストアプリケーション

問題の診断

上の図で、ルータAは送信元から、直接接続された受信側であるルータBにパケットを転送しません。ルータAでの  show ip mroute  コマンドの出力を見て、マルチキャストルーティングの状態を調べます。

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00 (*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00

すべてのルータはこの自動 RP ディスカバリ グループに参加しているため、出力の 224.0.1.40 を無視できます。ただし、224.1.1.1 に関して送信元がリストされていません。「*, 224.1.1.1」に加えて、「10.1.1.1, 224.1.1.1」も表示できません。

RPF の問題であるかどうかを確認するために、show ip rpf コマンドを入力します。

ROUTERA#show ip rpf 10.1.1.1

RPF information for ? (10.1.1.1)

RPF interface: Ethernet0/0

RPF neighbor: ? (0.0.0.0) - directly connected

RPF route/mask: 10.1.1.1/24

RPF type: unicast (connected)

RPF recursion count: 0

Doing distance-preferred lookups across tables

出力から判断すると、これはRPFの問題ではありません。RPFチェックでは、送信元IPアドレスに到達するE0/0が正しく指定されています。

show ip pim interfaceコマンドで、このインターフェイスでPIMが設定されているかどうかを調べます。

ROUTERA#show ip pim interface

Address          Interface          Version/Mode    Nbr   Query     DR

Count Intvl

10.1.1.2          Ethernet0/0        v2/Sparse-Dense  0    30     10.1.1.2

10.2.1.1          Ethernet0/1        v2/Sparse-Dense  2    30     10.2.1.2

出力は正しいようです。したがって、この箇所が問題ではありません。show ip mroute activeコマンドで、ルータがアクティブなトラフィックを認識しているかどうかをチェックします。

ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps

この出力によると、ルータはアクティブ トラフィックを認識していません。

ROUTERA#debug ip mpacket IP multicast packets debugging is on

おそらく、レシーバがグループ224.1.1.1のInternet Group Management Protocol(IGMP)レポート(join)を送信していません。このチェックには、show ip igmp group  コマンドを使用します。

ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 10.2.1.2 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2

224.1.1.1 は既に E1/2 に加入していました。これは正常です。

PIM 稠密モードはフラッディングとプルーニングを行うプロトコルであるため、加入（join）はありませんが、グラフト（graft）があります。ルータ B ではルータ A からのフラッドが受信されていないため、グラフトの送り先が認識されていません。

これがTTLの問題であるのかどうかは、スニファキャプチャで確認できますが、 show ip traffic  コマンドでも確認できます。

ROUTERA#show ip traffic IP statistics: Rcvd: 248756 total, 1185 local destination 0 format errors, 0 checksum errors, 63744 bad hop count 0 unknown protocol, 0 not a gateway 0 security failures, 0 bad options, 0 with options

出力には、63744 bad hop count と示されています。このコマンドを入力するたびに、この不正なホップ カウントの値は増加します。これは、送信側が TTL=1 を設定したパケットを送信し、ルータ A がこれをゼロにデクリメントしていることを強く示唆しています。これによって、不正なホップ カウントのフィールドの値が増えています。

考えられる解決方法

この問題を解決するには、TTL を増やす必要があります。これは送信側のアプリケーション レベルで行います。詳細は、マルチキャスト アプリケーションのマニュアルを参照してください。

この設定を行うと、ルータ A の状態はこのように表示されます。

ROUTERA#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00 (*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00 (10.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00

これが望ましい結果です。

ルータ B での表示は次のようになります。

ROUTERB#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00 (*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00 (10.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1 Outgoing interface list: Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00

ルータの TTL しきい値が原因で、ルータによってマルチキャスト パケットが転送されない

このセクションでは、TTL しきい値の設定が小さすぎて IP マルチキャスト トラフィックが受信側に到達しないという、一般的な問題の解決策を説明します。例として、次のネットワーク ダイアグラムが使用されています。

TTLしきい値が低すぎるため、IPマルチキャストトラフィックが受信側に到達しない

問題の診断

上記の図では、受信側は送信元からのマルチキャスト パケットを受信していません。発信元とルータ75aの間には複数のルータが存在することがあります。ルータ 75a は受信側に直接接続されているため、まずルータ 75a を確認します。

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00 (10.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00

出力には、ルータ 75a が Ethernet0/1 からパケットを転送していることが示されています。ルータ75aによって確実にパケットが転送されるようにするには、この送信元とマルチキャストグループに対してのみdebug をオンにします。

ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 10.1.1.1 host 224.1.1.1 ip22-75a(config)#end ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

このdebug メッセージは、TTLのしきい値に到達したために、ルータ75aでマルチキャストパケットが転送されないことを示しています。その理由を特定する目的で、ルータ設定を調べます。次の出力に原因が示されています。

interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15

ルータの TTL しきい値は 15 になっていますが、これは TTL が 15 を超えるパケットが送信されないことを示すものではありません。実は、その逆が正解です。アプリケーションは TTL 15 で送信されます。これがルータ 75a に到達した時点では、そのマルチキャスト パケットの TTL は 15 より低い値になっています。

ip multicast ttl-threshold <value>コマンドは、指定されたしきい値（この場合は15）よりも低いTTLを持つパケットは転送されないことを意味します。このコマンドは通常、内部マルチキャスト トラフィックがイントラネットの外部に流れないよう、境界を定めるために使用されます。

考えられる解決方法

ip multicast ttl-threshold <value>コマンドをこのコマンドのno形式で削除します。これにより、TTLしきい値がデフォルトの0に戻ります。または、TTLしきい値を下げて、トラフィックが通過できるようにします。

複数の等コスト パスにより、RPF が不適切な動作をする

このセクションでは、マルチキャスト送信元への等コスト パスが不適切な RPF 動作の原因になる理由を説明します。また、そのような動作を防ぐために IP マルチキャストを設定する方法についても説明します。例として、次のネットワーク ダイアグラムが使用されています。

マルチキャスト送信元への等コストパスが原因で、望ましくないRPF動作が発生する

問題の診断

図では、ルータ75bは発信元(10.1.1.1)に戻る3つの等コストパスを持ち、RPFリンクとしての最初の選択肢にはしたくないリンクを選択しています。

発信元に対して複数の等コスト パスがある場合、IP マルチキャストでは、最も大きな IP アドレスの Protocol Independent Multicast（PIM）ネイバーを持つインターフェイスを着信インターフェイスとして選択し、他のリンクの PIM ネイバーにプルーニングを送信します。

考えられる解決方法

IP マルチキャストで着信インターフェイスとして選択されるインターフェイスを変更するには、以下のいずれかを行うことができます。

- マルチキャストを経由させたいインターフェイスだけに PIM を設定します。ただし、これはマルチキャストの冗長性が失われることを意味します。

- サブネットを変更して、最優先のマルチキャスト リンクに指定したいリンクに最も大きな IP アドレスが割り当てられるようにします。

- 優先するマルチキャスト インターフェイスを指す静的マルチキャスト ルート（mroute）を作成します。つまり、マルチキャストの冗長性がなります。

例のように、スタティックな mroute が作成されます。

スタティックなmrouteを設定する前に、この出力で、ルーティングテーブルに発信元アドレス10.1.1.1に対する等コストのルートが3つあることがわかります。RPF 情報では、RPF インターフェイスが E1/3 であることが示されています。

ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/3 RPF neighbor: ? (10.4.1.1) RPF route/mask: 10.1.1.1/24 RPF type: unicast (ospf 1) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00 (10.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT Incoming interface: Ethernet1/3, RPF nbr 10.4.1.1 Outgoing interface list: Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42

静的 mroute を設定した後は、以下の出力に示されているように、RPF インターフェイスが E1/1 に変化しています。

ip22-75b#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 10.2.1.1 ip22-75b(config)#end ip22-75b#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet1/1 RPF neighbor: ? (10.2.1.1) RPF route/mask: 10.1.1.1/0 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-75b#show ip route 10.1.1.1 Routing entry for 10.1.1.1/24 Known via "ospf 1", distance 110, metric 20, type intra area Redistributing via ospf 1 Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks: * 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 1 10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 1 10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00 Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00 (10.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00 Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47 Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28

使用可能なすべての等コスト パス全体に対して、IP マルチキャストのロード バランスが行われない理由

このセクションでは、利用可能なすべての等コストパスでロード バランシングが行われるように IP マルチキャストを設定するうえでの一般的な問題の解決策を説明します。例として、次のネットワーク ダイアグラムが使用されています。

注：トンネルを介した等コストパス間でIPマルチキャストトラフィックをロードスプリットする前に、CEFパケット単位のロードバランシングを設定してください。そうしないと、GREパケットをパケット単位でロードバランシングできません。マルチキャスト環境でロード シェアリングを行う他の方法については、ECMP での IP マルチキャスト トラフィックのロード スプリットを参照してください。

使用可能なすべての等コストパス間でロードバランシングを行うようにIPマルチキャストを設定する

図では、ルータ75bには発信元(10.1.1.1)に戻る3つの等コストパスがあります。この 3 つのリンク全体に渡り、マルチキャスト トラフィックのロード バランスを行います。

考えられる解決方法

「複数の等コスト パスにより、RPF が不適切な動作をする」のセクションで説明したように、Protocol Independent Multicast（PIM）は RPF 用に 1 つのインターフェイスだけを選択し、他のインターフェイスをプルーニングします。これはロード バランスが行われないことを意味します。ロード バランスを行うには、冗長リンクから PIM を削除し、ルータ 75a とルータ 75b との間にトンネルを作成する必要があります。その後、リンク レベルでロード バランスを行い、トンネル上で IP を実行することができます。

次はトンネル用の設定です。

ルータ 75a

interface Tunnel0

ip address 10.6.1.1 255.255.255.0

ip pim sparse-dense-mode

tunnel source Ethernet0/0

tunnel destination 10.5.1.1

!

interface Ethernet0/0

ip address 10.1.1.2 255.255.255.0

ip pim sparse-dense-mode

!

interface Ethernet0/1

ip address 10.2.1.1 255.255.255.0

!

interface Ethernet0/2

ip address 10.3.1.1 255.255.255.0

!

interface Ethernet0/3

ip address 10.4.1.1 255.255.255.0

ルータ 75b

interface Tunnel0

ip address 10.6.1.2 255.255.255.0

ip pim sparse-dense-mode

tunnel source Ethernet1/4

tunnel destination 10.1.1.2

!

interface Ethernet1/1

ip address 10.2.1.2 255.255.255.0

!

interface Ethernet1/2

ip address 10.3.1.2 255.255.255.0

!

interface Ethernet1/3

ip address 10.4.1.2 255.255.255.0

!

interface Ethernet1/4

ip address 10.5.1.1 255.255.255.0

ip pim sparse-dense-mode

!

ip mroute 0.0.0.0 0.0.0.0 Tunnel0

トンネルを設定した後、show ip mrouteコマンドを入力して、グループに対するマルチキャストルート(mroute)を調べます。

ip22-75a#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 (10.1.1.1, 224.1.1.1), 02:40:32/00:03:29, flags: TA Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00 ip22-75b#show ip mroute 224.1.1.1 IP Multicast Routing Table Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer Running A - Advertised via MSDP Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00 Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00 (10.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT Incoming interface: Tunnel0, RPF nbr 10.6.1.1, Mroute Outgoing interface list: Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00

マルチキャスト データのロード バランシングが 3 つのリンクで均等に行われていることを確認するには、ルータ 75a のインターフェイス データを調べます。

着信インターフェイスは 9000 bps/秒です。

ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec

3 つの発信インターフェイスは、それぞれ 3000 bps と示されています。

ip22-75a#show interface e0/1 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/2 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/3 . . 5 minute output rate 3000 bits/sec, 7 packets/sec

ルータでIPマルチキャストの「INVALID_RP_JOIN」エラーメッセージを受信する場合

このセクションでは、IP マルチキャストの「INVALID_RP_JOIN」エラー メッセージに関連する一般的な問題のソリューションを説明しています。

問題の診断：第 1 部

次のエラー メッセージが Rendezvous Point（RP; ランデブー ポイント）で受信されます。

00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4

『Cisco IOSソフトウェアシステムエラーメッセージ』ドキュメントでは、このエラーの原因について説明しています。ダウンストリームPIMルータがJoinメッセージを共有ツリーに送信し、このルータはこれを受け入れない場合です。この動作は、このルータが下流ルータだけに特定の RP への加入を許可することを示しています。

フィルタリングを行っている疑いがあります。次のように、ルータの設定を調べる必要があります。

interface Ethernet0/0 ip address 10.1.5.4 255.255.255.0 ip pim sparse-dense-mode ! ip pim accept-rp 10.2.2.2 8 ip pim send-rp-announce Ethernet0/0 scope 15 ip pim send-rp-discovery scope 15 ! access-list 8 permit 224.0.0.0 0.255.255.255

この設定の中で、 accept-rp  文が意味するところは何ですか。IPマルチキャストルーティングコマンドでは、「指定されたRPおよびグループの特定のリストに対するJoinsまたはPrunesをルータが受け入れるように設定するには、ip pim accept-rp global configurationコマンドを使用します。このチェックを削除するには、このコマンドの no 形式を使用します。』

ip pim accept-rpコマンドを削除すると、メッセージが表示されなくなります。問題の原因となっていたコマンドは見つかりましたが、そのコマンドを設定に維持する必要がある場合はどうなるでしょうか。誤ったRPアドレスを許可する可能性があります。正しいRPアドレスを確認するには、 show ip pim rp mapping  コマンドを入力します。

ip22-75a#show ip pim rp mapping PIM Group-to-RP Mappings This system is an RP (Auto-RP) This system is an RP-mapping agent Group(s) 224.0.0.0/4 RP 10.1.5.4 (?), v2v1 Info source: 10.1.5.4 (?), via Auto-RP Uptime: 01:00:48, expires: 00:02:07

出力によると、Auto-RPまたはその他の方法で学習したRPは10.1.5.4だけです。ただし、このルータはグループ 224.0.0.0/4 に対する唯一の RP です。したがって、設定の pim accept-rp文は間違っています。

考えられる解決方法

ソリューションは、ip pim accept-rp文のIPアドレスを次のように修正することです。

変更するのは次の設定です。

ip pim accept-rp 10.2.2.2 8

変更後は、

ip pim accept-rp 10.1.5.4 8

別の方法として、auto-rp キャッシュの内容を受け入れるようにこのステートメントを変更して、必要なマルチキャスト グループ範囲がアクセス リスト（この例では 8）で確実に許可されるようにすることもできます。次に例を示します。

ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255

問題の診断：第 2 部

router2 に、次のエラー メッセージが表示されます。

router2# *Aug 12 15:18:17.891: %PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40) Join from 0.0.0.0 for invalid RP 10.2.1.1

router2 がグループ 224.1.1.1 の RP であるかどうかを確認します。

router2#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:21:26, expires: 00:02:24 router2#

224.1.1.1 の RP は 10.1.1.1 です。

これが router2 のインターフェイスの 1 つであるかどうかを確認します。

router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.1.1.2 YES NVRAM up up Ethernet1/0 10.2.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#

router2はRPではないため、このRP-Joinパケットを受信していないはずです。下流ルータがJoinをrouter2に送信する理由をチェックします。ただし、次の理由をチェックしてはなりません。

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:24:30, expires: 00:02:16 Group(s): 224.0.0.0/4, Static-Override RP: 10.2.1.1 (?) router3#

上記の出力を見るとわかるように、router3 で静的に設定している RP 情報で、誤って router2 を指しています。これが、router3 が router2 に RP-Join を送信している理由です。

考えられる解決方法

router2 をグループ 224.1.1.1 の RP にするか、router3 で設定を変更して正しい RP アドレスが参照されるようにします。

router3#show run | i rp ip pim rp-address 10.2.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 10.2.1.1 override router3(config)#exit router3#

router3の設定が修正された後、router3は正しいRPアドレスを参照し、エラーメッセージは停止します。

router3#show ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 10.1.1.1 (?), v2v1 Info source: 10.1.1.1 (?), elected via Auto-RP Uptime: 00:30:45, expires: 00:02:02 router3#

重複したマルチキャスト パケット ストリームが受信される

原因 1

2 台のルータが稠密モードに設定されてる場合、重複したマルチキャスト パケットが受信されます。稠密モードでは、デバイスによってストリームが散発的にフラッディングされます。フラッディングの後、ストリームが必要とされない部分のインターフェイスがプルーニングされます。2 台のルータでもアサーション処理が発生し、フォワーダが判断されます。タイマーが切れるたびにこのプロセスが行われますが、プロセスが完了するまでは、両方のルータがストリームを転送します。これは、アプリケーションで重複するマルチキャスト ストリームが受信される原因となります。

考えられる解決方法 1

この問題は、一方のルータをマルチキャスト ルーティングに設定しておき、他方のルータを上流で RP に設定すると解決できます。このルータにストリームが到達する前にストリームを希薄モードへ変換するようにこのルータを設定します。これにより、アプリケーションへの重複パケットの到達を阻止できます。重複したパケットがエンド ホストへ確実に到達しないようにすることは、ネットワーク側の責任ではありません。重複したパケットを処理し、不要なデータを無視することは、アプリケーション側の責任です。

原因 2

この問題は、出力マルチキャスト レプリケーション モードに設定されている Catalyst 6500 スイッチで発生する可能性があり、いずれかのラインカードの抜き差し（OIR）によって引き起こされる可能性があります。OIR の後、Fabric Port Of Exit（FPOE）が誤ってプログラミングされることが原因で、誤ったファブリック出口チャネルにパケットが転送され、そこから誤ったライン カードに送信される可能性があります。結果として、これらのパケットはファブリックにループバックされ、正しいラインカード上で終了する際に繰り返し複製されるようになります。

C6509#show mls ip multicast capability Current mode of replication is Egress Auto replication mode detection is ON Slot Multicast replication capability 1 Egress 2 Egress 3 Egress 4 Egress 5 Egress 6 Egress 7 Egress

考えられる解決方法 2

回避策としては、入力レプリケーション モードへ変更してください。出力から入力レプリケーション モードへ変更する間、ショートカットが削除されて再インストールされるため、トラフィック中断が発生する可能性があります。

mls ip multicast replication-mode ingress

この問題を永続的に解決するには、Cisco IOSソフトウェアをCisco Bug ID CSCeg28814の影響を受けないリリースにアップグレードします。

注：シスコの内部ツールおよびバグ情報にアクセスできるのは、登録ユーザのみです。

原因 3

この問題は、エンドホストまたはサーバ上で Receive Side Scaling（RSS）設定が無効になっている場合にも発生することがあります。

考えられる解決方法 3

RSS 設定により、複数の CPU 間でのデータの高速な送信が容易になります。エンド ホスト側またはサーバ側で RSS 設定をイネーブルにします。

マルチキャスト パケットがドロップされる

原因 1

マルチキャスト トラフィックが転送される際には、過剰なフラッシュやパケット ドロップが発生する可能性があります。show interfaceコマンドでフラッシュを確認できます。

Switch#show interface gigabitethernet 1/0 !--- Output suppressed MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s, media type is SX input flow-control is off, output flow-control is on Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of "show interface" counters never Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 30 second input rate 195000 bits/sec, 85 packets/sec 30 second output rate 1000 bits/sec, 1 packets/sec L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt,

438000092206 bytes mcast L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes 1326976857 packets input, 506833655045 bytes, 0 no buffer Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 31643944 packets output, 3124494549 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out

考えられる解決方法 1

過剰なフラッシュが確認されたインターフェイスに関して、STP 値を無限に設定できます。

これを設定します。

Switch(config-if)#ip pim spt-threshold infinity

原因 2

ip igmp join-group <group-name>コマンドをインターフェイスで使用すると、プロセススイッチングが行われます。いずれかのインターフェイスでマルチキャスト パケットのプロセス スイッチングが行われると、該当するグループへのすべてのパケットのプロセス スイッチングが必要になるため、CPU 使用率が増加します。 show buffers  input-interface コマンドを実行して、異常なサイズをチェックできます。

Switch#show buffers input-interface gigabitethernet 1/0 Header DataArea Pool Rcnt Size Link Enc Flags Input Output 437C6EAC 8096AE4 Middl 1 434 7 1 280 Gi1/1 None 437C74B4 8097864 Middl 1 298 7 1 280 Gi1/1 None 437C98E4 809C964 Middl 1 434 7 1 280 Gi1/1 None 437CAAFC 809F1E4 Middl 1 349 7 1 280 Gi1/1 None 437CAE00 809F8A4 Middl 1 519 7 1 280 Gi1/1 None !--- Output suppressed

考えられる解決方法 2

ip igmp join-group <group-name>コマンドの代わりにip igmp static-group <group-name>コマンドを使用できます。

注:以前の問題が原因で、CPU使用率が約90 %高くなる可能性があります。「考えられる解決策」で問題が解決すると、CPU 使用率は通常の状態に戻ります。

関連情報

- CLIツールを使用したマルチキャストネットワークのトラブルシューティング

- マルチキャスト クイックスタート設定ガイド

- ECMPマルチキャストロードスプリットの有効化

- IP マルチキャスト テクノロジーに関するサポート ページ

- IP ルーティング プロトコルに関するサポート ページ

- シスコテクニカルサポートとダウンロード