IPマルチキャストガイドのトラブルシューティング

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 を実行することができます。

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

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

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 ルーティング プロトコルに関するサポート ページ
• シスコテクニカルサポートとダウンロード