On 06/05/13 18:57 +0200, Mikael Abrahamsson wrote:
On Wed, 5 Jun 2013, William Herrin wrote:
Nothing. The problem is that the arp source IP doesn't fall within the interface netmask at the receiver. Some receivers ignore that... after all, why do they care what the source IP is? They only care about the source MAC. Other receivers see a spoofed packet and drop it.
Why wouldn't it be within the source IP mask? I would imagine local-proxy-arp would work exactly the same way as if a directly connected host with the IP the ARP request was for would have answered.
I've seen two vendors get it wrong: 1) when originating an ARP request, the router uses a source IP that does not match the subnet of the ip being requested (happened when the interface on the router had secondary IPs); 2) when a customer had more than IP address assigned on an interface/VLAN, and one device ARPd the other, the router responded with its own MAC, creating a race condition where sometimes traffic between those two devices was forced up through the router. -- Dan White