Sign in with
Sign up | Sign in
Your question

igmp query and snooping

Last response: in Networking
Share
Anonymous
October 6, 2004 7:13:49 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi,
I have a media server and a media client connect at one switch.
This switch has igmp query and snooping function and no multicast
routing protocol. I disable query and enable snooping because server
and client connect same switch same vlan. But media client can not
get media server stream. I think it is a bug.
any comments?
if disable both of query and snooping it works. but it
is flooding all ports which not what i like.
anyone can explain funcation of query.
I have found cisco 2950 does not query function. Does it need
router to send query?

Thanks,

LL
Post a

More about : igmp query snooping

Anonymous
October 6, 2004 6:53:49 PM

Archived from groups: comp.dcom.lans.ethernet (More info?)

"wld" <aaabbb16@hotmail.com> wrote:

> Hi,
> I have a media server and a media client connect at one switch.
> This switch has igmp query and snooping function and no multicast
> routing protocol. I disable query and enable snooping because server
> and client connect same switch same vlan. But media client can not
> get media server stream. I think it is a bug.
> any comments?
> if disable both of query and snooping it works. but it
> is flooding all ports which not what i like.
> anyone can explain funcation of query.
> I have found cisco 2950 does not query function. Does it need
> router to send query?

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
Anonymous
October 10, 2004 8:39:47 AM

Archived from groups: comp.dcom.lans.ethernet (More info?)

"Albert Manfredi" <albert.e.manfredi@nospam.com> wrote in message news:<I5641M.n4o@news.boeing.com>...
> "wld" <aaabbb16@hotmail.com> wrote:
>
> > Hi,
> > I have a media server and a media client connect at one switch.
> > This switch has igmp query and snooping function and no multicast
> > routing protocol. I disable query and enable snooping because server
> > and client connect same switch same vlan. But media client can not
> > get media server stream. I think it is a bug.
> > any comments?
> > if disable both of query and snooping it works. but it
> > is flooding all ports which not what i like.
> > anyone can explain funcation of query.
> > I have found cisco 2950 does not query function. Does it need
> > router to send query?
>
> 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
Anonymous
October 11, 2004 2:17:40 AM

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...

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
!