Bugzilla – Bug 2057
ARP and Ndisc caches should be updated by receiving valid L3 packets
Last modified: 2016-04-04 16:24:48 EDT
Both caches should have their entries updated by "successful" packets received/sent by L4. As an example, if TCP receives an ACK or a data packet from IP X, the ARP / NDISC cache entry should be refreshed. Same for UDP or any other L4 protocol (we should check the RFC for ICMP but I think it applies to that too).
*** Bug 2217 has been marked as a duplicate of this bug. ***
Hello Tomasso; regarding Bug #2217, thank you for your comment, I'm happy to work on an improved patch for this bug #2057.
Created attachment 2365 [details] patch This approach is simple and effective. The only downside is that it *could* have a non-negligible performance hit for nodes that have a lot of entries in their ARP cache.
Created attachment 2366 [details] TCP flow analysis A TCP flow pre and post patch according to Wireshark.
(In reply to Tommaso Pecorella from comment #4) > Created attachment 2366 [details] > TCP flow analysis > > A TCP flow pre and post patch according to Wireshark. Do I understand correctly that the improvement is due to avoiding TCP transmission 'pausing' for new request/reply exchanges every so often? If static ARP entries were used, would the same performance improvement be visible?
(In reply to Tom Henderson from comment #5) > (In reply to Tommaso Pecorella from comment #4) > > Created attachment 2366 [details] > > TCP flow analysis > > > > A TCP flow pre and post patch according to Wireshark. > > Do I understand correctly that the improvement is due to avoiding TCP > transmission 'pausing' for new request/reply exchanges every so often? If > static ARP entries were used, would the same performance improvement be > visible? Correct. And you could see it on UDP as well (for UDP it takes the form of a sudden drop and a peak afterwards, since packets are buffered and theres no timeout). Static ARP have the very same effect, but (again) the ARP entry "pinning" is confirmed by experiments using 3 Linux boxes (source - router - destination). Until the flow is... flowing, the entry is marked as alive. As soon as the flow stops, the entry timeout kicks in and, after 30 seconds (or the configured timeout) it is marked as invalid and then removed. As a side note: yes, pure unidirectional UDP flows are in trouble even with this patch. Alas, this is normal.
(In reply to Tommaso Pecorella from comment #6) > (In reply to Tom Henderson from comment #5) > > (In reply to Tommaso Pecorella from comment #4) > > > Created attachment 2366 [details] > > > TCP flow analysis > > > > > > A TCP flow pre and post patch according to Wireshark. > > > > Do I understand correctly that the improvement is due to avoiding TCP > > transmission 'pausing' for new request/reply exchanges every so often? If > > static ARP entries were used, would the same performance improvement be > > visible? > > Correct. And you could see it on UDP as well (for UDP it takes the form of a > sudden drop and a peak afterwards, since packets are buffered and theres no > timeout). > > Static ARP have the very same effect, but (again) the ARP entry "pinning" is > confirmed by experiments using 3 Linux boxes (source - router - destination). > Until the flow is... flowing, the entry is marked as alive. As soon as the > flow stops, the entry timeout kicks in and, after 30 seconds (or the > configured timeout) it is marked as invalid and then removed. > > As a side note: yes, pure unidirectional UDP flows are in trouble even with > this patch. Alas, this is normal. Agreed; I support merging this patch.
changeset: 12073:c2f388ad2677