>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 11/15/00, 4:39:07 PM, Mark Spencer <markster@xxxxxxxxxxxxxxxxx> wrote
regarding Re: Neighbour Table Overflow:
> > I have noticed something like this which seems to be related to the ARP
> > cache entry expiring and so the packet can not be delivered. This
> > usually happens somewhere between 12 and 15 seconds. If you hardcode the
> > ARP entries the problems goes away.
> But why is the re-arp taking so long? And I thought ARP entries lived
> much longer than 15 seconds, more like a couple of minutes. Can the time
> be changed? That's still not the solution, certainly. Do arp entries
> get their lives extended if they're used?
Nope, in our test we are blasting packets at the box and they are
expiring (or dropping). It turns out that the device that I was using
for testing only replies to arp at the beginning of the test (so that I
can account for packets exactly). This seems to be just a problem under
linux, other OSes don't seem to have the problem and Cisco routers (et.
al.) don't either. We used the hardcode arp trick to get throught the
> Perhaps what's happening is that the ethernet is getting overrun, and so
> the ARP is getting dropped because the ethernet is flooded. But
> an ARP have some sort of priority?
Nope, not it either. I can generate the same problem with a 1% test
traffic load, so I don't think that it is load related. The odd think is
that it does this at all load levels that we have tested...up to 100%.
We know that it occurs just after the linux box does an arp request at
around 12 secs, but the odd thing is that it makes the request for an
existing arp entry that has an established flow moving through the device
at the same time.