Subject: [magma] Question about IGMP and MLD Snooping Switches

From: "Seehofer, Markus" <[email-masked]>
Date: Fri, 7 Mar 2003 17:04:32 +0100

> Hello,
> 
>            Considerations for IGMP and MLD Snooping Switches
>                     <draft-ietf-magma-snoop-06.txt>
> 
> reads as follows:
> --------------------------------------------------------------------------
> -----------------------------
>     4)  An IGMP snooping switch should be aware of link layer topology
>          changes.  Following a topology change the switch should
>          initiate the transmission of a General Query over the receiving
>          ports in order to reduce network convergence time.
> 
>          a) ....
> 
>          b)  ....
> 
>          c)   When a new port comes up, a General Query message should
>               be sent out the new port to determine which groups, if
>               any, have receipients that have become reachable.  The new
>               port is designated as a router port in MRD messages are
>               processed.
> 
>          If the switch is not the Querier, it should use the 'all-zeros'
>          IP Source Address in these proxy queries.  When such proxy
>          queries are received, they must not be included in the Querier
>          election process.
> --------------------------------------------------------------------------
> --------------------------------
> 
> I encountered that M$-Windows based hosts don't support this 'all-zeros'
> IP Source Address-Query.
> They swallow the Query and never send a response to it.
> 
> It works fine with a Linux-Host: A report is sent to an 'all zero'- Query
> as expected.
> 
> How to react to this malfunction(?) of M$-Windows ?
> What happens if I always send a General Query on a topology change instead
> of the 'all zero' Query?
> Could this lead to other problems in certain configurations ?
> Has anyone an idea ?
> 
> Best Regards,
>             Markus
> 
> 
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "Morten Jagd Christensen (MJC)" <[email-masked]>
Date: Wed, 12 Mar 2003 13:18:12 +0100

Hi Markus
 
In my oppinion there is no alternative to sending a query
with source address 0.0.0.0 in this scenario if the switch
is not the querier. Using its own IP address could lead
to wrong querier election and subsequently wrong (or no) 
forwarding. Using a 'stored' IP address from the last 
'real query' is also not a good solution due to the possibility to 
mess up querier election and other potential problems.
 
The feature is there to support quick network convergence, but
if hosts do not wish to use this feature they still have the 
alternative to just wait for the 'normal' queries to be sent.

/Morten

---

From: "Morten Jagd Christensen (MJC)" <[email-masked]>
Date: Wed, 12 Mar 2003 13:18:12 +0100

Hi Markus

/Morten

---

From: "Seehofer, Markus" <[email-masked]>
Date: Wed, 12 Mar 2003 14:09:45 +0100

> Hi Markus
	Hello Morten,
> is not the querier.
	What annoys me is that this only occures with MS - machines.
	I tested it with serveral Unix machines and it works fine.

> Using its own IP address could lead
> forwarding.
	Yes, that is what i saw, too.

> Using a 'stored' IP address from the last 
	I've tried to use the 224.0.0.1 ip address as source ip address, but
this
	also does not work (as expected).
> alternative to just wait for the 'normal' queries to be sent.
	Yes, but this could prevent some switches in the LAN from forwarding
	multicast addresses correctly.

	Consider the following setup:

	                             |
	                             |
	                  ------------------------
	                 |           P1         |
	                 |                        |
	                 |        Switch1    |
	                 |                        |
	                 |   P2          P3   |
	                  ------------------------
	                     |               |
	                     |               | 
	                  ------     ------------------------
	                 |       |   |        P1           |
	                 |  H1 |   |                       |
	                 |       |   |       Switch2     |
	                  ------    |                       |
	                            |                  P2 |
	                             ------------------------
	                                                |
	                                                |
	                                             ------
	                                            |       |
	                                            |  H2 |
	                                            |       |
	                                             ------

	Both switches have IGMP - Snooping enabled,
	on Switch1/P1 is a IP - Multicast Router connected (Querier).
	Both host H1 and host H2 join'ed the same ip multicast address (e.
g. M1).

	This leads to the following configuration:
	- Switch1: Query on port P1, Multicast membership (M1) on port P2
and port P3.
	- Switch2: Query on port P1, Multicast membership (M1) on port P2

	Now Switch2 goes in power down for some reason, and the time the
Switch2
	is in reset is longer than the aging time for the multicast address
on Switch1/P3/M3,
	you'll get a new configuration on Switch1.

	New configuration for Switch1:
	- Switch1: Query on port P1, Multicast membership (M1) on port P2.

	Now Switch2 comes up, Host H2 still wants M1, but because of the new
configuration on
	Switch1, host H2 has to wait until the IP - Multicast Router sends
out a new query to 
	're-join' to the multicast group.

	Regards,
	 Markus

---

From: "Seehofer, Markus" <[email-masked]>
Date: Wed, 12 Mar 2003 14:09:45 +0100

Hello Morten,

	                             |
	                             |
	                  ------------------------
	                 |           P1         |
	                 |                        |
	                 |        Switch1    |
	                 |                        |
	                 |   P2          P3   |
	                  ------------------------
	                     |               |
	                     |               | 

	Regards,
	 Markus