On 2012-08-31T13:41:14, Ulrich Windl <[email protected]> wrote:
> Hi!
>
> There are things I don't understand: Even after
> # /usr/lib64/heartbeat/send_arp -i 200 -r 5 br0 172.20.3.59 f1e991b1b951
> not_used not_used
>
> neither the local arp table (arp) not the software bridge (brctl ...
> showmacs) know anything about the MAC address being used. So how will the
> system respond to ARP queries?
That sends an unsolicited ARP reply to *other* systems on the network
segment, so that they can update their ARP tables. The local node
doesn't show up in the local ARP cache, and the CIP isn't any
different.
(You'll also not find the MAC address of, say, your desktop/laptop in
its own ARP table.)
> BTW: I wondered why the "lo" interafce has an "UNKNOWN" up status in "ip link
> show":
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
> link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
Because the lo interface doesn't implement the up/down state interface,
since it doesn't have physical link state. That is completely unrelated.
> I have no idea how to debug this problem. The gateway just shows one
> of the nodes using that MAC address, and ARPs sent out have the
> interface's MAC address as source; maybe that confuses the gateway.
You need to reconfigure the gateway to either accept the multicast MAC
it gets via the ARP reply, or statically configure the ARP entry on the
gateway, or, if that fails, use a more traditional setup, like LVS with
direct routing.
(That would imply that one of your nodes has to process all inbound
traffic once at the network layer, but at least work distribute the
application load and outbound traffic. It may even be higher performing
than the CLUSTERIP.)
Regards,
Lars
--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
