arplookup x.x.x.x failed: host is not on local network

[Peter Jeremy]

OK, my responses to the replies so far.

One off-line reply requested a topology and netstat output.  Since the
toplogy may be relevant, below is an extremely simplified approximation
(the real network has about 60 subnets and about 70 hosts, each
appearing in between two and four subnets).

			       Corp Network
         192.168.10.0/24       	     |             192.168.12.0/24
  +------+-------------+----------|  |  |----------+-------------+-----+
       .1|           .2|      .254|  |  |.254    .3|           .4|
     +-------+     +-------+     +-------+     +-------+     +-------+
     |       |     |       |     |       |     |       |     |       |
     | host1 |     | host2 |     |  NAT  |     | host3 |     | host4 |
     |       |     |       |     |       |     |       |     |       |
     +-------+     +-------+     +-------+     +-------+     +-------+
       .1|           .2|      .254|     |.254    .3|           .4|
  +------+-------------+----------|     |----------+-------------+-----+
         192.168.11.0/24       	                   192.168.13.0/24

The errors appear to be randomly spread across hosts and subnets.  It
does not appear consistently and seems to correlate with load (I am
getting significant numbers at present and the NAT host is routing
about 90Kpps and 100MBps if netstat can be believed).  The problem
also shows up on another interior routing host that has visibility
across the internal networks so it isn't related to NAT or directly
related to host load (that host is only seeing about 3.5Kpps - but is
also a much slower host).

I have managed to capture a tcpdump across the error.  syslog reported:
Jul  3 21:28:30 xxxx kernel: arplookup 192.168.169.26 failed: host is not on local network
and the packets for that host during that second are:
21:28:30.320340 00:0b:cd:d6:66:26 > 00:03:ba:ab:6f:ef, ethertype 802.1Q (0x8100), length 64: vlan 169, p 0, ethertype IPv4, IP (tos 0x0, ttl  64, id 29304, offset 0, flags [none], length: 28) 192.168.169.26 > 192.168.169.111: icmp 8: echo request seq 35079
21:28:30.320429 00:d0:b7:20:8f:ee > 00:03:ba:ab:6f:ef, ethertype 802.1Q (0x8100), length 46: vlan 168, p 0, ethertype IPv4, IP (tos 0x0, ttl  63, id 29304, offset 0, flags [none], length: 28) 192.168.169.26 > 192.168.169.111: icmp 8: echo request seq 35079
21:28:30.320445 00:0b:cd:d6:66:26 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 64: vlan 169, p 0, ethertype ARP, arp who-has 192.168.169.250 tell 192.168.169.26
21:28:30.320459 00:0b:cd:d6:66:26 > 00:d0:b7:20:8f:ee, ethertype 802.1Q (0x8100), length 64: vlan 169, p 0, ethertype IPv4, IP (tos 0x0, ttl  64, id 29307, offset 0, flags [none], length: 28) 192.168.169.26 > 192.168.169.250: icmp 8: echo request seq 35079
21:28:30.320493 00:d0:b7:20:8f:ee > 00:0b:cd:d6:66:e4, ethertype 802.1Q (0x8100), length 46: vlan 168, p 0, ethertype IPv4, IP (tos 0x0, ttl  64, id 15305, offset 0, flags [none], length: 28) 192.168.169.250 > 192.168.169.26: icmp 8: echo reply seq 35079
21:28:30.320531 00:d0:b7:20:8f:ee > 00:0b:cd:d6:66:26, ethertype 802.1Q (0x8100), length 46: vlan 169, p 0, ethertype ARP, arp reply 192.168.169.250 is-at 00:d0:b7:20:8f:ee
(this was captured MAC 00:d0:b7:20:8f:ee).

Possibly, I'm seeing packet leakage from the switches and that is
confusing FreeBSD - definitely the first packet above should not be
visible.

On 2008-Jul-03 09:05:15 +0200, Daniel Ponticello <daniel at skytek.it> wrote:
>i'm having exactly the same problem, but without NAT configuration. Just 
>a simple host on network 192.168.170.xxx
>that when tries to reach an host on 192.168.181.xxx: it gives the same error

Except that in my case, the addresses _are_ local.

On 2008-Jul-03 02:16:30 -0500, David DeSimone <fox at verio.net> wrote:
>My theory is that this is a response to ARP requests.  ARP requests are
>broadcast, so the BSD box hears someone asking for this IP, but cannot
>find it on any local interfaces, and so complains that it cannot
>construct a proper reply.

Except that the address it's complaining about is on a local subnet.
Interestingly, in the above case, the host is spuriously seeing a packet
and has re-routed it via vlan168 - which is the wrong subnet, though the
destination host will still see it there.

On 2008-Jul-03 10:48:22 +0300, Stefan Lambrev <stefan.lambrev at moneybookers.com> wrote:
>I bet 192.168.181.114 have a wrong network mask ;)

You lose.

-- 
Peter Jeremy
Please excuse any delays as the result of my ISP's inability to implement
an MTA that is either RFC2821-compliant or matches their claimed behaviour.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20080703/75bfb0a3/attachment.pgp