Несоответствие дуплекса
В Ethernet соединении дуплексное несоответствие — это состояние, при котором два подключенных устройства работают в разных дуплексных режимах , то есть одно работает в полудуплексном режиме, а другое — в полнодуплексном. Результатом дуплексного несоответствия является неэффективная работа канала. Несоответствие дуплексного режима может быть вызвано ручной настройкой двух подключенных сетевых интерфейсов в разных дуплексных режимах или подключением устройства, выполняющего автосогласование, к устройству, для которого вручную установлен полнодуплексный режим. [1]
Несоответствие дуплексных режимов из-за автосогласования
[ редактировать ]Когда устройство, настроенное на автосогласование, подключено к устройству, которое не использует автосогласование, процесс автосогласования завершается сбоем. Сторона соединения с автосогласованием все еще может правильно определить скорость другого конца, но не может правильно определить дуплексный режим. Для обратной совместимости с концентраторами Ethernet стандарт требует, чтобы устройство автосогласования использовало в таких условиях полудуплекс. Таким образом, сторона соединения с автосогласованием использует полудуплекс, в то время как несогласующий узел блокируется в полнодуплексном режиме, и это является несоответствием дуплекса.
Стандарты Ethernet и основные производители оборудования Ethernet рекомендуют включать автосогласование. [2] [3] [4] Тем не менее, сетевое оборудование позволяет отключить автосогласование, а в некоторых сетях автосогласование отключается на всех портах и используется фиксированная модальность 100 Мбит/с и полнодуплексный режим. Это часто делалось сетевыми администраторами намеренно при введении автосогласования из-за проблем совместимости с исходной спецификацией автосогласования. Фиксированный режим работы хорошо работает, если на обоих концах соединения установлены одни и те же настройки. Однако поддерживать такую сеть и гарантировать ее согласованность сложно. Поскольку автосогласование обычно является настройкой производителя по умолчанию, почти наверняка в среде, где политика предусматривает фиксированные настройки порта, кто-то рано или поздно по ошибке оставит порт, настроенный для использования автосогласования. [5]
Последствия несоответствия дуплексных режимов
[ редактировать ]Связь возможна через соединение, несмотря на несоответствие дуплексного режима. Отдельные пакеты отправляются и подтверждаются без проблем. В результате простая команда ping не может обнаружить несоответствие дуплексного режима, поскольку отдельные пакеты и их результирующие подтверждения с интервалом в 1 секунду не вызывают никаких проблем в сети. Терминальный сеанс, который отправляет данные медленно (очень короткими пакетами), также может успешно взаимодействовать. Однако, как только любой конец соединения пытается отправить значительный объем данных, скорость сети внезапно снижается до очень низкой. Поскольку в остальном сеть работает, причина не так очевидна.
Несоответствие дуплексного режима вызывает проблемы, когда оба конца соединения пытаются передать данные одновременно. Это происходит, даже если канал используется (с точки зрения высокого уровня или пользователя) только в одном направлении, в случае передачи больших объемов данных. Действительно, когда большая передача данных отправляется по TCP , данные передаются в нескольких пакетах, некоторые из которых инициируют отправку пакета подтверждения обратно отправителю. В результате пакеты отправляются в обоих направлениях одновременно.
В таких условиях полнодуплексный конец соединения отправляет свои пакеты, одновременно получая другие пакеты; в этом и состоит суть полнодуплексного соединения. Между тем, полудуплексный конец не может принять входящие данные во время отправки — он воспримет это как коллизию . Полудуплексное устройство прекращает текущую передачу данных, вместо этого отправляет сигнал застревания, а затем повторяет попытку позже в соответствии с CSMA/CD . Это приводит к тому, что полнодуплексная сторона получает неполный кадр с ошибкой CRC или неполный кадр . Он не обнаруживает коллизий, поскольку CSMA/CD отключен на полнодуплексной стороне. В результате, когда оба устройства пытаются передать сигнал (почти) в одно и то же время, пакет, отправленный полнодуплексным концом, будет отброшен и потерян из-за предполагаемого конфликта, а пакет, отправленный полудуплексным устройством, будет задержан. или потерян из-за ошибки CRC в кадре. [6]
Потерянные пакеты вынуждают протокол TCP выполнять восстановление после ошибок, но первоначальные (упрощенные) попытки восстановления терпят неудачу, поскольку повторно переданные пакеты теряются точно так же, как и исходные пакеты. В конце концов окно передачи TCP заполняется, и протокол TCP отказывается передавать какие-либо дальнейшие данные до тех пор, пока не будут подтверждены ранее переданные данные. Это, в свою очередь, остановит новый трафик по соединению, оставив только повторные передачи и подтверждения. Поскольку таймер повторной передачи постепенно увеличивается между попытками, в конечном итоге повторная передача произойдет, когда в соединении нет обратного трафика и наконец будет получено подтверждение. Это перезапустит TCP-трафик, что, в свою очередь, немедленно приведет к потере пакетов при возобновлении потоковой передачи.
Конечным результатом является соединение, которое работает, но работает крайне плохо из-за несоответствия дуплексного режима. Признаками несоответствия дуплексных режимов являются соединения, которые, кажется, нормально работают с командой ping , но легко «блокируются» из-за очень низкой пропускной способности при передаче данных; эффективная скорость передачи данных, вероятно, будет асимметричной и будет работать намного хуже в полудуплексном и полнодуплексном направлении, чем в другом. В обычных полудуплексных операциях поздние коллизии не возникают. Однако при дуплексном несоответствии коллизии, наблюдаемые на полудуплексной стороне канала, часто являются поздними коллизиями. Полнодуплексная сторона обычно регистрирует ошибки последовательности проверки кадров или короткие кадры . [7] [8] Просмотр этой стандартной статистики Ethernet может помочь диагностировать проблему.
Вопреки тому, что можно было бы разумно ожидать, для правильной работы обе стороны соединения должны быть одинаково настроены. Другими словами, установка одной стороны на автоматический режим (скорость, дуплекс или оба) и установка фиксированной другой стороны (скорость, дуплекс или оба), скорее всего, приведет либо к несоответствию скорости, либо к несоответствию дуплекса, либо к тому и другому. Несоответствие дуплексного режима можно исправить, либо включив автосогласование (если оно доступно и работает) на обоих концах, либо принудительно установив одинаковые настройки на обоих концах (если позволяет наличие интерфейса конфигурации). Если нет другого выбора, кроме как иметь заблокированную настройку на одном конце и автосогласование на другом (например, старое устройство со сломанным автосогласованием, подключенное к неуправляемому коммутатору), необходимо использовать полудуплекс. Все современное оборудование локальной сети поставляется с включенным автосогласованием, и различные проблемы совместимости решены. Лучший способ избежать дуплексных несоответствий — использовать автосогласование и заменить любое устаревшее оборудование, которое не использует автосогласование или не выполняет автосогласование правильно.
Ссылки
[ редактировать ]- ^ «Несоответствие дуплексного режима порта коммутатора» . Архивировано из оригинала 14 июля 2011 г. Проверено 15 февраля 2011 г.
- ^ «Настройка и устранение неполадок полу-/полнодуплексного автоматического согласования Ethernet 10/100/1000 Мбит» . Циско . Проверено 12 января 2012 г.
Cisco рекомендует оставлять автосогласование включенным для устройств, совместимых со стандартом 802.3u .
- ^ Джим Эггерс и Стив Ходнетт (июль 2004 г.). «Лучшие практики автосогласования Ethernet» (PDF) . Сан Микросистемс . Архивировано из оригинала (PDF) 20 мая 2011 г.
Использование автосогласования является стандартом IEEE 802.3, и клиентам рекомендуется следовать «намерению» стандартов IEEE 802.3u/z и реализовывать автосогласование в своих средах Ethernet.
- ^ Рич Эрнандес (2001). «Автосогласование Gigabit Ethernet» . Делл . Проверено 12 января 2012 г.
- ^ «Автосогласование в Ethernet – оно работает, оно должно быть обязательным!» . 10 марта 2010 г. Проверено 12 октября 2012 г.
- ^ Гэри А. Донахью (2007). Сетевой воин . О'Рейли. п. 21. ISBN 978-0-596-10151-0 .
- ^ США 6580697 , «Расширенное автоматическое согласование Ethernet».
- ^ Джим Эггерс и Стив Ходнетт (июль 2004 г.). «Лучшие практики автосогласования Ethernet» (PDF) . Сан Микросистемс . Проверено 18 февраля 2011 г.