All things related to multicast

[Alan Crosswell <>]

Thanks, Dan.  This is very useful stuff.  I know vbrick has a "join own 
multicast" option just to deal with the flooding on the same switch issue.
/a

Dan Pritts wrote:
> On Fri, Sep 24, 2004 at 10:54:33AM -0400, Alan Crosswell wrote:
>
> > Along the lines of this inquiry I'd like to restate my request from the 
> > instructors of the hands-on multicast workshop for feedback on experiences 
> > with LAN multicast issues so that we can improve the workshop.  This is an 
>
>
> Here is a quick review of our experience with HP switches.
>
> I've used the following models:
>
>  408    - desktop 8-port unmanaged switch
>  4000M  - older chassis & code base
>  4108gl,2650 - newer chassis, seems to be the same code between these two
>
> I have not used any of the HP "routing switches".
>
> I have not tested the IGMPv3 support to any significant extent but it
> is there.
>
> general issues
> --------------
> Not specifically multicast-related but the 4000M does not support ssh
> management, only telnet.  the newer switches can do SSH.  Our 4000M
> crashes periodically (every month or two).  We push around a fair amount
> of DVTS streams & other multicast.  This might mean that the switch
> doesn't like multicast or it might just have memory leaks or something.
> I don't know if they still even sell this switch but if they do i
> would not recommend buying it (or the 8000M, a bigger version of the same
> architecture) if you plan to use multicast.
>
> the 408 desktop switch has two hardware revisions.  The one you can buy
> today works great.  The older hardware can be identified by a pushbutton
> to change the function of the blinkenlights.  This switch cannot keep
> up with wire rate - a flooding DVTS stream with three or four devices
> connected will make it unusable.  Don't know if this is multicast specific
> or just high data rates in general.  Either model is just a dumb unmanaged
> switch, no IGMP snooping support.
>
> Nessus scans our security guy did have often caused these switches to
> fall over half-dead.  They seem to still forward frames OK but advanced
> functionality is gone, no IGMP snooping, you cannot ssh to the switch
> to manage it, etc.  we have solved this by not scanning the switches
> but this does mean they are potentially subject to a DoS attack.
>
> In general, I really like the HP switches.  The price is nice, they
> generally perform quite well, and they come with lifetime free hardware &
> software support.  
>
> multicast issues 
> ----------------
> The 4108gl and 2650 have the option to become IGMP queriers on your LAN.
> This should be disabled and may be on by default.  I don't think there is
> a way to handle this other than via direct access to the switch management
> MIB (you can do it from the switch command line, you do not need to use
> an SNMP management tool).  the procedure is in the user manual.
>
> The only big issue I have had with multicast with these switches is when
> you have a local multicast source but no local listener on that group.
> The switch defaults to flooding all ports with that group when this
> happens.  This sucks when it is flooding a 30M dvts stream and you have
> 10M gear on the same LAN.
>
> The solution is just to fire up a local listener on that group, and
> everything is happy.  This is a bit tricky.  When this originally became
> an issue, I thought I'd solve the problem by bringing up a listener on
> an old server sitting in my machine room, which happened to be on a 
> different switch.  
>
> This did not have the desired effect - the switch with the source
> was still flooding.  
>
> I had the following config (all one IP subnet):
>
>          router ----- core switch ---- upstairs switch --- source
>                           |
>                       downstairs switch --- "local" listener
>
> Since IGMPv2 messages are sent on the multicast group that they
> control, they are subject to pruning by the switch's snooping/pruning
> algorithm.  
>
> So my "local" listener was sending IGMP messages to the multicast group
> in question.  This was snooped by the downstairs switch, which caused the
> downstairs switch to prune all its other ports from the group in question.
>
> Similarly, the core switch snooped this IGMP and pruned the group from all
> its other ports except the uplink to the downstairs switch.
>
> Notably, this included the link to the upstairs switch.  So, the IGMP
> messages never got to the upstairs switch, so it did not know about
> any listeners, so it defaulted to flooding all its ports.
>
> I can think of a few ways to fix this.
>
>    1)  I don't know for sure but I presume that switching to IGMPv3
>        would fix it, since IGMPv3 messages are sent on their own dedicated
>        multicast group.  Of course since some of your clients still
>        may speak IGMPv2 this is not as simple as just turning on v3 on
>        the router, but i guess it would work as long as the sacrificial
>        listener were speaking IGMPv3.
>    2)  configure the inter-switch links to flood multicast always.
>        This will let the IGMPv2 messages make it to all the switches,
>        which can then snoop them and act accordingly.  This has the
>        downside of potentially overutilizing your backbone links, and
>        the CPUs on your switches.  This is what I did and it has worked
>        well enough so far.
>    3)  always make sure that your local listener is on the same physical
>        switch as the source.
>    4)  segregate high-bandwidth sources to a different IP subnet on
>        a different physical or virtual LAN.
>
> I guess that there is a potential other issue with this - if you're
> sourcing on a group but for whatever reason do not want to listen to
> other sources from the Internet, you'll have to find another solution 
> (IGMPv3 local listener?).
>
> I'd be interested in knowing folks' experiences with other switch lines.
> In particular, do any of them have a knob to tweak to disable "flood
> by default" for IP multicast traffic with no declared listeners?
> This probably isn't standards-compliant but it might be what we want.
>
> danno
> --
> dan pritts                                       
>
> systems administrator                            734/352-4953 office
> internet2                                        734/834-7224 mobile