Re: arp table - same mac address shows two ip addresses

Grant Taylor <[email protected]> Fri, 19 Oct 2018 02:43:27 +0000
Newsgroups org.kernel.vger.lartc
Message-ID <[email protected]>
On 10/18/2018 05:38 PM, Grant Taylor wrote:
> I can get ARP to respond.  But I've not gotten ICMP to function yet.  It 
> looks like it may be, funny enough, an ARP issue.  B has two ARP entries 
> for A's IP, one from the what it learned from A's ARP request and an 
> incomplete entry.  I've not done any more investigation to see if I can 
> make this work.  Yet.  }:-)

Okay.  I've done some more investigating and I think it is more of a 
routing issue than /just/ an ARP issue.  In short, the kernel doesn't 
quite know what to do with the traffic destined to one subnet with an 
ARP entry for a different interface than the subnet is on.

> I think I'm going to need to reconfigure the network a bit to have B 
> function as a router with A being on the wrong interface.  Probably 
> something like this:
> 
> (A)---1---(B)---2---(C)
>             |
>             3
>             |
>            (D)
> 
> Such that A looks like it moved from the 3 network to the 1 network. 
> With C being something on the other side of "the router", B.

This wasn't enough.

> Once I had the network namespace TCP/IP stacks set to defaults, B did in 
> fact respond to A's ARP request for an IP on the 2nd network.

rp_filter (Reverse Path Filtering) seems to also protect ARP.

The biggest issue that I can see with arp_filter is that it may disclose 
information about other interfaces on a router.  Where as if arp_filter 
is enabled, then the information won't be leaked.

rp_filter vs arp_filter  rp_filter will only protect incorrect routed 
paths.  arp_filter will protect disclosure / leakage from correct routed 
paths.

I plan on starting to keep arp_filter enabled in addition to rp_filter 
on my machines.  At least until I have a reason not to do so.



-- 
Grant. . . .
unix || die
smime.p7s (application/pkcs7-signature, 3.9 KB) - not displayed