ノードはTxとRxに異なる回路を使用するため、ケーブルでイーサネットの衝突はどのくらい正確に発生しますか?


13

特に、デュプレックスの不一致が存在する場合、またはレガシーイーサネットネットワーク上で2つのノードが同時に送信する場合に、イーサネットで衝突が発生する方法を理解しようとしています。

誰もが上位レベルで衝突を説明します(一方が送信され、もう一方が受信されるときに2つのフレームが衝突します)。ただし、下のグラフは、RxとTxに異なる回路があることを示しています。フレームを送受信するための専用回線があるため、衝突はどのように発生しますか?

異なる回路が送信と受信に使用されます

編集:たぶん「Hub MDI-X」というラベルは私の質問のポイントに関して混乱を引き起こします。ハブの機能性がどのように衝突を引き起こす可能性があるのか​​を尋ねているのではありません。私の焦点は、MDIまたはMDI-Xインターフェースを備えた2つのノード間の通信にあります(ハブとスイッチにはMDI-Xインターフェースがあります)。これらの2つのケースのいずれにおいても、デュプレックスミスマッチがある場合に2つのノード間で衝突が発生する可能性がありますが、デュプレックスミスマッチではRxとTxにはまだ専用回線がありますか?


10Base2または10Base5は同じ媒体、たとえば同じケーブルを共有したことに注意してください。
パトリックテリセン

それでも、デュプレックスの不一致があり、nodeAが半二重で、nodeBが全二重の場合、100base-txに関して同じ質問があります。nodeAにMDIインターフェースがあり、nodeBにMDI-Xインターフェースがあるとします。NodeBはピン3および4から送信し、nodeBは3および4からのみ受信します。nodeAはこれらのピンからのみ受信するため、nodeAで衝突はどのように発生しますか。
クリストスダラマグカス

6
衝突はL2ではなくL1で発生します-衝突するのはビット/キャリアです。2人の送信者が同時に(近くで)送信しようとすると衝突します。
-Zac67

回答:


11

これを理解するには、歴史的背景を理解する必要があります。

当初、イーサネットは共有同軸ケーブルを使用していました。これを一度に送信できるデバイスは1つだけです。2つのデバイスが同時に送信された場合、衝突と見なされました。

その後、リピーターが登場し、距離を伸ばしてノードの数を増やしました。リピーターは、どのポートが送信しているかを検出し、その後、他のポートでその信号を繰り返します。衝突検出を機能させるには、すべてのノードが衝突を検出することを保証する機能がリピーターに必要でした。最初のリピーターには2つのポートしかありませんでしたが、後のリピーターには複数のポートがあり、特にツイストペア配線と組み合わせて使用​​する場合、ハブとして知られるようになりました。リピーターはかなり馬鹿げたデバイスで、電気信号を再生しますが、それ以上のことはありません。

10BASE-Tが登場しました。気づいたように、各方向に専用のデータチャネルがあります。それでも、既存のモデルに適合する必要があったため、デフォルトでは同軸ケーブルをエミュレートする「半二重」モードで動作しました。信号は実際にはワイヤー上で衝突しませんでしたが、トランシーバーはあたかもそうであるかのように動作し、リピーターはこれがネットワーク全体で確認されるように以前と同じ手順を実行します。

ツイストペアイーサネットは、「全二重」モードもサポートできます。このモードでは、衝突関連のハードウェアはすべて無効になり、両端はいつでも送信できます。ただし、このモードにはいくつかの大きな欠点がありました。

  • リピーターハブとは互換性がありませんでした。衝突検出メカニズムがなければ、ハブは同時に送信する2つのデバイスを処理する方法がありません。
  • 同じ二重モードに設定されるリンクの両端は、そうでない場合、悪いことが起こります。

これらの問題により、実際には10BASE-Tシステムはほぼ常に半二重モードで動作していました。

100BASE-TXの場合、状況は劇的に改善しました。イーサネットスイッチ(技術的に高速なマルチポートブリッジ)は、低価格のリピーターハブが不要になるほど価格が下がりました。オートネゴシエーションにより、ネットワークカードは、エラーが発生しやすい手動設定なしで全二重接続を確立できました。2つの100BASE-TX NICをクロスケーブルで接続するか、100BASE-TX NICをスイッチに接続し、手動でオーバーライドする手順を実行しない場合、ほぼ確実に全二重モードをネゴシエートします。

1000BASE-Tには理論的には一部のNICがサポートすると主張する半二重モードがあり、ギガビットマルチポートリピーターの仕様がありましたが、これを販売したという証拠は見たことがありません。実際には、ギガビットリンクはほぼ確実に全二重モードで実行されます。

より速い速度は、半二重モードを完全に放棄しました。


そして、ワイヤレスイーサネットが登場し、メディアの衝突が再び発生します。
OrangeDog

@OrangeDogは、Wi-Fi(IEEE 802.11)を意味する場合、ワイヤレスイーサネット(IEEE 802.3)ではありません。これは、フレームが異なり、CSMA / CDの代わりにCSMA / CAを使用する完全に異なるプロトコルです。2つのプロトコルは大きく異なりますが、サポートするさまざまなメディアのイーサネットはすべて基本的に同じです。
ロンモーピン

14

ハブは、実際には、1つのインターフェイスで受信したすべての信号を他のすべてのインターフェイスに繰り返す単なる電源ケーブルです。2つのデバイスが同時にハブインターフェイスの受信に送信する場合、ハブは両方の信号を他のすべてのハブインターフェイスの送信に同時に繰り返し、受信した両方の信号が他のインターフェイスの送信で衝突します。同時に2つの信号であるため、他のすべてのインターフェイスがガベージシグナルを持つ衝突が発生します。同時に送信し、別の信号を聞くホストは、複数のホストが同時に送信していることを認識し、衝突があると判断します。

このように考えると、すべてのハブインターフェイスの受信が他のすべてのインターフェイスの送信に配線されます。ハブの内部では、送信側と受信側がインターフェースで分離されていても接続されています。

スイッチとは対照的です。各リンクはスイッチインターフェイスで終端され、スイッチには相互接続されたインターフェイスがありません。代わりに、スイッチには、1つのインターフェイスで受信したフレームの送信先を決定し、スイッチ内での衝突を防ぐためのロジック(通常はハードウェアに組み込まれています)があります。

スイッチは高密度ブリッジです。元のブリッジは、複数のインターフェイスを持つPCのようなものでした。複数のインターフェイスで同時にフレームを受信した場合、複数のインターフェイスを備えたPCが衝突することはありません。


編集:

あなたのコメントは、私がハブについて上で書いたことをまだ理解していないと信じさせてくれます。

UTPおよびハブを使用する場合の衝突の検出方法は、送信中に送信デバイスが別の信号を聞くことです。UTPを使用するデバイスが半二重に設定されている場合、送信中に信号を聞いたときに衝突が発生したと考えられます。

デュプレックスの不一致がある場合、全二重に設定されたデバイスは、半二重に設定されたデバイスからの受信中に喜んで送信します。一方、半二重に設定されたデバイスは、全二重に設定されたデバイスから信号を送信および受信するときに衝突があると信じます。半二重に設定されたデバイスはフレームの送信を停止し(ラントの原因となる)、全二重に設定されたデバイスが予期しない妨害信号を送信するため、すべてのタイプの問題が発生します。全二重に設定されたデバイスは、フレームの送信を停止します。


3
これが本当の答えです。OPは、クロスオーバーケーブル(または、最新の設定では任意のケーブル)を備えた2つのエンドポイントを除いて、すべてのケースを無視します。
R .. GitHub停止ヘルプICE

@R ..、質問の図はハブを示しているので、ハブ接続について回答しました。
ロンモーピン

この回答では、トポロジにハブがある場合に衝突が発生する方法について説明します。2つのノード(たとえば、スイッチとPC)がある場合、レイトコリジョンが発生する可能性がありますが、1つは半二重で、もう1つは全二重です。私の質問のグラフに示されているように、TxとRxに別々の回路があるにもかかわらず、なぜこの場合に衝突が起こるのですか?
クリストスDalamagkas

私の質問のポイントに関して、「ハブMDI-X」というラベルが混乱を引き起こしたようです。それに応じて編集しました。
クリストスダラマグカス

3
送信中に何かを聞くと、半二重の通信が衝突を宣言するためです。上記の回答を参照してください。半二重に設定されたデバイスが送信中に別の信号を聞く場合、半二重であると見なし、一度に1つのデバイスしか送信できないため、衝突があると想定する必要があります。
ロンモーピン

8

いい質問ですね。

全二重では、「左から右」へのトラフィック専用のチャネルと「右から左」からのトラフィック専用チャネルがあります。

専用チャンネル

したがって、全二重では、両方のNICが同時に送信する場合でも、衝突は不可能です。

半二重、しかし、いずれかの方向にトラフィックのみワイヤー、一度に一つの方向を使用することを意味します。したがって、物理的にはまだ専用チャネルがありますが、論理的に1つのNICが送信中に何かを受信した場合、衝突としてログに記録します。ビット/信号は実際にはワイヤ上で「衝突」することはありません。NICが同時に受信と送信を行うと、衝突カウンタが単純に増加します。


4
ツイストペアであっても、信号はワイヤ上で衝突します。3つのエンドノードでは、2つの同時信号が3番目のノードで衝突します。
Zac67

4
ビット/信号は実際にはワイヤ上で「衝突」しません」ハブでは、質問の図のように、ビットは実際にワイヤ上で衝突し、ごみ信号を生成します。同時に送信し、別の信号を受信するホストは、ハブ上の他のすべてのインターフェイスに妨害信号を送信します。
ロンモーピン

@RonMaupinもちろんあなたは正しいです-リピーターが衝突を検出/反応しなかったときに何が起こるかについて言及していました。
Zac67

1
@ Zac67、私はあなたのためにコメントしていなかった、あなたと私は基本的に同時に同じことを言った。
ロンモーピン

@ Zac67 / RonMaupin OPは、ハブのケースについて質問していないことを確認する質問を編集しました。
エディ

6

ツイストペアとリピータハブにより、ハブはデジタルアンプ以上のものではありません。そのため、1つのポートの着信信号からキャリアを検知し、他のすべてのポートを出力モードに切り替えます。この出力モードでは、追加の着信キャリアは衝突です。これにより、ジャム信号がトリガーされ、衝突が伝播され、送信者の送信が停止されます。

この繰り返し方法は、リピーターが物理セグメントジョイントまたはラインエクステンダーとしてのみ使用されていた以前の共有メディアイーサネットバリアント(10BASE5および10BASE2)の動作を模倣します。もちろん、あなたは正しいです。ツイストペアは、ワイヤレベルでは全二重媒体であり、衝突はワイヤ自体ではなく、上位の物理層でのみ発生します。

リピーターは、複数の送信者を同時に許可することはできません。複数の同時送信が出力ポートで混在し、判読できないノイズを生成します。同様に、半二重モードのノードは、全二重伝送ができない共有メディアを想定しています。送信中に検知されたキャリアは衝突であり、送信者はバックオフします。媒体が全二重対応(ファイバー、ツイストペア)であるかどうか(同軸)は関係ありません。

デュプレックスの不一致があると、一方のリンクの端が半二重モードになり、もう一方のリンクの端が全二重モードになります。現在、半二重(HDX)側が送信しているとき、そのレシーバーのキャリアにより衝突が検出されます。ただし、HDX側から受信している間、全二重(FDX)側は喜んで送信する可能性があり、遠側で発生するコリジョンを完全に無視します。HDX側は送信を中止し、ジャム信号を送信する必要があります。FDX側は衝突の疑いを検出できないため、部分的で破損したフレームを検出します。

低周波数で小さなフレームは、このデュプレックスの不一致を乗り越える合理的なチャンスがあるため、ping実際に動作する可能性があります。ただし、重大な送信が開始されるとすぐに、フレーム周波数が高くなりサイズが大きくなるため、送信は非常に確実に失敗します。

管理されていないスイッチでは、特にホストNICでさえもデュプレックスモードが適切に報告されていない場合、デュプレックスの不一致を検出するのが非常に困難です。

管理スイッチでは、通常、ポートエラーカウンターがあります。一方のコリジョンの増加(HDX)と、もう一方のサイドのラントとFCSエラーの増加(FDX)は、デュプレックスミスマッチの非常に強力な兆候です。

基本的に、自動ネゴシエーションに依存することは、デュプレックスの不一致を回避するための非常に良い方法です。速度と二重モードを手動で設定すると、特に数年後に機器を交換する場合は特に、不一致が生じる傾向があります。幸いなことに、半二重方式全体がギガビットイーサネットで高速になりました。


3

マシンAがマシンBへのデータの送信を開始すると仮定します。パケットの送信が開始されると、マシンCはマシンBへの異なるデータの送信を開始します。両方を受け取ります。

マシンBからマシンA、マシンCへの伝送に異なる回路が使用されているという事実は役に立ちません。発生しているのは、AとCがマシンBに同時に送信しようとしており、マシンBへの信号パスが1つしかないことです。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.