Bug 458882 - RHEL5.2: Firewall settings for multicast address poorly explained
Summary: RHEL5.2: Firewall settings for multicast address poorly explained
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: doc-Cluster_Administration
Version: 5.2
Hardware: All
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Paul Kennedy
QA Contact: Content Services Development
URL:
Whiteboard:
Depends On: 450397
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-08-12 21:11 UTC by Paul Kennedy
Modified: 2015-04-20 00:47 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-01-28 22:47:54 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Paul Kennedy 2008-08-12 21:11:17 UTC
+++ 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 10.10.10.200 -m multiport -m state --state NEW -p udp
-s 10.10.10.0/24 -d 10.10.10.0/24 --dports 5404,5405 -j ACCEPT

This cannot work:  the multicast socket has to be in the range 224.0.0.0 to
239.255.255.255.   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 192.168.2.0/255.255.255.0 -d 224.0.0.0/224.0.0.0 -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 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 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 21:06:57 UTC
Changes have been checked in to SVN for RHEL 5.2 version.

Comment 3 Christine Caulfield 2008-11-10 09:38:02 UTC
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 10.10.10.200 -m multiport -m state --state NEW -pudp -s  10.10.10.0/24  -d 10.10.10.0/24 --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 13:20:23 UTC
I think it should be removed. 

It doesn't do anything anyway. -i 10.10.10.200 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 22:47:54 UTC
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.