[vlc] Re: SOLVED (well, sort of): IGMP snooping on Foundry EdgeIron 4802F

[andy at seacoms.com]

Bruno,

thank you for sharing that information. We recently had some problems
with IGMP / multicast port filtering as well. We use 3COM Superstack
switches and it pans out that IGMP is not implemented on multicast
addresses with '0' and '1' (meaning 239.0.0.1 e.g. is not multicast port
filtered).
So we had to change our software to avoid those digits. Very annoying.

Also, one other drawback we've found is that the IGMP does not provide
mutlicast filtering based on ports. For example: 239.1.1.1:8000 and
239.1.1.1:8001 is considered the same and forwarded to any receiver which
signed up for either 239.1.1.1:8000 OR 238.1.1.1:8001. Very sad, because
with vlc you can multicast as many streams you want, just differing in the
port portion. It would have been great just to allocate a new port for a
new stream and not a whole new multicast group.

Unfortunatelly we had a similar experience with 3COM, that those small but
important details weren't documented anywhere and that we only found the
cause for those problems after some debugging sessions.

Oh well... looks like the switch guys have some work cut out for them.

Andy

> Hello everybody,
>
> Several months ago, I posted a message about a strange behaviour of an
> EdgeIron switch 4802F, which would cut off the stream when an "IGMP
> Membership report" was sent by a client, and would allow the stream on
> reception of an "IGMP Leave Group"... :-/
>
> The solution was finally sent to us by Foundry: one must NOT use
> multicast addresses lower than 224.0.7.0 on these switches, as IGMP is
> not taken into account on those addresses... This is rather weird, as
> (if I'm not mistaken) this limitation is not part of any draft or RFC...
>
> And of course it's not written in any of the switch's docs either ! :-)
> And yes (Murphy's law), we were using one of those forbidden addresses
> (and were miles away of thinking our problem could be related to that !).
>
> When using addresses from 224.0.7.0 up, everything is fine, except that
> when you don't have a multicast router and are multicasting on a single
> LAN, you must rely on the switch's functionalities in order to generate
> IGMP Queries. And on the 4802F, only 10 ports out of 48 (or 24 for the
> 2402F) can use the internal query generator simultaneously. On the 38
> (or 14) other ports, as no query is generated, the clients do not send
> periodic membership reports other than the (unsolicited) first one when
> they join a group. The timers associated with those unlucky ports
> eventually timeout, and the stream is cut off after 4 minutes or so
> (default timeout around 260 seconds)...
>
> Hopefully, their new generation switches (4802CF) do not seem to suffer
> from any of these "features" and their behaviour regarding IGMP seems
> rather sound.
>
> I hope this message will seem to you as factual as I meant it. It's in
> no way "Foundry bashing". My purpose is just to inform other people of
> the behaviour of the switches we are using here, just in case someone
> else stumbles on the same problems (we've lost a LOT of time digging
> into this).
>
> Best regards,
>
> Bruno
>
> P.S.: vlc is GREAT ! ;-)
>
> --
> -- Service Hydrographique et Oceanographique de la Marine ---
> EPSHOM/CIS/MIC
> --     13, rue du Chatellier ---  BP 30316  --- 29603 Brest Cedex, FRANCE
> --        Phone: +33 2 98 22 17 49  ---  Email: Bruno.Treguier at shom.fr
>
> --
> This is the vlc mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://www.videolan.org/support/lists.html
> If you are in trouble, please contact <postmaster at videolan.org>
>
>

-- 
This is the vlc mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://www.videolan.org/support/lists.html
If you are in trouble, please contact <postmaster at videolan.org>