Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

First, a little background: My understanding is that the purpose of IGMP (and its IPv6 cousin, MLD) is to avoid wasted bandwidth by ensuring that multicast packets only get transmitted to destinations that are actually interested in those packets. This logic is a refinement of an older/simpler switch behavior, which was to broadcast incoming multicast packets to all other ports no matter what, and leave it up to the connected devices to drop multicast packets that they weren't interested in.

IGMP and MLD do this by having the switch maintain a table that tracks which connected devices are currently joined to which multicast groups, and when a multicast packet comes in, the switch forwards it only to the ports that are joined to the group indicated by the packet's destination address. So far, so good.

But according to my co-worker, there is an odd special case: If no devices have joined a particular multicast group, then the switch must forward any incoming multicast packets to all ports (well, technically to all ports with an IGMP router attached, but he says it amounts to the same thing, since most switches don't know which ports have an IGMP router attached and so will fall back to flooding to all ports).

This seems very counterintuitive to me -- why would an algorithm whose entire purpose is to avoid multicast flooding deliberately flood to all ports in the a scenario where nobody is interested in receiving the multicast data? Is this done to ensure backwards compatibility with broken multicast implementations that expect to receive multicast packets they never requested? If not, what is the motivation for this? It seems like it significantly reduces the usefulness of the algorithm.

For reference, the guidelines my co-worker points to are in section 2.1.2 of RFC 4541:

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.

I think the following paragraph may explain the motivation, but I don't understand it:

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.

i.e. why would failure to flood unregistered streams prevent v3 hosts from receiving their traffic? (wouldn't v3 hosts know to join any groups they want to receive traffic on?) And in the alternative scenario, wouldn't traffic lossage due to flooding be just as bad a problem as traffic loss due not flooding?

share|improve this question
    
While this question belongs here on ServerFault and will probably get a larger audience here, it would make a great question for the new NetworkEngineering.StackExchange.com beta. –  David Houde May 19 '13 at 4:46
    
@DavidHoude: The line between ServerFault and NetworkEngineering sure is blurry. –  BatchyX May 19 '13 at 9:10

3 Answers 3

up vote 1 down vote accepted
+100

The problem is described in the meeting report which is referenced as [IETF56] in RFC4541:

Problem - Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host

Router sends IGMPv3 query, which tells the host to use IGMPv3 Hosts send IGMPv3 reports

What then happens ?

Switch does one of these 3 :

  1. Doesn’t forward reports
  2. Forwards reports but does not forward data
  3. Forwards reports and data but no queries, data then times out

Result - Multicast breaks when you upgrade a router or host (whichever is last) to IGMPv3.

Flooding unregistered streams works around the problem in the case 1 (when the old switch does not forward IGMPv3 reports), and should not make a difference in cases 2 and 3 (when IGMPv3 reports will be passed through the old switch).

As for which problem (dropped traffic or excessive flood) is worse, this highly depends on a particular situation. In some cases flooding may be worse because, unlike dropped traffic, it might not be noticed immediately during testing, and when at some later time the traffic volume increases enough to make flooding a problem, the broken configuration may be widely deployed, needing a lot of work to fix it.

share|improve this answer

First, a little background: My understanding is that the purpose of IGMP (and its IPv6 cousin, MLD) is to avoid wasted bandwidth by ensuring that multicast packets only get transmitted to destinations that are actually interested in those packets. This logic is a refinement of an older/simpler switch behavior, which was to broadcast incoming multicast packets to all other ports no matter what, and leave it up to the connected devices to drop multicast packets that they weren't interested in.

No. IGMP/MLD's purpose is for routers to know which multicast group have been joined by any locally-attached host (they don't even care which one, because at that time, shared media was expected). The router then feeds this information to a multicast routing algorithm which will exchange this information across routers to build multicast routing tables. This way, a machine X connected to a router A can send multicast traffic to group G, and a machine Y connected to another router B will receive it if it has joined G.

IGMP was invented before switches existed, and expected the media between hosts and routers to be shared. IGMP was even optimized for shared media, as it provided optimizations in case many hosts were interested in the same group, by letting only one host sending the membership report only once (because all hosts would receive traffic from that multicast group anyway).

This seems very counterintuitive to me -- why would an algorithm whose entire purpose is to avoid multicast flooding deliberately flood to all ports in the a scenario where nobody is interested in receiving the multicast data?

IGMP/MLD routers are always interested about any multicast data. It's their role to forward them after all. If a host sends multicast data to group X, the router must forward the packet to all other routers where at least one host has joined group X. The switch is completely unaware of this situation, so if it does not forward unknown traffic from the host to the router, it would just break multicast routing.

As for why forwarding unregistered packets to all ports should be enabled, there might be technical reasons for doing so, but, personally, I consider switches as an optimization compared to hubs. I want them to, in their default configuration, optimize things without breaking them. If the switch receives what would be illegitimate or unexpected packets, I would want it to forward it anyway, because that packet was likely sent for a reason. The last thing I want is my switch dropping packets.

share|improve this answer
        Router <-> IGMPv2 snooping switch <-> IGMPv3 capable host

Here I think standard explains,

The Igmpv3 unregistered packet send to the snooping switch (IGMPv2),It should not recognize the Igmp packet then switch prune the Igmp packet then Igmpv3 multicast packet does not flow to the Igmpv3 host.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.