Сначала немного предыстории: в рассматриваемой (изолированной) / 16 LAN у нас есть несколько устройств, которые поддерживают несколько постоянных TCP-соединений между собой. Программа на каждом конце этих TCP-соединений отправляет своему партнеру «контрольный» пакет каждые две секунды; а также каждая программа отслеживает, когда она в последний раз получила контрольный сигнал: если она не получила контрольный пакет в течение четырех секунд, она определяет, что что-то не так, закрывает TCP-соединение, сообщает о проблеме пользователю, а затем пытается повторно -установить связь.
Также в этой локальной сети есть Linux-сервер, который периодически выполняет следующую команду:
/usr/bin/arp-scan --interface=bond0:2 --localnet --bandwidth=2560
Он делает это, чтобы узнать, есть ли в локальной сети повторяющиеся адреса IPv4; если да, он сообщает о проблеме пользователю.
Это все нормально, за исключением того, что иногда (например, один раз в несколько дней) мы получаем тайм-ауты пульса без очевидной причины, и были некоторые предположения, что arp-сканирование может мешать трафику TCP, так что биения пульса удерживаются достаточно долго, чтобы активировать 4-секундный тайм-аут. Эти события часто происходят ночью, когда локальная сеть более или менее простаивает (за исключением, конечно, пакетов heartbeat и arp-сканирования). Когда происходят эти события, TCP-соединение всегда немедленно и успешно восстанавливается, но возникающие в результате сообщения об ошибках заставляют пользователей нервничать, поэтому я хотел бы разобраться, что здесь происходит.
Мой вопрос: достаточно ли навязчивый механизм сканирования arp-scan, чтобы он мог быть правдоподобным виновником здесь? Обратите внимание, что мы предоставляем параметр --bandwidth = 2560, чтобы он не занимал значительную часть полосы пропускания во время сканирования; но, возможно, пакеты arp вызывают очистку кешей IP-адресов arp <-> или что-то в этом роде?
Лично я бы просто перестал автоматически запускать arp-scan и запустил его вручную несколько раз в течение дня. Дайте ему пару недель и посмотрите, действительно ли arp-сканирование вызывает ваши проблемы, потому что я готов поспорить, что это совершенно не связано.
Я бы также начал tcpdumping с обеих сторон, чтобы вы могли видеть, какие пакеты действительно были отправлены / получены.
Но на самом деле TCP-соединение никогда не будет длиться бесконечно. Если ваше приложение "всегда" может воссоздать соединение, почему вы предупреждаете пользователя? Почему бы просто не воссоздать соединение в автоматическом режиме и выдать ошибку только в том случае, если повторное создание не удалось или вы обнаружите, что создаете более X соединений в час / день?
arp-scan просто отправляет запросы arp-who-has на широковещательный адрес - в любом случае это то, что происходит в сети все время, поэтому у него нет причин мешать каким-либо соединениям.
Даже если кеш ARP хоста переполнится, он просто выдаст запрос arp-who-has самостоятельно перед отправкой IP-пакета - он задержит пакет как минимум на RTT, что на три величины меньше, чем ваш тайм-аут. значение в средах LAN и, следовательно, незначительно.
TCP - не лучший протокол для использования с очень частыми биениями - каждый сегмент (то есть подтверждение), потерянный на канале, задерживает его прием как минимум на одну секунду (минимальное значение тайм-аута повторной передачи). Если потери будут достаточно неудачными и произойдут 2-3 раза подряд на определенной ссылке, вы получите таймауты вашего приложения.
Другим возможным объяснением может быть загрузка хоста, отправляющего контрольные сигналы - если он выполняет некоторые высокоприоритетные задания с высокой насыщенностью, ваши потоки, генерирующие сердцебиение, могут страдать от кратковременной работы. голодание и не получить вовремя сердцебиение.
Поэтому, чтобы точно определить проблему, я бы проверил счетчики уровня канала передачи данных на наличие ошибок или возможного влияния управления потоком, а также счетчики производительности вашего сервера, генерирующего сердцебиение, на предмет возможных узких мест в ЦП или памяти в ночное время. Если ничего подозрительного не обнаружите, просто увеличьте таймаут :)