[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IP4 address conservation method
- Subject: IP4 address conservation method
- From: dwhite at olp.net (Dan White)
- Date: Wed, 5 Jun 2013 13:42:53 -0500
- In-reply-to: <[email protected]>
- References: <[email protected]> <CAP-guGV_VihKzm1b6u29nkT0WL6=QE8=hLOKz4k1pg6UNbrK5g@mail.gmail.com> <[email protected]> <CAP-guGX=7n+=7kB5FeteTfkn5rVC3eCNPpsicCaWOuY_w-uGvA@mail.gmail.com> <[email protected]>
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