Re: Issues with ARP notification on latest CVS of wackamole

Theo wrote...
> I think it is the PIX not allowing arp-spoofing -- it is a firewall
> after all :-)
>
> Perhaps the ARP reply packets need to be addressed specifically to the
> PIX's MAC address.  I looked through the documentation, but I don't see
> anything that mentions how to send unsolicited ARP replies to a PIX.
> Any insight would be appreciated.  Whatever it is, I am sure it is a
> simple software fix.
I just got a response from a Cisco engineer - no dice really. There is no
way to make the PIX accept unsolicited arp requests. However, the timeout
can be set from the standard 14400 seconds down to 60 seconds. Any less than
60 seconds and the pix will probably start loosing packets.

So this leaves me with two possible solutions. First, we can set the arp
cache timeout on the pix down to 60. This will work fine, but we really hate
the 60 seconds of downtime for a failover. More directly because when we
push a cvs update to each machine for new website code, the system doing the
pushing fails a machine in the cluster (wackatrl -f), stops apache on the
machine (ssh xxxxx apachectl stop), rsyncs the new code, starts apache, then
starts wackamole (wackatrl -s). It then moves to the next machine in the
cluster. For small CVS updates it's entirely possible that 3 or 4 of the
machines will be in a failed state or just recovering at the same time (the
same 60 second window). Since there's 4 machines in the web cluster, this
would result in too large of a "downtime" window. Round robin DNS would mean
only one of 4 machines (or none) can service any requests. We may have to go
that route though.

However, there may be a second solution. Is there some way that whenever
wackamole brings up any VIP's, it can call an external program? I'm thinking
along the lines of perhaps sending an SNMP request to the PIX to clear it's
arp cache when this happens. Any thoughts?

Jay West

---
[This E-mail scanned for viruses by Declude Virus]