Problems with cluster...
- Thread starter bradmc
- Start date
I would suggest you to use tcpdump to debug your problem. Try to capture multicast address (from pvecm status) and see if it stops to comming/sending.
Because with 3.3 you updated corosync too. I would suggest you to use tcpdump. Try to capture multicast packets (see address from pvecm status) when node is failed. Also try to use omping when node is failed to see if it stops to receive heartbeat. And as a final workaround for 3 nodes cluster you can use unicast instead of multicast and see if it helps. The nature of your issue is not clear and all these steps will help to understand where exactly your problem is.
Last edited:
Symptoms were the same as in another thread, although it was in regard to running a mixed cluster of 3.10 and 2.6.32 kernels, so I thought I would give the fix a try, and it worked. However, I'm not running a mixed-kernel cluster; everything is 3.10-4. Anyway, this worked and fixed the issue. But, WHY must this be done?
find /sys/devices/virtual/net -name 'multicast_snooping' -exec sh -c 'echo 0 > {}' \;
find /sys/devices/virtual/net -name 'multicast_querier' -exec sh -c 'echo 0 > {}' \;
service cman stop; service cman start; service pve-cluster restart
find /sys/devices/virtual/net -name 'multicast_snooping' -exec sh -c 'echo 0 > {}' \;
find /sys/devices/virtual/net -name 'multicast_querier' -exec sh -c 'echo 0 > {}' \;
service cman stop; service cman start; service pve-cluster restart
If I remember, multicast_querier is disabled in kernel 3.10 by default, because of bugs and incompatiblity with cisco switches.
You should have an igmp querier somewhere in your physical switches to manage multicast; (or disable snooping on vmbrX if your switchs are not manageable and don't support igmp querier)
You should have an igmp querier somewhere in your physical switches to manage multicast; (or disable snooping on vmbrX if your switchs are not manageable and don't support igmp querier)