IP : IP マルチキャスト

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

2009 年 4 月 15 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2008 年 1 月 28 日) | フィードバック

目次


概要

このドキュメントでは、IP マルチキャストに関する一般的な問題とソリューションについて説明しています。



前提条件

要件

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



使用するコンポーネント

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



表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。



背景説明

マルチキャスト ルーティングをトラブルシューティングする場合、最初に調べるのは発信元のアドレスです。マルチキャストには、Reverse Path Forwarding(RPF; リバース パス転送)チェックの概念が取り入れられています。マルチキャスト パケットがインターフェイスに到達すると、RPF プロセスによって、この着信インターフェイスが、ユニキャスト ルーティングによってマルチキャスト パケットの発信元に到達するために使用される発信インターフェイスであることが確認されます。この RPF のチェック プロセスによってループが防止されます。マルチキャスト ルーティングでは、パケットの発信元が Reverse Path Forwarding(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 の障害に関連する一般的な問題のソリューションについて説明しています。例として、次のネットワーク ダイアグラムが使用されています。

ネットワーク ダイアグラム

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



問題の診断

ルータ 75a に直接接続されたホストではマルチキャストが受信されていますが、ルータ 72a に直接接続されたホストでは受信されていません。まず、show ip mroute 224.1.1.1 コマンドを発行して、ルータ 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 

(1.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 エントリに焦点を絞ります。1.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 
2.1.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
 
(1.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:      1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#

次のように、Other カウントからは RPF の障害が原因でトラフィックが廃棄されたことがわかります。 total 471 drops, due to RPF failure – 471…

show ip rpf <送信元> コマンドを発行して、RPF エラーが発生しているかどうかを確認します。

ip22-72a#show ip rpf 1.1.1.1
RPF information for ? (1.1.1.1)
  RPF interface: Ethernet2/0
  RPF neighbor: ? (0.0.0.0)
  RPF route/mask: 1.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 rpf 1.1.1.1 コマンド出力では、RPF インターフェイスが E2/0 であると示されていますが、着信インターフェイスは E3/1 である必要があります。

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

ip22-72a#show ip route 1.1.1.1
  Routing entry for 1.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 1.1.1.1 コマンド出力からは、RPF インターフェイスとして誤ったインターフェイスが選択されるようにするスタティックな /32 ルートが存在していることがわかります。

さらにいくつかの debug コマンドを発行します。

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=1.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 コマンドを使用して、デバッグの結果を確認できます。



考えられる解決方法

ユニキャスト ルーティング テーブルを要件を満たすように変更します。あるいは、スタティックな mroute を追加して、ユニキャスト ルーティング テーブルの状態にかかわらず、特定のインターフェイスに対して強制的に RPF を行うようにマルチキャストを設定することもできます。ここではスタティックな mroute を追加します。

ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1

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

ip22-72a#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet3/1 
  RPF neighbor: ? (2.1.1.1) 
  RPF route/mask: 1.1.1.1/32 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

show ip mroutedebug 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 

(1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA 
  Incoming interface: Ethernet3/1, RPF nbr 2.1.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: 1.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: 1.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=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 (Ethernet3/2) len 60, mforward 
*Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1) 
d=224.1.1.1 (Ethernet3/2) len 60, mforward


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

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

ネットワーク ダイアグラム



問題の診断

上記の図で、ルータ 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」の他に、「1.1.1.1, 224.1.1.1」も調べる必要があります。

show ip rpf コマンドを発行して、これが Reverse Path Forwarding(RPF; リバース パス転送)の問題なのかどうかを確認します。

ROUTERA#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet0/0 
  RPF neighbor: ? (0.0.0.0) - directly connected 
  RPF route/mask: 1.1.1.0/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 
1.1.1.2          Ethernet0/0        v2/Sparse-Dense  0    30     1.1.1.2 
2.1.1.1          Ethernet0/1        v2/Sparse-Dense  2    30     2.1.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     2.1.1.2 
224.1.1.1        Ethernet1/2          00:30:02  00:02:45  3.1.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 

(1.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 

(1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/1, RPF nbr 2.1.1.1 
  Outgoing interface list: 
    Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00


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

このセクションでは、TTL のしきい値が低すぎるために IP マルチキャスト トラフィックが受信側に届かないという、一般的な問題のソリューションについて説明しています。例として、次のネットワーク ダイアグラムが使用されています。

ネットワーク ダイアグラム



問題の診断

上記の図では、受信側(Receiver)で発信側(Source)からのマルチキャスト パケットが受信されません。発信元とルータ 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 

(1.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 1.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=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied 
*Jan 17 09:04:08.762: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied 
*Jan 17 09:04:08.814: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied

上記の debug メッセージでは、TTL のしきい値に到達したために、ルータ 75a でマルチキャスト パケットが転送されないことが示されています。ルータの設定を確認して、原因が見つかるかどうか調べます。次の出力に原因が示されています。

interface Ethernet0/1 
 ip address 2.1.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 しきい値の値を低くします。



等コスト パスが複数あることが原因で、意図しないリバース パス フォワーディングによって転送が行われる

このセクションでは、マルチキャストの送信元に対する等コスト パスによって、望まない Reverse Path Forwarding(RPF; リバース パス フォワーディング)の動作が起きる場合について説明しています。また、この動作を回避するように IP マルチキャストを設定する方法についても説明しています。例として、次のネットワーク ダイアグラムが使用されています。

ネットワーク ダイアグラム



問題の診断

上記の図では、ルータ 75b から発信元(Source)1.1.1.1 に戻るための等コスト パスが 3 つあり、RPF リンクとしての第一選択肢としては望まないリンクが選択されます。

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



考えられる解決方法

IP マルチキャストが選択したインターフェイスを着信インターフェイスとして変更するには、次の手順のいずれかを実行してください。

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

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

  • 望むマルチキャスト インターフェイスを示すスタティックなマルチキャスト ルート(mroute)を作成します。これはマルチキャストの冗長性が失われることを意味します。

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

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

ip22-75b#show ip route 1.1.1.1 
Routing entry for 1.1.1.0/24 
  Known via "ospf 1", distance 110, metric 20, type intra area 
  Redistributing via ospf 1 
  Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago 
  Routing Descriptor Blocks: 
  * 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 
      Route metric is 20, traffic share count is 1 
    2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 
      Route metric is 20, traffic share count is 1 
    3.1.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 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet1/3 
  RPF neighbor: ? (4.1.1.1) 
  RPF route/mask: 1.1.1.0/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 

(1.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CT 
  Incoming interface: Ethernet1/3, RPF nbr 4.1.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 2.1.1.1 
ip22-75b(config)#end 

ip22-75b#show ip rpf 1.1.1.1 
RPF information for ? (1.1.1.1) 
  RPF interface: Ethernet1/1 
  RPF neighbor: ? (2.1.1.1) 
  RPF route/mask: 1.1.1.1/0 
  RPF type: static mroute 
  RPF recursion count: 0 
  Doing distance-preferred lookups across tables 

ip22-75b#show ip route 1.1.1.1 
Routing entry for 1.1.1.0/24 
  Known via "ospf 1", distance 110, metric 20, type intra area 
  Redistributing via ospf 1 
  Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago 
  Routing Descriptor Blocks: 
  * 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 
      Route metric is 20, traffic share count is 1 
    2.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 
      Route metric is 20, traffic share count is 1 
    3.1.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 

(1.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CT 
  Incoming interface: Ethernet1/1, RPF nbr 2.1.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 マルチキャストで使用可能な等コスト パス全体に対してロード バランスを設定する場合の、一般的な問題に対するソリューションについて説明しています。例として、次のネットワーク ダイアグラムが使用されています。

ネットワーク ダイアグラム

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



考えられる解決方法

前述の「等コスト パスが複数あることが原因で、意図しないリバース パス フォワーディングによって転送が行われる」セクションで見たように、Protocol Independent Multicast(PIM)では、Reverse Path Forwarding(RPF; リバース パス フォワーディング)チェックのためにインターフェイスを 1 つだけ選択し、その他に対してはプルーニングします。これはロード バランスが行われないことを意味します。ロード バランスを行うには、冗長リンクから PIM を削除し、ルータ 75a とルータ 75b との間にトンネルを作成する必要があります。その後、リンク レベルでロード バランスを行い、トンネル上で IP を実行することができます。

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

ルータ 75a
interface Tunnel0 
 ip address 6.1.1.1 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet0/0 
 tunnel destination 5.1.1.1 
! 
interface Ethernet0/0 
 ip address 1.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
! 
interface Ethernet0/1 
 ip address 2.1.1.1 255.255.255.0 
! 
interface Ethernet0/2 
 ip address 3.1.1.1 255.255.255.0 
! 
interface Ethernet0/3 
 ip address 4.1.1.1 255.255.255.0

ルータ 75b
interface Tunnel0 
 ip address 6.1.1.2 255.255.255.0 
 ip pim sparse-dense-mode 
 tunnel source Ethernet1/4 
 tunnel destination 1.1.1.2 
! 
interface Ethernet1/1 
 ip address 2.1.1.2 255.255.255.0 
! 
interface Ethernet1/2 
 ip address 3.1.1.2 255.255.255.0 
! 
interface Ethernet1/3 
 ip address 4.1.1.2 255.255.255.0 
! 
interface Ethernet1/4 
 ip address 5.1.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 

(1.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 

(1.1.1.1, 224.1.1.1), 00:22:53/00:02:59, flags: CT 
  Incoming interface: Tunnel0, RPF nbr 6.1.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 1.1.6.2 for invalid RP 1.1.5.4 
00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) 
Join from 1.1.6.2 for invalid RP 1.1.5.4 

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

何らかのフィルタリングが適用されている疑いがあります。次のように、ルータの設定を調べる必要があります。

interface Ethernet0/0 
 ip address 1.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 グローバル設定コマンドを使用します。このチェックを削除するには、このコマンドの no 形式を使用します。」と説明されています。

ip pim accept-rp コマンドを削除すると、メッセージが発生しなくなります。問題を引き起こしているコマンドは発見されましたが、設定の中にこのコマンドをそのまま残しておきたい場合はどうなるでしょうか。誤った RP アドレスが指定されている可能性があります。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 1.1.5.4 (?), v2v1 
    Info source: 1.1.5.4 (?), via Auto-RP 
         Uptime: 01:00:48, expires: 00:02:07

上記出力によれば、1.1.5.4 が Auto-RP などから RP が学習した唯一のアドレスになっています。ただし、このルータはグループ 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 1.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 2.1.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 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:21:26, expires: 00:02:24
router2#

224.1.1.1 の RP は 1.1.1.1 です。

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

router2#show ip interface brief 
Interface                  IP-Address      OK? Method Status                Protocol
Ethernet0/0                1.1.1.2         YES NVRAM  up                    up      
Ethernet1/0                2.1.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 1.1.1.1 (?), v2v1
    Info source: 1.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: 2.1.1.1 (?)
router3#

表示されるように、router3 によってスタティックに RP 情報が設定され、router2 にポイントしていますが、これは誤りです。これが router3 によって RP-Join が router2 に送信されている理由です。

考えられる解決方法

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

router3#show run | i rp
ip pim rp-address 2.1.1.1 override
router3#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
router3(config)#no ip pim rp-address 2.1.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 1.1.1.1 (?), v2v1
    Info source: 1.1.1.1 (?), elected via Auto-RP
         Uptime: 00:30:45, expires: 00:02:02
router3#


CGMP によってマルチキャスト パケットのフラッディングが阻止されない

このセクションでは、Cisco Group Management Protocol(CGMP)が特定のサブネット上にあるすべてのルータでイネーブルにされていない場合に、マルチキャスト パケットが無用のフラッディングを起こす仕組みと、この問題を回避する方法について説明しています。例として、次のネットワーク ダイアグラムが使用されています。

ネットワーク ダイアグラム



問題の診断

上記の図では、Catalyst 5000 スイッチ A のスタティックな CAM テーブルに、実装されている正しいポートがまったく表示されません。CGMP が設定されているルータからは、CGMP パケットが送信されません。

CGMP は、スイッチ A での set cgmp enable コマンドと、ルータ 75a の E0/2 インターフェイスでの ip 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] 
----  ------------------    -----  ------------------------------------------- 

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 
2.1.1.1           Ethernet0/2        00:07:41  00:01:34  v2 

上記の出力では、ルータ 75a からルータ 75b がスイッチ A を通して有効な PIM ネイバーとして見えていることが分かります。

次に、ルータで正しいマルチキャスト ルート(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), 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 

(1.1.1.1, 224.1.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 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: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 

(1.1.1.1, 224.1.1.1), 00:00:35/00:02:59, flags: CTA 
  Incoming interface: Ethernet1/3, RPF nbr 2.1.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 

ここまでは、すべて良好のようです。ルータ 75a でいくつかの debug コマンドを発行して、その結果を確認します。

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 2.1.1.3 (Ethernet0/2) for 224.1.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 2.1.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 2.1.1.2 (this system) 
  IGMP querying router is 2.1.1.1 
  No multicast groups joined 

同じサブネット上に 2 台のルータがあり、両方に対して CGMP を設定している場合、片方だけが CGMP パケットを送信します。CGMP パケットを送信するルータは IGMP クエリー ルータになります。つまり、IGMP 対応ルータの中で最も小さなユニキャスト IP アドレスを持つルータです。

この場合、ルータ 75a とルータ 75b は IGMP 対応(ルータ 75b が IGMP クエリー ルータ)ですが、ルータ 75a だけが CGMP 対応ルータになっています。ルータ 75a は IGMP クエリー ルータでないため、CGMP パケットが送信されていません。



考えられる解決方法

この問題を解決するには、IGMP クエリー ルータに CGMP を設定する必要があります。この場合は、ルータ 75b です。最初に、ルータ 75b で debug コマンドをオンにします。

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 2.1.1.3 (Ethernet1/3) for 224.1.1.1 
*Feb  8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 
*Feb  8 12:58:42.422:       from 2.1.1.3 for 224.1.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 は 2.1.1.3 からグループ 224.1.1.1 に対する IGMP レポートを受信します。これに続き、224.1.1.1 に相当する MAC アドレスと対象ホスト 2.1.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 

動作が改善しています。224.1.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 Switch から、正しいホストだけにではなくすべてのポートに対してトラフィックがフラッドされるという一般的な問題のソリューションについて説明しています。例として、次のネットワーク ダイアグラムが使用されています。

ネットワーク ダイアグラム



問題の診断

上の図では、ルータ 75a、75b、および Catalyst 5000(スイッチ A)が、マルチキャストと Cisco Group Management Protocol(CGMP)用に正しく設定されています。ホストではマルチキャスト トラフィックが受信されています。ただし、他のすべてのホストでもスイッチ A から受信されています。スイッチ A はトラフィックをすべてのポートへフラッドしており、これは CGMP が正しく動作していないことを意味しています。

スイッチ 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] 
----  ------------------    -----  ------------------------------------------- 
6     01-00-5e-00-01-28             2/3-4 

Total Number of Entries = 1 

上記出力から、224.0.1.40 が唯一のグループであることが分かります。これはルータによって auto-RP グループに対する CGMP self-join が送信される場合に使用されます。他のグループが存在しない理由は何でしょうか。



考えられる解決方法

このソリューションを理解するためには、特定の条件下での CGMP の動作を理解する必要があります。CGMP 対応ルータはスイッチに CGMP join を送信し、特定のマルチキャスト グループ内の対象となるホストをスイッチに通知します。スイッチではこれらのホストの MAC アドレスを自身の CAM テーブルから探し、対象ホストにポートからマルチキャスト パケットを転送し、他のすべてのポートをマルチキャスト パケットの転送からブロックします。

ルータは、ルータの CGMP 対応インターフェイスと同じインターフェイス上にある発信元からのマルチキャスト パケットを受信すると、CGMP self-join を CGMP 対応インターフェイスから送信します。

たとえば、発信元がルータ 75a や 75b と同じサブネット(VLAN)である 2.1.1.0/24 にある場合、CGMP は完全に動作します。発信元からのパケットを認識すると、ルータは CGMP self-join をスイッチに送信します。これにより、ルータでオンになっているポートが動的に学習され、他のすべてのポートはマルチキャスト パケットの転送からはブロックされます。

ルータは、あるホストからの IGMP レポートを、CGMP 対応インターフェイスと同じインターフェイスで受信すると、CGMP join を CGMP 対応インターフェイスから送信します。

もう 1 つの例は、対象とするホストが同じ VLAN 上にある場合です。この場合、CGMP 対応ルータが Internet Group Management Protocol(IGMP; インターネット グループ管理プロトコル)レポートを特定のマルチキャスト グループに関係するホストから受信すると、ルータから CGMP join が送信されます。この join では、加入したいホストの Media Access Control(MAC; メディア アクセス制御)アドレスと、ホストが加入したいグループが示されています。次に、Catalyst 5000 では自身の CAM テーブルでそのホストの MAC アドレスを探し、マルチキャスト グループ リストで対応するポートを設定し、他の関係ないポートをすべてブロックします。

発信元および対象となるホストが CGMP 対応のサブネット(VLAN)以外のサブネットにある場合は、この動作は当てはまりません。送信元から送られてくるマルチキャスト パケットは、ルータがスイッチに CGMP self-join を送信するきっかけとはなりません。したがって、そのパケットがスイッチに到達すると、VLAN 内のあらゆる箇所でフラッドが発生します。この動作は、VLAN 内にあるスイッチのポートには接続されていないホストから IGMP join が送信されるまで続きます。ルータが CGMP パケットを送信するのは IGMP レポートを受信した場合だけで、これにより、スイッチによって対応するホストのポートが転送先として追加され、他のポートはすべてブロックされます(このルータのポートは除く)。

したがって、CGMP がこの移行型のトポロジで動作するためには、次のネットワーク ダイアグラムに示すように、ホストをルータ 75a や 75b と同じ VLAN に追加します。

あるいは、次の例のように、発信元をルータ 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 

224.1.1.1(01-00-5e-01-01-01)だけがルータのポート 2/3 と 2/4 にフラッドされ、スイッチ A の他のポートにはフラッドされていません。



CGMP によって特定のグループ アドレスに対するマルチキャスト パケットのフラッディングが阻止されない

このセクションでは、一部のマルチキャスト IP アドレスによって Cisco Group Management Protocol(CGMP)が local area network(LAN; ローカルエリア ネットワーク)上のすべてのポートにマルチキャスト トラフィックをフラッドする原因について説明しています。マルチキャスト グループ アドレス 225.0.0.1 を使用していると、Cisco Group Management Protocol(CGMP)が動作しません。マルチキャスト ストリームがすべてのスイッチのポートに溢れ出し、帯域幅を消費します。ところが、アドレスを 225.1.1.1 に変更すると、CGMP が正しく動作します。225.0.0.1 はルーティング プロトコル用に予約されたアドレスではありませんが、なぜこのアドレスを使用してはいけないのでしょうか。



考えられる解決方法

まず、レイヤ 3 のマルチキャスト アドレスがレイヤ 2 のマルチキャスト アドレスにマップされる仕組みを理解することが重要です。すべての IP マルチキャスト フレームでは、24 ビットのプレフィクス 0x0100.5e で始まる IEEE Media Access Control(MAC; メディア アクセス制御)レイヤ アドレスを使用しています。レイヤ 3 をレイヤ 2 のアドレスにマッピングする場合、レイヤ 3 マルチキャスト アドレスの下位 23 ビットは、IEEE MAC アドレスの下位 23 ビットにマップされます。

理解するために必要なもう 1 つの重要な点は、IP マルチキャスト アドレスには 28 ビットの固有のアドレス レンジがあることです(32 ビットからクラス D のプレフィックスである 1110 を含む最初の 4 ビットを引いたもの)。IEEE MAC アドレスには 23 ビットしか渡されていないため、重複する 5 ビット分がそのまま残ります。このことは、複数のレイヤ 3 マルチキャスト アドレスが、同一のレイヤ 2 マルチキャスト アドレスにマップされてしまう可能性があることを意味しています。

たとえば、次のような場合です。

224.0.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


224.128.0.1 = 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

上の例では、224.0.0.1 と 224.128.0.1 の両方がレイヤ 2 の同じマルチキャスト アドレスにマップされていることに注意してください。

レイヤ 3 からレイヤ 2 へのマルチキャスト アドレスのマッピングの仕組みが分かったので、上記の問題に対する具体的なソリューションに進みます。

スイッチ A ではマルチキャスト パケットを 224.0.0.x にフラッドしています。これは、これらのアドレスがリンクローカルであるためです。ここで、リンクローカル アドレスで local area network(LAN; ローカル エリア ネットワーク)上の全デバイスに到達できることを確認します。Catalyst スイッチでも、マルチキャスト パケットを他の 224.0.0.x という MAC レベルのあいまいなマルチキャスト アドレスにフラッドします(たとえば、224.0.0.1 と 225.0.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 設定をイネーブルにします。詳細は、Microsoft のサポート技術情報『Scalable Networking with RSSleavingcisco.comを参照してください。




関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報




Document ID: 16450