When a multicast group is "joined" the switch/router will periodically (three mins i think) send out a query to the members to see if the connection is still needed. If a member does not reply to this query, then the connection is dropped for that port. If a switch is rebooted, then it's up to the member to re-establish the connection I believe, not the switch. Snooping is not generally a problem unless it's broken in the switch/router firmware. If it is, then you might need an upgrade. We use Multicast for all sorts of things and have indeed run into some problems on devices like Flex-10 cards for HP c7000 blade chassis that didn't do igmp snooping correctly, but we have gotten fixes for these issues from various vendors. If you have a planned outage for a switch, you can have your network people relocate the querier for a particular multicast group to another switch accessible to say a bonded pair or something. Things get really odd if you are on two separate switches that aren't stacked. Generally speaking, multicast isn't hard, you just have to think backwards. -C On Sat, Feb 12, 2011 at 10:51 AM, Kit Gerrits <kitgerrits@xxxxxxxxx> wrote: > > Digimer, > > Did you ever get a reply from anyone? > > If what you say is true, failure of one of our HSRP(HA) switches/routers > might break the cluster. > (if they don't share multicast menberships) > > I would guess that multicast groups originate in the cluster, not the > switch. > In that case, if the switch has been rebooted, the cluster needs to > re-create the multicast groups on the switch. > > I would guess that the cluster itself needs to check if the switch is > properly handling multicast. > (subscribe to its own group and check if the packets are being handles > correctly) > > This should provide an insight into clustering/multicast: > http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note0918 > 6a008059a9df.shtml > > > Regards, > > Kit > > > -----Original Message----- > From: linux-cluster-bounces@xxxxxxxxxx > [mailto:linux-cluster-bounces@xxxxxxxxxx] On Behalf Of Digimer > Sent: maandag 24 januari 2011 16:37 > To: linux clustering > Subject: A better understanding of multicast issues > > Hi all, > > It seems to me that a very good number of clustering problems end up being > multicast and smart switch related. I know that IGMP snooping and STP are > often the cause, and PIM can help solve it. Despite understanding this, > though, I can't quite understand exactly *why* IGMP snooping and STP break > things. > > Reading up on them leads me to think that they should cleanly create and > handle multicast groups, but this obviously isn't the case. When a switch > restarts, shouldn't it send a request to clients asking to resubscribe to > multicast groups? When corosync starts, I expect it would also send > multicast joins. > > Sorry if the question is a little vague or odd. I'm trying to get my head > around the troubles when, on the surface, the docs seem to make the process > of creating/managing multicast quite simple and straight forward. > > Thanks! > > -- > Digimer > E-Mail: digimer@xxxxxxxxxxx > AN!Whitepapers: http://alteeve.com > Node Assassin: http://nodeassassin.org > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > > -- > Linux-cluster mailing list > Linux-cluster@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/linux-cluster > -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster