[c-nsp] Gratuitous arp and Pix

[Rodney Dunn]

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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/