On Monday 15 March 2004 14:44, David S. Miller wrote:
> Your original email was nice in describing the fact that ARP does not
> scale, but you've made no foundation on which to erect a claim that
> scalability for ARP (and thus the added complexity/changes) is even
> necessary.
You are absolutely correct that ARP search performance is not an issue. I
negelected to notice the 'struct dst_entry' mechanism built into sockets and
route table entries. I assumed arp_find() was called for every outbound
packet. Live and learn.
Given that ARP search times make no discernible difference (except when
base_reachable_time is ridiculously low), why not remove the hash complexity
altogether?
The issue that is driving me is that when I set base_reachable_time to a large
value (approx 10 hrs) in order to cut down on ARP traffic in our large,
bridged network, our 2.4.24 core router occaisionally fails to respond to a
ping from only one address for an extended period. It also refuses to route
that address. All other addresses appear to work. If I flush the host address
in question on the core router using 'ip neigh flush', then everybody is fat,
dumb, and happy. Hence my suspicions regarding ARP. This would be much easier
if I could reliably reproduce the problem, but it is devilishly infrequent.
rtg
--
Tim Gardner - timg@xxxxxxx
www.tpi.com 406-443-5357
|