Делюсь опытом Разгребание глюков Intel Pro адаптеров.

[GrayMagellan]

Здравствуйте все! Хочу поделиться опытом решения проблем, возникших у меня при установке новой версии драйвера (8.0.57.0) сетевых адаптеров семейства Intel PRO 1000.

Итак. Исходная ситуация. Есть пять серверов, построенных на материнских платах Supermicro. Описываю модель материнской платы и модель сетевого адаптера (все адаптеры интегрированы в мать), а также тип операционной системы, стоящей на компьютере:

сервер 1 и сервер 2:
мать - P4DMS-6GM.
NIC1 - Intel PRO/100 S Server Adapter (82550).
NIC2 - Intel PRO/1000 XT Network Connection (i82544GC).
OS - сервер 1 - Win2k3, сервер 2 - Win2k

сервер 3:
мать - X5DMS-6GM.
NIC1 - Intel PRO/100 PCI Adapter (82551).
NIC2 - Intel PRO/1000 MT Network Connection (i82545EM).
OS - Win2k3

сервер 4:
мать - X5DP8-G2.
NIC1 - Intel PRO/1000 MT Dual Port Server Adapter (i82546EB).
NIC2 - Intel PRO/1000 MT Dual Port Server Adapter (i82546EB).
OS - Win2k3

сервер 5:
мать - X6DA8-G2.
NIC1 - Intel PRO/1000 MT Dual Port Server Adapter (i82546EB).
NIC2 - Intel PRO/1000 MT Dual Port Server Adapter (i82546EB).
OS - Win2k3

На компьютерах стояли драйвера сетевых адаптеров, поставлявшихся вместе с материнскими платами. И вот, значит, решил я обновить все драйвера, стоявшие на серверах. Установив сначала драйвера на сервер 2 и погоняв их немного, я установил их на все остальные серверы. И вот тут начались проблемы. Через некоторое время пользователи стали сообщать мне, что у них стали отваливаться сетевые диски, пропадать сетевое окружение, а в логи серверов стали кучей сыпаться ошибки (с интервалом 30 - 60 минут) службы браузера о том, что она не может получить список резервных браузеров (ошибки 8032 и 8021) с контроллера домена. Это происходило на всех серверах, кроме сервера 2 - он является контроллером домена (и это, кстати, наш самый старый сервер - ему уже около года). Вот в этом сервере журнал был девственно красив - одни лишь информационные сообщения о старте - стопе системы - прям мечта любого сисадмина! В конечном итоге, проверив все, я все-таки пришел к выводу, что дело не в службе браузера, а в самой сети, и, как это не печально, возможно, в самих адаптерах или драйверах ФИРМЫ ИНТЕЛ (о боги, простите меня за глумление над вами). Опускаю полторы недели упорного сниффинга и исследований. Вот что я выяснил:

В серверных сетевых адаптерах интел используются аппаратные механизмы подсчета контрольной суммы заголовков IP и TCP, а также аппаратный механизм фрагментации TCP пакетов. И эти механизмы не всегда работают корректно.

Случай первый. Обычная рабочая станция testerver с Realtek 8139 по Fast Ethernet качает файл с сервера. При этом на них обоих запущен Microsoft Network Monitor. Результаты сохраняются в файлы. Затем в каждом файле находится одинаковая сессия TCP, фильтруется, и уже эти результаты в виде файлов я представляю Вам. Причем не имеет значения, какая это мать, какой адаптер работает на сервере, и какая текущая версия драйвера. В этой ситуации все адаптеры (по крайней мере, стоящие у нас) и драйверы, действуют одинаково. Все аппаратные механизмы включены по умолчанию.

http://dmaltk.narod.ru/t-8-ta.cap - со стороны Testserver
http://dmaltk.narod.ru/t-8-8a.cap - со стороны Север 2

MAC адрес "Сервер 2"=003048249093
MAC адрес "Testserver"=000C6E3129C9

Сравнив эти два файла, видим интересную картину в кадре №2 в t-8-8a.cap. Контрольная сумма IP заголовка равна 0, а должна быть равна 0xFD12. Т.е. в отправленном пакете в IP заголовке контрольная сумма равна 0. Кошмар! Ошибка! Неверно сформированный пакет ушел в сеть! Но не будем торопиться. Посмотрим, как этот пакет принял Testserver. Смотрим пакет №2 в файле t-8-ta. Оказывается, в заголовке IP, принятом Testserver, записано правильное значение контрольной суммы - 0xFD12. Это как же получается? Вычислением контрольной суммы занимается адаптер. В тоже время, копия пакета передается наверх - драйверу и операционной системе (и в таком виде он попадает в NetMon). И в этой копии IP checksum равна 0. А в реальном пакете, который уходит в сеть, адаптер все-таки правильно заносит значение контрольной суммы. Не знаю, почему операционная система игнорирует неправильно заполненное поле IP checksum и кто тут виноват - Intel или Microsoft. Так работает функция аппаратного вычисления контрольной суммы IP заголовка во всех исходящих от Сервер 2 пакетах. Это видно, если t-8-8a.cap отфильтровать по отправитель:Сервер 2, получатель: Testserver, IP checksum: exists.

Рассмотрим далее пакет №2 в t-8-8a.cap, а конкретно поле контрольной суммы TCP заголовка. Он тоже рассчитывается аппаратно адаптером. И что мы видим? Самостоятельно рассчитав контрольную сумму, NetMon кричит - Ошибка!!! Контрольная сумма равна 0x4BCA, а должна быть 0x7DB3. А теперь посмотрим, что принял сетевой адаптер на Testserver. Контрольная сумма равна 0x7DB3. Что ж, все правильно. Testserver не сбрасывает сессию и отвечает на принятый пакет, файл и дальше продолжает копироваться... Но мне кажется, что столь вольготное обращение со стандартами TCP/IP разработчиков из Intel, которые делают такие вещи, или разработчиков Microsoft, у которых операционная система пропускает мимо ушей такие трюки, неправильно и недопустимо.

А вот теперь я перехожу непосредственно к ошибке, приведшей ко всем моим проблемам. К сожалению, я тогда не догадался запустить NetMon на Сервер 2, поэтому здесь представлен содержащий ошибку файл, только со стороны Testserver, ну да это неважно. Вот по этой ссылке его можно скачать: http://dmaltk.narod.ru/12.cap. Обратите внимание - пакет №1 - запрос на NBT сессию Testserver к Сервер 2. В пакете №2 Сервер 2 возвращает положительный ответ. Но контрольная сумма TCP заголовка не совпадает с той, которую рассчитывает операционная система на Testserver. Поэтому Testserver отбрасывает этот пакет, как непригодный, и ждет, пока Сервер 2 не ретранслирует ошибочный пакет. Но Сервер 2 считает, что пакет отправлен успешно, поэтому ничего не предпринимает и ждет ответа от Testserver. Не дождавшись ответа от Testserver Сервер 2 через 3 секунды повторно передает свой положительный ответ. Но и в этот раз контрольная сумма TCP заголовка рассчитана неверно, и Testserver опять сбрасывает плохой пакет. Наконец, у него "не выдерживает терпение", и он через 3 секунды еще раз повторяет свой запрос на установление NBT сессии. Получив запрос, Сервер 2 на этот раз даже высылает подтверждение того (пакет №5), что он успешно получил запрос, и, обратите внимание - здесь правильно рассчитаны IP и TCP заголовки!!! И еще через шесть с половиной секунд присылает ответ. И снова TCP контрольная сумма рассчитана неверно, так что пакет опять Testserver'ом отбрасывается как непригодный. Наконец, у Testserver'а кончается таймаут на установление NBT сессии, и пакетом №7 он Сервер 2 посылает куда подальше. Таким образом, просидев ровно! 10 секунд перед монитором, я вижу на экране сообщение Windows "Timeout semaphore has expired". Т.о. я сделал вывод, что в алгоритме расчета контрольной суммы TCP заголовка определенных исходящих пакетов есть ошибка. Отключив в конце концов именно этот механизм, я вернул сеть в исходное состояние.

Вот что я еще должен сказать. С IP заголовком исходящих пакетов так обращаются все гигабитные адаптеры - 82544GC, 82545EM и 82546EB, вне зависимости от версии драйвера. А вот с ошибкой контрольной суммы TCP в исходящих пакетах NBT Positive Session Responce неверно работает только 82544GC именно в последней версии драйверов.

Дальше можно только предполагать. Положим, начиная с 82544 инженеры Intel внедряли аппаратные механизмы расчета контрольных сумм, улучшая от чипа к чипу работу таких механизмов. И в программном обеспечении, наверное, поначалу даже и не включали такие опции, потому что раньше таких опций я с свойствах адаптера не видел. а выпустив несколько поколений чипов и драйверов, они наконец отладили эти механизмы и полностью их включают по умолчанию в последних версиях своих драйверов. Только ошибки эти в старых чипах остались и всплывают при полном включении аппаратных методов. Ведь тот же драйвер на 82545 и 82546 работает стабильно. А в старых версиях драйвера, наверное, не задействовались аппаратные механизмы, и расчет контрольных сумм выполнялся операционной системой, как в случае простых адаптеров. Вот здесь лежат два файла, в которых тот же файл качается между двумя обычными рабочими станциями:

http://dmaltk.narod.ru/t-6-ta.cap - трафик на приемнике
http://dmaltk.narod.ru/t-6-6a.cap - трафик на передатчике.

И, наконец, для общего развития и понимания технологии TCP fragment, которую поддерживают интеловские адаптеры, привожу пару файлов, которые демонстрируют работу этой функции:

http://dmaltk.narod.ru/t-9-ta.cap - трафик на приемнике
http://dmaltk.narod.ru/t-9-9a.cap - трафик на передатчике.

Посмотрите на пакет №10 в t-9-9a.cap и посмотрите, как он принимается на удаленной стороне. Операционной системе кажется, что она отправила TCP пакет объемом 61503 байта, а на самом деле адаптер самостоятельно формирует кучу пакетов стандартным объемом 1460 байт, которые и принимает Testserver. Дурят разработчики Intel Windows как хотят ! И никаких Jumbo-пакетов не надо!!!

[Stranger03]

Отключив в конце концов именно этот механизм, я вернул сеть в исходное состояние.

Спасибо, очень познавательно. Не подскажете, этот режим отключается в настройках сетевой карты в винде? Как он называется точно?

[GrayMagellan]

Подскажу, конечно. После установки драйверов идем в свойства сетевого адаптера, на закладку Advanced, и там они все перечислены. Либо, если установлена управляющая утилита Intel PRO Set, смотрим эти параметры там.

Offload Receive IP Checksum - аппаратный расчет контрольной суммы IP заголовка при приеме.
Offload Receive TCP Checksum -аппаратный расчет контрольной суммы TCP заголовка при приеме.
Offload Transmit IP Checksum - аппаратный расчет контрольной суммы IP заголовка при передаче.
Offload Transmit TCP Checksum - аппаратный расчет контрольной суммы TCP заголовка при передаче.

Offload TCP Segmentation - разбиение крупных TCP пакетов на более мелкие самим адаптером.

После внесения изменений адаптер драйвер адаптера перезапускается!!!

По умолчанию все механизмы включены. И еще. 82544GC TCP fragment не поддерживает, поэтому такой опции в его свойствах нет.
Кстати, к расчету контрольных сумм принимаемых пакетов претензий нет.

[Stranger03]

Подскажу, конечно.

Сенкс, это полезная инфа, предлагается это внести в FAQ.

[Oleg2]

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

---10/11/2004 7:38:36 AM--------cut----------------------------------
Oleg,

There is a setting in PROSet driver named Adaptive Inter-frame Spacing, which is set on by default. This feature may conflict with other networking equipment which do not support it, i.e. switches. So, the first thing to try to do is to disable this setting.
If that helps - good; if not, another thing worth trying is disabling all settings responsible for calculating checksums, which are also enabled by default.
Please follow up on the results.

Thanks,
Konstantin
---------------------------------cut-------------------------------------
---10/21/2004 6:57:10 AM---cut-------------------------------------
Oleg,
We are currently waiting for an update from our Engineering team. On the Pro/1000XT the offloading checksum was a known hardware issue, which is not going to be fixed on that card. You should not have encountered this on the Pro/1000MT cards.
Again, to avoid the problem on XT card, please follow recommendations provided in the previous updated.
Could you please specify if the problem was faced on MT cards as well, because in the original report they were mentioned at the very bottom, and it is not completely clear if the problem persists or not.
Thanks,
Konstantin
---------------------------------cut---------------------------------------


Ну и сегодня упала напоминалка, что они ждут подтверждения
выполнения  их рекомендаций с результатами.

[GrayMagellan]

Ну не знаю... Причем здесь может быть Adaptive Interframe Spacing? Этот термин я перевожу как самоподстраивающийся интервал между пакетами. К проблеме неверного исчисления контрольной суммы это не должно иметь никакого отношения... Или я неправ? Я могу, конечно, попробовать выключить опцию Adaptive Interframe Spacing и опять включить Offload Transmit TCP Checksum, но мне кажется, что это не должно повлиять.

Кроме того, посмотрите на текст ответа специалистов Intel:

"On the Pro/1000XT the offloading checksum was a known hardware issue, which is not going to be fixed on that card. You should not have encountered this on the Pro/1000MT cards."

Т.е. они фактически признают наличие аппаратной проблемы в этой серии чипсетов (82544). Так что смысл менять опять настройки? Я и тогда уже догадывался, что это именно аппаратная проблема, и надо просто знать о ней. А насчет того, что специалисты Intel интересуются, есть ли такая проблема на 82545 и 82546, то я с этой проблемой на этих адаптерах не столкнулся, хотя еще раз хочу повторить - адаптеры не сообщают операционой системе рассчитанные ими контрольные суммы. У меня есть мысль относительно того, что поле контрольной суммы TCP отправляемого пакета равно нулю потому, что операционная система знает, что это поле рассчитывается непосредственно процессором адаптера после того, как пакет передается ему программой драйвера. Поэтому сама операционная система оставляет эти поля равными нулю. И ошибка неверного расчета контрольной суммы TCP лежит, скорее всего, в микропрограмме процессора 82544. Еще раз повторю, что так работают все вышеперечисленные адаптеры, но с ошибкой я столкнулся только в 82544GC. Надеюсь, такой ответ удовлетвоит инженеров фирмы Intel.

[Oleg2]

Ну не знаю... Причем здесь может быть Adaptive Interframe Spacing? Этот термин я перевожу как самоподстраивающийся интервал между пакетами. К проблеме неверного исчисления контрольной суммы это не должно иметь никакого отношения... Или я неправ? Я могу, конечно, попробовать выключить опцию Adaptive Interframe Spacing и опять включить Offload Transmit TCP Checksum, но мне кажется, что это не должно повлиять.

Кроме того, посмотрите на текст ответа специалистов Intel:

"On the Pro/1000XT the offloading checksum was a known hardware issue, which is not going to be fixed on that card. You should not have encountered this on the Pro/1000MT cards."

Т.е. они фактически признают наличие аппаратной проблемы в этой серии чипсетов (82544). Так что смысл менять опять настройки? Я и тогда уже догадывался, что это именно аппаратная проблема, и надо просто знать о ней. А насчет того, что специалисты Intel интересуются, есть ли такая проблема на 82545 и 82546, то я с этой проблемой на этих адаптерах не столкнулся, хотя еще раз хочу повторить - адаптеры не сообщают операционой системе рассчитанные ими контрольные суммы. У меня есть мысль относительно того, что поле контрольной суммы TCP отправляемого пакета равно нулю потому, что операционная система знает, что это поле рассчитывается непосредственно процессором адаптера после того, как пакет передается ему программой драйвера. Поэтому сама операционная система оставляет эти поля равными нулю. И ошибка неверного расчета контрольной суммы TCP лежит, скорее всего, в микропрограмме процессора 82544. Еще раз повторю, что так работают все вышеперечисленные адаптеры, но с ошибкой я столкнулся только в 82544GC. Надеюсь, такой ответ удовлетвоит инженеров фирмы Intel.

И всё-таки, коллега, я был бы Вам признателен, если бы Вы попробовали выполнить просьбу (рекомендацию) инженеров Интел. Допустите такую вещь, что, может быть, им не хватает информации, для того, чтобы переписать низкоуровневую часть драйвера...

Насколько я помню, интеловские сетевые контроллеры всегда отличались именно тем, что у них был подгружаемый драйвером микрокод.

[Stranger03]

И всё-таки, коллега, я был бы Вам признателен, если бы Вы попробовали выполнить просьбу (рекомендацию) инженеров Интел. Допустите такую вещь, что, может быть, им не хватает информации, для того, чтобы переписать низкоуровневую часть драйвера...

Насколько я помню, интеловские сетевые контроллеры всегда отличались именно тем, что у них был подгружаемый драйвером микрокод.

Знаете, я бы добавил немного туману в эту переписку, сказав так, что когда мой контроллер был подключен к 3Com BaseLine, то наблюдались именно такие проблемы. Я одно время просто лечил понижением со 100 на 10Мб, не догадался проанализировать трафик. Однако тут же, переткув линк на Intel свич, получил нормальные 100Мб.
Ну и уж самое распоследнее, похожие глюки я наблюдал на банальной RTL8139 подключенной к тому же 3Com BaseLine SuperSwitch. Так что возможно какие-то несовместимости карта - свитч..

[GrayMagellan]

Окей, давайте проверим... Чем черт не шутит. Я поменял настройки адаптеров на обоих серверах, где стоит 82544GC адаптер. Завтра будет видно, как они себя поведут.

[GrayMagellan]

Гм... Все работает нормально. За ночь никаких происшествий в сети не было. Все тихо-спокойно. Включение Offload Transmit TCP Checksum при выключенной Adaptive Inter-frame Spacing не привело к возникновению ошибок расчета контрольных сумм. Значит, это действительно помогает. Но вместе они не живут... Олег, а вы не могли бы спросить у инженеров Интел, что быстрее - Offload Transmit TCP Checksum=on, Adaptive Inter-frame Spacing=off или Offload Transmit TCP Checksum=off, Adaptive Inter-frame Spacing=on?

И еще информация. Инженеры Интел говорят, что Adaptive Inter-frame Spacing может конфликтовать со многими коммутаторами. Если это так, то я скажу модель нашего коммутатора. Кому-нибудь это может пригодиться - D-Link DGS-1008D. Возможно, что глюки действительно возникли из-за него.

[Oleg2]

Ещё один вопрос:

Возможно ли поиграться с этими же настройками на серверах, где стоят другие сетевые чипы?
P.S.К сожалению, пока ответа на Ваши дополнительные вопросы нет.

[alexisl]

Такой же глюк на  X5DPA-GG  чипсет сетевого контроллера - Intel82541
Причем если отключить Adaptive Inter-frame Spacing (а он и выключен по умолчанию) все равно идут баги, пока полностью не отключиш все расчеты контрольных сумм TCP и IP. Ставил разные дрова - таже бойда. Правда на другом серваке стакой-же конфигурацией\ОС\дровами  все работает ок. Получается что мама - маме рознь?

[Stranger03]

бойда. Правда на другом серваке стакой-же конфигурацией\ОС\дровами  все работает ок. Получается что мама - маме рознь?

Скорей всего сетевой контроллер - контроллеру рознь. Наблюдал такое много раз именно с интеловскими сетевухами. Удавалось просто подобрать коммутатор, с которым данная сетевуха работает. Например - интел - интел.

[art]

неприятности с em драйвером под FreebSD 5.3 на встроеных сетевых картах мат. платы P4SCT+.

http://www.freebsd.org/cgi/query-pr.cgi?pr=72933

Проявляется в полный рост даже без использования VLAN.
Запуск tcpdump или любой программы, переводящей интерфейс в promisc mode приводит к тихому drop пакетов.

Проверяю зависимость от версии BIOS и попробую поднять систему до STABLE или CURRENT.

[tommi]

Все вышесказанное очень интересно. Особенно доскональное исследование работы сетевых адаптеров Intel.
Однако садить сервера на D-Link DGS-1008D, а потом говорить, о том что чтото не так работает, не есть хорошо. Не надо смешивать сектор SOHO и Corp. ed. Может следовало подумать о замене D-Link DGS-1008D на нечто более серьезное (3Com,  HP, Cisco).
У нас в сети стоят только сетевухи Intel (на серверах и рабочих местах), проблем с новыми драйверами нет.