Мережевий адаптер Windows Server 2008 R2 перестає працювати, вимагає жорсткої перезавантаження

Версія TL; DR: виявляється, це була глибока помилка мереж Broadcom у Windows Server 2008 R2. Заміна апаратним забезпеченням Intel виправила це. Ми більше не використовуємо апаратне забезпечення Broadcom. Колись.

Ми використовували HAProxy разом із серцебиттям від проекту Linux-HA. Ми використовуємо два екземпляри Linux для забезпечення відмови. У кожного сервера є власний загальнодоступний IP та єдиний IP, який розділяється між двома за допомогою віртуального інтерфейсу (eth1: 1) за IP: 69.59.196.211

Віртуальний інтерфейс (eth1: 1) IP 69.59.196.211 налаштований як шлюз для серверів Windows за ними, і ми використовуємо ip_forwarding для маршрутного трафіку.

Ми спостерігаємо випадкові відключення мережі на одному з наших серверів Windows за нашими шлюзами Linux. HAProxy виявить сервер в автономному режимі, що ми можемо перевірити, видаливши на збій сервер і спробувавши пінг-шлюз:

Pinging 69.59.196.211 з 32 байтами даних:
Відповідь від 69.59.196.220: Хост призначення недоступний.

Запуск arp -aцього невдалого сервера показує, що немає адреси для шлюзу (69.59.196.211):

Інтерфейс: 69.59.196.220 --- 0xa
Тип фізичної адреси Інтернет-адреси
69.59.196.161 00-26-88-63-c7-80 динамічний
69.59.196.210 00-15-5d-0a-3e-0e динамічний
69.59.196.212 00-21-5e-4d-45-c9 динамічний
69.59.196.213 00-15-5d-00-b2-0d динамічний
69.59.196.215 00-21-5e-4d-61-1a динамічний
69.59.196.217 00-21-5e-4d-2c-e8 динамічний
69.59.196.219 00-21-5e-4d-38-e5 динамічний
69.59.196.221 00-15-5d-00-b2-0d динамічний
69.59.196.222 00-15-5d-0a-3e-09 динамічний
69.59.196.223 ff-ff-ff-ff-ff-ff статичний
224.0.0.22 01-00-5e-00-00-16 статичний
224.0.0.252 01-00-5e-00-00-fc статичний
225.0.0.1 01-00-5e-00-00-01 статичний

На наших екземплярах шлюзу Linux arp -aвідображається:

peak-colo-196-220.peak.org (69.59.196.220) в <incomplete> на eth1
stackoverflow.com (69.59.196.212) о 00: 21: 5e: 4d: 45: c9 [ефір] в еті1
peak-colo-196-215.peak.org (69.59.196.215) о 00: 21: 5e: 4d: 61: 1a [ефір] в еті1
peak-colo-196-219.peak.org (69.59.196.219) о 00: 21: 5e: 4d: 38: e5 [ефір] в еті1
peak-colo-196-222.peak.org (69.59.196.222) о 00: 15: 5d: 0a: 3e: 09 [ефір] на eth1
peak-colo-196-209.peak.org (69.59.196.209) о 00: 26: 88: 63: c7: 80 [ефір] на eth1
peak-colo-196-217.peak.org (69.59.196.217) о 00: 21: 5e: 4d: 2c: e8 [ефір] в еті1

Чому arp час від часу встановлює запис для цього невдалого сервера як <incomplete>? Чи повинні ми статично визначати наші записи arp? Я завжди залишав арпу в спокої, оскільки вона працює 99% часу, але в цьому одному випадку вона здається невдалою. Чи є якісь додаткові кроки щодо усунення несправностей, які ми можемо вжити для вирішення цієї проблеми?

РЕЧІ, ЩО МИ СКЛАДАЛИ

Я додав статичний запис arp для тестування на одному з шлюзів Linux, який все ще не допомагав.

root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1

root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms

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

Обмін мережевими картами та комутаторами

Я помітив, що індикатор посилання на порту комутатора для невдалого сервера Windows працює на 100Mb замість 1Gb на невдалому інтерфейсі. Я перемістив кабель до кількох інших відкритих портів, і посилання вказувало 100 Мбіт для кожного порту, який я спробував. Я також міняв кабель тим самим результатом. Я спробував змінити властивості мережевої картки у вікні та сервері заблокувались та вимагав жорсткого скидання після натискання кнопки застосувати. Цей сервер Windows має два фізичні мережеві інтерфейси, тому я поміняв кабелі та мережеві налаштування на двох інтерфейсах, щоб побачити, чи не відповідає проблема за інтерфейсом. Якщо загальнодоступний інтерфейс знову знизиться, ми будемо знати, що це не проблема з мережевою картою.

(Ми також спробували інший перемикач, який ми маємо під рукою, без змін)

Зміна версій мережевих драйверів апаратних засобів

У нас були ті ж проблеми з останнім драйвером Broadcom, а також із вбудованим драйвером, який постачається в Windows Server 2008 R2.

Заміна мережевих кабелів

Як останнє зусилля канави, ми згадали ще одну зміну, яка відбулася - заміна всіх патч-кордів між нашими серверами / комутатором. Ми придбали два набори, один зелений довжиною 1 фут - 3 фути для приватних інтерфейсів та інший набір червоних кабелів для публічних інтерфейсів. Ми обміняли всі патчі загальнодоступного інтерфейсу на іншу марку і без проблем запускали наші сервери протягом цілого тижня ... aaaaaand тоді проблема повторилася.

Вимкніть завантаження контрольної суми, видаліть TProxy

Ми також намагалися відключити завантаження контрольної суми TCP / IP у драйвері, без змін. Зараз ми витягуємо TProxy і переходимо до більш традиційного x-forwarded-forмережевого розташування без будь-якого фантазійного перезапису IP-адреси. Ми побачимо, чи допоможе це.

Переключити постачальників віртуалізації

З випадкових випадків це було пов’язано з Hyper-V певним чином (ми на ньому розміщуємо VM Linux), ми перейшли на сервер VMWare. Без змін.

Переключити модель хоста

Ми дійшли до кінця мотузки з усунення несправностей і зараз офіційно залучаємо підтримку Microsoft. Вони рекомендували змінити модель хоста:

• http://en.wikipedia.org/wiki/Host_model
• http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

Ми зробили це, і ми також отримали кілька неопублікованих виправлень ядра, які, ймовірно, були перенесені в R2 SP1 2008 року. Немає виправлень.

Заміна апаратного забезпечення мережевої карти

Зрештою, заміна апаратного забезпечення мережі Broadcom на мережеве апаратне забезпечення Intel вирішила цю проблему для нас. Тому я схильний думати, що драйвери Broadcom Windows Server 2008 R2 винні!

http://blog.serverfault.com/post/broadcom-die-mutha/

З http://linux-ip.net/html/ether-arp.html :

Якщо для запитуваного IP-адреса призначення не існує запису кешу ARP, ядро ​​генерує mcast_solicit ARP-запити до отримання відповіді. У цей період відкриття запис кешу ARP буде перерахований у неповному стані. Якщо пошук не вдався після вказаної кількості запитів ARP, запис кешу ARP буде перерахований у невдалому стані. Якщо пошук виявиться успішним, ядро ​​вводить відповідь у кеш ARP та скидає таймери підтвердження та оновлення.

Схоже, ваша скринька шлюзу не відповідає (або відповідає занадто повільно) на запити ARP з вашого шлюзу. Це <incomplete>зрештою переходить на <failed>? Яке мережеве обладнання у вас між сервером і шлюзом? Чи можливо трансляція або блокування запитів ARP десь між двома хостами?

Це означає, що ви ввели пінг-адресу, IP має запис PTR (звідси і назва), але нічого не відповіло з машини, про яку йдеться. Коли ми бачимо це, найчастіше це пов'язано з неправильним встановленням маски підмережі - або у випадку IP-адрес, пов'язаних з інтерфейсом зворотного зв'язку, який випадково був пов'язаний з інтерфейсом et.

Що таке 196,220? Які стосунки це з 196.211? Я припускаю, що .220 є одним з хостів HA Proxy. Коли ви запускаєте ifconfig -a & arp -a на ньому, що вона показує?

Як каже Макс Кларк, <incomplete> просто означає, що 69.59.196.211 подав запит ARP за 69.59.196.220 і ще не отримав відповіді. (У Windows-Land ви побачите це як відображення ARP на "00-00-00-00-00-00" ... Мені здається дивним, BTW, що ви не бачите такого відображення ARP на 69.59.196.220 за 69.59.196.211.)

Я, як правило, не люблю використовувати статичні записи ARP, тому що, на моєму досвіді, ARP взагалі весь час робив свою роботу.

Якби це я, я б обнюхав відповідний інтерфейс Ethernet на "провальній" машині Windows (69.59.196.220), щоб спостерігати його ARP'ing за 69.59.196.211, і спостерігати, як / якщо він відповідає на запити ARP від ​​69.59. 196.211. Я також розглядаю нюхання на машині шлюзу лише для ARP ( tcpdump -i interface-name arp), щоб побачити, як виглядає трафік ARP з боку машини Linux.

Я знаю з блогу , що у вас є бек-енд-мережа та фронтальна мережа. Під час цих відключень чи має "несправний" сервер Windows (69.59.196.220) якісь проблеми з комунікацією з іншими машинами в передній мережі, чи це просто проблеми з розмовою зі своїм шлюзом? Мені цікаво, якщо ви приїжджаєте на несправну машину через передню або задню мережу, коли ви їх ловите в акті.

Що ви робите, щоб "вирішити" проблему, коли вона виникає?

Редагувати:

З Вашого оновлення я бачу, що Ви перезавантажуєте "несправну" машину Windows для вирішення проблеми. Перш ніж зробити це наступним разом, чи можете ви переконатися, що машина Windows взагалі може «говорити» на своєму інтерфейсному інтерфейсі? Також route printпід час відмови також захопіть копію таблиці маршрутизації з машини Windows ( ). (Я намагаюся встановити, чи не працює драйвер NIC / драйвери на машині Windows, в основному.)

Цей документ показує різні стани (таблиця 2.1). Неповний означав би, що він надіслав перший запит ARP (імовірно, після затримки, затримки, зондування), але ще не отримав відповіді.

Причина статичної ARP на хапрокси-вузлі не допомагає в тому, що ваш веб-сервер все ще не може зрозуміти, як повернутися до шлюзу.

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

Чи встановлено будь-яке програмне забезпечення для захисту на несправному веб-сервері? Я провів довгу ніч із сервером Windows 2008, на якому було захищено Symantec Endpoint Security - він встановив деякий код фільтрації в мережевому стеку, який заважав йому взагалі бачити ARP-пакети шлюзу. Виправленням цього (як передбачено Microsoft) було видалення запису реєстру, який завантажував DLL.

В інший раз ця проблема виникла, видалення всього мережевого адаптера з диспетчера пристроїв та перевстановлення, здавалося, допомогло.

Оскільки ви статично встановили архівний запис, ваші сервери знають, де знайти шлюз. Однак якщо ваш комутатор не знає, де знаходиться шлюз, він не пересилатиме ваші пакети.

Здається, у вас поганий (або заплутаний) перемикання між вашими HAproxy і веб-серверами. Перезавантажте його.

Або це, або ваші сервери HAproxy не погоджуються щодо того, який з них контролюється, і обидва відповідають на пошук архів для .211.

За тими ж лініями, якщо ваш перемикач перевантажений, ваші HAproxies можуть не в змозі спілкуватися один з одним досить швидко і не спрацьовують.

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

На вашій машині HAproxy, швидше за все, буде встановлено деякий аромат tcpdump . Для машини Windows вам знадобиться програма WinPCAP , наприклад Wireshark або Microsoft Network Monitor .

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

Приклад синтаксису захоплення для Linux tcpdump (зауважте, я не маю зручної скриньки Linux для перевірки цього; будь-ласка, протестуйте поведінку -C та -W перед використанням у виробництві!):

tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp

Це, сподіваємось, дасть вам певну ознаку того, що саме не вдається. Коли термін дії ARP закінчується (і згідно з цією статтею , новіші версії Windows видають «неактивні» записи дуже агресивно), я очікую, що трапиться таке:

1. Вихідний хост надішле запит ARP до цільового хоста. Запити ARP, як правило, транслюються, але у випадку, коли хост оновлює існуючий запис, ARP може бути надісланий одноадресною.
2. Цільовий хост відповість ARP-відповіддю. У 99% випадків це буде одноадресно, але RFC дозволяє транслювати відповіді. (Докладніше див. Також RFC щодо виявлення зіткнення адреси IPv4 ).

Як це просто звучить, існує маса інших речей, які можуть заважати цьому процесу:

• Оригінальний запит може не надходити до цілі.
• Запит може надходити до цілі, але відповідь може не доходити до джерела.
• Якийсь механізм високої доступності може заважати нормальній поведінці ARP:
  • Як працює відмова між вузлами HAProxy? Чи використовує він спільну MAC-адресу або він використовує безоплатний ARP для відмови IP-адреси між вузлами?
  • Дуже багато MAC-адрес у таблицях ARP починається з 00-15-5D, що, очевидно, зареєстровано в Microsoft. Чи використовуєте ви будь-яку форму кластеризації чи іншу HA на відповідній машині Windows? Ці MAC-адреси 00-15-5D такі ж, як ви бачите, пов’язані з апаратними NIC, коли ви робите 'ipconfig / all' на сервері Windows?

Що потрібно перевірити, чи / коли це повториться:

• Подивіться на захоплення пакетів трафіку ARP; чи якась частина розмови, очевидно, не відбулася?
• Перевірте мостикові / CAM таблиці перемикача; чи всі MAC-адреси, про які йдеться, відображаються на порти, на які ви їх очікуєте?
• Чи мають інші хости в підмережі дійсні записи ARP для IP-адрес обох хостів Windows та HAProxy?
• Чи вирішуються записи ARP для одного і того ж цільового IP на декількох машинах-джерелах на одну MAC-адресу? тобто увійдіть до пари інших хостів у підмережі та переконайтеся, що 196.211 відповідає обом MAC-адресам обох.

У нас була аналогічна проблема з одним із наших сервісів терміналів R2 2008 року, де весь трафік на NIC припинявся, але залишався на зв’язку, а світлодіодні індикатори NIC показували б комунальну смугу. Це питання, що триває, продовжував з'являтися 2-3 рази на тиждень, але лише після 12-13 годин роботи (сервер перезавантажується щоночі).

Я виявив причину Seriousbit Netbalancer після того, як я спробував (з цікавості) припинити послугу NetbalancerService. Потім трафік почав рухатися через інтерфейс. Я з тих пір видалив Netbalancer.

У мене була така ж проблема з ланкою Asus Mainboard. Це було виправлено встановленням останнього драйвера з веб-сайту realtek