Huge Arp Cache - Neighbour Table Overflow on IPCOP

Don't they have a support mailing list or website?

I _don't_ use IPCop, so I'm coming from a slightly different direction. An ARP cache that huge is ludicrous. The ARP protocol (RFC0826) is used to "translate" MAC addresses to IPs at the 'link' level. RFC1122 (Requirements for Internet Hosts - Communication Layers) section 2.3.2 _recommends_ that the ARP Timeout be on the order of a minute, but this timeout "SHOULD" be configurable. The default setting in all versions of Linux that I've worked with is one minute.

Thus, the presence of "remote internet-hosts" in the ARP cache might be allowed if the next hop router is proxy-arping (most unusual, and would indicate a routing table mis-configuration on the sending host as well as the unusual setting of proxy-arp by the router). Another possible reason for the presence of such foreign addresses is if the firewall is trying to detect address spoofing.

Yes - 4000 hosts on a single Ethernet collision domain is a bit out of the ordinary.

Yes - there should be no more than ten addresses in the table on the LAN interface, and probably very few more on the next-hop interface. I'd look at the cache to see if there is something unusual. Perhaps

/sbin/arp -a | awk '{ print $4 }' | sort | uniq -c | column

would show how many entries there are for each MAC address. If you have more than a dozen or so entries, I'd be HIGHLY suspicious. As mentioned, this _could_ be an anti-spoofing configuration on the firewall, but if so, there's something wrong with the configuration or the implementation.

Old guy

Attempting to overflow an arp cache is a fairly common method of trying to force switches to fail over into "hub mode" to allow packet sniffing on a switched network.

Not saying that that is what it is but I'd be very suspicious if the cache shows IP addresses or MAC addresses that do not belong on the network.