Помилки інтерфейсу Ethernet

Мій інтерфейс 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, які я можу використати для дослідження глибоких причин цих помилок, чи є щось, що я можу зробити, щоб переналаштувати інтерфейс мого сервера, щоб позбутися цих помилок?

У вас, швидше за все, є дуплексне невідповідність за рахунок жорсткого кодування провайдера їх сторони до 100-Full, що фактично вимикає автоматичні переговори на ISP Ethernet PHY.

Якщо провайдер встановлений на 100-повний, а ваша сторона залишається в автоматичному / автоматичному (переконання, але загальна), автоматична переговорна робота з вашої сторони налаштує інтерфейс на 100-Половину - дуплексне невідповідність стороні провайдера залишиться 100-повним.

Виправити

Виправити проблему можна жорстким кодуванням вашого Ethernet PHY до 100-Full - або, зокрема, будь-яким іншим установленим провайдером. Більшість ISP використовують 100-повний.

Додаткова деталізація

При невідповідності дуплексу від 100-Full до 100-Half сторона 100-Full відключає CSMA / CD, тоді як CSMA / CD залишається в силі на стороні 100-Half. Сторона 100-Повна передає незалежно від того, вільний чи ні носій. Сторінки на 100 Половина виконують перевірки CSMA / CD та відновлення, як визначено CSMA / CD. Ось чому ви можете домогтися лише 20 Мбіт / с лише тим, що має бути мережевою ланцюгом 50 Мб / с . Перешкода CSMA / CD за рахунок 100-Половинного виявлення зіткнень обмежує пропускну здатність.

Завдяки жорсткому кодуванню інтерфейсу до 100-Full для відповідності ISP, обидві сторони будуть відключені CSMA / CD, тому виявлення баккоффа та зіткнення буде вимкнено, і ви повинні досягти цифр, набагато ближчих до швидкості передачі даних у мережі Інтернет на 50 Мб / с.

Історія

Багато провайдерів жорстко кодують свої передачі Ethernet PHY, оскільки був час, коли це було набагато надійніше. Коли вихідний стандарт 802.3u 100 Мбіт / с Fast Ethernet був випущений, автоматичне узгодження швидкості і дуплекс було присутнє, але не потрібно . Це було до 802.3z 1 Гбіт / с гігабітного Ethernet стандарту, коли автоматичне узгодження вимагало стандарт.

Багато інженерів мережі мають помилкові уявлення про автоматичні переговори. Найбільша помилкова думка полягає в тому, що автоматичні переговори можуть належним чином домовлятися про швидкість і дуплекс, якщо лише одна сторона здійснює автоматичні переговори. Це помилково - як ви бачили.

Причина цього, ймовірно, випливає з наступного - якщо одна сторона жорстко зашифрована на 100-Full, інша сторона, що веде автоматичне узгодження, завжди здається, що вона розраховує частину 100 Мб / с. Те саме, якщо одна сторона жорстко закодована до 10-Full - інша сторона, що працює за допомогою автоматичних переговорів, може визначити частину 10 Мб / с. Можливість визначати швидкість зв'язку відбувається від функції, званої паралельним виявленням, яка намагається прийняти сигнал фізичного рівня на всіх локально підтримуваних швидкостях зв'язку, поки не буде знайдено відповідність. Однак паралельне виявлення працює лише для швидкості, а не для дуплексного зіставлення. Ось чому можуть виникати дуплексні невідповідності - оскільки інтерфейс завжди повернеться до напівдуплексу, коли він не зможе визначити іншу сторону шляхом автоматичного узгодження.

Мильниця

Свого часу була точкова підтримка автоматичних переговорів, і це викликало стільки ж проблем, скільки планувалося вирішити. Той час, на думку інженера мережі - минув. Незважаючи на те, що проблеми з автоматичними переговорами все ще існують, кількість проблем, які я бачив через налаштування автоматичних переговорів протягом останніх 5 років, зменшує кількість проблем, які я бачив через те, що автоматичні переговори були відключені.

У мене ніколи не було Інтернет-провайдера, який не бажав змінювати свою передачу Ethernet на автоматичну / авто. У більшості кабельних та DSL-модемів і шлюзів це не проблема. Ця проблема зазвичай є саме NxT1 та CPE-маршрутизаторами, керованими волокнами, з передачею Ethernet. Проблема полягає в тому, що адміністратору мережі доводиться запитувати в першу чергу.

Із жорстким кодуванням ISP до 100-Full вони взяли на себе зобов'язання . Зобов'язання, яке повинно бути задокументовано та продовжено. Автомобільні переговори - це технологія, яка зараз стабільна, вона працює роками, і опікується цією проблемою для нас. Як вже згадувалося раніше, кількість проблем, викликаних автоматичними переговорами, значно переважає кількість питань, які виникають внаслідок його відключення в 2011 році. Існує технологія, щоб вирішити цю проблему, використовувати її. Можливо, нам слід вручну встановити початкові TCP SYN, MSS та керувати вікном прийому для кожної віртуальної схеми TCP? Я дитина.

Стривайся.