On Sun, Jun 08, 2008 at 11:25:47PM -0400, David Coulson wrote: > 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.
Get the client to implement BFD in echo mode? > > 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? Don't rely on arp for fast failover. Rodney > > David > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
