[Linux-cluster] people having trouble with the default multicast address 239.192.x.x

[Steven Dake]

On Sun, 2007-08-26 at 14:01 +1000, Nikolas Lam wrote:
> On Fri, 2007-08-24 at 09:17 -0700, Steven Dake wrote:
> > If you are having problems with the default multicast address
> > 239.192.x.x it is probably because your switch is not sending those
> > packets because of a configuration issue.
> > 
> > If you have this problem please contact me.  I would like to make a
> > cookbook of switch manufacturer/models and possible solutions.
> > 
> > Using 224.0.0.x is not recommended as these multicast packets are
> > broadcoast over the network.
> > 
> > Regards
> > -steve
> 
> Hi Steve,
> 
> I'm not sure if the problems I'm having are caused by switch
> configuration or compatibility - would the following be a good way to
> determine if the multicast communications are working?
> 
> 1) Check what multicast group (IP) the nodes have chosen using netstat
> -gn ?
> 
> e.g. for host0, I'm guessing that cman is using 239.192.205.2 (as I
> think 225.0.0.12 is for the fence_xvmd Xen virtualised host group and I
> can't see any activity on 224.0.0.251).
> 
> [root at host0 ~]# netstat -g
> IPv6/IPv4 Group Memberships
> Interface       RefCnt Group
> --------------- ------ ---------------------
> lo              1      all-systems.mcast.net
> eth0            1      224.0.0.251
> eth0            1      225.0.0.12
> eth0            1      239.192.205.2
> eth0            1      all-systems.mcast.net
> [root at host0 ~]# 
> 
> 

239.192.205.2 is the multicast address chosen by RHCS.

> 
> 2) Use tcpdump to check that this node is receiving transmissions from
> *other* nodes to the multicast group.
> 

Data will only be sent when a transmission is requested - ie: when using
a checkpoint, event service, or plock operation.

> e.g. 
> 
> [root at host0 ~]# tcpdump -i any -nn host 239.192.205.2 and ip multicast
> tcpdump: WARNING: Promiscuous mode not supported on the "any" device
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on any, link-type LINUX_SLL (Linux cooked), capture size 96
> bytes
> 13:42:03.674676 IP 172.31.99.50.5149 > 239.192.205.2.5405: UDP, length
> 118
> 13:42:03.767820 IP 172.31.99.50.5149 > 239.192.205.2.5405: UDP, length
> 74
> 13:42:03.962382 IP 172.31.99.50.5149 > 239.192.205.2.5405: UDP, length
> 74
> 13:42:04.162652 IP 172.31.99.50.5149 > 239.192.205.2.5405: UDP, length
> 118
> 13:42:04.267768 IP 172.31.99.50.5149 > 239.192.205.2.5405: UDP, length
> 74
> 13:42:04.450195 IP 172.31.99.50.5149 > 239.192.205.2.5405: UDP, length
> 74
> 13:42:04.650646 IP 172.31.99.50.5149 > 239.192.205.2.5405: UDP, length
> 118
> 13:42:04.766404 IP 172.31.99.50.5149 > 239.192.205.2.5405: UDP, length
> 74
> 13:42:04.940367 IP 172.31.99.50.5149 > 239.192.205.2.5405: UDP, length
> 74
> 
> 9 packets captured
> 19 packets received by filter
> 0 packets dropped by kernel
> [root at host0 ~]# 
> 
> In the above example I can only see transmissions to 239.192.205.2 from
> 172.31.99.50 (hosts0's IP address). If things were working properly, I'd
> be able to see transmissions from other source addresses wouldn't I?
> 

This is generally true for this phase of the protocol which is the
membership phase.  It looks to me from this trace like you have a
firewall configured on port 5405 for UDP.  Try turning off your firewall
for this port and see if that fixes the problem.

> E.g. I should have at least some entries like this
> 
> 13:42:04.940367 IP 172.31.99.100.5149 > 239.192.205.2.5405: UDP, length
> 74
> 
> where the source address is a different node, right?
> 

Once the protocol is in the "operational" mode meaning a membership has
been obtained, this is less likely unless there is plock/evt/ckpt
traffic on one of those nodes.  Multicast isn't randomly sent - it is
only sent when data is transmitted.

Pls send a copy of your /var/log/messages and I'll take a look if the
firewall configuration is not your issue.

Regards
-steve

> 
> Regards,
> 
> Nik Lam
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>