Перестает работать сетевой адаптер 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 иногда устанавливает запись для этого отказавшего сервера как
Вещи, которые мы испытали
Я добавил статическую запись 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!
9 ответов
С 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 и вашими веб-серверами. Перезагрузите его.
Либо так, либо ваши HAproxy-серверы не согласны с тем, какой из них находится под контролем, и оба отвечают на запросы arp для.211.
В том же духе, если ваш коммутатор перегружен, ваши HA-прокси могут быть не в состоянии обмениваться данными друг с другом достаточно быстро и при сбое.
Причина, по которой статический ARP на узле haproxy не помогает, заключается в том, что ваш веб-сервер все еще не может понять, как вернуться к шлюзу.
Статический ARP на веб-сервере лишает ваши веб-серверы возможности переключать шлюзы при сбое одного из узлов haproxy - я предполагаю, что виртуальный интерфейс использует тот же MAC-адрес, что и eth1 узла haproxy, поэтому вам придется код для одного из двух шлюзов в каждый веб-сервер.
У вас установлено какое-либо защитное программное обеспечение на неисправном веб-сервере? Я провел долгую ночь с сервером Windows 2008, на котором был установлен Symantec Endpoint Security - он устанавливает некоторый фильтрующий код в сетевой стек, который вообще не позволял видеть пакеты ARP шлюза. Исправление для этого (как предусмотрено Microsoft) заключалось в удалении записи реестра, которая загружала DLL.
В другой раз, когда возникла эта проблема, казалось, помогло удаление всего сетевого адаптера из диспетчера устройств и переустановка.
В следующий раз, когда возникнет эта проблема, я бы предложил запустить некоторые перехваты пакетов на двух указанных хостах, чтобы определить, какой трафик 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, как представляется, очень агрессивно устаревают "неактивными" записями), я ожидаю, что произойдет следующее:
- Исходный хост отправит запрос ARP целевому хосту. ARP-запросы обычно передаются в широковещательном режиме, но в случае, когда хост обновляет существующую запись, ARP может отправляться в одноадресном режиме.
- Целевой хост ответит 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 коммутатора; do all the MAC addresses in question map to the ports you expect them to?
- Do other hosts on the subnet have valid ARP entries for the IP addresses of both the Windows and HAProxy hosts?
- Do ARP entries for the same target IP on multiple different source machines resolve to the same MAC address? ie log on to a couple of other hosts on the subnet and verify that 196.211 resolves to the same MAC address on both.
У меня была такая же проблема с локальной сетью Asus. Это было исправлено путем установки последней версии драйвера с сайта realtek
У нас была похожая проблема с одним из наших терминальных серверов 2008 R2, когда весь трафик на NIC останавливался, но оставался подключенным, а светодиоды NIC показывали бы связь. Это была постоянная проблема, которая продолжала появляться 2-3 раза в неделю, но только после 12-13 часов безотказной работы (сервер перезагружался ночью).
Я обнаружил, что причиной стал Seriousbit Netbalancer, после того как я попытался (из любопытства) прекратить службу NetbalancerService. Затем трафик начал двигаться через интерфейс. С тех пор я удалил Netbalancer.