На 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 может помочь диагностировать проблему.
Вопреки тому, что можно было ожидать, обе стороны соединения должны быть одинаково настроены для правильной работы. Другими словами, установка для одной стороны автоматического режима (либо скорость, либо дуплексный режим, либо обоих) и установка фиксированного значения для другой (скорость, дуплексный режим или и то, и другое), вероятно, приведет к несоответствию скорости, несоответствию дуплексного режима или к обоим. Несоответствие дуплексного режима можно исправить либо включив автосогласование (если оно доступно и работает) на обоих концах, либо принудительно установив одинаковые настройки на обоих концах (наличие интерфейса конфигурации позволяет). Если нет другого выбора, кроме как иметь заблокированную настройку на одном конце и автосогласование на другом (например, старое устройство с нарушенным автосогласованием, подключенное к неуправляемому коммутатору), необходимо использовать полудуплекс. Все современное оборудование LAN поставляется с включенным автосогласованием, и различные проблемы совместимости решены. Лучший способ избежать несоответствия дуплексного режима - использовать автосогласование и заменить любое устаревшее оборудование, которое не использует автосогласование или не выполняет автосогласование правильно.
Рекомендации
- ^ «Несоответствие дуплексного режима порта коммутатора» . Архивировано из оригинала на 2011-07-14 . Проверено 15 февраля 2011 .
- ^ «Настройка и устранение неполадок Ethernet 10/100 / 1000Mb с автосогласованием полудуплексного / полнодуплексного режима» . Cisco . Проверено 12 января 2012 .
Cisco рекомендует оставить автоматическое согласование для устройств, совместимых со стандартом 802.3u .
- ^ Джим Эггерс и Стив Ходнетт (июль 2004 г.). «Лучшие практики автосогласования Ethernet» (PDF) . Sun Microsystems . Архивировано из оригинального (PDF) 20 мая 2011 года.
Использование автосогласования является стандартом IEEE 802.3, и клиентам рекомендуется следовать «намерениям» стандартов IEEE 802.3u / z и реализовывать автосогласование в своих средах Ethernet.
- ^ Рич Эрнандес (2001). «Автосогласование Gigabit Ethernet» . Dell . Проверено 12 января 2012 .
- ^ «Автосогласование в Ethernet - это работает, оно должно быть обязательным!» . 2010-03-10 . Проверено 12 октября 2012 .
- ^ Гэри А. Донахью (2007). Сетевой воин . О'Рейли. п. 21. ISBN 978-0-596-10151-0.
- ^ US 6580697 , «Расширенное автосогласование Ethernet»
- ^ Джим Эггерс и Стив Ходнетт (июль 2004 г.). «Лучшие практики автосогласования Ethernet» (PDF) . Sun Microsystems . Проверено 18 февраля 2011 .