Перестает работать сетевой адаптер 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 настроен как шлюз для оконных серверов позади них, и мы используем ip_forwarding для маршрутизации трафика.

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

Пинг 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 static
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) на <не завершено> на eth1
stackoverflow.com (69.59.196.212) в 00: 21: 5e: 4d: 45: c9 [эфир] на eth1
peak-colo-196-215.peak.org (69.59.196.215) в 00:21: 5e: 4d: 61: 1a [эфир] на eth1
peak-colo-196-219.peak.org (69.59.196.219) в 00: 21: 5e: 4d: 38: e5 [эфир] на eth1
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 [эфир] на eth1

Почему arp иногда устанавливает запись для этого отказавшего сервера как <incomplete>? Должны ли мы определять наши записи arp статически? Я всегда оставляю 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 работал на 100 МБ вместо 1 ГБ на отказавшем интерфейсе. Я переместил кабель к нескольким другим открытым портам, и ссылка указала 100 МБ для каждого порта, который я попробовал. Я также поменял местами кабель с тем же результатом. Я попытался изменить свойства сетевой карты в Windows, и сервер заблокировался, и после нажатия кнопки «Применить» потребовалась полная перезагрузка. Этот сервер Windows имеет два физических сетевых интерфейса, поэтому я поменял местами кабели и настройки сети на этих двух интерфейсах, чтобы увидеть, следует ли проблема за интерфейсом. Если общедоступный интерфейс снова выйдет из строя, мы будем знать, что это не проблема с сетевой картой.

(Мы также попробовали другой переключатель, который у нас есть, без изменений)

Изменение версий драйверов сетевого оборудования

У нас была та же проблема с последним драйвером Broadcom, а также со встроенным драйвером, который поставляется в Windows Server 2008 R2.

Замена сетевых кабелей

В качестве последнего усилия мы вспомнили еще одно изменение, произошедшее с заменой всех коммутационных шнуров между нашими серверами / коммутатором. Мы купили два комплекта: один зеленый длиной 1–3 фута для частных интерфейсов и другой комплект красных кабелей для открытых интерфейсов. Мы заменили все соединительные кабели общедоступного интерфейса другой марки и без проблем работали на наших серверах целую неделю ... ааааа, а затем проблема возобновилась.

Отключить разгрузку контрольной суммы, удалить TProxy

Мы также попытались отключить разгрузку контрольной суммы TCP / IP в драйвере, без изменений. Сейчас мы вытаскиваем TProxy и переходим к более традиционному x-forwarded-forсетевому соглашению без какой-либо сложной перезаписи IP-адреса. Посмотрим, поможет ли это.

Переключить провайдеров виртуализации

В случае, если это каким-то образом связано с Hyper-V (на нем мы размещаем виртуальные машины Linux), мы переключились на VMWare Server. Без изменений.

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

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

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

Мы сделали это, и мы также получили некоторые неопубликованные исправления ядра, которые предположительно были добавлены в 2008 R2 SP1. Не исправить.

Замена оборудования сетевой карты

В конечном счете, замена сетевого оборудования 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, ядро ​​будет генерировать запросы ARP mcast_solicit до получения ответа. В течение этого периода обнаружения запись кэша ARP будет отображаться в неполном состоянии. Если поиск не завершится успешно после указанного числа запросов ARP, запись кэша ARP будет отображена в состоянии сбоя. Если поиск действительно успешен, ядро ​​вводит ответ в кэш ARP и сбрасывает таймеры подтверждения и обновления.

Похоже, ваш шлюз не отвечает (или слишком медленно) на ARP-запросы от вашего шлюза. Это в <incomplete>конечном итоге переключиться на <failed>? Какое сетевое оборудование у вас есть между сервером и шлюзом? Возможно ли, что широковещательные ARP-запросы фильтруются или блокируются где-то между двумя хостами?

Это означает, что вы пропинговали адрес, IP-адрес имеет запись PTR (отсюда и имя), но ничего не отвечало с рассматриваемой машины. Когда мы видим это, это чаще всего происходит из-за того, что маска подсети установлена ​​неправильно - или в случае IP-адресов, привязанных к интерфейсу обратной связи, которые вместо этого были случайно привязаны к интерфейсу eth.

Что такое 196,220? Каковы его отношения с 196.211? Я предполагаю, что .220 является одним из хостов прокси-сервера HA. Когда вы запускаете на нем ifconfig -a & arp -a, что это показывает?

Как говорит Макс Кларк, <неполное> означает, что 69.59.196.211 выдал запрос ARP для 69.59.196.220 и еще не получил ответа. (В Windows-land вы увидите это как ARP-отображение на «00-00-00-00-00-00» ... Мне кажется странным, что вы не видите такого ARP-отображения на 69,59,196,220 для 69,59,196,211.)

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

Если бы это был я, я бы прослушал соответствующий интерфейс Ethernet на «сбойной» машине с Windows (69.59.196.220), чтобы наблюдать за ARP'ом для 69.59.196.211, и наблюдать, как / если он отвечает на запросы ARP от 69.59. 196,211. Я также рассмотрел бы прослушивание на машине шлюза только для ARP ( tcpdump -i interface-name arp), чтобы увидеть, как выглядит ARP-трафик со стороны машины Linux.

Из блога я знаю, что у вас есть внутренняя сеть и внешняя сеть. Во время этих сбоев возникает ли у "сбойного" Windows-сервера (69.59.196.220) какие-либо проблемы с подключением к другим машинам в интерфейсной сети, или это просто проблемы с его шлюзом? Мне любопытно, попадете ли вы на неисправный компьютер через интерфейсную или фоновую сеть, когда вы ловите его в действии.

Что вы делаете, чтобы «решить» проблему, когда она возникает?

Редактировать:

Из вашего обновления я вижу, что вы перезагружаете «сбойную» машину Windows, чтобы решить эту проблему. Прежде чем вы сделаете это в следующий раз, можете ли вы убедиться, что машина Windows вообще способна «общаться» по интерфейсу внешнего интерфейса? Также возьмите копию таблицы маршрутизации с машины Windows ( route print) также во время сбоя. (Я пытаюсь выяснить, действительно ли сетевой адаптер / драйвер не работает на Windows-машине.)

Этот документ показывает различные состояния (таблица 2.1). Неполный будет означать, что он отправил первый запрос ARP (предположительно, после устаревания, задержки, исследования), но еще не получил ответ.

Причина, по которой статический ARP на узле haproxy не помогает, заключается в том, что ваш веб-сервер все еще не может понять, как вернуться к шлюзу.

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

У вас установлено какое-либо защитное программное обеспечение на неисправном веб-сервере? Я провел долгую ночь с сервером Windows 2008, на котором был установлен Symantec Endpoint Security - он устанавливает некоторый фильтрующий код в сетевой стек, который вообще не позволяет пакетам ARP видеть шлюз. Исправление для этого (как предусмотрено Microsoft) заключалось в удалении записи реестра, которая загружала DLL.

В другой раз, когда возникла эта проблема, казалось, помогло удаление всего сетевого адаптера из диспетчера устройств и переустановка.

Поскольку вы статически устанавливаете свою запись arp, ваши серверы знают, где найти шлюз. Однако, если ваш коммутатор не знает, где находится шлюз, он не будет пересылать ваши пакеты.

Похоже, у вас плохой (или запутанный) переключатель между вашим HAproxy и вашими веб-серверами. Перезагрузите его.

Либо так, либо ваши HAproxy-серверы не согласны с тем, какой из них находится под контролем, и оба отвечают на запросы arp для .211.

В том же духе, если ваш коммутатор перегружен, ваши HA-прокси могут быть не в состоянии обмениваться данными друг с другом достаточно быстро и при сбое.

В следующий раз, когда возникнет эта проблема, я бы предложил запустить некоторые перехваты пакетов на двух указанных хостах, чтобы определить, какой трафик 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, о которой идет речь? Являются ли эти 00-15-5D MAC-адреса теми же, которые вы видите связанными с аппаратными сетевыми картами, когда вы выполняете 'ipconfig / all' на сервере Windows?

Что нужно проверить, если / когда это произойдет снова:

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

У нас была похожая проблема с одним из наших терминальных серверов 2008 R2, когда весь трафик на NIC останавливался, но оставался подключенным, а светодиоды NIC показывали бы связь. Это была постоянная проблема, которая продолжала появляться 2-3 раза в неделю, но только после 12-13 часов безотказной работы (сервер перезагружался ночью).

Я обнаружил, что причиной стал Seriousbit Netbalancer, после того как я попытался (из любопытства) прекратить службу NetbalancerService. Затем трафик начал двигаться через интерфейс. С тех пор я удалил Netbalancer.

У меня была такая же проблема с локальной сетью Asus. Это было исправлено путем установки последней версии драйвера с сайта realtek