[<prev] [next>] [day] [month] [year] [list]
Message-id: <1284650487.1858.105.camel@andsee-laptop>
Date: Thu, 16 Sep 2010 17:21:27 +0200
From: Andreas Seelinger <Andreas.Seelinger@...h-aachen.de>
To: netdev@...r.kernel.org
Subject: [Fwd: Problem with arp request caching]
Hi,
imagine the following scenario:
Node A(ath0 ip: 172.16.1.5 | ath1 ip: 10.0.1.5)
Node B(ath0 ip: 172.16.1.6)
Node C(ath0 ip: 10.0.1.7)
Node A <-(ath0)-> Node B
Node A <-(ath1)-> Node C
Node A has no Arp table entries for both nodes.
Actual behavior of two fast ping from Node A to Node C, which looks like
this is a failure of both ping. Even if the second ping SHOULD be
successful.
[ping -I 172.16.1.5 -c 1 -W 1 10.0.1.7; ping -c 1 10.0.1.7;]
The first ping forces three arp request to Node C (device ath1)
[arp who-has 10.0.1.7 tell 172.16.1.5 hardware #778]
All three arp requests cannot be answered by Node C, because it does not
know the IP 172.16.1.5 of Node A. And so the first ping fails.
The second ping should lead to an successful arp request, BUT no
arp request with the source address "10.0.1.5" is sent (because
ARP cache contains a FAIL?)
If I increase the time between the two pings, than the second ping is
successful (probably because the ARP entry timed out)
[ping -I 172.16.1.5 -c 1 -W 5 10.0.1.7; ping -c 1 10.0.1.7;]
Expected behavior would be that the host will redo the ARP request,
if the packet has a different source address. In this case a new
arp request should be performed if the cached one is invalid.
Comments?
Thanks
Andreas
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists