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
