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@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@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@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@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 > > > > > > > > > > > > -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
