[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ha-dev
Subject:    [Linux-ha-dev] Heartbeat + iproute issues and solution.
From:       Kevin Dwyer <kevin () pheared ! net>
Date:       2002-08-19 15:13:03
[Download RAW message or body]

Per Alan's request, I'm sending a message to the lists which contains the
solution to my iproute troubles in the hopes that no one else need endure
them.  I've condensed the whole issue into this short email.

The Problem:
	We are using Heartbeat for High-Availability firewall pairs.  To
work effectively, heartbeat needs to be able to communicate between
the two machines on as many channels as possible.  One of these channels
is broadcast over UDP.  To set up the broadcast properly, heartbeat uses a
specific ioctl call to learn the broadcast address of an interface.  This
will work fine if you are using a 'normal' setup with just ifconfig.
However, we make use of iproute2 when configuring the IP aliases, with
commands like the following:

ip -f inet addr add 10.5.5.1 dev eth0 scope link

In practice, this works just fine.  The problem arises when heartbeat
tries to locate the broadcast address for the given interface (eth0 in
this example.)  It makes the call to the ioctl as usual, but instead of
receiving 10.5.5.255 (which has been set with ifconfig) it gets 0.0.0.0.

The Solution:
	There happens to be a very simple solution to this problem.  I
almost had it while reading the documentation for iproute2 and exchanging
email with another member of the list.  Essentially, you need to specify
the broadcast address explicitly with each iproute2 command, like so:

ip -f inet addr add 10.5.5.1 dev eth0 scope link brd 10.5.5.255

We had been incorrectly trying to use 'brd +' to inherit the broadcast
address from the device.  Setting the broadcast address explicitly in the
iproute2 command will allow heartbeat to pull it from the ioctl as it has
done in the past.  This solution should have occurred to me, but the
problem was just so weird that I was totally thrown off.  Luckily, the
netdev list was able to come through.


A thank you to all who helped, including members of the netdev list (who
I've already thanked, so I don't have to add yet another cross-post).

/* kevin@pheared.net               http://devel.pheared.net/ */
/* Network Security Engineer       http://pheared.net/~kevin */
/* Sabotage will set us free.   Throw a rock in the machine. */


_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.community.tummy.com
http://lists.community.tummy.com/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
[prev in list] [next in list] [prev in thread] [next in thread]