Сетевой адаптер Windows Server 2008 R2 прекращает работать, требует "жесткой" перезагрузки

Из http://linux-ip.net/html/ether-arp.html:

Если никакая запись кэша ARP не будет существовать для требуемого целевого IP, то ядро генерирует mcast_solicit запросы ARP до получения ответа. В течение этого периода исследования запись кэша ARP будет перечислена в неполном состоянии. Если поиск не успешно выполнится то после конкретного количества запросов ARP запись кэша ARP будет перечислена в состоянии отказа. Если поиск действительно успешно выполняется, ядро вводит ответ в кэш ARP и сбрасывает таймеры подтверждения и обновления.

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

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

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

Поскольку Max Clark говорит, <неполный> просто средство, которое 69.59.196.211 произвело запрос ARP на 69.59.196.220 и еще не получило ответ. (На земле Windows Вы будете рассматривать это как 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 Server (69.59.196.220), имеют какие-либо проблемы при передаче с другими машинами в сети фронтенда, или это просто имеет проблемы, говорящие с ее шлюзом? Мне любопытно, если Вы приезжаете в провальную машину через фронтенд или сеть бэкенда, когда Вы застаете его на месте.

Что Вы делаете для "решения" вопроса, когда он происходит?

Править:

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

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

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

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

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

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

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

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

Или это или Ваши серверы HAproxy не соглашается, о котором сознает ситуацию, и оба ответа arp поиски для.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? Действительно ли эти 00-15-5D MAC-адреса являются теми же, которые Вы видите связанный с аппаратными средствами NICs, когда Вы делаете 'ipconfig / все' на Windows Server?

Вещи проверить, происходит ли это снова:

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

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

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

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