Take the 2-minute tour ×
Ask Ubuntu is a question and answer site for Ubuntu users and developers. It's 100% free, no registration required.

When using Corosync with two rings via multi-cast addresses 226.94.1.1 (Port 5405) & 226.94.1.2 (Port 5406) what iptables rules are required to allow two nodes to communicate optimally without giving any undue access and making the rules too lenient?

I current have:

iptables -A INPUT -p udp -m multiport --dports 5404,5405,5406 -j ACCEPT

Will that allow all the communication a Corosync/Pacemaker setup requires for both rings?

I have heard arguments that something like:

iptables -I INPUT 1 -m pkttype --pkt-type multicast -j ACCEPT

is required. However I cannot seem to replicate a situation where this assists if the first rule I listed above is already in place.

The Red Hat documentation would seem to support the first approach. There is some IBM documentation espousing the second but is it just a case of a rule that is far too lenient when the first would do the job equally well whilst leaving no unnecessary ports open?

I'm leaning more towards the first rule being sufficient but wanted to get some more opinions on the matter.

share|improve this question

1 Answer 1

The documentation from Red Hat and IBM specifies rules that actually allow more packets than are really needed.

Multicast IP packets are really not much different from unicast IP packets, the only difference (in addition to the way how they are sent on Layer 2 and routed) is the destination address, which must be in the range 224.0.0.0/4.

As described on Server Fault, the following rules can be used for a single Corosync ring (assuming that the OUTPUT chain does not block any traffic):

iptables -A INPUT -p igmp -i $corosync_interface -j ACCEPT
for src_addr in $ip_addr_self $ip_addr_partner1 $ip_addr_partner2; do
  iptables -A INPUT -i $corosync_interface -s $src_addr -d $ip_addr_self \
    -p udp --source-port $(($corosync_port - 1)) \
    --destination-port $corosync_port -j ACCEPT
  iptables -A INPUT -i $corosync_interface -s $src_addr -d $ip_addr_mcast \
    -p udp --source-port $(($corosync_port - 1)) \
    --destination-port $corosync_port -j ACCEPT
done

In this example, the following variables are assumed to be defined:

  • $corosync_interface: the network interface which is used by Corosync
  • $ip_addr_self: the IP address to which Corosync binds locally (specified as bindnetaddr in corosync.conf)
  • $ip_addr_partner1, $ip_addr_partner2: the IP addresses of the other Corosync nodes - more can be added if the cluster has more than three nodes.
  • $ip_addr_mcast: the multicast address used for Corosync (specified as mcastaddr in corosync.conf)
  • $corosync_port: the (destination) port used by Corosync (specified as mcastport in corosync.conf)

For multiple rings, the same approach can be used with the interface name, IP addresses and port numbers changed to match the respective definitions.

In comparison to the rules specified in the documentation, the rules above are restricted to specific interfaces, source addresses and source ports and the destination port is limited to a single port. Actually, Corosync does not send packets to more than one destination port, it just uses a different port (destination port minus one) for sending data than for receiving data.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.