Bob Arendt <[email protected]> wrote on 09/27/2010 04:51:15 PM:
> Per rfc 2236, the v2 client *can't* drop the IGMPv3 query. From para
2.5:
> 2.5. Other fields
> Note that IGMP messages may be longer than 8 octets, especially
> future backwards-compatible versions of IGMP. As long as the Type
is
> one that is recognized, an IGMPv2 implementation MUST ignore
anything
> past the first 8 octets while processing the packet. However, the
> IGMP checksum is always computed over the whole IP payload, not just
> over the first 8 octets.
>
> The IGMPv3 query *is* a valid v2 query with extra crap at the end (it's
> backward compatible). Per rfc 2236 p2.5, the v3 query has to be
regarded
> as a valid v2 query if you're correctly implementing IGMPv2. Some
switch
> vendors (Cisco for one) only generate v3 queries when operating as an
> IGMP snooping switch, since a proper v2 client will respond with IGMPv2
> packets and it handles this properly. However, we're seeing some
switches
> get confused when a client initial joins with v2, then responds to a
query
> with v3. It ends up creating 2 entries, and only one is cleared by the
> leave message. This is also an issue when the primary (querier) switch
> only generates v3 queries, and some intermediate switches only support
v2.
> We set all the Linux clients to v2 .. but they respond the v2 query with
> v3 protocols, which could be missed by the intermediate switch.
>
> I believe the intent of the bug 18212 patch is correct.
Bob,
That would've been a nice quote for the other discussion; I didn't
do the v2 implementation for Linux, but it appears I broke this. I'll
take another look (and thanks for pointing that out!).
+-DLS
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
