Arp issues

[gsatchivi]

I have a set of pix 525's set up as primary and failover. The IOS is 6.1.1. Recently the DMZ interface started to behave strangely. After the arp cache times out, the mac address of the router on the DMZ interface is not being learnt. From the PIX, I can reach any other device in that segment except the router ( a cat 4006 with a routing module). As soon as I do clear arp on the router both devices start to communicate. There is no dupicate IP addr, the port on the switch ok. The problem occurs also when I shut down the Primary PIX and let the failover only run. I duplicated the problem by doing "clear arp IP-addr dmz" on the PIX. Then I started to ping from both directions. I had I packet sniffer on the segment and I cannot see any arp request coming from the PIX. Nor do I see any ping packets. I do see one arp reply from the router directed to its own IP but the mac addr is a broadcast addr. Finally I decided to statically code the mac of the router in the PIX and everything started working fine. Has anyone seen this issue before. My next step is to upgrade the firewall to vers 6.3. I went through the bug track info about this version, yet I would like to hear from those who have already deployed it. How stable is it? How well does it handle ipsec PIX to PIX VPN conjoined with PPTP vpn and a fairly long access-list and conduit tables.

Thanks in advance for your input.

[jeff.roback]

We have seen lots of strange behavior with 6.1.1. However 6.3 is a major revision, so it'd probably contain some new issues.

You might try upgrading to 6.1.4. We've been runnning it in several locations and it's been rock solid.

Also double-check that the IP address of the router isn't in any of your NAT tables...the Pix will proxy-arp for it's NATed addresses, which can cause interesting problems. We've seen Macintosh machines boot up with "Duplicate IP address" warnings because the pix was responding for their IP Address in a way they didn't like. (Never got around to troubleshooting it with packet capture, though).

One thing to try is "sysopt noproxyarp if_name". We've found this helps with strange ARP and/or IP address conflicts that we can't otherwise find a reason for.