Windows 2008 ігнорує безкоштовні ARP-запити

Нещодавно ми побачили проблему після відмови нашого маршрутизатора, коли наші Windows 2008 Boxes не почали спілкуватися з основним маршрутизатором після відмови.

Коли ми робили копання, вони все ще мали запис ARP від ​​вторинного маршрутизатора. Згідно з блогом TechNet, це побічна конструкція:

По-перше, Windows Vista або Windows Server 2008 не оновлюватимуть кеш-пам'ять сусіда, якщо буде отримано трансляцію ARP, якщо вона не є частиною запиту ARP широкомовної передачі для приймача . Це означає, що якщо безплатний ARP надсилається в мережу з Windows Vista та Widows Server 2008, ці системи не оновлюють кеш-пам'ять з невірною інформацією, якщо є конфлікт IP-адреси.

По-друге, виявляється, що кеш-пам'ять кешу Windows (arp-кеш) оновлюється лише в тому випадку, якщо машина більше не може спілкуватися з машиною, яка знаходиться в цьому кеші. Він не надсилає випадкових запитів ARP, щоб переконатися, що кеш не є розмитим. Незважаючи на те, що це не проблема під час початкового відключення, під час відмови назад, коли обидва вікна живі, це призводить до того, що Windows продовжує розмовляти з вторинним вікном.

Чи є який-небудь спосіб змусити 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 з вікна вікна, побачивши, як він отримує арпу в провідній ослінці. Потім я застосував виправлення та повторив тест.

Крім того, здається, що команда arping повинна використовувати не одноадресну MAC-адресу, а широкомовні MAC, оскільки це єдиний тип GARP, який ігнорується в моїх тестах.

Перед виправленням:

При цьому захопленні за допомогою проводів пінг після запиту GARP не надсилається до пункту призначення MAC, з якого прийшов GARP, тож ви можете бачити, що GARP ігнорується.

Після виправлення:

У цьому тесті, після виправлення, запит GARP, як видається, виконується, оскільки пінг надсилається на MAC-адресу, з якої прийшов GARP.

Отже, з цих тестів, схоже, виправлення 2582281 виправляє проблему передач GARP, що ігнорується.

Досліджуючи власну проблему TCPIP зараз, я натрапив на це дуже цікаве виправлення:

http://support.microsoft.com/kb/2582281

Причина:

Ця проблема виникає через те, що стек TCP / IP сервера додатків неправильно ігнорує безоплатні запити протоколу вирішення адреси (ARP).

Це звучить дуже жахливо, як те, в що ти стикаєшся. І це зовсім нове виправлення, випущене 22.07.2011, тому його не було, коли ви вперше натрапили на нього.

Спробуйте, netsh interface ipv4 set interface x basereachable=yде x - індекс інтерфейсу, а y - час очікування ARP в мілісекундах. Не забудьте зробити це з командного рядка з правами адміністратора!

Який перший протокол надмірності скачки ви використовуєте?

Я знаю, що це не відповідає безпосередньо на ваше запитання, проте VRRP (і його власник передвістя, HSRP) використовують спільну MAC-адресу, яка перекидається на новий порт комутатора, коли головний роутер змінюється. Це повністю усуває потребу в безоплатному ARP.

Prereqs
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 відключений на мережевому інтерфейсі, через обмеження на арпування.
4. arping
- http://mathieu.carbou.free.fr/pub/arping/2.06/arping.zip (Windows Binary)

Виконання
1. Отримати ім'я інтерфейсу
- "E: \ Program Files \ Wireshark \ tshark.exe "-D
- З деталей інтерфейсу Wireshark Де 10.20.30.50 є ipaddress, який потрібно повідомити мережі (маршрутизатору)
2. Виконайте arping, щоб надіслати запит ARP
Gratuitous - arping.exe -A -i \ Пристрій \ NPF_ {4399F778-AF25-4B6D-AFFB-A1F2C7DFA667} 10.20.30.50 -c 3 -S 10.20.30.50

Я зіткнувся з цим посиланням з http://blog.serverfault.com/post/windows-2008-and-broken-arp/ .

Якби ви запитали в stackoverflow, ви могли б виправити набагато швидше.

Обнюхуйте пакети GARP та запустіть arp -s inet_addr eth_addr.

Не робіть цього, якщо є найменший шанс отримати ворожу машину у вашій локальній мережі.