[Linux-cluster] corosync issue with two interface directives

Dan Frincu dfrincu at streamwide.ro
Tue Jul 13 04:33:19 UTC 2010


It seems that the issue could also be caused because Corosync looks at 
the classfull network masks of a bindnetaddr directive, in this case, 
even if you have addresses with /24 netmask, Corosync thinks they're /8. 
Try changing to a private class C addressing scheme, which also uses /24.

Read more here http://www.corosync.org/doku.php?id=faq:configure_openais

Regards.

Digimer wrote:
> On 10-07-12 03:38 PM, Dan Frincu wrote:
>> Just a wild stab in the dark, but both your multicast groups result in
>> the same MAC address 01:00:5e:5e:01:01. Now these are supposed to be
>> redundant connections, which means different IP/port/MAC's, different
>> routes, in case one fails the other one takes over. Try changing the
>> multicast groups so that the they differ at the end of the address,
>> rather than at the beginning.
>>
>> You could use 226.94.1.1 for ring 0 and 226.94.1.2 for ring 1. The key
>> thing to remember here is that when building a multicast MAC address,
>> you only use the low order 23 bits of the multicast IP address, thus
>> allowing for overlapping of close high order bits in the multicast IP
>> address.
>>
>> Regards.
>
> Hi Dan,
>
>   I tried changing my config file as per your recommendation, but it 
> didn't seem to sort out the problem. The 'corosync-objctl' output only 
> shows one ring. Oddly though, when I don't start corosync via cman, 
> and instead start corosync by itself, both rings are in fact shown...
>
>   Also, I must claim ignorance - I am not familiar with how multicast 
> addresses map to MAC addresses. Perhaps I am missing something 
> fundamental here? I originally extrapolated the second ring's config 
> by adapting the first ring which, itself, was adapted from example 
> configs available in the docs.
>
> Here is my current corosync.conf file:
>
> ------------------------------------------------------------------
> # This is a skeleton example configuration file.
> compatibility: whitetank
>
> # Totem Protocol options.
> totem {
>     version: 2
>     secauth: off
>     threads: 0
>     rrp_mode: passive
>     interface {
>         # This is the back-channel subnet, which is the primary network
>         # for the totem protocol.
>         ringnumber: 0
>         bindnetaddr: 10.0.1.0
>         mcastaddr: 226.94.1.1
>         mcastport: 5405
>     }
>     interface {
>         # This is the storage network, which acts as a secondary, backup
>         # network for the totem protocol.
>         ringnumber: 1
>         bindnetaddr: 10.0.0.0
>         mcastaddr: 227.94.1.2
>         mcastport: 5405
>     }
> }
>
> logging {
>     to_syslog: yes
>         fileline: off
>         to_stderr: yes
>         to_logfile: off
>         to_syslog: yes
>         #logfile: /var/log/corosync.log
>         debug: on
>         timestamp: on
> }
>
> amf {
>     mode: disabled
> }
> ------------------------------------------------------------------
>

-- 
Dan FRINCU
Systems Engineer
CCNA, RHCE
Streamwide Romania

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-cluster/attachments/20100713/2f6d14e0/attachment.htm>


More information about the Linux-cluster mailing list