Недавно мы столкнулись с проблемой после сбоя нашего маршрутизатора, когда наши боксы 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неустановленной Windows 2008 R2. Я добавил дополнительный IP-адрес 64.34.119.80 к машине с тем же сегментом сети L2. Затем я выполнил следующую команду с другого компьютера сети (sudo arping -U 64.34.119.80 -I bond0 -c1). Сразу после этого я выполнил команду 64.34.119.80 из окна Windows, увидев, что он получает arp в wireshark. Затем я применил исправление и повторил тест.Кроме того, кажется, что команда arping должна использовать не MAC-адрес одноадресной рассылки, а широковещательный MAC-адрес, поскольку это единственный тип GARP, игнорируемый в моих тестах.
Перед патчем:
В этом захвате Wireshark пинг после запроса GARP не отправляется в пункт назначения MAC, из которого поступил GARP, поэтому вы можете видеть, что GARP игнорируется.
После патча:
В этом тесте после исправления запрос GARP кажется выполненным, поскольку пинг отправляется на MAC-адрес, с которого поступил GARP.
Таким образом, похоже, что из этих тестов исправление 2582281 исправляет проблему игнорирования широковещательных сообщений GARP.
источник
При исследовании собственной проблемы TCPIP я наткнулся на это очень интересное исправление:
http://support.microsoft.com/kb/2582281
Это звучит очень похоже на то, с чем вы сталкиваетесь. И это совершенно новое исправление, выпущенное 22.07.2011, поэтому его не было, когда вы впервые столкнулись с ним.
источник
Попробуйте,
netsh interface ipv4 set interface x basereachable=yгде x - это индекс интерфейса, а y - время ожидания ARP в миллисекундах, которое вы хотите. Не забудьте сделать это из командной строки с правами администратора!источник
Какой протокол резервирования первого скачка вы используете?
Я знаю, что это не отвечает на ваш вопрос напрямую, однако VRRP (и его собственный предшественник, HSRP) используют общий MAC-адрес, который переключается на новый порт коммутатора при смене главного маршрутизатора. Это полностью избавляет от необходимости безвозмездного 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. arping
- 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.
Не делайте этого, если есть самый маловероятный шанс получить враждебную машину в вашей локальной сети.
источник