Форум на Trinity - Преглед на темата - Споделяне на опит за отстраняване на грешки на Intel Pro адаптери
Отворен технически форум за сървъри и системи за съхранение, клъстерни решения, SAN, NAS.| Текущ час: 09 април 2019 г., 21:12 |
Часова зона: UTC + 3 часа [DST]
Споделям моя опит Почистване на проблеми на Intel Pro адаптери.
| Страница1 от2 | [ Мнения: 19 ] | Отидете на страница1, 2 следваща |
| Предишен тема Следваща предмет |
| Грей Магелан |
Здравейте всички! Искам да споделя опита си при решаването на проблеми, които срещнах при инсталирането на нова версия на драйвера (8.0.57.0) за мрежови адаптери от семейството Intel PRO 1000.
Така. Първоначална ситуация. Има пет сървъра, изградени на дънни платки Supermicro. Описвам модела на дънната платка и модела на мрежовия адаптер (всички адаптери са интегрирани в майката), както и вида на операционната система, инсталирана на компютъра:
сървър 1 и сървър 2: майка - P4DMS-6GM. NIC1 - сървърен адаптер Intel PRO/100 S (82550). NIC2 - мрежова връзка Intel PRO/1000 XT (i82544GC). ОС - сървър 1 - Win2k3, сървър 2 - Win2k
сървър 3: майка - X5DMS-6GM. NIC1 - Intel PRO/100 PCI адаптер (82551). NIC2 - Intel PRO/1000 MT мрежова връзка (i82545EM). ОС - Win2k3
сървър 4: майка - X5DP8-G2. NIC1 - Intel PRO/1000 MT двупортов сървърен адаптер (i82546EB). NIC2 - Intel PRO/1000 MT двупортов сървърен адаптер (i82546EB). ОС - Win2k3
сървър 5: майка- X6DA8-G2. NIC1 - Intel PRO/1000 MT двупортов сървърен адаптер (i82546EB). NIC2 - Intel PRO/1000 MT двупортов сървърен адаптер (i82546EB). ОС - Win2k3
Компютрите имаха драйвери за мрежовите адаптери, които идваха с дънните платки. И така, това означава, че реших да актуализирам всички драйвери, които бяха на сървърите. След като първо инсталирах драйверите на сървър 2 и ги пуснах малко, ги инсталирах на всички останали сървъри. И тук започнаха проблемите. След известно време потребителите започнаха да ме информират, че техните мрежови устройства започнаха да падат, мрежовата среда изчезна и грешки (с интервал от 30 - 60 минути) на услугата на браузъра започнаха да се изливат в регистрационните файлове на сървъра, заявявайки, че не може да получи списък с резервни браузъри (грешки 8032 и 8021) от домейн контролера. Това се случи на всички сървъри с изключение на сървър 2 - той е домейн контролер (и това е най-старият ни сървър между другото - на около година е). Тук в този сървър дневникът беше девствено красив - само информационни съобщения за стартиране - спиране на системата - просто мечта на всеки системен администратор! В крайна сметка, след като проверих всичко, все пак стигнах до заключението, че проблемът не е в услугата на браузъра, а в самата мрежа и, за съжаление, може би в самите адаптери или драйвери на INTEL (о, богове, простете ми, че ви се подигравам). Пропуснете седмица и половина усилено душене и проучване. Ето какво разбрах:
Сървърните мрежови адаптери на Intel използват хардуерни механизми за изчисляване на контролната сума на IP и TCP заглавки, както и хардуерен механизъм за фрагментиране на TCP пакети. И тези механизми не винаги работят правилно.
Случай първи. Типичен тестер на работна станция с 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 контролната сума е равна на 0. И в истински пакет, който отива в мрежата, адаптерът все още въвежда правилно стойността на контролната сума. Не знам защо операционната система игнорира неправилно попълненото поле IP checksum и кой е виновен - Intel или Microsoft. Ето как изчисляването на хардуерната контролна сума на IP хедъра работи във всички изходящи пакети от сървър 2. Това може да се види, ако t-8-8a.cap е филтриран от изпращач: сървър 2, получател: тестов сървър, IP контролна сума: съществува.
Помислете за следващия пакет #2 в t-8-8a.cap, по-специално полето за контролна сума на TCP хедъра. Изчислява се и от хардуерния адаптер. И какво виждаме? След независимо изчисляване на контролната сума, NetMon крещи - Грешка. контролсумата е 0x4BCA и трябва да бъде 0x7DB3. Сега нека видим какво е получил мрежовият адаптер на Testserver. Контролната сума е 0x7DB3. Е, това е наред. Testserver не нулира сесията и отговаря на получения пакет, файлът продължава да се копира по-нататък. Но ми се струва, че подобно небрежно третиране на TCP/IP стандартите от разработчиците на Intel, които правят подобни неща, или разработчиците на Microsoft, чиято операционна система игнорира подобни трикове, е погрешно и неприемливо.
И сега преминавам директно към грешката, която доведе до всичките ми проблеми. За съжаление не мислех да стартирам NetMon на Server 2 по това време, така че ето файла, съдържащ грешката, само от страната на Testserver, добре, няма значение. Можете да го изтеглите от тази връзка: http://dmaltk.narod.ru/12.cap. Обърнете внимание - пакет #1 е заявка за NBT сесия Testserver към сървър 2. В пакет #2 сървър 2 връща положителен отговор. Но контролната сума на TCP хедъра не съвпада с тази, изчислена от операционната система на Testserver. Следователно Testserver отхвърля този пакет като невалиден и изчаква, докато Server 2 препредаде отново грешния пакет. Но Server 2 смята, че пакетът е изпратен успешно, така че не прави нищо и чака отговор от Testserver. След като не изчака отговор от Testserver, Server 2 препредава своя положителен отговор след 3 секунди. Но този път контролната сума на TCP хедъра е изчислена неправилно и Testserver отново изхвърля лошия пакет. Накрая той "не издържа на търпението" и след 3 секунди повтаря молбата си за установяване на NBT сесия отново. След като получи заявката, сървър 2 този път дори изпраща потвърждение (пакет #5), че е получил успешно заявката и имайте предвид, че IP иTCP заглавки. И след още шест секунди и половина той изпраща отговор. Отново TCP контролната сума се изчислява неправилно, така че пакетът отново се отхвърля от Testserver като неизползваем. Накрая тестовият сървър изтича времето за изчакване за установяване на NBT сесия и с пакет № 7 изпраща сървър 2 по дяволите. По този начин, след като седите прави! 10 секунди пред монитора виждам на екрана съобщението на Windows „Timeout semaphore has expired“. Че. Заключих, че има грешка в алгоритъма за изчисляване на контролната сума на TCP хедъра на определени изходящи пакети. Деактивирайки този механизъм в крайна сметка, върнах мрежата в първоначалното й състояние.
Ето какво още имам да кажа. Всички гигабитови адаптери - 82544GC, 82545EM и 82546EB - третират IP хедъра на изходящите пакети по този начин, независимо от версията на драйвера. Но с TCP грешка в контролната сума в изходящите пакети NBT Positive Session Responce, само 82544GC не работи правилно в най-новата версия на драйвера.
Освен това може само да се спекулира. Да предположим, че започвайки с 82544, инженерите на Intel въведоха хардуерни механизми за изчисляване на контролни суми, подобрявайки работата на такива механизми от чип до чип. И в софтуера вероятно първоначално дори не са включили такива опции, защото не бях виждал такива опции със свойствата на адаптера преди. и след като пуснаха няколко поколения чипове и драйвери, те най-накрая са отстранили грешки в тези механизми и са ги активирали напълно по подразбиране в най-новите версии на техните драйвери. Само тези грешки останаха в старите чипове и изскачат, когато хардуерните методи са напълно включени. В крайна сметка един и същ драйвер на 82545 и 82546 работи стабилно. И в по-старите версии на драйвера вероятно не са включени хардуерни механизми и изчисляването на контролните суми се извършва от операционната система, както в случая с прости адаптери. Ето двефайлове, в които един и същи файл се изтегля между две обикновени работни станции:
И накрая, за общото развитие и разбиране на технологията за TCP фрагменти, поддържана от адаптерите на Intel, ето няколко файла, които демонстрират работата на тази функция: