Date: Thu, 3 Oct 2002 14:29:24 -0700 (PDT) From: Mike Hoskins <mike@adept.org> To: stable@freebsd.org Subject: Re: 'losing' every second packet Message-ID: <20021003140708.S74025-100000@fubar.adept.org> In-Reply-To: <853crnvgd2.fsf@stiegl.mj.niksun.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3 Oct 2002, Andrew Heybey wrote:
> > We also run a freebsd firewall at work 4.4-STABLE that works perfectly
> > (uptime 220+ days).
Citing similar configurations, I have a 4.6-STABLE box running
ipfw+natd+keep-state without any problems at home. However, it's an old
p2/300, so I haven't built 4.7 yet (wating for -release).
> Sep 17 13:40:17 celis /kernel: arplookup 10.150.16.1 failed: host is not on local network
<snip>
> option dhcp-server-identifier 10.150.1.2
The last time I saw this was 2-3 years ago. I had some boxes running a
lot of aliases (vhosting). A local gateway had an old "compatability"
alias configured on the local interface because the LAN had been
resubnetted. Arp packets from the old subnet on the gateway would cause
this to be logged on my vhost machines.
Perhaps your subnet is part of a supernet, so your segment's and the
gateway's subnet masks are different - causing the messages you see.
> and since I do NAT with my internal network on net 10, I suspect that
> there is some problem with the dhcp server or router not hearing from
> me often enough and somehow forgetting about me.
It is certainly possible ARP packets are getting lost through
misconfiguration and/or congestion.
From ``arp(4)'':
"ARP caches Internet-Ethernet address mappings. When an interface
requests a mapping for an address not in the cache, ARP queues the
message which requires the mapping and broadcasts a message on the
associated network requesting the address mapping.
...
If the target host does not respond after several requests, the host
is considered to be down for a short period (normally 20 seconds),
allowing an error to be returned to transmission attempts during this
interval. The error is EHOSTDOWN for a non-responding destination
host, and EHOSTUNREACH for a non-responding router."
> Regardless, deleting the arp cache periodcially fixes the problem.
Rather than deleting all entries, does simply re-establishing the
gateway's entry have a simialr effect?
Packet analysis is certainly a useful tool at this point...
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021003140708.S74025-100000>