[Linux-cluster] A better understanding of multicast issues

Kit Gerrits kitgerrits at gmail.com
Sat Feb 12 10:51:09 UTC 2011


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
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

This should provide an insight into clustering/multicast:



-----Original Message-----
From: linux-cluster-bounces at redhat.com
[mailto:linux-cluster-bounces at redhat.com] On Behalf Of Digimer
Sent: maandag 24 januari 2011 16:37
To: linux clustering
Subject: [Linux-cluster] 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

  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.


E-Mail: digimer at alteeve.com
AN!Whitepapers: http://alteeve.com
Node Assassin:  http://nodeassassin.org

Linux-cluster mailing list
Linux-cluster at redhat.com

More information about the Linux-cluster mailing list