Windows 2008 игнорирует безвозмездные запросы ARP
Недавно мы столкнулись с проблемой после аварийного переключения нашего маршрутизатора, когда наши коробки Windows 2008 не начинали взаимодействовать с основным маршрутизатором после восстановления после сбоя.
Когда мы немного покопались, у них все еще была запись ARP от вторичного маршрутизатора. Согласно Блог TechNet это по замыслу:
Во-первых, Windows Vista или Windows Server 2008 будет не обновлять кеш соседа, если получена широковещательная передача ARP если он не является частью широковещательного запроса ARP для получателя. Это означает, что при отправке бесплатного ARP в сети с Windows Vista и Widows Server 2008 эти системы не будут обновлять свой кеш с неверной информацией, если возникает конфликт IP-адресов.
Во-вторых, похоже, что соседний кеш Windows (arp-cache) обновляется только в том случае, если машина больше не может разговаривать с машиной, которая в данный момент находится в ее кеше. Он не отправляет случайные запросы ARP, чтобы убедиться, что кеш не устарел. Хотя это не проблема во время первоначального переключения при отказе, во время восстановления после отказа, когда оба блока активны, это заставляет окна поддерживать связь с вторичным блоком.
Есть ли способ заставить Windows 2008 принимать беспричинные запросы ARP?
После тестирования кажется, что Исправление 2582281 устраняет проблему. Вы можете получить исправление без необходимости платить за поддержку, используя их страница запроса исправления.
Я проверил это, используя arping и непропатченные окна 2008 R2. Я добавил вторичный IP-адрес 64.34.119.80 к машине, находящейся в том же сетевом сегменте L2. Затем я выполнил следующую команду из отличающийся машина сети (sudo arping -U 64.34.119.80 -I bond0 -c1). Сразу после этого я пропинговал 64.34.119.80 из окна Windows, увидев, что он получил arp в wirehark. Затем я применил исправление и повторил тест.
Кроме того, похоже, что команда arping должна использовать не одноадресный MAC-адрес, а широковещательный MAC-адрес, потому что это единственный тип GARP, проигнорированный в моих тестах.
Перед патчем:
В этом захвате wirehark эхо-запрос после запроса GARP не отправляется MAC-адресу, из которого пришел GARP, поэтому вы можете видеть, что GARP игнорируется.
После патча:
В этом тесте после исправления запрос GARP, похоже, выполняется, поскольку эхо-запрос отправляется на MAC-адрес, с которого пришел GARP.
Таким образом, из этих тестов кажется, что исправление 2582281 устраняет проблему игнорирования широковещательных сообщений GARP.
Только что исследуя свою проблему с TCPIP, я наткнулся на очень интересное исправление:
http://support.microsoft.com/kb/2582281
Причина:
Эта проблема возникает из-за того, что стек TCP / IP сервера приложений неправильно игнорирует беспричинные запросы протокола разрешения адресов (ARP).
Это очень похоже на то, с чем вы столкнулись. И это совершенно новое исправление, выпущенное 22 июля 2011 года, поэтому его не было, когда вы впервые столкнулись с ним.
Какой протокол резервирования первого перехода вы используете?
Я знаю, что это не дает прямого ответа на ваш вопрос, однако VRRP (и его проприетарный предшественник, HSRP) используют общий MAC-адрес, который переключается на новый порт коммутатора при смене главного маршрутизатора. Это полностью избавляет от необходимости в бесплатном ARP.
Пытаться netsh interface ipv4 set interface x basereachable=y где x - это индекс интерфейса, а y - время ожидания ARP в миллисекундах, которое вы хотите. Не забудьте сделать это из командной строки с правами администратора!
Предварительные требования
1. WinPCAP 4.0.1 (версия 4.1.2 не работает)
- http://www.winpcap.org/archive/4.0.1-WinPcap.exe (Версия для Windows)
2. Wireshark 1.6.7
3. IPv6 отключен на сетевом интерфейсе из-за ограничений arping
4. арпинг
- http://mathieu.carbou.free.fr/pub/arping/2.06/arping.zip (Двоичный файл Windows)
Исполнение
1. Получите имя интерфейса
- «E: \ Program Files \ Wireshark \ tshark.exe» -D
- Из деталей интерфейса Wireshark
2. Выполните arping, чтобы отправить бесплатный запрос ARP.
- arping.exe -A -i \ Device \ NPF_ {4399F778-AF25-4B6D-AFFB-A1F2C7DFA667} 10.20.30.50 -c 3 -S 10.20.30.50
Где 10.20.30.50 - это ip-адрес, который вы хотите объявить в сеть (маршрутизатор)
Я столкнулся с этим по ссылке из http://blog.serverfault.com/post/windows-2008-and-broken-arp/.
Если бы вы спросили о stackoverflow, вы могли бы исправить это намного быстрее.
Понюхайте пакеты GARP и запустите arp -s inet_addr eth_addr.
Не делайте этого, если есть малейший шанс получить враждебную машину в вашей локальной сети.