Форум Трініті - Перегляд теми - Ділюсь досвідом Розгрівання глюків Intel Pro адаптерів
Відкритий технічний форум по серверам та системам зберігання даних, кластерним рішенням, SAN, NAS.| Cьогодні: 09 Кві 2019, 21:12 |
Часовий пояс: UTC + 3 години [ Літній час ]
Розподіл глюків Intel Pro адаптерів.
| Сторінка1 із2 | [ Повідомлень: 19 ] | На сторінку1, 2 Слід. |
| Попер. тема Слід. тема |
| 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, фільтрується, і ці результати у вигляді файлів я представляю Вам. Причому немає значення, яка це мати, який адаптер працює на сервері, і яка поточна версія драйвера. У цій ситуації всі адаптери (принаймні стоять у нас) і драйвери діють однаково. Усі апаратні механізми включені за умовчанням.
Порівнявши ці два файли, бачимо цікаву картину в кадрі №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 знову скидає поганий пакет. Зрештою, у нього "не витримує терпіння", і він через три секунди ще раз повторює свій запит на встановлення 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 працює стабільно. А в старих версіях драйвера, мабуть, не задіялися апаратні механізми, і розрахунок контрольних сум виконувався операційною системою, як у простих адаптерів. Ось тут лежать двафайлу, в яких той же файл хитається між двома звичайними робочими станціями:
І, нарешті, для загального розвитку та розуміння технології TCP fragment, яку підтримують інтелівські адаптери, наводжу пару файлів, які демонструють роботу цієї функції: