Re: [magma] igmp snooping

Marshall Eubanks <marshall.eubanks@gmail.com> Tue, 25 October 2005 16:17 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURU9-00005b-ME; Tue, 25 Oct 2005 12:17:13 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EURU8-0008VI-4G for magma@megatron.ietf.org; Tue, 25 Oct 2005 12:17:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02357 for <magma@ietf.org>; Tue, 25 Oct 2005 12:16:56 -0400 (EDT)
Received: from zproxy.gmail.com ([64.233.162.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EURh6-000132-E3 for magma@ietf.org; Tue, 25 Oct 2005 12:30:37 -0400
Received: by zproxy.gmail.com with SMTP id n1so454150nzf for <magma@ietf.org>; Tue, 25 Oct 2005 09:17:02 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=cP+AptdkSoVzJbhUusO+aDI+ALwbmbG/G8LNfhErhW3zGinMa/UCnpYyQyWUwPehaEoTghDmGSOXC7ueXVBg9tgPsqTYIyuS+JdGkJL4jBqRzvhE0bOGw09Hy8D1RsRM9FS5SFAA7Sl4bmITtJ6WGZj/gDLzbZRDF/fmRMVSfWE=
Received: by 10.37.21.27 with SMTP id y27mr715823nzi; Tue, 25 Oct 2005 09:17:02 -0700 (PDT)
Received: by 10.36.43.6 with HTTP; Tue, 25 Oct 2005 09:17:01 -0700 (PDT)
Message-ID: <dcad22d80510250917r6732ba64wae90ee45e6ad8b7e@mail.gmail.com>
Date: Tue, 25 Oct 2005 12:17:02 -0400
From: Marshall Eubanks <marshall.eubanks@gmail.com>
To: "Shenoy, Vivekananda (Vivek)" <vshenoy@riverstonenet.com>
Subject: Re: [magma] igmp snooping
In-Reply-To: <FCAF0E8A270B6E4781D91431E853F6F3F1EEBA@GONDOR.rs.riverstonenet.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <FCAF0E8A270B6E4781D91431E853F6F3F1EEBA@GONDOR.rs.riverstonenet.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Content-Transfer-Encoding: quoted-printable
Cc: magma@ietf.org
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
Sender: magma-bounces@ietf.org
Errors-To: magma-bounces@ietf.org

Hello;

Maybe I am  misunderstanding something, but I don't think that there
is a problem :

RFC 2236 and 3376 are pretty similar here.

>From RFC 2236

 On startup, a
   router SHOULD send [Startup Query Count] General Queries spaced
   closely together [Startup Query Interval] in order to quickly and
   reliably determine membership information.  A General Query is
   addressed to the all-systems multicast group (224.0.0.1), has a Group
   Address field of 0, and has a Max Response Time of [Query Response
   Interval].

So the switch should also hear these messages and thus determine the
querier and the non-querier.

Suppose for some reason  that it  doesn't (say, the wrong packets are
lost or the switch, not knowing that the router exists, doesn't
forward the Query messages).

Then the non-querier will not receive queries, will not know the other
router exists, and will start sending out General Query messages in
due course. The same applies if it receives the initial Query from the
other router and never sends any queries out at startup.

So the switch should find both routers for sure; even if the start-up
is fouled up; it
should heal itself.

Note, BTW, that draft-ietf-magma-snoop-12.txt and the MRD draft
draft-ietf-magma-mrdisc-07.txt (which is going to Proposed Standard IIRC) sets
up a new mechanism, Multicast Router Discovery, just to avoid  these
sorts of problems.

Regards
Marshall  Eubanks


On 10/25/05, Shenoy, Vivekananda (Vivek) <vshenoy@riverstonenet.com> wrote:
>
> Hi,
>
> My topology is below
>
>  +---------+
>  |ROUTER1  |        |
>  |         |IGMP    |
>  |         ---------|
>  |         |        |
>  |         |        |
>  +---------+        |        +---------+
>                     |        |         |
>                     |        |         |
>                     |        |SNOOPING |
>                     |--------|         |
>                     |        |SWITCH   |
>                     |        |         |
>                     |        +---------+
>                     |
>  +----------+       |
>  |          |       |
>  |          |       |
>  |ROUTER2   --------|
>  |          |IGMP   |
>  |          |       |
>  +----------+
>
> A scenario where I have 2 IGMP routers on a single LAN, we know that one
> of them will be a querier since only he can send IGMP queries say
> Router1 in my case.
>
> My doubt is how snooping switch will know about the Router2 who is the
> non-querier since switch is not receiving any queries from Router2.I
> have seen snooping switch maintaining 2 tables 1)Querier table (ROUTER1
> in this case) 2)Router table (ROUTER2 in this case).
>
> This scenario may exist where Router1 may act as the IGMP querier and
> Router2 may be the destination DR who is forwarding the traffic on to
> the LAN
>
> PIM or any multicast routing protocol is not enabled on the IGMP
> interfaces so switch cannot see these hellos.
>
> Thanks
> Vivek
>
>
> _______________________________________________
> magma mailing list
> magma@ietf.org
> https://www1.ietf.org/mailman/listinfo/magma
>

_______________________________________________
magma mailing list
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma