S3lph at 01:30, 3 December 2022

2022-12-03T01:30:17Z

← Older revision		Revision as of 01:30, 3 December 2022
Line 1:		Line 1:
			[[File:3thernet verpackt.jpg\|thumb\|640px\|Ein funktionierendes Ethernetkabel mit 3 Enden in halbwegs schöner Verpackung.]]

	Projekt von [[User:S3lph\|s3lph]], Ende 2022. Ein Ethernetkabel mit 3 Enden.		Projekt von [[User:S3lph\|s3lph]], Ende 2022. Ein Ethernetkabel mit 3 Enden.

S3lph: Created page with "Projekt von s3lph, Ende 2022. Ein Ethernetkabel mit 3 Enden. == WARUM?!?! == Im beruflichen Kontext bin ich über folgende Argumentation gestolpert:

 E..."

2022-12-03T01:21:53Z

Created page with "Projekt von s3lph, Ende 2022. Ein Ethernetkabel mit 3 Enden. == WARUM?!?! == Im beruflichen Kontext bin ich über folgende Argumentation gestolpert: <pre> E..."

New page

Projekt von [[User:S3lph|s3lph]], Ende 2022. Ein Ethernetkabel mit 3 Enden.

== WARUM?!?! ==

Im beruflichen Kontext bin ich über folgende Argumentation gestolpert:

<pre>
Ein 3-Node-Cluster ist nicht möglich wegen:
- Netzwerklimitierung (Ein Netzwerkkabel hat nur 2 Enden!)
- ...
</pre>

Ignorieren wir mal, dass es diese grün blinkenden Pizzaboxen namens "Switche" gibt... und versuchen, die Absurdität dieser Argumentation auf eine andere Weise aufzuzeigen:

«Was wäre, wenn ein Netzwerkkabel wirklich mehr als 2 Enden hätte».

So war die Idee geboren, ein 3-endiges Netzwerkkabel zu bauen.

== Das Kabel ==

Nach ein paar Versuchen ist folgende Verdrahtung herausgekommen:

[[File:3thernet Verkabelung.png|Die Verdrahtung der 3 Enden miteinander. Jedes TX-Differentialpaar wird in Tx+ und Tx- getrennt, und die beiden Einzeldrähte gehen an die passenden Rx-Leitungen von den zwei jeweils anderen Enden.]]

Jedes TX-Differentialpaar wird in Tx+ und Tx- getrennt, und die beiden Einzeldrähte gehen an die passenden Rx-Leitungen von den zwei jeweils anderen Enden:

<pre>
A/Tx+ -> B/Rx+
A/Tx- -> C/Rx-
B/Tx+ -> C/Rx+
B/Tx- -> A/Rx-
C/Tx+ -> A/Rx+
C/Tx- -> B/Rx-
</pre>

Und so sieht das in gemurkst mit 3 Switches und einem Breadboard aus:

[[File:3thernet Breadboard.jpg|640px]]

Das ganze funktioniert aber nur in 10BASE-T, und die Ports müssen händisch auf 10 Mbps, Half-Duplex, MDI konfiguriert werden.

== Test-Setup ==

Um das ganze zu testen, hatte ich folgendes Test-Setup aufgebaut:

[[File:3thernet setup.png]]

=== LLDP ===

Zuerst sollten die Switches sich gegenseitig sehen können. Die Switches sprechen in der Standardkonfiguration LLDP, daher musste hier nur die Tabelle ausgegeben werden:

Auf AAAA:

<syntaxhighlight lang="shell-session">
AAAA# show lldp info remote-device 26

LLDP Remote Device Information Detail

Local Port : 26
ChassisType : mac-address
ChassisId : 00 24 a8 05 24 00
PortType : local
PortId : 26
SysName : BBBB
System Descr : ProCurve J9019B Switch 2510B-24, revision Q.11.75, ROM Q....
PortDescr : 26

System Capabilities Supported : bridge
System Capabilities Enabled : bridge

Remote Management Address
Type : ipv4
Address : 10.0.0.2

------------------------------------------------------------------------------
Local Port : 26
ChassisType : mac-address
ChassisId : 00 24 a8 05 55 20
PortType : local
PortId : 26
SysName : CCCC
System Descr : ProCurve J9019B Switch 2510B-24, revision Q.11.75, ROM Q....
PortDescr : 26

System Capabilities Supported : bridge
System Capabilities Enabled : bridge

Remote Management Address
Type : ipv4
Address : 10.0.0.3
</syntaxhighlight>

Auf BBBB:

<syntaxhighlight lang="shell-session">
BBBB# show lldp info remote-device 26

LLDP Remote Device Information Detail

Local Port : 26
ChassisType : mac-address
ChassisId : 00 24 a8 05 55 20
PortType : local
PortId : 26
SysName : CCCC
System Descr : ProCurve J9019B Switch 2510B-24, revision Q.11.75, ROM Q....
PortDescr : 26

System Capabilities Supported : bridge
System Capabilities Enabled : bridge

Remote Management Address
Type : ipv4
Address : 10.0.0.3

------------------------------------------------------------------------------
Local Port : 26
ChassisType : mac-address
ChassisId : 00 1c 2e 55 48 c0
PortType : local
PortId : 26
SysName : AAAA
System Descr : ProCurve J9019B Switch 2510B-24, revision Q.11.17, ROM Q....
PortDescr : 26

System Capabilities Supported : bridge
System Capabilities Enabled : bridge

Remote Management Address
Type : ipv4
Address : 10.0.0.1
</syntaxhighlight>

Und auf CCCC:

<syntaxhighlight lang="shell-session">
CCCC# show lldp info remote-device 26

LLDP Remote Device Information Detail

Local Port : 26
ChassisType : mac-address
ChassisId : 00 24 a8 05 24 00
PortType : local
PortId : 26
SysName : BBBB
System Descr : ProCurve J9019B Switch 2510B-24, revision Q.11.75, ROM Q....
PortDescr : 26

System Capabilities Supported : bridge
System Capabilities Enabled : bridge

Remote Management Address
Type : ipv4
Address : 10.0.0.2

------------------------------------------------------------------------------
Local Port : 26
ChassisType : mac-address
ChassisId : 00 1c 2e 55 48 c0
PortType : local
PortId : 26
SysName : AAAA
System Descr : ProCurve J9019B Switch 2510B-24, revision Q.11.17, ROM Q....
PortDescr : 26

System Capabilities Supported : bridge
System Capabilities Enabled : bridge

Remote Management Address
Type : ipv4
Address : 10.0.0.1
</syntaxhighlight>

=== ICMP ===

LLDP ist aber rein unidirektional, es findet kein Handshake o.Ä. statt. Daher auch noch via ICMP. Dafür mussten die Switches erst IP-Adressen haben (und können natürlich nur v4 :/ ), dann geht auch ping:

<syntaxhighlight lang="shell-session">
AAAA# ping 10.0.0.2
10.0.0.2 is alive, time = 1 ms
AAAA# ping 10.0.0.3
10.0.0.3 is alive, time = 1 ms
</syntaxhighlight>

<syntaxhighlight lang="shell-session">
BBBB# ping 10.0.0.1
10.0.0.1 is alive, time = 25 ms
BBBB# ping 10.0.0.3
10.0.0.3 is alive, time = 1 ms
</syntaxhighlight>

<syntaxhighlight lang="shell-session">
CCCC# ping 10.0.0.1
10.0.0.1 is alive, time = 25 ms
CCCC# ping 10.0.0.2
10.0.0.2 is alive, time = 1 ms
</syntaxhighlight>

=== iperf3 ===

Und jetzt mit etwas mehr Traffic: An einen anderen Port an BBBB kommt ein iperf3-Server, und an AAAA ein iperf3-Client:

<syntaxhighlight lang="shell-session">
$ iperf3 --bidir -c fe80::23%eno1 -p 12345
Connecting to host fe80::23%eno1, port 12345
[ 5] local fe80::42 port 49622 connected to fe80::23 port 12345
[ 7] local fe80::42 port 49626 connected to fe80::23 port 12345
[ ID][Role] Interval Transfer Bitrate Retr Cwnd
[ 5][TX-C] 0.00-1.00 sec 520 KBytes 4.26 Mbits/sec 2 29.3 KBytes
[ 7][RX-C] 0.00-1.00 sec 319 KBytes 2.62 Mbits/sec
[ 5][TX-C] 1.00-2.00 sec 583 KBytes 4.78 Mbits/sec 1 29.3 KBytes
[ 7][RX-C] 1.00-2.00 sec 291 KBytes 2.39 Mbits/sec
[ 5][TX-C] 2.00-3.00 sec 322 KBytes 2.64 Mbits/sec 3 16.7 KBytes
[ 7][RX-C] 2.00-3.00 sec 459 KBytes 3.76 Mbits/sec
[ 5][TX-C] 3.00-4.00 sec 307 KBytes 2.51 Mbits/sec 2 12.6 KBytes
[ 7][RX-C] 3.00-4.00 sec 347 KBytes 2.84 Mbits/sec
[ 5][TX-C] 4.00-5.00 sec 537 KBytes 4.40 Mbits/sec 1 23.7 KBytes
[ 7][RX-C] 4.00-5.00 sec 297 KBytes 2.43 Mbits/sec
[ 5][TX-C] 5.00-6.00 sec 568 KBytes 4.65 Mbits/sec 0 37.7 KBytes
[ 7][RX-C] 5.00-6.00 sec 234 KBytes 1.92 Mbits/sec
[ 5][TX-C] 6.00-7.00 sec 568 KBytes 4.65 Mbits/sec 1 33.5 KBytes
[ 7][RX-C] 6.00-7.00 sec 324 KBytes 2.65 Mbits/sec
[ 5][TX-C] 7.00-8.00 sec 460 KBytes 3.77 Mbits/sec 3 19.5 KBytes
[ 7][RX-C] 7.00-8.00 sec 238 KBytes 1.95 Mbits/sec
[ 5][TX-C] 8.00-9.00 sec 476 KBytes 3.90 Mbits/sec 2 23.7 KBytes
[ 7][RX-C] 8.00-9.00 sec 297 KBytes 2.43 Mbits/sec
[ 5][TX-C] 9.00-10.00 sec 368 KBytes 3.02 Mbits/sec 0 34.9 KBytes
[ 7][RX-C] 9.00-10.00 sec 329 KBytes 2.70 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID][Role] Interval Transfer Bitrate Retr
[ 5][TX-C] 0.00-10.00 sec 4.60 MBytes 3.86 Mbits/sec 15 sender
[ 5][TX-C] 0.00-10.02 sec 4.46 MBytes 3.73 Mbits/sec receiver
[ 7][RX-C] 0.00-10.00 sec 3.14 MBytes 2.64 Mbits/sec 20 sender
[ 7][RX-C] 0.00-10.02 sec 3.06 MBytes 2.56 Mbits/sec receiver

iperf Done.
</syntaxhighlight>

Die Retransmit Counters fallen hier schon ins Auge. Und so sieht das auf einem der Switches aus:

<syntaxhighlight lang="shell-session">
BBBB# show interfaces 26

Status and Counters - Port Counters for port 26

Name :
Link Status : Up
Totals (Since boot or last clear) :
Bytes Rx : 4,428,572 Bytes Tx : 4,501,623
Unicast Rx : 5609 Unicast Tx : 4442
Bcast/Mcast Rx : 9 Bcast/Mcast Tx : 1
Errors (Since boot or last clear) :
FCS Rx : 18 Drops Rx : 0
Alignment Rx : 0 Collisions Tx : 3564
Runts Rx : 0 Late Colln Tx : 0
Giants Rx : 0 Excessive Colln : 0
Total Rx Errors : 1784 Deferred Tx : 0
Rates (5 minute weighted average) :
Total Rx (bps) : 241008 Total Tx (bps) : 240176
Unicast Rx (Pkts/sec) : 28 Unicast Tx (Pkts/sec) : 22
B/Mcast Rx (Pkts/sec) : 0 B/Mcast Tx (Pkts/sec) : 0
Utilization Rx : 02.41 % Utilization Tx : 02.40 %
</syntaxhighlight>

== Fazit ==

«If it's stupid, but it works, it ain't stupid!»

Ein Ethernet-Kabel mit 3 Enden ist möglich*, aber definitiv nicht nützlich!

(* mit starken Einschränkungen)

[[Category:Projekt]]
[[Category:Projekt:Abgeschlossen]]

3thernet - Revision history

S3lph at 01:30, 3 December 2022

S3lph: Created page with "Projekt von s3lph, Ende 2022. Ein Ethernetkabel mit 3 Enden. == WARUM?!?! == Im beruflichen Kontext bin ich über folgende Argumentation gestolpert:
E..."