Subject: [magma] igmp snooping

From: "Shenoy, Vivekananda \(Vivek\)" <[email-masked]>
Date: Tue, 25 Oct 2005 10:14:38 +0530

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 25 Oct 2005 12:17:02 -0400

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