Re: IGMP v3 reponse

Bob Arendt [off-list ref] 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html