Inter-switch IGMP on a VLAN with two switches, and a multicast source per switch

Question

I have a network consisting of two HP 2810 switched. Attached to each switch is, on one port, a multicast video coder, and on a different port, a decoder.

There are two VLANs - a control VLAN (running on the default VLAN) and a video VLAN. Ideally, I would like to use IGMP snooping on the video VLAN.

If I turn off IGMP snooping on the switches, the decoders can decode the stream from either the local coder or the remote coder. However, if I turn on IGMP snooping, the decoder can only join the multicast group on the local switch. It would appear the the IGMP requests do not get passed on to the other switch when a decoder requests to listen to the stream from the remote coder.

I want the system to work bi-directionally - e.g., a decoder on either switch can listen to the stream from the local coder or remote coder.

What do I need to configure on the switches, and how?

Answer 1

This is an all too common problem. Snooping requires either a full multicast router, or an igmp querier in the network (one per broadcast domain.) Both periodically send out multicast group requests to learn who's interested in what. That information has a lifetime (usually a multiple of the query interval, which is 125s by default), so after a few minutes without a querier, your multicast streams simply stop. (or the switch begins flooding to all ports, which is the opposite of the intent of enabling snooping)

The command is: vlan ## ip igmp querier

Answer 2

There is a problem with IGMP snooping across switches since the IGMP message on one switch doesn't get send to the other switch, so the switch with the source will not know that the port to the other switch should receive the multicast frames. Cisco has a document which describes the problem (and Cisco-specific solutions). This is not a vendor-specific problem, but a solution would be vendor-specific. From what I can tell, for the HP 2810, you will need to manually set the switch-to-switch ports to Forward: Causes the switch to forward all IGMP and IP multicast transmissions through the port.

Cisco's explanation of the problem:

Understand the Problem and Its Solutions

By default, the Catalyst switches have IGMP snooping enabled. With IGMP snooping, the switch snoops (or listens) for IGMP messages on all the ports. The switch builds an IGMP snooping table that basically maps a multicast group to all the switch ports that have requested it.

Assume that, without any prior configuration, Receiver 1 and Receiver 2 have signaled their intentions to receive a multicast stream for 239.239.239.239 that maps to the L2 multicast MAC address of 01.00.5e.6f.ef.ef. Both Switch 1 and Switch 2 create an entry in their snooping tables for these receivers in response to the IGMP reports that the receivers generate. Switch 1 enters port Gigabit Ethernet 2/48 in its table, and Switch 2 enters port Fast Ethernet 1/0/47 in its table.

Note: At this point, the multicast source has not started its traffic, and none of the switches knows about the switch mrouter port.

When the source on Switch 1 starts to stream multicast traffic, Switch 1 has "seen" the IGMP report from Receiver 1. As a result, Switch 1 delivers the multicast out port Gigabit Ethernet 2/48. But, since Switch 2 "absorbed" the IGMP report from Receiver 2 as part of the IGMP snooping process, Switch 1 does not see an IGMP report (multicast request) on port Gigabit Ethernet 2/46. As a result, Switch 1 does not send any multicast traffic out to Switch 2. Therefore, Receiver 2 never gets any multicast traffic, even though Receiver 2 is in the same VLAN but merely on a different switch than the multicast source.

The reason for this issue is that IGMP snooping is not really supported on any Catalyst platform without an mrouter. The mechanism "breaks down" in the absence of an mrouter port. If you want a fix for this solution, you must have the switches somehow learn or know of an mrouter port. The Solutions section of this document explains the procedure. But how does the presence of an mrouter port on the switches remedy the situation?

Basically, when the switches learn or statically know about an mrouter port, two critical things occur:

• The switch "relays" the IGMP reports from the receivers to the mrouter port, which means that the IGMP reports go toward the multicast router. The switch does not relay all the IGMP reports. Instead, the switch sends only a few of the reports to the mrouter. For the purpose of this discussion, the number of reports is not important. The multicast router only needs to know if there is at least one receiver that is still interested in the multicast downstream. In order to make the determination, the multicast router receives the periodic IGMP reports in response to its IGMP queries.
• In a source-only multicast scenario, in which no receivers have yet "joined" in, the switch only sends the multicast stream out its mrouter port.

When the switches know their mrouter port, Switch 2 relays out the IGMP report that the switch received from Receiver 2 to its mrouter port. This port is Fast Ethernet 1/0/33. Switch 1 gets this IGMP report on the switch port Gigabit Ethernet 2/46. From the perspective of Switch 1, the switch has received merely another IGMP report. The switch adds that port into its IGMP snooping table and begins to send out the multicast traffic on that port as well. At this point, both the receivers receive the requested multicast traffic, and the application works as expected.

But how do the switches identify their mrouter port so that IGMP snooping works as it is expected to work in a simple environment like this? The Solutions section provides some answers.

HP's explanation of the problem:

When the switch receives an IGMP Join, it accepts the host request and begins forwarding the IGMP traffic. This means ports that have not joined the group and are not connected to routers or the IGMP Querier will not receive the group's multicast traffic.

It appears that you could set the switches up as IGMP Queriers:

Using the Switch as Querier

Querier Operation

The function of the IGMP Querier is to poll other IGMP-enabled devices in an IGMP-enabled VLAN to elicit group membership information. The switch performs this function if there is no other device in the VLAN, such as a multicast router, to act as Querier. Although the switch automatically ceases Querier operation in an IGMP-enabled VLAN if it detects another Querier on the VLAN, you can also use the Command Prompt to disable the Querier capability for that VLAN.

Note A Querier is required for proper IGMP operation. For this reason, if you disable the Querier function on a switch, ensure that there is an IGMP Querier (and, preferably, a backup Querier) available on the same VLAN.

If the switch becomes the Querier for a particular VLAN (for example, the DEFAULT_VLAN), then subsequently detects queries transmitted from another device on the same VLAN, the switch ceases to operate as the Querier for that VLAN. If this occurs, the switch Event Log lists a pair of messages similar to these:

I 01/15/01 09:01:13 igmp: DEFAULT_VLAN: Other Querier detected
I 01/15/01 09:01:13 igmp: DEFAULT_VLAN: This switch is no longer Querier

In the above scenario, if the other device ceases to operate as a Querier on the default VLAN, then the switch detects this change and can become the Querier as long as it is not pre-empted by some other IGMP Querier on the VLAN. In this case, the switch Event Log lists messages similar to the following to indicate that the switch has become the Querier on the VLAN:

I 01/15/01 09:21:55 igmp: DEFAULT_VLAN: Querier Election in process
I 01/15/01 09:22:00 igmp: DEFAULT_VLAN: This switch has been elected as Querier

Answer 3

I used two switch HP v1910 conected throw port gigaethernet 1/0/1 And I needed to execute this commands:

_cmdline-mode on   (from console)
key: 512900
System-view
Interface gigabitEthernet 1/0/1 
Igmp-snooping static-router-port vlan X

and it worked for me.