Bug 458882 - RHEL5.2: Firewall settings for multicast address poorly explained
RHEL5.2: Firewall settings for multicast address poorly explained
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: Cluster_Administration (Show other bugs)
All Linux
low Severity low
: rc
: ---
Assigned To: Paul Kennedy
Content Services Development
: Documentation
Depends On: 450397
  Show dependency treegraph
Reported: 2008-08-12 17:11 EDT by Paul Kennedy
Modified: 2015-04-19 20:47 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-28 17:47:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul Kennedy 2008-08-12 17:11:17 EDT
+++ This bug was initially created as a clone of Bug #450397 +++

Description of problem:

Documentation of the iptables settings are incorrect for cluster in RHEL 5.1.

Version-Release number of selected component (if applicable):

Cluster_Administration RHEL 5.1 (2008-01-10T14:58)

How reproducible:

Follow the instructions for building a cluster using the iptables settings in
chapter 2, and the luci instructions in chapter 3.  The nodes will reboot,etc.
but will not join.  

Steps to Reproduce:
1.  Apply the iptables settings described in chapter 2, section 2.1 and 2.2 -
changing the IP address as appropriate for your nodes. 
2.  Install and start ricci and luci as per chapter 3, section 2.
3.  Create and configure the cluster as per chapter 3, section 3.
Actual results:

We see the nodes reboot, etc., but the final join stage times out.

Expected results:

The cluster should start with all nodes joined.

Additional info:

The problem is with the firewall settings for the multicast socket.  The
document gives us:

iptables -A INPUT -i -m multiport -m state --state NEW -p udp
-s -d --dports 5404,5405 -j ACCEPT

This cannot work:  the multicast socket has to be in the range to   The firewall needs to be set so that the destination is the
multicast address, with the source as the unicast IP address of the interface.

On my configuration, I used the command:

iptables -A INPUT -s -d -p udp -m
state --state NEW -m multiport --dports 5404,5405 -j ACCEPT

By default, the cluster will be assigned a multicast address that is based on a
hash of the cluster name, and so will not be known in advance (hence the /4
setting on the destination).  Perhaps the example in the manual should use a
fixed multicast address and apply more specific firewalling to it.

--- Additional comment from pkennedy@redhat.com on 2008-08-12 17:01:19 EDT ---

Created an attachment (id=314141)
Revised content in PDF and HTML printed to PDF.

Revised content in PDF and HTML printed to PDF is included.

--- Additional comment from pkennedy@redhat.com on 2008-08-12 17:03:32 EDT ---

Revised content is attached in both PDF and HTML output formats. Revised content has been reviewed and approved by subject matter expert. Fixed in 5.3 branch. Will merge with published versions.
Comment 1 Paul Kennedy 2008-08-13 17:06:57 EDT
Changes have been checked in to SVN for RHEL 5.2 version.
Comment 3 Christine Caulfield 2008-11-10 04:38:02 EST
There's a typo in the first referenced page, section 3.4.3
  "For IPV4 — The address formed is 239.122" should read
  "For IPV4 — The address formed is 239.192"

It's correct in the paragraph below.

The second referenced page, section 5.2.3, has the same typo.

In the third referenced page, I think the first rule is harmless but superfluous:
"iptables -A INPUT -i -m multiport -m state --state NEW -pudp -s  -d --dports 5404,5405 -j ACCEPT"

If you're going to keep it then there needs to be a space between -p and udp ... itables is VERY fussy about it's command-line!
Comment 5 Christine Caulfield 2008-11-17 08:20:23 EST
I think it should be removed. 

It doesn't do anything anyway. -i can't be useful (-i indicates an interface name according to the man page!) and the two rules below it do the job perfectly correctly.

'cman' as a separate entity doesn't really exist in RHEL-5, it is just a plugin to openais that provides services.
Comment 10 Paul Kennedy 2009-01-28 17:47:54 EST
Resolved with RHEL 5.3. Updated content is published here:

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