[ClusterLabs] Antw: Corosync ring marked as FAULTY

Denis Gribkov dun at itsts.net
Mon Mar 6 11:30:14 EST 2017


Hi Everyone.

On 22/02/17 10:54, Vladislav Bogdanov wrote:
> That could be igmp querier issue. Corosync does not follow "common" 
> model of mcast usage - one sender/router in a segment and many 
> receivers. Instead, all corosync nodes are mcast senders and 
> receivers. For that to work reliably, both IGMP snooping should be 
> enabled and *work* in a segment and IGMP querier exists there (in 
> absence of a mcast router). Also, if switches differ in that two 
> segments, then issue could be with IGMPv2 vs IGMPv3 snooping support 
> in that in ring0 segment. Not all switches support IGMPv3 (linux 
> default) snooping, and to be on a safest side it could be needed to 
> downgrade used linux IGMP version to v2 
> (/proc/sys/net/ipv4/conf/<intf>/force_igmp_version).

I have checked both networks private and public and now I'm sure that 
they are have the similar settings and IGMP working fine.

After lot of digging I found that if I run Corosync daemon standalone 
from Pacemaker both rings are
working fine. Netstat utility shows that corosync listen on both interfaces:
# netstat -lnup |egrep '5405|5505'
udp        0      0 111.11.11.1:5405 
0.0.0.0:*                               14912/corosync
udp        0      0 192.168.1.54:5505 
0.0.0.0:*                               14912/corosync

# corosync-cfgtool -s
Printing ring status.
Local node ID -1306941248
RING ID 0
         id      = 192.168.1.54
         status  = ring 0 active with no faults
RING ID 1
         id      = 111.11.11.1
         status  = ring 1 active with no faults

When it starts under Pacemaker - Corosync listen only on public interface.

Check with tcpdump also catching so many packets for both 
ports/rings/interfaces.

So my question is - why Corosync didn't work correctly if it start under 
Pacemaker?

For sure - I have no any unusual settings for pacemaker in /etc/sysconfig.

Thank you.

-- 
Regards Denis Gribkov


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3695 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.clusterlabs.org/pipermail/users/attachments/20170306/c801fc74/attachment-0002.p7s>


More information about the Users mailing list