Ошибки интерфейса 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, которые я могу использовать для углубленного изучения причин этих ошибок, или я могу что-то сделать, чтобы перенастроить интерфейс моего сервера, чтобы избавиться от этих ошибок?
1 ответ
Скорее всего, у вас есть несоответствие дуплексных режимов из-за того, что провайдер жестко закодировал их сторону на 100-Full, по существу отключив автоматическое согласование на PHY ISP Ethernet.
Если для интернет-провайдера установлено значение 100-Full, а ваша сторона остается в режиме auto / auto (догадка, но обычное явление), автоматическое согласование на вашей стороне настроит интерфейс на 100-Half - несоответствие дуплекса в качестве стороны ISP. останется 100-Full.
исправлять
Вы можете решить эту проблему, жестко запрограммировав свой PHY Ethernet на 100-Full или, в частности, на то, на что настроен провайдер. Большинство интернет-провайдеров используют 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? Я ребенок.
Срочно