Итак, сценарий таков, что у нас есть веб-сервер. Перед этим веб-сервером находятся два SonicWalls и два управляемых коммутатора L2 без стекирования. Мы пытаемся найти эффективный способ настроить здесь резервирование на всех уровнях (маршрутизатор, коммутатор, машина) с уже имеющимся у нас оборудованием (так что, пожалуйста, никаких ответов «иди и купи X»). У SonicWalls есть активный / пассивный канал высокой доступности, у коммутаторов ничего нет, а машина имеет двойные сетевые адаптеры, объединенные с одним и тем же IP-адресом (разные MAC).
Таким образом, у каждого маршрутизатора есть ссылка на каждый коммутатор. Коммутаторы имеют магистральный канал между собой, и каждый коммутатор подключен к двойной сетевой карте на ПК. Прямо сейчас избыточность работает так, что я могу отключить связь между маршрутизатором / коммутатором или коммутатором / компьютером, и у меня все еще есть доступ к сети. Для этого я установил ARP flush на 2 минуты на Sonicwalls (минимальное значение) и 60 секунд на коммутаторах). Я могу настроить постоянный PING на машине, а затем удалить одну из ссылок. У меня обычно время простоя 20-30 секунд, а затем снова начинается пинг.
У меня вопрос: каковы негативные последствия такого низкого времени промывки арп. На сервере работает платформа онлайн-тестирования, которую люди используют, и в некоторых случаях они загружают аудиофайлы. Один партнер сказал мне, что если они загружают файл и кеш arp очищен на маршрутизаторе, они потеряют свою загрузку. Насколько я понимаю, с TCP, если он не получит в ответ ACK, он будет повторно отправлять тот же пакет, пока не получит? Учитывая эту информацию, можете ли вы увидеть какие-либо проблемы, с которыми я могу столкнуться?
В сетях, с которыми я работал в прошлом, серверы с избыточными ссылками имели одинаковый MAC-адрес для обоих каналов, этот MAC-адрес использовался для основного трафика на сервер и с сервера, а собственные MAC-адреса использовались для поддержки активности между ссылки. Этот метод устраняет необходимость постоянной очистки кэша ARP.
В любом случае, отвечая на ваш вопрос, да, TCP будет повторять попытку при необходимости, но, вероятно, это не потребуется, потому что устройство, у которого только что был очищен кеш ARP, просто отправит запрос ARP, как это было бы при первой попытке связаться устройство с некэшированным адресом. На коммутаторах, как вы, возможно, знаете, кэш адресов будет повторно заполнен почти мгновенно, потому что он узнает адреса, как только через него будет проходить трафик с неизвестным MAC.