On Thu, Apr 05, 2007 at 12:34:21PM -0700, Jeff Haran wrote: > > > > This is happening for exactly thre reason you are describing. > > Arp table entries are use the tuple <ip,dev> as a key for > > matching when lookup up arp table entries. since you are > > receiving arp responses on both interfaces for the same > > subnet, you get two entries for each host on your system (why > > you have 100 entries as opposed to two when you only use 1 > > interface, I'm not sure). > > That's the mysterious part. I am suspecting that the presense of > multiple interfaces on the same network is stimulating some weird > behavior from other hosts on the LAN that is causing this growth in ARP > entries. Guess I'll have to do some tcpdumping to figure that one out, > but its possible it has nothing to do with the other hosts on the LAN > (see below). > Perhaps. As you suggest (and suggest again below), it sounds like tcpdumping is in order. > > In any case, the kernel treats > > each arp packet as a unique entry since they arrived on > > separate interfaces. > > > > > Is there some tweaking down in /proc/sys/net that can make > > this stop? > > You have a few choices: > > > > 1) Don't worry about it. This is clearly a potential > > performance problem, but until something really bad happens, > > it would appear that you are resolving arp entries when you > > need them, and so functionally you should be ok. > > Except that sometimes when the target system starts generating these > messages, I can't communicate with it at all. If I login thru the serial > port and try pinging its default router, no response. If I run arp -a at > that point I see one and only one ARP entry to the default router, > incomplete. This is not easily reproduced and could be unrelated > ethernet link problems. > > > > > 2) Up the gc_thresh[1,2,3] values to support ~100 entries. > > That should allow your arp table to grow to the size it needs > > to be (one entry for each MAC on each interface) and quiesce > > there. It should remove your overflow warning messages. > > These thresholds are set to 128, 512 and 1024, respectively. When I > first ran into this, I started eyeballing the code that generates the > message to figure out where it could be coming from. So I added the > following to net/core/neighbour.c:neigh_alloc(): > > So the output of arp -a is showing 90 or so entries and then all of a > sudden tbl->entries has 1024 in it. Either I am getting stormed with > connections from over 900 hosts on the LAN within the same second, or > there is something funky with how tbl->entries is being maintained when > multiple interfaces are configured on the same net. Again, it sounds like alot more is going on here. definately time for a tcpdump. Almost sounds like you're bridging some frames and their causing some sort of arp storm. Neil - 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
