igmp query and snooping

First, what is the problem with flooding all ports with multicast packets? Is there a traffic congestion problem, in the home LAN?

I am assuming that the media server does not do IGMP, but merely transmits multicast packets. Correct? I am also assuming that the switch, even though it's a layer 2 switch, can be set up to conduct IGMP (violating the ISO/OSI layer separation) in order to send the multicast packets from the media server only to those switch ports which have members of the multicast group(s). Switches should not technically do any of this IGMP stuff, although snooping for the membership reports (the replies which indicate interest from clients) is a reasonable thing for a switch to do. But I will *assume* that this switch is conducting IGMP.

If this assumption is correct, then the switch would have to detect the presence of a multicast source in one or more of its ports. If such a source(s) exists, the switch would have to transmit periodic IGMP general queries to the 224.0.0.1 "all hosts" multicast group to all its ports. It is these queries that indicate to the clients out there that multicasts exist. Until the switch sees clients reponding with IGMP "reports," the switch should not send any multicast data packets out from the source. The multicast packets should be blocked at the source port of the switch, i.e. the port that connects the media server to the switch.

It is *possible* to set up clients to send IGMP reports before they get a query. This is done to speed things up when the client is first booted up. But the switch needs to receive the periodic responses to its IGMP queries to keep the multicast packets flowing to the port in question. Otherwise, the multicast group membership automatically times out, after a configured amount of time (minutes). I don't know whether your client is sending out reports before receiving a query. Probably not, from what you describe.

To answer you last question, it is multicast routers which should normally transmit IGMP queries. Not layer 2 switches. But these days, there are all sorts of strange features built into unusual places, to fill specific needs. Seems to me that the home LAN switch that does IGMP, for situations such as you describe, ought to work okay. But yes, you do need IGMP queries to be enabled, otherwise the switch won't know that group members exist. *Something* has to send out IGMP queries.

If the Cisco 2950 doesn't do IGMP queries, but only IGMP snooping, it's because that is the normal way a layer 2 switch should work. Routers are supposed to do IGMP. Not switches.

To get a good understanding of IGMP overall, read RFC 1112. It's very well written. Then, if you want to find out more detail about IGMPv2 and v3, to see how they differ from the original, simple IGMPv1, you can read RFC 2236 and RFC 3376, respectively. RFC 3376 gets pretty complicated. It introduces multicast source filtering capability to IP multicast routing, which introduces all sorts of extra stuff to worry about.

Bert

Bert Thanks! Right It is not a bug. Currently on the market toady some switch has query function because some network no routers,and media server and media client in same vlan. so snoofing still can work. I have read rfc you mentioned above but it not mention snooping. I know snooping work at coversation between query and report. right? Would you please give a little bit in detail how snooping work? I can not sniffing it from outside of switch.

Thanks,

LL

Snoopping is somewhat unorthodox, and it was introduced years after RFCs

1112 and 2236. Besides which, being somewhat unorthodox, it was not described in existing RFCs so far, that I know of. It was a proprietary feature in certain switches that the IETF did not think needed to be a standard.

But it is now being addressed by the IETF. Probably because there are enough IGMP snooping switches out there that it makes sense to at least try to make them interoperable. So there is in fact an Internet Draft that discusses IGMP snooping in layer 2 switches. This topic may also be increasingly important because "proper" Link Layer multicast protocols, e.g. GMRP, are not used much. So it makes sense to focus on something like IGMP snooping.

The draft is being worked in the MAGMA (Multicast and Anycast Group Membership) working group of the IETF, and it's also a good read. But beware that this is a working document, not the final say. These I-Ds are debated and modified many times before they become RFCs. And many of them never make it.

IGMP snooping is conceptually simple enough. Switches look for IGMP reports appearing at their ports. When they see the report appearing at a given port, they know that frames with a particular destination MAC group address (derived from the IP address) should be sent to that port. Alternatively, the switches can be even more, shall we say, bastardized, and actually use the IP multicast address directly to route frames to the appropriate ports. This is probably the preferred approach, it turns out, because IP multicast addresses are more specific that the derived MAC group address. There are potentially multiple IP multicast groups that may end up being mapped to just one MAC multicast address. (This last comment is explained in RFC 1112.) So if you want to be sure not to send multucast packets to a port unnecessarily, you should use the IP Class D address.

There are many details that the snooping switch must take care of, as the Internet Draft explains. For example, IGMPv1 and v2 both suppress IGMP reports if there is more than one group member in a given Ethernet LAN. This is done to reduce IGMP traffic for the multicast router. If at least one member exists, the router simply forwards the multicast. In principle, it's a waste of bandwidth for each and every group member in that LAN to indicate interest.

This works fine for multicast routers, but it can't work this way for snooping switches. Every host on every switch port interested in the multicast must indicate this interest, for the snooping switch to have the complete list of ports that want the multicast. It's obvious that if all but one group member suppress their IGMP reports, they won't be included in the distribution of the multicast frames. Since IGMPv1 and v2 reports are always sent using a destination address which is the group address of the group in question, the switch must look inside this IP packet to determine whether it's an IGMP report. If yes, then the switch must only forward that multicast to the router port, not to any of the other hosts. And the switch can prevent multiple reports from being sent to the multicast router. As long as the switch knows where all the group members are.

Another detail is that the 224.0.0.x multicasts which are not associated with IGMP must be flooded to all ports all the time. In this address range, there is no IGMP "join" used. However, IGMPv1 queries, which use the 224.0.0.1 address, should not be sent to switch ports associated with mutlicast routers. So switches must know which ports are used only by a multicast router.

The switch must know which ports are active in the current spanning tree, so that it knows what ports to flood these non-IGMP 224.0.0.x frames to. You don't want to flood these 224.0.0.x frames to inactive ports. Of course, this should also apply to broadcasts such as ARP queries, so it's not such a big deal of a requirement.

And so on.

Bert