Чи варто встановити мережеве обладнання на "автоматичне обговорення" швидкості або фіксовану швидкість?

Нещодавно у нас була невелика проблема з мережею, коли кілька серверів переривались втратою мережевого підключення досить болючим способом вирішення (потрібне жорстке перезавантаження). Це триває близько двох тижнів, здавалося б, навмання, на різних серверах. Немає конкретного шаблону, який би ми могли його розрізнити.

Після деякого заглиблення в нього ми побачили, що комутатор повідомляв про 100 Мбіт / с за проблемний порт:

Це звучить надзвичайно схоже на те, що сталося в статті Джоела Спольського « П’ять віт»

Майкл провів деякий час, роблячи посмертний смерть, і виявив, що проблема - це проста проблема конфігурації на комутаторі. Існує кілька можливих швидкостей, які комутатор може використовувати для зв'язку (10, 100 або 1000 мегабіт / секунду). Можна або встановити швидкість вручну, або ви можете дозволити комутатору автоматично узгоджувати найвищу швидкість, з якою можуть працювати обидві сторони. Невдалий перемикач було встановлено для автоматичного ведення переговорів. Зазвичай це працює, але не завжди, і вранці 10 січня цього не сталося.

Зараз ми відключили автоматичні переговори щодо нашого мережевого обладнання та встановили його на фіксовану швидкість 1000 Мбіт / с (гігабіт).

Мої запитання до тих, хто має більше досвід роботи з серверним апаратним забезпеченням:

1. Наскільки поширені проблеми з автоматичним узгодженням із сучасним мережевим обладнанням?
2. Чи вважається хорошою, стандартною практикою роботи в мережі вимкнути автоматичні переговори та встановити фіксовану швидкість при налаштуванні мереж?

1. Я ще не бачив проблеми з автоматичним узгодженням швидкості мережі, яка не викликана (а) невідповідністю посібника на одному кінці посилання та авто на іншому або (b) несправним компонентом посилання ( кабель, порт тощо).

2. Це залежить від адміністратора, але мій досвід показав мені, що якщо ви вручну вкажете швидкість зв'язку та параметри дуплексу, то ви неодмінно зіткнетеся з невідповідностями швидкості. Чому? Оскільки майже неможливо документувати різні з'єднання між комутаторами та серверами, а потім слідувати цій документації під час внесення змін. Більшість помилок, які я бачив, - це через 1 (а), і ви потрапляєте в цю ситуацію лише тоді, коли починаєте налаштування швидкості / дуплексу вручну.

Як згадується в документації Cisco :

Якщо ви вимкнете автоматичну переговори, вона приховує перепади посилань та інші проблеми фізичного рівня. Відключіть автопоговори лише на кінцевих пристроях, наприклад, на старих гігабітних мережах, що не підтримують автонаповнення Gigabit. Не вимикайте автопоговори між перемикачами, якщо це абсолютно не потрібно, оскільки проблеми з фізичним рівнем можуть залишатися невиявленими та призводити до циклів, що охоплюють дерево.

Якщо ви не готові налаштувати систему управління змінами для змін в мережі, яка вимагає перевірки швидкості / дуплексу (і не забудьте управління потоком) або ви не готові мати справу з випадковими невідповідностями, які виникають внаслідок вручну вказувати ці налаштування на всіх мережевих пристроях, потім дотримуйтесь конфігурації за замовчуванням auto / auto.

Надалі розглянемо моніторинг помилок на портах комутаторів за допомогою MRTG, щоб ви могли помітити ці проблеми, перш ніж виникнуть проблеми.

Редагувати: Я бачу дуже багато людей, які посилаються на збої в переговорах на старому обладнанні. Так, це було давним-давно, коли стандарти створювались, і не всі пристрої дотримувалися їх. Вашим NIC та комутаторам менше 10 років? Якщо так, то це не буде проблемою.

1. Дуже часто, протягом багатьох років у мене виникли численні проблеми з різними видами обладнання.

2. На мою думку, якщо налаштування статичне (тобто серверна стійка), і ви не думаєте, що відбудуться зміни, це гарна ідея встановити швидкості та дуплекси вручну. Поки це добре задокументовано, щоб уникнути майбутніх проблем.

Редагувати:

Щоб уточнити, я не виступаю за використання ручних швидкостей у всій вашій мережі, я б сказав, що 95% часу авто / авто - це шлях. Я просто кажу, що у мене виникли проблеми з дуплекс / швидкістю, і в моїй мережі є невеликі частини (тобто одна з наших серверних стелажів), які мають в основному ручні настройки. Ми працюємо з дуже жорсткою контрольованою локальною мережею з відключенням невикористаних портів та MAC-фільтрами на більшості портів, тому відстежувати швидкість не дуже складно.

Я вважаю, що якщо автопоговори працювали годину на день чи місяць, а потім чомусь "щось трапляється", якщо встановити посилання на фіксовану швидкість "виправляє", існує проблема, яка не вирішується, а замість цього обходить. Я думаю, я бачу встановлення посилання на фіксований як тимчасове рішення, поки справжня проблема не буде усунена.

Отже, кроки з усунення несправностей (припустимо, що ви зупиняєтесь після кожного та чекаєте, коли проблема знову з’явиться):

1. Перевірте журнали на комутаторі, щоб побачити, чи говорить він, чому він використовує 100M.
2. Якщо ви все ще працюєте з цим, вимкніть цю надзвичайно злісну фігню з "балансуванням завантаження Windows", яку Джоел постійно натискає - так це працює, порушуючи кеш комутатора, змушуючи його програмно обробляти кожен пакет. Ваш перемикач призначений для переадресації пакетів в апаратному забезпеченні і має лише центральний процесор, необхідний для того, щоб визначити, який фізичний шлях повинен пройти невідомий потік трафіку (in -> asic -> out), і запрограмувати апаратне забезпечення для цього (читайте: a калькулятор має кращий процесор, ніж ваш комутатор, не робіть дурних речей, які змушують роботу процесора вашого комутатора важче). Урівноваження завантаження Windows працює, змушуючи ваш перемикач приймати це рішення та перевстановлювати кеш-пам'ять для кожного пакету. Це, можливо, не вирішить цю конкретну проблему, але це відвертає мене від подкастів ... Вибачте.
3. Переконайтесь, що налаштування збігаються з обох сторін - це здається, що ви це зробили
4. Помилки Google для autoneg на вашому комутаторі - якщо ви не створили його самостійно, ви не єдиний, хто намагається запустити autoneg на те, що ви використовуєте
5. Замініть кабель номіналом Cat5e або вище - в ідеалі кабель, який ви знаєте, працює, як той, до якого підключена ваша робоча станція. Не намагайтеся використовувати Cat5 або якесь лайно, яке хтось зробив, використовуйте той, у якого фактичні формовані кінці з упаковки.
6. Перемістити порт - Помістіть сервер на інший порт на одному комутаторі
7. Змініть NIC - використовуйте іншу партію, замовлену в інший час

На цей момент ви усунули конфігурацію, фізичні порти, до яких ви підключені, кабелі між ними. Якщо це все ще відбувається, деякі інші причини можуть бути:

1. Прокладка кабелів - будьте обережні щодо перешкод ЕМ від кабелів живлення змінного струму, прокладіть їх по різних сторонах стійки.
2. Охолодження - переконайтеся, що темп навколишнього середовища не такий, як 90 градусів, і ваші картки NIC не потрапляють у якийсь режим "дорогий Боже, дозвольте мені просто передати цей пакет, будь ласка". Я чув, але не бачив, щоб маршрутизатори Cisco перестали робити швидкі комутації та переадресацію пакетів через процесор, наприклад, коли вони перегріваються, наприклад.
3. Замініть перемикач чимось, що не спрацьовує - перевірте, яка пропускна здатність ваших хостів розмовляє за секунду в сукупності, а потім подивіться на номінальну потужність задньої площини вашого комутатора. 7 хостів з потенційних 48, що передають 1,0 Г, достатньо, щоб зупинити Cisco 3750, наприклад. Будьте дуже обережні і щодо постачальників мереж, що входять до компанії cheapo: D-Link, Linksys, Dell, Intel та HP. Ніхто не ставиться до мереж серйозно, не використовує цих хлопців, і не тому, що "ніхто ніколи не звільнявся за використання Cisco", а тому, що "люди пам’ятають, що комутатор Intel, який мав 20/48 портів, вийшов з ладу протягом 2 років" або "Я використовував виключно ProCurve і доречно про те, наскільки злим був Cisco, поки я фактично не використовував Cisco, і тоді я перестав купувати щось менше ". Cisco вважається середнього класупостачальник мережі, так що це говорить вам про хлопців нижче Cisco ...? :-)

Передумови / чому моя відповідь найдивовижніша: я працюю інженером мережі / систем у фінансовій галузі, і ось мій досвід роботи з нашою невеликою глобальною мережею (15 філій, 8 центрів обробки даних):

Усі наші порти локальної мережі працюють автоматично, оскільки ми контролюємо обладнання з обох кінців, і маємо певний доступ до обох сторін --- що може бути таким же простим, як потрапити на телефон до когось і змусити їх перевірити налаштування. Протягом трьох років у мене тільки колись не вийшов один із внутрішніх портів через вихід з ладу, і це було через невдалий кабель --- він відпав після заміни кабелю.

У нас було набагато більше проблем, коли попередники твердо кодували 100 / full у своїх NIC, і не зафіксували цього факту. Скиньте все до автоматичного / автоматичного в наступному віконці і з тих пір не виникало жодних проблем.

На пару місць, де у нас є мідна передача від перевізника для нашої WAN? Ви майже очікуєте, що мідний WAN / Інтернет-зв’язок буде смоктати, весь час --- частково, тому що ви не маєте уявлення, що з іншого боку. Деякий стародавній перемикач Extreme, який має помилкову прошивку для autoneg, але чи позначає MPLS теги? Деякі медіаконвертор у розмірі 5 доларів, тому що крайовий пристрій Ciena у вашого Інтернет-провайдера просто занадто дивовижний, щоб забезпечити Ethernet через виту пару? Вирішіть заздалегідь, як це буде оброблятися, і дотримуйтесь його, тоді очікуйте, що якийсь твіт всередині перевізника змінить його о 10 вечора в суботу, оскільки узгоджена конфігурація ніколи не була задокументована, і у них є певна політика.

Однак серйозно отримайте передачу волокон у свого провайдера.

Мережа, за яку я відповідаю (разом з кількома іншими хлопцями), складається з ~ 40 серверів, 1000+ робочих станцій (розповсюджених у досить великому кампусі) та ~ 1000 WAP-мереж, також розповсюджених на великій території з різними типами та віком мережевого обладнання.

Як сказав dimitri.p, коли щось раптом не вдається зупинити автопоговори, зазвичай це є ознакою іншої проблеми. Встановлення порту вручну схоже на те, щоб покласти пов'язку на когось, хто отримав колоту в кишечнику - це може зупинити кровотечу, але під цим, мабуть, пошкодження.

Мій звичайний контрольний список:

• щось змінилося на машині? водії? Налаштування на рівні ОС або BIOS? Можливо, autoneg був відключений в ОС?
• Ви поміняли патч-кабелі та перевірили, чи працює кабель (якщо це запуск вхідника, ніж одна стійка?)
• Ви перевірили, чи поганий порт комутатора поганий чи несправний?
• може НІК піде погано?

Ми, як правило, ніколи не вимикаємо автоматичну реєстрацію на серверах (або що-небудь ще в центрі обробки даних), якщо це не ситуація, коли всі інші можливі причини були усунені, ми перемістили порти комутаторів, змінили кабелі, протестували NIC і т.д., і немає інший вибір. У такому випадку це задокументується смертю. Це трапляється дуже рідко, і зазвичай із пристроями, до яких ми не можемо отримати доступ, щоб перевірити настройки BIOS та ОС.

З іншого боку, робочі станції та AP - це інша історія. Невдалий автонег - це класичний ознака поганого пробігу кабелю, і багато разів нам доводиться вручну встановлювати швидкість і дуплекс, поки не настане літній сезон, що працює за новим кабелем у стінах.

Це мережевий міф. Наші хлопці в мережі присягаються цією нісенітницею, тому що ще в 1998 році комутатори Bay не домовлялися з Cisco чи що-небудь. Таким чином, замість використання за замовчуванням 99,999% обладнання на Землі, ми маємо цю смішну вправу управління конфігурацією та чудову козлу відпущення для тих часів, коли оновлення драйверів NIC скидає налаштування для автоматичного узгодження і будь-що відбувається.

Це стало більш кумедним, оскільки багато наших серверів використовують такі сумнівні функції, як NIC-об'єднання, які заважають вам втратити доступ до мережі у випадку навряд чи виходу з ладу комутатора, піддаючи вас набагато більшій ймовірності відмови програмного забезпечення. (Водії завжди смокчуть)

На захист хлопців із мережі, безліч серверів працює з драйверами NIC за замовчуванням для Windows, які, як правило, висмоктуються. Якщо у вас є проблеми з автоматичним переговором, і ваше обладнання не входить до адміністрації Клінтона, оновіть ці драйвери NIC.

Вам слід автоматично домовитися. Якщо у вас є перемикач, який не зможе автоматично домовитись надійно, придбайте кращий перемикач.

Гігабіт повинен автоматично домовлятися, і це включає автоматичне виявлення кроссовера (MDI-X).

100baseT гарантовано вийде з ладу, якщо один кінець встановлено в автоматичному режимі, а інший - вручну, і це відповідно до специфікацій. Якщо ви змушуєте один кінець 100 / повний , то інший кінець буде автоматично узгодить 100 / половини, даючи вам дуплексне невідповідність.

Як правило, я встановлюю сервери фіксованими, оскільки я бачив, як мережеве обладнання домовляється до 10 / половина замість 1000 / повно.

Також деякі CoLos встановлюють свої комутатори не для ведення переговорів, а лише для того, щоб робити посилання на 1000 / full.

Вимкнення автоматичних переговорів у неперевіреній початковій конфігурації схоже на програмування вуду - ви щось змінюєте без поважних причин. Якщо після тестування ви побачите, що існує дуплекс або невідповідність швидкості або є непомітні помилки на порту, тоді ввімкніть інше усунення несправностей і, нарешті, виправте конфігурацію, якщо це необхідно.

Під час оновлення драйвера або заміни апаратного забезпечення немає гарантій, що ваші налаштування будуть збережені на стороні сервера.

Встановіть обидві сторони посилання для узгодження або виправлення обох сторін. Коли ви фіксуєте параметри швидкості та дуплексу на деяких пристроях, вони більше не оголошують своїх можливостей своїм колегам. Я не знаю, що говорить стандарт Ethernet про те, що робити, коли одна сторона оголошує про можливості, а інша - ні, і це, ймовірно, означає, що багато реалізаторів теж не знають. Деякі виберуть найнижчий загальний знаменник, який становить 10 половин, а інші вважатимуть, що все гаразд, і підберуть найбільш швидку швидкість.

Є кілька сучасних апаратних засобів, які не підтримують автоматичні переговори про гігабітний мідний Ethernet, як (принаймні деякі) комутатори Cisco з мідними SFP.

Багато років тому я витратив деякий час, працюючи на 3com, займаючись технічною підтримкою майже всієї їх мережевої передачі. Дивовижно, як часто виникало це питання, і це було майже стандартною процедурою, щоб все встановити вручну.

У мене було багато проблем з переговорами з авто. Багато хто, звичайно, означає один раз на кілька місяців, але це одна проблема занадто багато в моїй книзі.

Проблеми з автоматичним узгодженням важко знайти, особливо коли люди, що працюють з мережею, серверами, програмами та базами даних, є чотирма різними командами. Зазвичай останні два витратять багато часу на пересування вперед і назад, звинувачуючи один одного у поганій роботі та брехні про вимірювання, а іноді і підкошують його до людей сервера, які гідно подивляться на вихід "верх" і скажуть, що все добре з сервером.

Це триває до тих пір, поки справа не переростає до того, коли "клопітка" (насправді хтось, хто є загальним професіоналом, і, таким чином, розуміє мережі, апаратне забезпечення, операційні системи, бази даних, рамки та програми) не призначається до проблеми і не виявляє проблему протягом п'яти-десяти хвилин.

Отже, моє власне правило, коли я маю можливість зробити щось із цього, - ВЖЕ Встановити фіксовану швидкість на виробничих серверах, комутаторах та маршрутизаторах. Невиробничі сервери також, якщо вони достатньо відокремлені для людей, які користуються ним, не мають кореневого доступу до нього.

Перемикачі, що працюють з доступом до робочого столу / ноутбука, можна залишити для автоматичного узгодження, і з цього правила є винятки. Зазначимо лише одне, якщо в мережі відбувається чимало змін, краще залишити його на автоматичному режимі та слідкувати за речами.

Ще один момент, який може бути корисним, незалежно від того, який вибір ви зробите щодо автоматичних переговорів , - це контролювати цю річ. Просто налаштуйте Nagios або що-небудь у вас є, щоб слідкувати за станом будь-якого важливого порту. Ви вже стежите за цим мережевим обладнанням, чи не так?

Груба одна. Я бачив, що мікросхеми 100Mb 3com, які не підключатимуться ні до чого, що перевищує 10 Мбіт, якщо ви змусили швидкість або дуплекс. Ви можете отримати повну швидкість, лише дозволяючи їм автоматично вести переговори, навіть якщо в драйвера були налаштування 100Mb Full та наполовину 100Mb.

Багато драйверів NIC не дозволять вам вказати 1000Mb. Єдиний вибір - 10, 100, Авто. Знову змушуючи вас робити Авто, якщо ви хочете на повну швидкість. наприклад, гігантський драйвер Broadcom netXtreme 57xx так поводиться.

Ви можете легко змусити Gigabit на комутаторі, але я думаю, що ви змушені будете дозволити більшості NIC авто домовлятися.

1. З мого досвіду (в основному обладнання 3Com та HP, не багато Cisco), автоматичні переговори не викликають багато проблем.

2. Як і у mrdenny, я зазвичай встановлюю сервери на їх найшвидшу швидкість (у нас їх все ще є 100), повний дуплекс, а потім залишаю вимикач автоматичним. Оскільки у нас суміш швидкостей як на серверах, так і на робочих станціях, я набагато вважаю за краще залишити вимикачі в автоматичному режимі і дозволити їм адаптуватися до кінцевої точки.

У мене були деякі проблеми з автоматичною переговоркою в домашніх умовах, і ця проблема була в проводці, зокрема мережеві кабелі, згорнуті в петлю із занадто малим діаметром або накладання його занадто близько до силових кабелів.

Але я вважаю, що ці пропозиції є занадто банальними для вашого налаштування. ;)

Я нещодавно читав про це в Мережевому воїні від Гері Донахю. Виходячи з цієї книги, щоб автоматичні переговори справно працювали ТАКОЖ перемикач і NIC повинні бути встановлені на автоматичне узгодження. Налаштування NIC на певну швидкість і дуплексний режим та залишення сервера на автоматичному узгодженні буде працювати не правильно - автоматичне узгодження є протоколом, і обидві сторони повинні говорити на ньому, щоб налаштування працювали правильно.

Якщо ви хочете чітко встановити швидкість і дуплексний режим, вам потрібно зробити це на обох кінцях з'єднання.

Cisco обговорює деякі випадки, коли ви, можливо, хочете вручну налаштувати швидкість порту та дуплекс, а не використовувати autonegotiate при використанні пристроїв безпеки PIX / ASA: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/ products_tech_note09186a008009491c.shtml # усунення несправностей

Моє правило - використовувати автоматичні переговори для всього, крім посилань маршрутизатора, якщо у вас конкретно не виникає проблема (наприклад, останні картки Broadcom ... BAH!)

Наприклад, якщо у вас є два маршрутизатори, пов'язані через Ethernet, наприклад, вручну встановіть швидкість на обох кінцях.