At 06:14 PM 8/6/01, Eric A. Hall wrote:
Alex Bligh wrote:
1. RFC826 appears to mandate only positive ARP caching. I can't see a reason why negative ARP caching shouldn't work this way:
Keep only one ARP request in flight at a time. Retry ARPs a maximum of [5] times, separated by at least [1] second. After that, cache non-existance of a h/w address for that IP address for normal positive caching time.
The immediate problem with this is that it requires a *MUCH* larger ARP cache. Rather than needing enough memory for a couple of thousand active entries (the current norm for middle-of-the road routers), you need enough room for every possible address on every attached segment.
[unsubstantiated conjecture] This may be what's killing the cable networks. If they are making room in the NAS ARP caches for the addresses that are being probed, then they are making room by flushing the "real" ARP entries, resulting in a constant flush/load cycle. [/uc, but exemplary of the problem with negative ARP caching.]
Adding to this conjecture, I'm seeing VERY high ARP rates (arp broadcast packets) arriving via the cable modem in my office. Also seeing a high rate of Code Red type attacks attempted at the machines attached. Firewall is just catching and logging them. ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranth.com