igmp query and snooping

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
3 answers Last reply
More about igmp query snooping
  1. 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
  2. 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
  3. 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
Ask a new question

Read More

Media Server Switch Networking