web-dev-qa-db-ja.com

イーサネットインターフェイスエラー

ISPのマルチプレクサに接続する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に接続すると、このようなエラーも表示されました。割り当てられた帯域幅は50mbpsですが、取得できるのは20mbpsだけです。 ISPは、MUXでデバイス（イーサネットスイッチまたはハブのように見える）を変更することに消極的です。 ISPのエンジニアは、私の側のせいであると非難しています。しかし、3つ以上のデバイスで確認したところ、すべてエラーが表示されました。それで、これらのエラーの原因を深く調査するために使用できるLinux用のツールはありますか、またはそれらのエラーを取り除くためにサーバーのインターフェイスを再構成するためにできることはありますか？

ethernetwide-area-networkerrors
10
nixnotwin

ISPがサイドを100にハードコーディングしているため、デュプレックスのミスマッチが発生している可能性があります。ISPイーサネットPHYでの自動ネゴシエーションを実質的に無効にします。

ISPが100-Fullに設定され、あなたの側がauto/autoのままである場合（勘ですが、一般的なものです）、あなたの側の自動ネゴシエーションは、インターフェイスを100-Halfに構成します-ISP側としてのデュプレックスのミスマッチ100-Fullのままになります。

修正

イーサネットPHYを100-Fullにハードコーディングするか、具体的にはISPが設定されているものにハードコーディングすることで、問題を解決できます。ほとんどのISPは100-Fullを使用しています。

追加の詳細

100-Fullから100-Halfのデュプレックスの不一致により、100-Full側はCSMA/CDを無効にしますが、CSMA/CDは100-Half側で有効なままです。 100-フルサイドは、メディアが空いているかどうかに関係なく送信します。 100-Half側は、CSMA/CDで定義されているようにCSMA/CDチェックとバックオフを実行します。 これが、50 Mb/sのインターネット回線で20 Mb/sしか達成できない理由です。衝突を検出する100-Half側のためのCSMA/CDバックオフは、スループットを制限しています。

インターフェイスを100-FullにハードコーディングしてISPに一致させると、両側でCSMA/CDが無効になるため、バックオフと衝突検出が無効になり、50 Mb/sのインターネット回線データレートにはるかに近い数値を達成できます。

履歴

多くのISPは、イーサネットPHYハンドオフをハードコーディングしています。これは、そうする方がはるかに信頼性が高い時期があったためです。元の802.3u100 Mb/sファストイーサネット規格がリリースされたとき、速度とデュプレックスの自動ネゴシエーションが存在していましたが、ただし必須ではありません。オートネゴシエーションが必要になったのは、802.3z 1 Gb/sギガビットイーサネット標準までではありませんでした標準によって。

多くのネットワークエンジニアは、オートネゴシエーションについて誤解しています。最大の誤解は、片側だけが自動ネゴシエーションを実装している場合、自動ネゴシエーションは速度と二重を適切にネゴシエートできるということです。あなたが見てきたように、これは誤りです。

この理由は、次の理由による可能性があります。一方が100-Fullでハードコーディングされている場合、自動ネゴシエーションを実行しているもう一方は常に100 Mb/sの部分を把握しているようです。一方が10-Fullにハードコーディングされている場合も同じです。オートネゴシエーションを実行しているもう一方の側は、10 Mb/sの部分を把握できます。リンク速度を決定する機能は、並列検出と呼ばれる機能からのものであり、一致が見つかるまで、ローカルでサポートされているすべてのリンク速度で受信した物理層信号を試行します。 。ただし、並列検出は速度に対してのみ機能し、デュプレックスマッチングに対しては機能しません。これがデュプレックスのミスマッチが発生する理由です。自動ネゴシエーションで相手側を判別できない場合、インターフェイスは常に半二重にフォールバックするためです。

Soapbox

かつてはオートネゴシエーションのサポートが不十分で、解決しようとしていたのと同じくらい多くの問題を引き起こしていました。 その時、このネットワークエンジニアの意見では-は過ぎました。オートネゴシエーションの問題はまだ存在しますが、問題の数はオートネゴシエーションが原因で見た構成されている過去5年間で、私が見た問題の数は少なくなっています。オートネゴシエーションが無効になっています。

求められたときにイーサネットハンドオフを自動/自動に変更することを望まないISPは一度もありませんでした。ほとんどのケーブルおよびDSLモデムとゲートウェイでは、これは問題ではありません。この問題が通常存在するのは、イーサネットハンドオフを備えたNxT1およびファイバーマネージドCPEルーターです。問題は、ネットワーク管理者が最初に質問しなければならないことです。

ISPが100-Fullにハードコーディングしている場合彼らは義務を負っています。文書化して継続しなければならない義務。オートネゴシエーションは、現在安定していて、何年も前からあり、この問題を処理してくれるテクノロジーです。先に述べたように、オートネゴシエーションによって引き起こされる問題の数は、2011年に無効にされたために発生する問題の数をはるかに上回っています。この問題を解決する技術が存在し、それを使用します。おそらく、初期のTCP SYN、MSSを手動で設定し、すべてのTCP仮想回線の受信ウィンドウも管理する必要がありますか？私は子供です。

暴言を吐く。

8
Weaver