multicast and IGMP snooping/query mode - Network

This is a discussion on multicast and IGMP snooping/query mode - Network ; Hi all, I'm having trouble getting some switches configured correctly, but I'm starting to think that what we want simply is impossible (unlikely) or not supported by most models. I'll first describe the setup and situation. I work for a ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: multicast and IGMP snooping/query mode

  1. multicast and IGMP snooping/query mode

    Hi all,

    I'm having trouble getting some switches configured correctly, but I'm
    starting to think that what we want simply is impossible (unlikely) or
    not supported by most models.

    I'll first describe the setup and situation. I work for a company that
    makes video detection boards: you give them analog video input, and it
    generate events based on the video, but you can also have live streaming
    video over IP (using RTSP). We are trying to use multicast for the video
    streaming, to save bandwidth, but only if we can find a switch that does
    proper 'IGMP snooping' and multicast filtering, to block unwanted
    traffic (the detector boards always stream, whether or not there's
    someone listening).
    So what we actually want to have is a 48-port switch of which every port
    is connected to a detector board that continuously streams video over
    multicast. The boards of course have a valid IP address and the
    multicast address is derived from it: e.g. the board on 172.17.3.33 wil
    stream to 225.17.6.33. The switch is then uplinked to another switch to
    which our workstations are connected (Win XP Pro). On those workstations
    we run a client that 'connects' to the multicast streaming of one (or
    more) of those detetor boards.
    For testing purposes, we disconnected 1 detector board, and connected a
    workstation directly to the switch on that port, and removed the uplink,
    to rule out uplink problems of any sort.

    The problem that we're having is that the multicast traffic isn't
    filtered at all on most switches (with IGMP snooping and query enabled),
    and is filtered on only one we tested. The switches on which the
    filtering works is the 3Com 4228G, if IGMP snooping and query is
    enabled. We also tested it on a 3Com 4500 and a 3Com 2250 Plus, but the
    4500 only supports snooping, and not query mode, while the 2250 Plus
    supports both (like the 4228), but both still flood the multicast packets.
    In the 3Com manualfor the 4500 we found this:
    "IGMP snooping does not learn unknown multicast packet addresses. As a
    result, any unknown multicast packet is flooded on the network.
    Multicast packets sent from multicast server towards the IGMP Query
    device will be unknown and will be flooded. Packets sent towards a
    client that has responded to the IGMP Query messages will be filtered."
    And we suspect this to be the reason, but I don't really understand what
    is meant by it, and how we can solve it.
    Why does the 4228G filter, and the 2250 not, with analog configuration?
    is that a bug in either one?
    What are we missing here?
    BTW: we see analog IGMP V2 packets being generated on both the 4228G and
    the 2250 (not on the 4500, most probably because of the lack of the
    query mode).

    Any help would be GREATLY appreciated!

  2. Re: multicast and IGMP snooping/query mode

    "The Unlord" wrote:

    > Hi all,
    >
    > I'm having trouble getting some switches configured correctly, but I'm
    > starting to think that what we want simply is impossible (unlikely) or
    > not supported by most models.
    >
    > I'll first describe the setup and situation. I work for a company that
    > makes video detection boards: you give them analog video input, and it
    > generate events based on the video, but you can also have live
    > streaming video over IP (using RTSP). We are trying to use multicast
    > for the video streaming, to save bandwidth, but only if we can find a
    > switch that does proper 'IGMP snooping' and multicast filtering, to
    > block unwanted traffic (the detector boards always stream, whether or
    > not there's someone listening).
    > So what we actually want to have is a 48-port switch of which every
    > port is connected to a detector board that continuously streams video
    > over multicast. The boards of course have a valid IP address and the
    > multicast address is derived from it: e.g. the board on 172.17.3.33
    > wil stream to 225.17.6.33.


    Just as a parenthetical comment, did you read RFC 3171? The multicast
    address range 225.0.0.0 to 231.255.255.255 is supposed to be "reserved."
    I'd probably choose something in the 239.192.0 0 to 239.255.254.255
    range, in the so-called "organization local scope" address range spelled
    out in RFC 2365.

    > The switch is then uplinked to another switch to which our
    > workstations are connected (Win XP Pro). On those workstations we run
    > a client that 'connects' to the multicast streaming of one (or more)
    > of those detetor boards.
    > For testing purposes, we disconnected 1 detector board, and connected
    > a workstation directly to the switch on that port, and removed the
    > uplink, to rule out uplink problems of any sort.
    >
    > The problem that we're having is that the multicast traffic isn't
    > filtered at all on most switches (with IGMP snooping and query
    > enabled), and is filtered on only one we tested. The switches on which
    > the filtering works is the 3Com 4228G, if IGMP snooping and query is
    > enabled. We also tested it on a 3Com 4500 and a 3Com 2250 Plus, but
    > the 4500 only supports snooping, and not query mode, while the 2250
    > Plus supports both (like the 4228), but both still flood the multicast
    > packets.
    > In the 3Com manualfor the 4500 we found this:
    > "IGMP snooping does not learn unknown multicast packet addresses. As a
    > result, any unknown multicast packet is flooded on the network.
    > Multicast packets sent from multicast server towards the IGMP Query
    > device will be unknown and will be flooded. Packets sent towards a
    > client that has responded to the IGMP Query messages will be
    > filtered."


    It might be good to absorb RFC 4541. This is what describes how IGMP
    snooping switches should operate, and it includes in Section 2.1.2 3):

    "An unregistered packet is defined as an IPv4 multicast packet with a
    destination address which does not match any of the groups announced in
    earlier IGMP Membership Reports.

    "If a switch receives an unregistered packet, it must forward that
    packet on all ports to which an IGMP router is attached. A switch may
    default to forwarding unregistered packets on all ports. Switches that
    do not forward unregistered packets to all ports must include a
    configuration option to force the flooding of unregistered packets on
    specified ports."

    So if a multicast packet arrives at the switch, for which there was no
    previous IGMP query or report, the switch may flood that packet to all
    interfaces. Since IGMP snooping is really meant to operate in L2
    switched networks that include IP multicast-enabled ROUTERS, you need to
    ask yourself exactly how the query-enabled switch works. How does it
    know when a particular IP multicast group starts operating? Could be
    that different switches react differently if no router is present.

    Also, how are the router interfaces in these switches set? This matters
    because all multicasts must be flooded on router interfaces.

    Bottom line is that IGMP snooping is a bit of a kludge. As long as it's
    made to operate in the environment for which it was written, all should
    work fine. If you're doing something unusual, like trying to make it
    work in a purely L2 network, I'd expect some problems.

    Bert


  3. Re: multicast and IGMP snooping/query mode

    Albert Manfredi schreef:
    > "The Unlord" wrote:
    >
    >> Hi all,
    >>
    >> I'm having trouble getting some switches configured correctly, but I'm
    >> starting to think that what we want simply is impossible (unlikely) or
    >> not supported by most models.
    >>
    >> I'll first describe the setup and situation. I work for a company that
    >> makes video detection boards: you give them analog video input, and it
    >> generate events based on the video, but you can also have live
    >> streaming video over IP (using RTSP). We are trying to use multicast
    >> for the video streaming, to save bandwidth, but only if we can find a
    >> switch that does proper 'IGMP snooping' and multicast filtering, to
    >> block unwanted traffic (the detector boards always stream, whether or
    >> not there's someone listening).
    >> So what we actually want to have is a 48-port switch of which every
    >> port is connected to a detector board that continuously streams video
    >> over multicast. The boards of course have a valid IP address and the
    >> multicast address is derived from it: e.g. the board on 172.17.3.33
    >> wil stream to 225.17.6.33.

    >
    > Just as a parenthetical comment, did you read RFC 3171? The multicast
    > address range 225.0.0.0 to 231.255.255.255 is supposed to be "reserved."
    > I'd probably choose something in the 239.192.0 0 to 239.255.254.255
    > range, in the so-called "organization local scope" address range spelled
    > out in RFC 2365.
    >


    Thanks for the comment, I'll pass that on to development why they chose
    de 225.x range.

    >> The switch is then uplinked to another switch to which our
    >> workstations are connected (Win XP Pro). On those workstations we run
    >> a client that 'connects' to the multicast streaming of one (or more)
    >> of those detetor boards.
    >> For testing purposes, we disconnected 1 detector board, and connected
    >> a workstation directly to the switch on that port, and removed the
    >> uplink, to rule out uplink problems of any sort.
    >>
    >> The problem that we're having is that the multicast traffic isn't
    >> filtered at all on most switches (with IGMP snooping and query
    >> enabled), and is filtered on only one we tested. The switches on which
    >> the filtering works is the 3Com 4228G, if IGMP snooping and query is
    >> enabled. We also tested it on a 3Com 4500 and a 3Com 2250 Plus, but
    >> the 4500 only supports snooping, and not query mode, while the 2250
    >> Plus supports both (like the 4228), but both still flood the multicast
    >> packets.
    >> In the 3Com manualfor the 4500 we found this:
    >> "IGMP snooping does not learn unknown multicast packet addresses. As a
    >> result, any unknown multicast packet is flooded on the network.
    >> Multicast packets sent from multicast server towards the IGMP Query
    >> device will be unknown and will be flooded. Packets sent towards a
    >> client that has responded to the IGMP Query messages will be filtered."

    >
    > It might be good to absorb RFC 4541. This is what describes how IGMP
    > snooping switches should operate, and it includes in Section 2.1.2 3):
    >
    > "An unregistered packet is defined as an IPv4 multicast packet with a
    > destination address which does not match any of the groups announced in
    > earlier IGMP Membership Reports.
    >
    > "If a switch receives an unregistered packet, it must forward that
    > packet on all ports to which an IGMP router is attached. A switch may
    > default to forwarding unregistered packets on all ports. Switches that
    > do not forward unregistered packets to all ports must include a
    > configuration option to force the flooding of unregistered packets on
    > specified ports."
    >
    > So if a multicast packet arrives at the switch, for which there was no
    > previous IGMP query or report, the switch may flood that packet to all
    > interfaces. Since IGMP snooping is really meant to operate in L2
    > switched networks that include IP multicast-enabled ROUTERS, you need to
    > ask yourself exactly how the query-enabled switch works. How does it
    > know when a particular IP multicast group starts operating? Could be
    > that different switches react differently if no router is present.
    >


    Aha, if I understand well, if nobody is registered for any group,
    everybody will/should get all multicast packets that get sent to the switch.
    As soon as someone registers for a group, the packets for that group
    will only be sent to the registered ports, but all the other groups are
    still flooded, right?
    So basically, it's the router's task not to send packets that nobody
    requested to the switch, and in that case the IGMP snooping will work
    perfectly indeed: a host will request a group, the switch forwards the
    request to all router ports, and the routers start forwarding that group
    to the switch, but at that moment the multicast address is known, and
    there's no flooding.
    What our problem is: in fact our detector boards are all multicast
    'routers' in a sense: they send out multicast data packets. So in fact,
    we should implement IGMP on our boards, and if no one requested the
    group, don't stream (but I think that'll be a problem with the streaming
    library we use).
    Putting a router between our 'detector' switch and the workstation
    switch will not be ideal: if we have 48 boards streaming at 3Mbps on the
    same switch, they'll kill each other's networks.

    > Also, how are the router interfaces in these switches set? This matters
    > because all multicasts must be flooded on router interfaces.


    On the switches we have, you can't set/change the router ports (or I
    didn't find how). That might also be a reason why everything is flooded,
    if the switch automatically flags all ports that send multicast data as
    router ports...

    >
    > Bottom line is that IGMP snooping is a bit of a kludge. As long as it's
    > made to operate in the environment for which it was written, all should
    > work fine. If you're doing something unusual, like trying to make it
    > work in a purely L2 network, I'd expect some problems.


    I had more or less come to the same conclusion, but couldn't really
    pinpoint the actual problem. Now, I got some RFCs to prove my case to
    R&D that our implmentation isn't 'optimal' (I'm test engineer BTW).

    >
    > Bert
    >


    Thanks a lot!

  4. Re: multicast and IGMP snooping/query mode

    "The Unlord" wrote:

    > Aha, if I understand well, if nobody is registered for any group,
    > everybody will/should get all multicast packets that get sent to the
    > switch.
    > As soon as someone registers for a group, the packets for that group
    > will only be sent to the registered ports, but all the other groups
    > are still flooded, right?


    Yes, that's the way RFC 4541 reads. Or at least, that behavior is
    permitted.

    > So basically, it's the router's task not to send packets that nobody
    > requested to the switch, and in that case the IGMP snooping will work
    > perfectly indeed: a host will request a group, the switch forwards the
    > request to all router ports, and the routers start forwarding that
    > group to the switch, but at that moment the multicast address is
    > known, and there's no flooding.


    Yes, that's exactly right. RFC 4541 depends on a multicast-enabled
    router (or several) being present.

    Bert


  5. Re: multicast and IGMP snooping/query mode

    Albert Manfredi schreef:
    > "The Unlord" wrote:
    >
    >> Aha, if I understand well, if nobody is registered for any group,
    >> everybody will/should get all multicast packets that get sent to the
    >> switch.
    >> As soon as someone registers for a group, the packets for that group
    >> will only be sent to the registered ports, but all the other groups
    >> are still flooded, right?

    >
    > Yes, that's the way RFC 4541 reads. Or at least, that behavior is
    > permitted.
    >
    >> So basically, it's the router's task not to send packets that nobody
    >> requested to the switch, and in that case the IGMP snooping will work
    >> perfectly indeed: a host will request a group, the switch forwards the
    >> request to all router ports, and the routers start forwarding that
    >> group to the switch, but at that moment the multicast address is
    >> known, and there's no flooding.

    >
    > Yes, that's exactly right. RFC 4541 depends on a multicast-enabled
    > router (or several) being present.
    >
    > Bert
    >


    Thanks! Now that I understand it perfectly, I can start thinking about
    our options.

    I was thinking: if we would make our detector boards register membership
    for their own multicast group, wouldn't that make the adrresses of each
    board known to the switch, stopping the flooding?
    I think that would be the 'cheapest' solution, as I don't think we can
    let the boards stop streaming (third party lib issue).

+ Reply to Thread