I am looking at implementing some IP takeover services on a network
behind Pixs (I think it's a pair of 535s running 7.2 - I don't control
it, but I can request config changes). It would appear that Pix does not
handle gratuitous arp responses in any useful way, which as a security
appliance I would consider to be reasonable. That said, I don't want to
wait 5 minutes (current arp timeout config) for an IP takeover, neither
do I want to cut down the arp timeout for all network interfaces unless
necessary. The particular implementation for IP takeover which is being
implemented does not use a virtual MAC, and instead binds the VIP to the
physical MAC of the active server - Hence the gratuitous arp when it
switches devices.
So, I'm trying to assess options. My first idea would be to put a hop
between the Pix and the servers, so the IP update is handled by the
device handling the routing (probably the switch w/ SVI). Right now the
switch between Pix and servers is a 2950, so that is not going to be up
to the task. I realize that the switch continues to be a single point of
failure, but statistically my x86 servers are going to take a dump long
before the switch will. I'd love to get a 4948 in there (that is our
standard top-of-rack switching platform today), but I don't see that
happening since the Pix only has 100Meg interfaces. That said, I'm
unsure if there are other problems introduced by having the boxes on a
different subnet (e.g. if I have a box directly connected to the L2
network the Pix inside interface is on, will it correctly route through
the Pix, back to the switch and to the servers on the other VLAN - I'm
going to guess 'no'. I'd then have to move it all onto separate VLAN(s),
use the switch as a central routing box with a default route out to the
Pix, which seems like a mess).
Has anyone encountered this problem before, and how exactly did you work
around it? Would this problem improve any by moving to the ASA platform?
David
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
