まず、少し背景があります。私の理解では、IGMP(およびそのIPv6のいとこであるMLD)の目的は、マルチキャストパケットが実際にそれらのパケットに関心のある宛先にのみ送信されるようにすることで、帯域幅の浪費を回避することです。このロジックは、着信マルチキャストパケットを他のすべてのポートにブロードキャストし、接続されたデバイスに任せて、関心のないマルチキャストパケットをドロップするという、古い/単純なスイッチの動作を改良したものです。
IGMPとMLDは、接続されているデバイスが現在どのマルチキャストグループに参加しているかを追跡するテーブルをスイッチに維持させることでこれを行い、マルチキャストパケットが着信すると、スイッチは、で示されるグループに参加しているポートにのみパケットを転送します。パケットの宛先アドレス。ここまでは順調ですね。
しかし、私の同僚によると、奇妙な特殊なケースがあります。noデバイスが特定のマルチキャストグループに参加している場合、スイッチは着信を転送する必要がありますパケットをすべてのポートにマルチキャストします(技術的には、IGMPルーターが接続されているすべてのポートに送信されますが、ほとんどのスイッチは同じことになると彼は言いますどのポートにIGMPルーターが接続されているかわからないため、すべてのポートへのフラッディングにフォールバックします)。
これは私には非常に直感に反しているようです-全体の目的がマルチキャストフラッディングを回避することであるアルゴリズムが、誰もマルチキャストデータの受信に興味がありませんか?これは、要求したことのないマルチキャストパケットを受信することを期待する壊れたマルチキャスト実装との下位互換性を確保するために行われますか?そうでない場合、これの動機は何ですか?アルゴリズムの有用性が大幅に低下しているようです。
参考までに、私の同僚が指摘しているガイドラインは、 RFC 4541 のセクション2.1.2にあります。
3) An unregistered packet is defined as an IPv4 multicast packet with
a destination address which does not match any of the groups
announced in earlier IGMP Membership Reports.
If a switch receives an unregistered packet, it must forward that
packet on all ports to which an IGMP router is attached. A switch
may default to forwarding unregistered packets on all ports.
Switches that do not forward unregistered packets to all ports
must include a configuration option to force the flooding of
unregistered packets on specified ports.
次の段落で動機を説明できると思いますが、わかりません。
In an environment where IGMPv3 hosts are mixed with snooping
switches that do not yet support IGMPv3, the switch's failure to
flood unregistered streams could prevent v3 hosts from receiving
their traffic. Alternatively, in environments where the snooping
switch supports all of the IGMP versions that are present,
flooding unregistered streams may cause IGMP hosts to be
overwhelmed by multicast traffic, even to the point of not
receiving Queries and failing to issue new membership reports for
their own groups.
つまり、未登録のストリームのフラッディングに失敗すると、v3ホストがトラフィックを受信できなくなるのはなぜですか? (v3ホストは、トラフィックを受信したいグループに参加することを知りませんか?)そして、別のシナリオでは、フラッディングによるトラフィック損失は、フラッディングしないことによるトラフィック損失と同じくらい悪い問題ではないでしょうか?
この問題は 会議レポート で説明されています RFC4541では[IETF56]と呼ばれています :
問題-ルーター<-> IGMPv2スヌーピングスイッチ<-> IGMPv3対応ホスト
ルーターはIGMPv3クエリを送信し、IGMPv3を使用するようにホストに指示します。ホストはIGMPv3レポートを送信します。
その後、何が起こりますか?
スイッチはこれらの3つのうちの1つを行います:
- レポートを転送しません
- レポートを転送しますが、データは転送しません
- レポートとデータを転送しますが、クエリは転送しません。データはタイムアウトします
結果-ルーターまたはホスト(どちらか最後の方)をIGMPv3にアップグレードすると、マルチキャストが中断します。
未登録のストリームのフラッディングは、ケース1(古いスイッチがIGMPv3レポートを転送しない場合)の問題を回避し、ケース2と3(IGMPv3レポートが古いスイッチを通過する場合)では違いがないはずです。
どの問題(交通量の減少または過剰な洪水)がより悪いかについては、これは特定の状況に大きく依存します。場合によっては、トラフィックのドロップとは異なり、テスト中にすぐに気付かない可能性があるため、フラッディングが悪化することがあります。また、後でトラフィック量が増加してフラッディングが問題になると、壊れた構成が広く展開され、多くのことが必要になることがありますそれを修正するための作業の。
まず、少し背景があります。私の理解では、IGMP(およびそのIPv6のいとこであるMLD)の目的は、マルチキャストパケットが実際にそれらのパケットに関心のある宛先にのみ送信されるようにすることで、帯域幅の浪費を回避することです。このロジックは、着信マルチキャストパケットを他のすべてのポートにブロードキャストし、接続されたデバイスに任せて、関心のないマルチキャストパケットをドロップするという、古い/単純なスイッチの動作を改良したものです。
いいえ。IGMP/ MLDの目的は、ローカルに接続されたホストがどのマルチキャストグループに参加したかをルーターが知ることです(当時は共有メディアが想定されていたため、どのマルチキャストグループも気にしません)。次に、ルーターはこの情報をマルチキャストルーティングアルゴリズムにフィードします。マルチキャストルーティングアルゴリズムは、ルーター間でこの情報を交換して、マルチキャストルーティングテーブルを作成します。このようにして、ルータAに接続されたマシンXはマルチキャストトラフィックをグループGに送信でき、別のルータBに接続されたマシンYは、Gに参加している場合にそれを受信します。
IGMPは、スイッチが存在する前に発明され、ホストとルーターの間でメディアが共有されることを期待していました。 IGMPは、多くのホストが同じグループに関心を持っている場合に最適化を提供し、1つのホストのみがメンバーシップレポートを1回だけ送信するようにすることで、共有メディア用に最適化されました(すべてのホストがそのマルチキャストグループからトラフィックを受信するため)。
これは私には非常に直感に反しているように思われます-マルチキャストデータの受信に誰も興味がないシナリオで、マルチキャストフラッディングを回避することを目的とするアルゴリズムが意図的にすべてのポートにフラッディングするのはなぜですか?
IGMP/MLDルーターは、マルチキャストデータに常に関心があります。結局、それらを転送するのは彼らの役割です。ホストがマルチキャストデータをグループXに送信する場合、ルーターは、少なくとも1つのホストがグループXに参加している他のすべてのルーターにパケットを転送する必要があります。スイッチはこの状況を完全に認識しないため、ホストからの不明なトラフィックを転送しない場合ルーターに対しては、マルチキャストルーティングが中断されるだけです。
未登録のパケットをすべてのポートに転送できるようにする必要がある理由については、技術的な理由があるかもしれませんが、個人的には、ハブと比較して最適化としてスイッチを検討しています。デフォルトの構成で、物事を壊すことなく最適化してほしい。スイッチが不正または予期しないパケットを受信した場合、そのパケットは何らかの理由で送信された可能性があるため、とにかく転送してほしいと思います。私が最後に欲しいのは、スイッチがパケットをドロップすることです。
Router <-> IGMPv2 snooping switch <-> IGMPv3 capable Host
ここで私は標準が説明すると思います、
Igmpv3未登録パケットがスヌーピングスイッチ(IGMPv2)に送信され、Igmpパケットを認識せず、Igmpパケットをプルーニングし、Igmpv3マルチキャストパケットがIgmpv3ホストに流れません。