IPマルチキャストガイドのトラブルシューティング
内容
はじめに
このドキュメントでは、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にマルチキャストパケットが着信し、グループ10.224.1.1に送信されています。これを (S,G) または (10.1.1.1, 10.224.1.1) と記します。
問題の診断
ルータ 75a に直接接続されたホストではマルチキャストが受信されていますが、ルータ 72a に直接接続されたホストでは受信されていません。最初に、 show ip mroute 224.1.1.1 コマンドを発行して、ルータ75aのアクティビティを確認します。次のコマンドでは、グループ アドレス 10.224.1.1 に対するマルチキャスト ルート（mroute）が検査されます。
75a#show ip mroute 10.224.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
(*, 10.224.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, 10.224.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 のアドレスを持つサーバからマルチキャスト パケットが発信されることが、このエントリから分かります。ここでは 10.224.1.1 のマルチキャスト グループに送信されます。パケットは Ethernet0/0 インターフェイスに着信して、Ethernet0/1 インターフェイスから転送されます。これは完全なシナリオです。
config コマンドを入力します 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ネイバーシップは良好であることがわかります。
config コマンドを入力します show ip mroute コマンドを発行して、ルータ72aに正しいmrouteが設定されているかどうかを確認します。
ip22-72a#show ip mroute 10.224.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
(*, 10.224.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, 10.224.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 10.224.1.1 コマンドを使用して、着信インターフェイスがEthernet2/0であり、Etheret3/1が想定されていることを確認します。
config コマンドを入力します show ip mroute 10.224.1.1 count コマンドを発行して、このグループのマルチキャストトラフィックがルータ72aに到達したかどうか、および次に何が起こるかを確認します。
ip22-72a#show ip mroute 10.224.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: 10.224.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...
config コマンドを入力します show ip rpf コマンドを発行して、RPFエラーが発生しているかどうかを確認します。
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 アドレスが使用されます。
-
複数の一致するルートが見つかった場合は、アドミニストレーティブディスタンスが最も小さいルートが使用されます。
-
アドミニストレーティブ ディスタンスが等しい場合は、以下の優先順位が適用されます。
-
スタティックな mroute
-
DVMRP ルート
-
MBGP ルート
-
ユニキャスト ルート
-
-
同じルート テーブル内でルートの複数のエントリが発生する場合、一致する最も長いルートが使用されます。
「 show ip mroute 224.1.1.1 コマンド出力は、RPFインターフェイスがE2/0であることを示していますが、着信インターフェイスはE3/1である必要があります。
config コマンドを入力します show ip mroute 224.1.1.1 コマンドを発行して、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 10.224.1.1 *Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface
パケットは適切に E3/1 に着信しています。しかし、これはユニキャスト ルーティング テーブルで RPF チェックに使用するインターフェイスではないため、パケットがドロップされます。
考えられる解決方法
この要件を満たすためにユニキャスト ルーティング テーブルを変更できます。あるいは、ユニキャスト ルーティング テーブルの内容とは無関係に、特定のインターフェイスから 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 HostAはパケットを受信します。
ip22-72a#show ip mroute 10.224.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
(*, 10.224.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, 10.224.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 10.224.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: 10.224.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 10.224.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: 10.224.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 10.224.1.1
*Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
発信元の TTL 設定が原因で、ルータによってマルチキャスト パケットがホストに転送されない
このセクションでは、存続可能時間（TTL）値がゼロになったために IP マルチキャスト パケットが転送されないという一般的な問題の解決策を説明します。多くのマルチキャスト アプリケーションが存在するため、これは一般的な問題です。これらのマルチキャスト アプリケーションは、主に LAN を使用する設計になっているため、TTL を低い値に設定します（1 であっても設定可能）。次のネットワーク ダイアグラムを例として使用します。
主にLAN使用のために設計されたマルチキャストアプリケーションの例
問題の診断
上の図では、ルータAは送信元から直接接続された受信側のルータBにパケットを転送しません。次の出力を参照してください。 show ip mroute コマンドをルータ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), 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
(*, 10.224.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 ディスカバリ グループに参加しているため、出力の 10.224.0.40 を無視できます。ただし、10.224.1.1 に関して送信元がリストされていません。「*, 10.224.1.1」に加えて、「10.1.1.1, 10.224.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が正しく指定されています。
インターフェイスでPIMが設定されているかどうかを show ip pim interface コマンドにより、WLC CLI で明確に示されます。
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 コマンドにより、WLC CLI で明確に示されます。
ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps
この出力によると、ルータはアクティブ トラフィックを認識していません。
ROUTERA#debug ip mpacket IP multicast packets debugging is on
おそらく、レシーバはグループ10.224.1.1のInternet Group Management Protocol(IGMP)レポート(join)を送信しません。次のコマンドを使用して確認できます。 show ip igmp group コマンドにより、WLC CLI で明確に示されます。
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 10.224.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2
10.224.1.1はE1/2に参加しています。これは問題ありません。
PIM 稠密モードはフラッディングとプルーニングを行うプロトコルであるため、加入（join）はありませんが、グラフト（graft）があります。ルータ B ではルータ A からのフラッドが受信されていないため、グラフトの送り先が認識されていません。
これがTTLの問題であるかどうかは、スニファキャプチャで確認できます。また、 show ip traffic コマンドにより、WLC CLI で明確に示されます。
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
(*, 10.224.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, 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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によって確実にパケットが転送されるようにするには、ルータ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 10.224.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=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.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
コマンドは、指定されたしきい値（この場合は15）よりも低いTTLを持つパケットは転送されないことを意味します。このコマンドは通常、内部マルチキャスト トラフィックがイントラネットの外部に流れないよう、境界を定めるために使用されます。
考えられる解決方法
次のいずれかを削除します ip multicast ttl-threshold
このコマンドを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 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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マルチキャストを設定する
図では、ルータ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 10.224.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
(*, 10.224.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, 10.224.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 10.224.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
(*, 10.224.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, 10.224.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 (*, 10.224.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.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および特定のグループリスト宛てのJoinまたはPrunesを受け入れるようにルータを設定するには、 ip pim accept-rp グローバル コンフィギュレーション コマンドを発行します。このチェックを削除するには、このコマンドの no 形式を使用します。』
を削除すると、 ip pim accept-rp コマンドを実行すると、メッセージが表示されなくなります。問題の原因となっていたコマンドは見つかりましたが、そのコマンドを設定に維持する必要がある場合はどうなるでしょうか。誤ったRPアドレスを許可する可能性があります。config コマンドを入力します show ip pim rp mapping コマンドを発行して、正しいRPアドレスを確認します。
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 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がグループ10.224.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#
10.224.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パケットを受信していないはずです。下流のルータがrouter2にJoinを送信する理由をチェックします。ただし、次の理由をチェックしてはなりません。
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をグループ10.224.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#
CGMP によってマルチキャスト パケットのフラッディングが阻止されない
このセクションでは、Cisco Group Management Protocol（CGMP）が特定のサブネット上にあるすべてのルータでイネーブルにされていない場合に、マルチキャスト パケットが無用のフラッディングを起こす仕組みと、この問題を回避する方法について説明しています。例として、次のネットワーク ダイアグラムが使用されています。
Cisco Group Management Protocol(CGMP)が有効になっていない
問題の診断
この図では、Catalyst 5000 スイッチ A の静的 CAM テーブルに、入力されている正しいポートがまったく表示されていません。CGMP が設定されているルータからは、CGMP パケットが送信されません。
CGMPはCGMPを使用して set cgmp enable コマンドをスイッチAで発行し、 ip cgmp コマンドをルータ75aのE0/2インターフェイスで発行します。ただし、スイッチAでマルチキャストグループが見られないのは、 show multicast group コマンドが発行されます。
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- Total Number of Entries = 0
このコマンドの出力では、CGMPが設定されたルータがある各ポート（ポート2/3）と、対象のレシーバがある各ポート（ポート2/6）を表示する必要があります。0がリストされているため、すべてのポートが望むかどうかにかかわらず、マルチキャストトラフィックで不必要にフラッディングされると考えられます。
観察
ルータ 75a に Protocol Independent Multicast（PIM）ネイバーが設定されているかどうかを確認します。
ip22-75a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 Ethernet0/2 00:07:41 00:01:34 v2
出力に示されるとおり、ルータ 75a は、スイッチ A を介して有効な PIM ネイバーとしてルータ 75b を認識できます。
次に、ルータで正しいマルチキャスト ルート（mroute）情報を受信するかどうかを確認します。
ip22-75a#show ip mroute 10.224.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
(*, 10.224.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00
(10.1.1.1, 10.224.1.1), 00:14:56/00:02:59, flags: CTA
Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00
出力に示されるとおり、ルータ 75a は E0/2 からスイッチ A に向けてマルチキャスト パケットを転送します。この出力には、ルータ 75b がマルチキャスト パケットを受信して正しく転送していることが示されています。
ip22-75b#show ip mroute 10.224.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
(*, 10.224.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00
(10.1.1.1, 10.224.1.1), 00:00:35/00:02:59, flags: CTA
Incoming interface: Ethernet1/3, RPF nbr 10.2.1.2
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
スイッチAの観点からは、ルータ75aがポート2/3から見えていることがわかります。
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 Total Number of Entries = 1
ここまでは、すべて良好のようです。一部を入力 debug コマンドをルータ75aで発行して、確認できる内容を確認します。
ip22-75a#debug ip cgmp CGMP debugging is on *Feb 8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:45:22.206: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:46:22.234: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:47:22.262: GDA 0000.0000.0000, USA 00d0.ff2f.a002
出力によると 0000.0000.0000 は全グループのアドレスです。ルータから CGMP Join/Leave メッセージが送られるときにこれが使用され、こうしてスイッチがルータ ポートを入力できます。GDA は Media Access Control（MAC; メディア アクセス制御）レベルの形式での Group Destination Address（グループ宛先アドレス）を、USA は Unicast Source Address（ユニキャスト発信元アドレス）を意味しています。これは、この CGMP メッセージの生成対象である IGMP レポートを発信したホストのアドレスです。この場合、ルータ 75a の E0/2 インターフェイスの MAC アドレスになっています。ルータ75aのE0/2のMACアドレスは、 show interface コマンドを発行します。
ip22-75a#show interface e0/2 Ethernet0/2 is up, line protocol is up Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)
また、次の場合に定期的にこの状態が表示されます。 debug ip igmp コマンドがオンになっている：
*Feb 8 12:51:41.854: IGMP: Received v2 Report from 10.2.1.3 (Ethernet0/2) for 10.224.1.1
ただし、ルータ 75a からの対応する CGMP パケットが引き続いて表示されることはありません。これは、ルータ 75a が IGMP レポートを受信するにもかかわらず、ブロック対象ポートをスイッチ A に認識させるために必要な CGMP パケットを生成しないことを意味します。ルータ 75a が IGMP クエリアであれば、このような動作をすべきです。ルータ 75a からの以下の出力を見ると、期待される動作が行われない理由がわかります。
ip22-75a#show ip igmp interface e0/2 Ethernet0/2 is up, line protocol is up Internet address is 10.2.1.2/24 IGMP is enabled on interface Current IGMP version is 2 CGMP is enabled IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 3 joins, 1 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 10.2.1.2 (this system) IGMP querying router is 10.2.1.1 No multicast groups joined
同じサブネット上に2台のルータがあり、両方をCGMP用に設定している場合、CGMPパケットを送信できるのは1台だけです。CGMPパケットを送信するルータは、ルータに照会するIGMPです。つまり、IGMP 対応ルータの中で最も小さなユニキャスト IP アドレスを持つルータです。
この場合、ルータ 75a とルータ 75b は IGMP 対応（ルータ 75b が IGMP クエリー ルータ）ですが、ルータ 75a だけが CGMP 対応ルータになっています。ルータ 75a は IGMP クエリア ルータではないため、CGMP パケットは送信されません。
考えられる解決方法
この問題を解決するには、IGMP クエリア ルータで CGMP を設定する必要があります。この場合は、ルータ 75b です。まず、オンにします debug ルータ75bでのコマンド：
ip22-75b#conf t Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#int e 1/3 ip22-75b(config-if)#ip cgmp ip22-75b(config-if)#end ip22-75b#debug ip cgmp ip22-75b#debug ip igmp *Feb 8 12:58:42.422: IGMP: Received v2 Report from 10.2.1.3 (Ethernet1/3) for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 *Feb 8 12:58:42.422: from 10.2.1.3 for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 *Feb 8 12:58:42.422: GDA 0100.5e01.0101, USA 0030.b655.a859
ルータ75bは、グループ10.224.1.1に対するIGMPレポートを10.2.1.3から受信します。これに続き、10.224.1.1 に相当する MAC アドレスと対象ホスト 10.2.1.3 の MAC アドレス（USA）に関する CGMP Join を、スイッチ A に送信します。スイッチ A では、ホストがオンになっているポートを判別でき、これをオープンとしてマークし、他をブロックします。
スイッチAで動作する必要があります。
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4,2/6 Total Number of Entries = 2
動作が改善しています。10.224.1.1(01-00-5e-01-01-01)パケットは、スイッチAのポート2/3、2/4、および2/6からのみ送信されます。他のすべてのポートに対するフラッディングは止まっています。エントリの総数はここでは正しく 2 と表示されています。MAC アドレス 01-00-5e-00-01-28 はマルチキャスト アドレス 224.0.1.40 からマップされています。これは CGMP の self-join に使用されています。
発信元または受信側の配置が原因で、CGMP によってマルチキャスト パケットのフラッディングが阻止されない
このセクションでは、Catalyst スイッチが正しいホストにだけトラフィックをフラッディングするのではなく、すべてのポートにフラッディングするという一般的な問題の解決策を説明します。例として、次のネットワーク ダイアグラムが使用されています。
すべてのポートにトラフィックをフラッディングするCatalystスイッチ
問題の診断
上記の図では、ルータ 75a および 75b と Catalyst 5000（スイッチ A）が、マルチキャストおよび Cisco Group Management Protocol（CGMP）に対応するように正しく設定されています。ホストがマルチキャスト トラフィックを受信します。ただし、スイッチ A の他のすべてのポートも同じようにマルチキャスト トラフィックを受信します。スイッチ A はすべてのポートでトラフィックをフラッディングするため、CGMP が機能しません。
show multicast group スイッチAでのコマンドは次のようになります。
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 Total Number of Entries = 1
出力からわかるとおり、唯一のグループは 224.0.1.40 であり、ルータが自動 RP グループの CGMP 自己参加を送信するときにこのグループを使用します。他のグループが存在しない理由は何でしょうか。
考えられる解決方法
解決策を理解するには、特定の状況で CGMP がどのように動作するかを理解する必要があります。CGMP 対応ルータは CGMP 参加をスイッチに送信することで、特定のマルチキャスト グループを扱うホストをスイッチに通知します。スイッチではこれらのホストの MAC アドレスを自身の CAM テーブルから探し、対象ホストにポートからマルチキャスト パケットを転送し、他のすべてのポートをマルチキャスト パケットの転送からブロックします。
ルータは、ルータの CGMP 対応インターフェイスと同じインターフェイス上にある発信元からのマルチキャスト パケットを受信すると、CGMP self-join を CGMP 対応インターフェイスから送信します。
たとえば、送信元がルータ75aおよび75bと同じサブネット(VLAN)(10.2.1.0/24)にある場合、CGMPは正常に動作します。ルータは、送信元からのパケットを識別すると、CGMP self-joinをスイッチに送信します。これにより、ルータがオンになっているポートが動的に学習され、他のすべてのポートはマルチキャストパケットを転送できなくなります。
ルータは、あるホストからの IGMP レポートを、CGMP を有効にしているインターフェイスと同じインターフェイスで受信すると、CGMP join を CGMP 対応のインターフェイスから送信します。
別の例として、対象となるホストが同じ VLAN 上にあるとします。この場合、CGMP 対応ルータが、特定のマルチキャスト グループを扱うホストから Internet Group Management Protocol（IGMP）レポートを受信すると、ルータは CGMP 参加を送信します。この join では、加入したいホストの Media Access Control（MAC; メディア アクセス制御）アドレスと、ホストが加入したいグループが示されています。次に、Catalyst 5000は自身のCAMテーブルでホストMACアドレスをチェックし、関連付けられたポートをマルチキャストグループリストに登録して、他の関係のないポートをすべてブロックします。
発信元および対象となるホストが CGMP 対応のサブネット（VLAN）以外のサブネットにある場合は、この動作は当てはまりません。そのような送信元から着信するマルチキャスト パケットは、スイッチに CGMP 自己参加を送信するようにルータをトリガーしません。したがって、そのパケットがスイッチに到達すると、VLAN 内のあらゆる箇所でフラッドが発生します。このシナリオは、スイッチ上のポートに属する VLAN 内のホストが IGMP 参加を送信するまで続きます。ルータが CGMP パケットを送信するのは IGMP レポートを受信した場合だけで、これにより、スイッチによって対応するホストのポートが転送先として追加され、他のポートはすべてブロックされます（このルータのポートは除く）。
CGMPをこのトランジットタイプのトポロジで動作させるには、次のネットワークダイアグラムに示すように、ルータ75aおよび75bと同じVLANにホストを追加します。
ルータ75aおよび75bと同じVLANへのホストの追加
あるいは、次の例のように、発信元をルータ 75a や 75b と同じサブネットに移動させます。
ルータ75aおよび75bと同じサブネットでの送信元の移動
発信元を同じサブネットに移動し、その後スイッチ A からの出力をチェックします。
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 2/4 6 Total Number of Entries = 2 '*' - Configured Console> (enable) Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4 Total Number of Entries = 2
CGMP によって特定のグループ アドレスに対するマルチキャスト パケットのフラッディングが阻止されない
この項では、一部のマルチキャスト IP アドレスによって Cisco Group Management Protocol（CGMP）が local area network（LAN; ローカルエリア ネットワーク）上のすべてのポートにマルチキャスト トラフィックをフラッドする原因について説明します。マルチキャスト グループ アドレス 10.225.0.1 を使用すると、CGMP は機能しません。マルチキャスト ストリームがすべてのスイッチのポートに溢れ出し、帯域幅を消費します。ところが、アドレスを 10.225.1.1 に変更すると、CGMP が正しく動作します。10.225.0.1はルーティングプロトコルの登録済みアドレスではないため、使用できますか。
考えられる解決方法
まず、レイヤ 3 のマルチキャスト アドレスがレイヤ 2 のマルチキャスト アドレスにマップされる仕組みを理解することが重要です。すべての IP マルチキャスト フレームは、24 ビット プレフィックス 0x0100.5e で始まる IEEE MAC レイヤ アドレスを使用します。レイヤ 3 アドレスをレイヤ 2 アドレスにマッピングすると、レイヤ 3 マルチキャスト アドレスの下位 23 ビットが IEEE MAC アドレスの下位 23 ビットにマッピングされます。
理解すべきもう 1 つの重要な点として、IP マルチキャスト アドレスには固有の 28 ビット アドレス空間（32 ビットから、1110 クラス D プレフィックスを含む最初の 4 ビットを除外）があります。IEEE MAC アドレスには 23 ビットしか渡されていないため、重複する 5 ビット分がそのまま残ります。このことは、複数のレイヤ 3 マルチキャスト アドレスが、同一のレイヤ 2 マルチキャスト アドレスにマップされてしまう可能性があることを意味しています。
例：
10.244.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001 10.244.128.0 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001
上記の例では、10.244.0.1 と 10.244.128.0 の両方が同じレイヤ 2 マルチキャスト アドレスにマッピングされます。
レイヤ 3 /レイヤ 2 間でのマルチキャスト アドレスのマッピング方法がわかったところで、この問題の具体的な解決策を見ていきましょう。
スイッチ A はマルチキャスト パケットを 224.0.0.x にフラッディングします。その理由は、これらのアドレスがリンクローカルであり、ローカル エリア ネットワーク（LAN）上のすべてのデバイスにリンクローカル アドレスが到達すべきだからです。Catalystスイッチは、224.0.0.xでMACレベルが曖昧な他のマルチキャストアドレスにもマルチキャストパケットをフラッディングします（たとえば、10.244.0.1と10.225.0.1はどちらも0100.5e00.0001にマッピングされます）。CGMP がイネーブルかどうかにかかわらず、スイッチではこれらのリンクローカルなアドレスに宛てられたマルチキャスト パケットをフラッドします。
したがって、マルチキャストアプリケーションでは、0100.5e00.00xxのレイヤ2マルチキャストアドレスにマッピングするクラスDアドレスの使用を避ける必要があります。ここで、xxは16進数の00 ～ FFです。これには、これらのクラス D アドレスが含まれます。
224.0.0.x (x = 0 to 255) 225.0.0.x . 239.0.0.x 224.128.0.x (x = 0 to 255) 225.128.0.x . 239.128.0.x
重複したマルチキャスト パケット ストリームが受信される
原因 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 gi 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
コマンドを実行すると、プロセススイッチングが行われます。いずれかのインターフェイスでマルチキャスト パケットのプロセス スイッチングが行われると、該当するグループへのすべてのパケットのプロセス スイッチングが必要になるため、CPU 使用率が増加します。この場合は、 show buffers input-interface コマンドを発行し、異常なサイズをチェックします。
Switch#show buffers input-interface gi 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
コントローラ GUI または CLI を使用して ip igmp static-group
コマンドを使用して、 ip igmp join-group
コマンドを使用して、アップグレードを実行します。
関連情報
更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
2.0 |
26-May-2023 |
再認定 |
1.0 |
02-Dec-2013 |
初版 |
フィードバック