Re: Secondary IP addresses

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Michael,
this seems to be bug. I've rewrote that code so Linux platform specific things gone and probably didn't test your test case.

Corosync implementation of getifaddrs should return same order as getifaddrs, if it's doing otherwise, it's bug (should be simple to fix).

I believe "best match" is not implemented even in older releases, but seems to be good idea to have.

Regards,
  Honza

Michael Chapman napsal(a):
On Tue, 22 May 2012, Dan Frincu wrote:
Best choice would have been to use the actual IP address in the config
file, rather than using the network address. This would lead to the
same effect (bind on the right IP) without having to modify code. This
is also the recommended way of doing things when having overlapping
subnets. And, yes, it will always go for the highest numerical IP it
finds.

Using the actual IP address in the config doesn't help anything. Corosync still applies each interface address's network mask to see whether the address matches, and 192.168.0.1/24 and 192.168.0.0/24 end up being masked to the same thing.

Also, it's not necessarily the "highest" IP address; it will just be whatever address comes last when enumerated by getifaddrs(). As far as I know, getifaddrs() doesn't guarantee any ordering, so this is potentially non-deterministic. (On Linux, it seems that the "primary" IP address for a particular interface will always be enumerated before its "secondary" IP addresses, however.)

So this problem still stands: there's no way to tell Corosync to bind to a particular IP and ignore any other IPs it might see in the same subnet. And (as my earlier Question 1 mentioned) there seem to be certain conditions when Corosync might re-evaluate which IP to use *whilst* it is running.

totemip_iface_check() could be modified to match on a specific IP if it matches exactly the value from the config file, and only falling back to "any IP in the same subnet" if that IP isn't found. Would a patch along those lines be welcome?

- Michael

_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss

_______________________________________________
discuss mailing list
discuss@xxxxxxxxxxxx
http://lists.corosync.org/mailman/listinfo/discuss


[Index of Archives]     [Linux Clusters]     [Corosync Project]     [Linux USB Devel]     [Linux Audio Users]     [Photo]     [Yosemite News]    [Yosemite Photos]    [Linux Kernel]     [Linux SCSI]     [X.Org]

  Powered by Linux