On Wed, 17 Aug 2005, [ISO-8859-1] Harald Nordgård-Hansen wrote:
I've run into what probably is a policy decision, but I cannot quite get the reason: When sending TCP traffic to a machine, the first packet will cause an arp request to be made. Later on, this arp entry gets its lifetime extended by the TCP packets, so that it does not have to arp again until the network becomes quiet.
Are you sure? I see some ARP traffic even when there is TCP, and can find no trace of this extending of the neighbor entries in the TCP code (but this does not mean it isn't there)..
The ARP traffic seen is unicast however.
But if i ping the machine, thus sending only ICMP and no TCP traffic, the arp entry will time out every 30-45 seconds, and it has to re-arp for the next packet. As far as I can tell, the ICMP handlers does not update the arp entry, and I really cannot understand why (not).
Probably hasn't been considered important to implement for ICMP, if it is implemented for TCP. But I do have a feeling both ICMP and TCP behaves the same in this regard, and my testing indicates this is the case.
Usually this is not a big problem, it just causes some extra arp traffic. In my case though, we have an application monitoring the arp events trying to do some "smart" stuff wrt. routing etc. And it would be easier if we could assume that an arp entry that disappears does that because there is no traffic using it. :)
Maybe your problem is that the traffic is simply too infrequent causing the entry to expire entirely before the next ICMP is sent?
Regards Henrik - : 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
