|
Hi Carlos,
>We are facing an issue against an HP Procurve Switch 2124, used in a
>cluster using Heartbeat and Ldirectord as HA and Balancing mechanisms.
>Well, everything works fine, till we make a takeover on directors. As
>the switch documentation saids, the switch automatically learn MAC
>address and associate it to its ports, so that although heartbeat
>changes IP address, the switch try to use the same switch port, and this
>situation remains for at least 1 hour
Here's something I don't understand: heartbeat IP takeover involves no change
of MAC addressess at all; both nodes keep their previously used mac address,
only the IP address moves to another node. I'd expect a switch to work at
physical/mac layer only, so this IP takeover shouldn't concern your switch at
all.
However: your default gateway/router/firewall DOES have en entry for the
MAC/IP combination that just changed. especially if it's a firewall there's a
good chance that it doesn't accept gratuitous ARP (see below..) for security
reasons; it may be that the only option you've got is to reduce the arp
timeout setting on the firewall to get better failover times.
>Is there any way to force the switch to refresh MAC Address Table?, is
>there any Linux tool that sent any kind of packet over the net forcing
>the ARP Table to be updated?
Well, good and bad news: Yes, there is a tool that generaly gets attached
equipment to update its arp table. The bad news: it's already part of
heartbeat and gets called by the IPaddr resource, i.e it most probably
doesn't work for your configuration.
The tool used by heartbeat is send_arp and sends out both arp queries and the
corresponding answers; experience shows that that the combination works with
some pieces of equipment where just the arp replies don't work.
you should find references to send_arp in your heartbeat log:
/usr/lib/heartbeat/send_arp eth1 10.192.1.76 0007E923353A 10.192.1.76
ffffffffffff
would be an example from my logs.
Please make extra sure that it's actually the switch that's causing your
problems ant not your router, I think you may be looking at the wrong
suspect.
Bye, Martin
********************************************************
Martin Bene, CTO
icomedias GmbH, A-8020 Graz, Entenplatz 1b
t +43 (316) 721671-14, f +43 (316) 721671-26
e martin.bene@xxxxxxxxxxxxx, i http://www.icomedias.com
********************************************************
|
