Hi,
We've been running 2.4.27 as routers for some time now with good success.
(Yes, yes, I need to reply to those emails about newer kernels being
slower...) Anyway, I was noticing that neigh_lookup was taking a bunch of
CPU and noticed that the hash table size was fixed to 16 buckets in these
kernel versions...Whoops. 2.4.28 (and 2.6.9) seem to allow for dynamic
growth, which is good.
When looking at other changes made to neighbour.c, I noticed something
which stood out: the minimum hold time for entries was removed. See
these partial chunks from patch-2.4.28:
- - (NEW and probably wrong)
- INCOMPLETE entries are kept at least for
- n->parms->retrans_time, otherwise we could
- flood network with resolution requests.
- It is not clear, what is better table overflow
- or flooding.
...
if (atomic_read(&n->refcnt) == 1 &&
- !(n->nud_state&NUD_PERMANENT) &&
- (n->nud_state != NUD_INCOMPLETE ||
- jiffies - n->used > n->parms->retrans_time)) {
+ !(n->nud_state&NUD_PERMANENT)) {
*np = n->next;
n->dead = 1;
I think this can cause a larger problem than perhaps expected. Because
routers don't keep any reference to neighbour entries other than from the
rtcache, and because routers running BGP with full tables can get
frequent table updates thus toasting the rtcache, I think it can be very
easy for the occasional neigh_forced_gc() run to toast a bunch of active
(but not referenced) ARP entries, causing a bunch of ARP lookup flooding.
Are there any other mechanisms for keeping neigh entries around if the
rtcache is no longer pointing to them? It seems that this could easily
result in a lot of ARP flooding for routers where gc_thresh2 hasn't been
raised above the expected number of entries.
Simon-
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
