Hi, I have a PPC32 based embedded system running linux 2.6.14. It has multiple ethernet interfaces. I find that if I configure two of those interfaces (eth0 and eth1) with separate IPv4 addresses on the same subnet and connect them both to that LAN, the ARP cache on the system seems to grow with ARP entries to other hosts on that subnet. If I run the following script: while [ 1 ]; do sleep 1 arp -a | wc -l done the script will report an ever increasing number of lines in the output of arp -a, until it gets to 100 or so at which point I suspect the neighbor table garbage collection code kicks in and reported number of entries in the ARP cache drops to 2 very quickly. But as soon as that happens, it starts growing again. This is happening in a fairly big lab network so I have no reason to believe that the ARP entries do not correspond to valid hosts on that LAN. When I telnet to them I find they are usually Windows machines. Sometimes, this is accompanied by: "Neighbour table overflow." messages. I suspect this is originating from the garbage collection code where the number of entries in the ARP cache exceeds gc_thresh3 and thus attempts to allocate a neighbor structure fail. But gc_thread3 is 1024 and I have never seen arp -a display anything close to that many entries. Here's an example of it while running the above script: 95 95 96 Neighbour table overflow. Neighbour table overflow. 97 97 98 99 This only occurs when I have the multiple interfaces configured on the same subnet. If I ifconfig one of them down, the content of the ARP cache remains very small (typically 2 though sometimes up to 5 or so). So I suspect this has something to do with ARPs from the same network being received on both interfaces. I note that if I look at the output of arp -a, sometimes a given other host's IP address will be associated with eth0 and sometimes with eth1. But what I don't understand is why the kernel would be caching these ARP entries in the first place. The "Neighbour table overflow." messages are often accompanied by loss of ability to communicate with the system. I'll run arp -a on it and it will show one incomplete ARP entry to the systems's default router. Has anybody ever seen anything like this? Is there some tweaking down in /proc/sys/net that can make this stop? Thanks, Jeff Haran Brocade - To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html