First a little background: On the (isolated) /16 LAN in question, we have several devices that keep several persistent TCP connections open between them. The program at each end of these TCP connections sends a "heartbeat" packet to its partner once every two seconds; and also each program keeps track of when it last received a heartbeat: if it hasn't received a heartbeat packet for four seconds, it figures something is wrong, closes the TCP connection, reports a problem to the user, and then tries to re-establish the connection.
Also on this LAN is a Linux box that runs the following command periodically:
/usr/bin/arp-scan --interface=bond0:2 --localnet --bandwidth=2560
It does this to find out if there are any duplicate IPv4 addresses on the LAN; if so, it reports the problem to the user.
This is all fine, except that occasionally (e.g. once every few days) we get heartbeat-timeouts for no obvious reason, and there has been some speculation that the arp-scan may be interfering with the TCP traffic such that the heartbeats are getting held off long enough to trigger the 4 second timeout. These events often happen at night, when the LAN is more or less idle (except for the heartbeat packets and the arp-scan, of course). When these events occur, the TCP connection is always immediately and successfully re-established, but the resulting error messages are making the users nervous, so I'd like to figure out what is going on here.
My question is: is arp-scan's scanning mechanism intrusive enough that it might plausibly be the culprit here? Note that we supply a --bandwidth=2560 parameter so that it shouldn't use up a significant amount of bandwidth during the scan; but perhaps the arp packets cause the arp<->IP address caches to be flushed, or something like that?