Pound has been working wonderfully for us in a testbed, we're getting ready
to move it into production. Thanks to all who have provided advice along the
way! One last item I need to address:

We want HA for the pound server itself. I was going to look at the Linux
Heartbeat project, or cobbling together some scripts to handle failing over
one pound server to another. Can anyone suggest other solutions for this
they have used?
[...]
cause arp problems because the PIX firewall in front of it won't honor the
arp notifications. This may not be as big of an issue as we had with
spread/wackamole, but I'm curious about any other specific solutions people
have had success with.

Thanks in advance for any thoughts!

Jay West
Knight's Direct

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

On Friday 04 June 2004 16.16, Jay West wrote:[...]

If your Cisco won't honour the ARP notifications then you have a real problem: 
all failover solutions I know of are based (one way or another) on taking 
over an IP address, and this can only be achieved via an ARP notification. On 
the other hand I find it difficult to believe this is the case - if a machine 
dies and you start another (different MAC) for the same IP surely the Cisco 
must accept that.[...]

Robert wrote...[...]
problem:[...]
Hummm ok. I'll see if there isn't a way to mitigate this, possibly locating
the pound server outside the pix.
[...]
machine[...]
Cisco[...]
Nope, it's a fact, confirmed with Cisco. The pix will not allow any changes
to it's arp cache table from outside forces when there's already an existing
entry (it's a firewall after all). There are 3 exceptions 1) Power cycle the
pix (not good), 2) issue a 'clear arp' command from the command prompt on
the pix, or 3) allow the old arp entry to timeout and thus a new one can be
accepted.

I dislike the idea of having the failover software run an expect script to
log into the pix and do a clear arp upon an IP switch for several reasons,
the most important being the requirement for the pix password to be coded
into the script. I also checked with cisco to see if there was an snmp
variable that could be set to cause the arp cache to clear. The benefit
would be you could restrict it to a certain IP so the community write string
being coded in the script wouldn't be a huge deal. However, according to
cisco, no such snmp variable exists that you can write to and cause a clear
arp.

This leaves the last possibility above, #3. The pix allows you to set the
arp cache timeout to any value in seconds. Any arp entries older than the
set timeout value expire and can thus be overwritten. But there is an issue
here as well. The lowest you can set the arp cache timeout on the pix is 60
seconds. You can set it lower, but then the pix will start to lose packets.
So we're stuck with 60 seconds. I'm not wild about a failover taking 60
seconds, and would certainly like it to happen faster than that.

However there may be another possibility, I'd have to think through it. If I
put the pound server in front of the pix, the router ahead of it would
probably accept the arp notifications, unlike the pix. Then this would be a
non issue. I'd rather not put any server in front of the pix though.

Anyways, I realize this whole discussion really isn't a pound issue per say,
but I figured many on the list using pound would have crossed this bridge
already and may have some thoughts.

Thanks again!

Jay West

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

> Robert wrote...[...][...][...][...][...][...][...][...][...][...]

Once I've been hit by this problem when doing a remote server hardware
change....

The solution to your problem is a HA solution which not only takes over
the IP adress to the redundant server but also the MAC adress. I don't if
it's possible with Linux HA solutions but I'm sure it could even be done
with some simple scripts. That way the PIX doesn't even notice what's
going on.

Simon

On Fri, Jun 04, 2004 at 11:16:23AM -0500, Jay West wrote:[...]

It seems very odd that a feature like this would not be configurable.
The ARP protocol is *designed* to allow overwrites.  If you can't tell
your PIX to accept perfectly legitimate protocol traffic to let it talk
to the rest of your network, you should open a ticket with Cisco to get
this bug repaired.

At $dayjob, we have a pair of Nokia firewalls that regularly toss
responsibility back and forth, not to mention Cisco CSS load balancers
and a myriad other devices.  I see a few hundred arp overwrites every
day in this environment.  I suspect some of it may be unnecessary (I'm
not responsible for the *whole* network), but if we had to `clear arp`
every time something changed, we'd need to hire someone just for that.

I don't have a solution for your PIX problem, I'm just complaining in
sympathy.  ;-)
[...]

Ya, putting the server in front of the pix doesn't seem right.

You might want to look into FreeVRRPd.  VRRP (RFC2338) uses a "virtual"
MAC address that gets passed between devices; if the MAC doesn't change,
the PIX won't see the change, it'll just happen in the Ethernet switch
as the virtual MAC moves from one interface to another.  Check out
http://www.b0l.org/?idcategory=3&idsection=1
for details.  I haven't
needed to play with this at all -- if you do, please report back to the
list, as I'm sure lots of us are interested.  :)
[...]