Ошибки интерфейса Ethernet

Мой интерфейс Ethernet серверов Ubuntu, который подключается к мультиплексору ISP, показывает ошибки. Вот снимок:

          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. Инженеры ISP обвиняют в этом свою вину на моей стороне. Но я проверил с более чем 3 устройствами, все показали ошибки. Итак, есть ли инструменты для Linux, которые я могу использовать для углубленного изучения причин этих ошибок, или я могу что-то сделать, чтобы перенастроить интерфейс моего сервера, чтобы избавиться от этих ошибок?

Скорее всего, у вас есть несоответствие дуплексных режимов из-за того, что провайдер жестко кодирует их сторону до 100-Full, по существу отключая автоматическое согласование на PHY ISP Ethernet.

Если для интернет-провайдера установлено значение 100-Full, а ваша сторона остается в режиме auto / auto (догадка, но распространенная), автоматическое согласование на вашей стороне настроит интерфейс на 100-Half - несоответствие дуплекса в качестве стороны ISP. останется 100-Full.

Fix

Вы можете решить эту проблему, жестко запрограммировав свой PHY Ethernet на 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, так как было время, когда это было намного надежнее. Когда был выпущен исходный стандарт Fast Ethernet 802.3u 100 Мбит / с, автоматическое согласование скорости и дуплекса присутствовало, но не требовалось . Лишь в стандарте Gigabit Ethernet 802.3z 1 Гбит / с стандарт требовал автоматического согласования .

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

Вероятно, причина этого заключается в следующем: если одна сторона жестко запрограммирована на 100-Full, другая сторона, выполняющая автосогласование, всегда, кажется, вычисляет часть 100 Мбит / с. То же самое, если одна сторона жестко запрограммирована на 10-Full - другая сторона, выполняющая автосогласование, может определить часть 10 Мбит / с. Способность определять скорость канала определяется функцией параллельного обнаружения, которая проверяет принятый сигнал физического уровня на всех локально поддерживаемых скоростях канала до тех пор, пока не будет найдено соответствие. Однако параллельное обнаружение работает только для скорости, а не для дуплексного сопоставления. Вот почему могут возникать несоответствия дуплексных режимов - поскольку интерфейс всегда переключается на полудуплексный режим, когда он не может определить другую сторону посредством автосогласования.

импровизированная трибуна

Когда-то была автоматическая поддержка переговоров, и это вызывало столько же проблем, сколько и предполагалось решить. То время, по мнению инженера этой сети, - прошло. Хотя проблемы с автосогласованием все еще существуют, число проблем, с которыми я столкнулся из- за настройки автосогласования за последние 5 лет, значительно превышает количество проблем, с которыми я столкнулся в связи с отключением автосогласования.

У меня никогда не было провайдера, который не желал менять свою эстафетную передачу Ethernet на авто / авто по запросу. С большинством кабельных и DSL модемов и шлюзов это не проблема. Эта проблема обычно связана с маршрутизаторами CPE, управляемыми по NxT1 и оптоволокну, с передачей обслуживания Ethernet. Проблема в том, что администратор сети должен спросить в первую очередь.

При жестком кодировании ISP до 100-Full они дали обязательство . Обязательство, которое должно быть задокументировано и продолжено. Автосогласование - это технология, которая сейчас стабильна, существует уже много лет и решает эту проблему для нас. Как упоминалось ранее, количество проблем, вызванных автосогласованием, значительно перевешивается количеством проблем, которые возникают из-за его отключения в 2011 году. Для решения этой проблемы существует технология, используйте ее. Возможно, нам следует вручную установить начальные значения SYN TCP, MSS и управлять окном приема для каждого виртуального канала TCP? Я ребенок.

Срочно