Presumably you were routing between the subnets somewhere, so the packets came back from the second machine's default router.

-- Graham

We saw this was in an isolated test environment, with no routers available. (Hence the weirdness.)

We saw this was in an isolated test environment, with no routers available. (Hence the weirdness.)

I presume the system which received the pings was not configured with route add default dev eth0 as the first system was: that would be far too obvious.

Any chance the second machine's subnet mask was incorrect?

Could the first machine reach the second via, e.g., TCP or UDP, or was it only ICMP ECHO/REPLY that worked between them? Could the second machine also ping the first one?

(My best guess has to do with the first machine being present in the other system's arp cache, but I'm not completely convinced.)

Well, that just begs the question: how did the first machine get added to the other's arp cache?

If the second machine was a Linux machine, /sbin/ip neighbour may yield slightly more information (under modern Linuxes, the ARP table is a special case of what it refers to as the neighbour table, and the distinctions between layers 2 and 3 are somewhat blurred; commands like arp, route and ifconfig seem to merely be interfaces to the mechanisms controlled more directly by the /sbin/ip command).

--Dan

First, what's odd to me is the proxy arp behavior you describe. This should not have happened in the first place.

Second, I would expect this route to result in the box treating everything as local, essentially ignoring its own (implied) connected routes. In this case, since there is no L2 separation both the arp request from source box and the ping are expected to make it to the target box. However, if the target machine had no route back, the ping would fail.

If the proxying behavior is as you describe (arping for the destination), are you sure the box wasn't responding to its own ping? This is easily verified with tcpdump.

To clarify: I don't think that the first machine was doing arp proxying, I think it was just sending out arp requests for all destinations (even ones theoretically not on the local network).

As for how the first machine got added to the second machine's arp cache, I believe that most machines add things to their arp caches when they answer arp requests (Linux certainly does), and I suspect that they do this without caring whether the target IP is theoretically reachable on that interface's local network.