Archived from groups: comp.dcom.lans.ethernet (
More info?)
"wld" <aaabbb16@hotmail.com> wrote:
> 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.
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.
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-ietf-magma-snoop-11.txt
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