Bug 144838 - Split brain if tiebreaker IP is not on network used for cluster communication
Summary: Split brain if tiebreaker IP is not on network used for cluster communication
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: clumanager   
(Show other bugs)
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Lon Hohberger
QA Contact: Cluster QE
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-11 20:55 UTC by Lon Hohberger
Modified: 2009-04-16 20:16 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-11 20:55:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Lon Hohberger 2005-01-11 20:55:19 UTC
Description of problem:
A split brain can occur if the tiebreaker IP address is on one network
while the cluster is communicating over another.

Version-Release number of selected component (if applicable):
All, up to and including 1.2.22

How reproducible:

Steps to Reproduce:
1. Configure a 2-node cluster using either multicast or broadcast with
"clumembd%primary_only" enabled.
2. Set communication paths (node names) on one network
3. Set tiebreaker IP on another network which is separate from the
communication network (one which uses different physical NICs).
4. Start both nodes
5. Wait for quorum
6. Unplug one node's cluster communication link.

Actual results:
Split brain.  Both nodes ping the IP tiebreaker and believe they are
the sole member of the cluster, even though the tiebreaker is on the
wrong network.

Expected results:
Unknown;  this is a misconfiguration.  Cluster Manager requires that
all members coexist on the same fully connected subnet and that the
link(s) used for cluster communication are the same link(s) used to
monitor the tiebreaker IP address.

Additional info:
We could possibly detect that the IP tiebreaker is on the same network
and refuse to use it if it is not, but this would be an undesirable
enhancement in some cases where users use something outside their LAN
for the tiebreaker IP address (for instance, their ISP's router).

* This behavior does not occur in 2-node clusters where the disk
tiebreaker is in use.

* This behavior does not occur in 2-node clusters utilizing broadcast
heartbeat (with clumembd%primary_only disabled) in Cluster Manager
versions 1.2.23 and higher.

Note You need to log in before you can comment on or make changes to this bug.