Должно ли сетевое оборудование быть настроено на автоматическое согласование скоростей или фиксированных скоростей?

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

Немного покопавшись в этом, мы увидели, что коммутатор сообщает 100 Мбит / с для проблемного порта:

Это удивительно похоже на то, что произошло в статье Джоэла Спольски Five Whys.

Майкл провел некоторое время после вскрытия и обнаружил, что проблема заключается в простой проблеме конфигурации коммутатора. Существует несколько возможных скоростей, которые коммутатор может использовать для связи (10, 100 или 1000 мегабит в секунду). Вы можете установить скорость вручную или позволить коммутатору автоматически согласовывать максимальную скорость, с которой могут работать обе стороны. Неисправный коммутатор был настроен на автосогласование. Обычно это работает, но не всегда, а утром 10 января этого не произошло.

Теперь мы отключили автосогласование на нашем сетевом оборудовании и установили фиксированную скорость 1000 Мбит / с (гигабит).

Мои вопросы к тем, кто обладает большим опытом работы с серверным оборудованием:

1. Насколько распространены проблемы автоматического согласования с современным сетевым оборудованием?
2. Считается ли хорошей стандартной сетевой практикой отключать автосогласование и устанавливать фиксированные скорости при настройке сети?

1. Я до сих пор не видел проблему с автоматическим согласованием скорости сети, которая не вызвана (а) несоответствием руководства на одном конце ссылки и авто на другом или (б) неисправным компонентом ссылки ( кабель, порт и т. д.).

2. Это зависит от администратора, но мой опыт показал мне, что если вы вручную укажете скорость соединения и настройки дуплекса, вы обязательно столкнетесь с несоответствиями скорости. Почему? Потому что практически невозможно документировать различные соединения между коммутаторами и серверами, а затем следовать этой документации при внесении изменений. Большинство сбоев, которые я видел, вызваны 1 (a), и вы попадаете в эту ситуацию только тогда, когда начинаете вручную устанавливать настройки скорости / дуплекса.

Как упомянуто в документации Cisco :

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

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

В будущем рассмотрите возможность мониторинга ошибок на портах коммутатора с помощью MRTG, чтобы вы могли определить эти проблемы до того, как возникнут проблемы.

Изменить: я вижу много людей, ссылающихся на сбои переговоров на старом оборудовании. Да, это было проблемой давным-давно, когда создавались стандарты, и не все устройства следовали им. Ваши сетевые карты и коммутаторы менее 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.0G, достаточно, чтобы остановить Cisco 3750. Также будьте очень осторожны с дешевыми сетевыми поставщиками: D-Link, Linksys, Dell, Intel и HP. Никто не относится к этим сетям всерьез, не потому, что «никто не был уволен за использование Cisco», а потому, что «люди помнят, что коммутатор Intel с 20/48 портами выходил из строя в течение 2 лет» или «я использовал исключительно ProCurve и рассказывай о том, насколько злой был Cisco, пока я фактически не использовал Cisco, после чего я перестал покупать что-либо меньшее ». Cisco считается средним уровнемпоставщик сети, так что это говорит вам о парнях ниже Cisco ...? :-)

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

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

У нас было гораздо больше проблем, когда предшественники жестко закодировали 100 / full на своих сетевых картах и ​​не документировали этот факт. Сбросьте все на auto / auto в следующем окне и с тех пор проблем с ними не было.

В тех местах, где у нас есть медная передача от оператора для нашей глобальной сети? Вы должны ожидать, что медное соединение WAN / Internet будет сосать постоянно - отчасти потому, что вы не знаете, что находится на другой стороне. Какой-то древний экстремальный переключатель, который, как оказалось, имеет глючную прошивку для autoneg, но поддерживает ли MPLS тегирование? Какой-нибудь медиаконвертер за 5 долларов, потому что граничное устройство Ciena вашего интернет-провайдера за $ 200 тыс. Просто слишком круто для обеспечения Ethernet по витой паре? Заранее решите, как это будет обрабатываться, и придерживайтесь его, а затем ожидайте, что какой-то дурак внутри оператора изменит его в 22:00 в субботу, потому что согласованный конфиг никогда не был задокументирован, и у них есть некоторая политика, которой необходимо следовать.

Серьезно, однако, получить передачу волокна от вашего интернет-провайдера.

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

Как сказал dimitri.p, когда что-то внезапно не может прекратить автосогласование, это обычно указывает на другую проблему. Установка порта вручную подобна наложению повязки на человека, которому нанесли удар в кишку - это может остановить кровотечение, но под ним наверняка будет повреждение.

Мой обычный контрольный список:

• что-нибудь изменилось на машине? водители? Настройки на уровне ОС или BIOS? Возможно, автонег был отключен в ОС?
• Вы поменяли местами соединительные кабели и проверили, работает ли кабель?
• Вы проверили, чтобы видеть, порт коммутатора плох или отказывает?
• может NIC идет плохо?

Мы, как правило, никогда не отключаем autoneg на серверах (или что-либо еще в центре обработки данных), за исключением случаев, когда устранены все другие возможные причины, мы переместили порты коммутатора, изменили кабели, протестировали сетевую карту и т. Д. другой выбор. В этом случае это документируется до смерти. Это происходит очень редко, и обычно с устройствами, к которым у нас нет доступа для проверки настроек BIOS и ОС.

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

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

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

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

Вы должны автоматически договориться. Если у вас есть коммутатор, который не может автоматически договариваться, купите лучший коммутатор.

Гигабит должен автоматически договариваться, и это включает в себя обнаружение автоматического пересечения (MDI-X).

100baseT гарантированно потерпит неудачу, если один конец установлен в автоматический режим, а другой - в ручной, и это соответствует спецификациям. Если вы установите один конец на 100 / полный, то другой конец автоматически согласится на 100 / половину, что даст вам несоответствие дуплекса.

Обычно я устанавливаю серверы как фиксированные, так как я видел, как сетевое оборудование согласовывало 10 / половину вместо 1000 / полное.

Также некоторые CoLos устанавливают свои переключатели не для согласования, а только для установления связи на 1000 / полный.

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

При обновлении драйвера или замене оборудования нет никаких гарантий того, что ваши настройки будут сохранены на стороне сервера.

Установите обе стороны ссылки для согласования или исправьте обе стороны. Когда вы фиксируете настройки скорости и дуплекса на некоторых устройствах, они больше не объявляют о своих возможностях своим партнерам. Я не знаю, что говорит стандарт Ethernet о том, что делать, когда одна сторона объявляет о возможностях, а другая нет, и это, вероятно, означает, что многие разработчики также не знают. Некоторые выбирают наименьший общий знаменатель, равный 10 с половиной, а другие предполагают, что все в порядке, и выбирают максимально возможную скорость.

Существуют некоторые современные аппаратные средства, которые не поддерживают автосогласование по гигабитному медному Ethernet, такие как (по крайней мере, некоторые) коммутаторы Cisco с медными SFP.

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

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

Проблемы с автосогласованием трудно найти, особенно когда люди, работающие с сетью, серверами, приложениями и базами данных, - это четыре разные команды. Обычно последние два тратят много времени на то, чтобы обвинять друг друга в плохой производительности и лгать об измерениях, а иногда пинают его на серверных людей, которые должным образом посмотрят на вывод «top» и скажут, что все хорошо с сервером.

Это продолжается до тех пор, пока вопрос не перерастет в точку, где «эксперт» (на самом деле, кто-то, кто является универсалом, и, следовательно, понимает сети, оборудование, операционные системы, базы данных, платформы и приложения), назначается на проблему и находит проблему в течение пяти или десяти минут.

Итак, мое собственное эмпирическое правило, когда у меня есть возможность что-то с этим сделать, ВСЕГДА устанавливать фиксированные скорости на производственных серверах, коммутаторах и маршрутизаторах. Непроизводственные серверы также, если они достаточно сегрегированы, чтобы люди, которые их используют, не имели корневого доступа к нему.

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

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

Грубый Я видел 100-мегабайтные сетевые адаптеры 3com, которые не подключались бы при скорости выше 10 Мб, если бы вы использовали скорость или дуплекс. Вы могли получить полную скорость, только разрешив им автоматическое согласование, даже если у драйвера были настройки 100 МБ Full и 100 МБ Half.

Многие драйверы NIC не позволяют указать 1000 МБ. Единственные варианты: 10, 100, Авто. Снова заставляю вас делать Авто, если вы хотите на полной скорости. например, драйвер Broadcom netXtreme 57xx Gigabit ведет себя так.

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

1. По моему опыту (в основном оборудование 3Com и HP, немного Cisco), автоматическое согласование не вызывает много проблем.

2. Как и в случае с mrdenny, я обычно устанавливаю на серверах самую быструю скорость (у нас все еще есть некоторые при 100), полный дуплекс, а затем оставляю коммутатор включенным автоматически. Поскольку у нас есть разные скорости как на серверах, так и на рабочих станциях, я предпочитаю оставить коммутаторы включенными автоматически и позволить им адаптироваться к конечной точке.

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

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

Я недавно читал об этом в Network Warrior Гэри Донахью. В соответствии с этой книгой для автоматического согласования для правильной работы ОБА коммутатор и NIC должны быть установлены в режим автоматического согласования. Установка сетевой карты на определенную скорость и дуплексный режим и оставление сервера на автосогласовании не будет работать правильно - автосогласование - это протокол, и обе стороны должны говорить его, чтобы настройки работали правильно.

Если вы хотите явно установить скорость и дуплексный режим, вам нужно сделать это на обоих концах соединения.

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

Мое эмпирическое правило заключается в том, чтобы использовать автосогласование для всего, кроме каналов маршрутизатора, если у вас нет особых проблем (например, недавние карты Broadcom ... БАХ!)

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