Интерфейс Ethernet моих серверов Ubuntu, который подключается к мультиплексору провайдера, показывает ошибки. Вот снимок:
RX packets:204564288 errors:3193970 dropped:0 overruns:0 frame:3138402
TX packets:29305799 errors:38752 dropped:0 overruns:0 carrier:38762
collisions:2205053 txqueuelen:1000
Интерфейс Ubuntu поддерживает полнодуплексный режим, но поддерживает только полудуплексное соединение. Когда я подключал к MUX другое устройство (роутер), он тоже показывал такие ошибки. Пропускная способность назначена 50 мбит / с, но я получаю только 20 мбит / с. Интернет-провайдер не хочет менять свое устройство (выглядит как коммутатор или концентратор Ethernet) в MUX. Инженеры интернет-провайдера винят в этом мою ошибку. Но проверял более чем на 3 устройствах, все показывали ошибки. Итак, есть ли какие-либо инструменты для Linux, которые я могу использовать, чтобы глубже изучить причины этих ошибок, или я могу что-то сделать, чтобы перенастроить интерфейс моего сервера, чтобы избавиться от этих ошибок?
Скорее всего, у вас есть несоответствие дуплексного режима из-за того, что ISP жестко закодировал свою сторону до 100-Full, по сути, отключив автосогласование на ISP Ethernet PHY.
Если для ISP установлено значение 100-Full, а ваша сторона остается в автоматическом / автоматическом режиме (догадка, но обычная), автоматическое согласование на вашей стороне настроит интерфейс на 100-Half - дуплексное несоответствие со стороны ISP останется 100-Full.
Исправить
Вы можете решить эту проблему, жестко закодировав свой Ethernet PHY на 100-Full - или, в частности, в зависимости от того, что установлен ISP. Большинство интернет-провайдеров используют 100-Full.
Дополнительная деталь
При несоответствии дуплексного режима 100-Full на 100-Half сторона 100-Full отключает CSMA / CD, в то время как CSMA / CD остается в силе на стороне 100-Half. Сторона 100-Full передает независимо от того, свободен ли носитель. Сторона 100-Half выполняет проверки CSMA / CD и откат, как определено CSMA / CD. Вот почему вы можете достичь только 20 Мбит / с на том, что должно быть интернет-каналом со скоростью 50 Мбит / с.. Отсрочка передачи CSMA / CD из-за обнаружения коллизий на стороне 100-Half ограничивает пропускную способность.
При жестком кодировании интерфейса на 100-Full, чтобы соответствовать ISP, обе стороны будут отключены CSMA / CD, поэтому откат и обнаружение коллизий будут отключены, и вы должны достичь значений, намного ближе к скорости передачи данных вашего интернет-канала 50 Мбит / с.
История
Многие интернет-провайдеры жестко кодируют передачу обслуживания Ethernet PHY, поскольку было время, когда это было намного надежнее. Когда был выпущен оригинальный стандарт 802.3u 100 Мбит / с Fast Ethernet, автоматическое согласование скорости и дуплексного режима присутствовало, но не обязательно. Так было до стандарта 802.3z 1 Гбит / с Gigabit Ethernet при автосогласовании. требовалось по стандарту.
Многие сетевые инженеры имеют неправильное представление об автосогласовании. Самым большим заблуждением является то, что автосогласование может правильно согласовывать скорость и дуплекс, если только одна сторона реализует автосогласование. Это ложь - как вы видели.
Причина этого, вероятно, заключается в следующем - если одна сторона жестко запрограммирована на 100-Full, другая сторона, выполняющая автосогласование, всегда, кажется, вычисляет часть 100 Мбит / с. То же самое, если одна сторона жестко запрограммирована на 10-Full - другая сторона, выполняющая автосогласование, может вычислить часть 10 Мбит / с. Возможность определения скорости соединения обеспечивается функцией, называемой параллельное обнаружение который пробует принятый сигнал физического уровня на всех локально поддерживаемых скоростях канала до тех пор, пока не будет найдено совпадение. Тем не мение, параллельное обнаружение работает только для скорости, а не для дуплексного согласования. Вот почему могут возникать дуплексные несовпадения - поскольку интерфейс всегда возвращается к полудуплексному режиму, когда он не может определить другую сторону посредством автосогласования.
Мыльница
Когда-то поддержка автосогласования была неоднозначной, и это вызывало столько же проблем, сколько и предназначалось для решения. То время, по мнению сетевого инженера, прошло. Хотя проблемы с автосогласованием все еще существуют, количество проблем, которые я видел из-за автосогласования настраивается за последние 5 лет количество проблем, которые я видел, затмевается из-за отключения автосогласования.
У меня никогда не было интернет-провайдеров, которые не желали бы переключать передачу обслуживания Ethernet на автоматический / автоматический режим по запросу. Для большинства кабельных и DSL-модемов и шлюзов это не проблема. Обычно эта проблема связана с NxT1 и маршрутизаторами CPE с оптоволоконным управлением и переключением каналов связи через Ethernet. Проблема в том, что в первую очередь должен спросить сетевой администратор.
С жестким кодированием ISP до 100-Full они дали обязательство. Обязательство, которое должно быть задокументировано и продолжено. Автосогласование - это технология, которая сейчас стабильна, существует уже много лет и решает эту проблему за нас. Как упоминалось ранее, количество проблем, вызванных автосогласованием, намного перевешивается количеством проблем, возникающих из-за его отключения в 2011 году. Существуют технологии для решения этой проблемы, используйте их. Возможно, нам следует вручную установить начальные TCP SYN, MSS и управлять окном приема для каждого виртуального канала TCP? Я ребенок.
Убей.