arp/neighbours caching

From: Stéphane Doyon (sdoyon@vipswitch.com)
Date: Thu Aug 03 2000 - 11:04:23 EST


I am puzzled by some behavior of arp (neighbours). I am using kernel
2.4.0-test4 (on x86).

When a machine initiates a connection to a new IP, the "confirmed" time
that is initially set on the entry (when receiving the ARP reply) is
such that the entry is already expired (although it is in the reachable
state). The result is a sort of three-way request-reply series before
things stabilize.

I believe this patch would fix the problem:

--- linux-2.4.0-test4.orig/net/core/neighbour.c Mon Jul 10 01:30:41 2000
+++ linux-2.4.0-test4/net/core/neighbour.c Thu Aug 3 10:15:29 2000
@@ -832,7 +832,8 @@
         if (lladdr != neigh->ha) {
                 memcpy(&neigh->ha, lladdr, dev->addr_len);
                 neigh_update_hhs(neigh);
- neigh->confirmed = jiffies - (neigh->parms->base_reachable_time<<1);
+ if(old&NUD_VALID)
+ neigh->confirmed = jiffies - (neigh->parms->base_reachable_time<<1);
 #ifdef CONFIG_ARPD
                 notify = 1;
 #endif

Is this right?

Without the patch, the behavior is as follows. If A wants to
ping B:
- A sends an ARP request for B's address.
- B makes a stale entry for A and replies.
- A makes B's entry reachable but with a "confirmed" time older than
   reachable_time!
- A sends his ping.
- B sends the echo-reply, and his entry for A goes into NUD_DELAY.
- B eventually sends an ARP request for A.
- A: arp_rcv calls neigh_event_ns and neigh_update (which calls
   neigh_sync) which will make his entry for B stale.
- If A continues sending, B's entry goes into NUD_DELAY.
- A sends yet another ARP request for B!
- B replies.
Now both are in NUD_REACHABLE state for a little while.

I suppose this was not intended?

Also, I don't quite understand some principles of the ARP
implementation:

- Why, when receiving an ARP request from a new host (for who's IP we
   don't have an ARP entry), can we not trust that address and put it
   into NUD_REACHABLE state right away (instead of NUD_STALE)?

- What is the purpose of the systematic 5 seconds delay (NUD_DELAY)
   between the neigh_event_send on a stale entry and sending
   the request? What's the idea behind it?

- What does "_ns" mean in neigh_event_ns?

Please reply directly.

Thanks

-- 
Stéphane Doyon
<sdoyon@vipswitch.com>

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:11 EST