Cisco ASA 5510 needs "clear arp <Interface>" periodically to reach a single host

Question

ASA 9.0(3)

The symptom is that I can ping from the ASA to any other host in that interface's subnet, save one particular host (that host can ping the interface on the ASA however). If I do "clear arp FooInterface" I'll be able to ping the host for a few minutes (varies, but < 10), then it won't work until I re-issue the command.

sho arp on the ASA shows the correct MAC for the host, arp -a on the host shows the correct MAC for the ASA's interface.

This subnet is on a VLAN, none of the other VLANs on this physical interface have this problem.

Any ideas what's causing this?

=== edit ===

As requested, show arp for the IP when communication works:

ykf-fw-1# sho arp | include 10.10.40.36
Infrastructure 10.10.40.36 90e6.ba8c.1828 363

and when it doesn't:

ykf-fw-1# sho arp | include 10.10.40.36
Infrastructure 10.10.40.36 90e6.ba8c.1828 144

=== edit #2 ===

A ping from the ASA:

ykf-fw-1# ping 10.10.40.36
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.40.36, timeout is 2 seconds:
?????
Success rate is 0 percent (0/5)

the host sees this via tcpdump:

[root@ykf-nas-2] ~# tcpdump -i vlan1 host 10.10.40.1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan1, link-type EN10MB (Ethernet), capture size 65535 bytes
22:01:17.563705 IP 10.10.40.1 > 10.10.40.36: ICMP echo request, id 17480, seq 25146, length 80
22:01:17.563719 IP 10.10.40.36 > 10.10.40.1: ICMP echo reply, id 17480, seq 25146, length 80
22:01:19.561476 IP 10.10.40.1 > 10.10.40.36: ICMP echo request, id 17480, seq 25146, length 80
22:01:19.561490 IP 10.10.40.36 > 10.10.40.1: ICMP echo reply, id 17480, seq 25146, length 80
22:01:21.561253 IP 10.10.40.1 > 10.10.40.36: ICMP echo request, id 17480, seq 25146, length 80
22:01:21.561267 IP 10.10.40.36 > 10.10.40.1: ICMP echo reply, id 17480, seq 25146, length 80
22:01:23.561107 IP 10.10.40.1 > 10.10.40.36: ICMP echo request, id 17480, seq 25146, length 80
22:01:23.561120 IP 10.10.40.36 > 10.10.40.1: ICMP echo reply, id 17480, seq 25146, length 80
22:01:25.560906 IP 10.10.40.1 > 10.10.40.36: ICMP echo request, id 17480, seq 25146, length 80
22:01:25.560920 IP 10.10.40.36 > 10.10.40.1: ICMP echo reply, id 17480, seq 25146, length 80

(and ping from the host to the ASA work as expected).

[edit Feb 17] I've been back and forth with Cisco TAC for the last month. Upgraded to 9.1(5), same problem. The support rep took packet captures from the ASA, the host and the L2 switch connecting them, and is supposed to get back to me at some point. He claims he's never seen anything like this and thinks it might have something to do with the VLAN encapsulation between the switch and the ASA (this problem doesn't happen to subnets on the ASA's native interface).

Solution

The problem ended up being an older firewall kept being attached to the network by a different team, several network devices away. So those of you who said "duplicate IP" were correct.

Comments

[Joseph]

You might try networkengineering.stackexchange.com if you don't get an answer here.

[ravi yarlagadda]

Can you get a packet capture on the wire (probably from a switch, or possibly from both the host and the ASA at the same time?) of the traffic? There has to be some interesting difference between the communication in one direction or the other - and whether the echo request or echo reply is the one getting lost is important info, too.

[Joe]

This is more of a comment but i don't have 50 rep. Anyway, it sounds like there is another device on the network with the same IP address. When you notice you cant reach the device, check the arp table. If I am right, you will notice that the mac address for that specific IP changed.

[user966602]

See edit, the MAC is the same.

[packetologist]

Could you try sourcing the ping from the proper interface to see if that works? Is the ASA interface the default gateway for that VLAN?

[yagmoth555]

How your arp table look like ? Did you checked if you do arp inspection on your other VLAN ? arp-inspection interface_name enable [flood | no-flood] "Where flood forwards non-matching ARP packets out all interfaces, and no-flood drops non-matching packets."