[Linux-cluster] A better understanding of multicast issues
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:
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
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
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
Node Assassin: http://nodeassassin.org
Linux-cluster mailing list
Linux-cluster at redhat.com
More information about the Linux-cluster