Damals war das modulare ACO-System von AMP en vogue. Sie erinnern sich: Man verlegte ein hochwertiges vierpaariges Kabel und legte es auf eine würfelförmige, silberglänzende Anschlussdose auf. Hier steckte man dann das eigentliche Anschlussmodul hinein. Es gab Anschlussmodule mit einer RJ-45-Buchse, achtadrig belegt. Darüber hinaus wurden Module mit zwei RJ-45-Buchsen angeboten, die entweder für Ethernet (Paare 1/2, 3/6) oder für ISDN (Paare 3/6, 4/5) beschaltet waren. Das nannte man „Cable Sharing“.
Zweimal Ethernet über ein und dasselbe Kabel, das ist effizient. Und 100 Mbit/s sind für die meisten Clients noch heute mehr als ausreichend. Wer wirklich Gigabit Ethernet am Endgerät brauchte, konnte nachträglich die achtadrigen Einsätze einbauen. Das haben aber die wenigsten gemacht, wir bei ComConsult jedenfalls nicht…
Neulich erzählte mir ein Kunde von folgendem Problem in Zusammenhang mit Cable-Sharing: Nach dem Austausch von Access Switches meldeten Anwender fehlende Netzverbindung nach dem Booten. Die Rechner meldeten „kein Internetzugang“, obwohl die LED am Ethernet-Adapter blinkte. Die Prüfung der IP-Adressen betroffener Rechner zeigte Adressen im Netz 169.254.0.0/16. Die vergibt sich der Client selbst, wenn der DHCP-Server nicht antwortet.
„Kenne ich“, werden Sie sagen: „Das liegt am Spanning Tree Protocol“. Ja, das kann sein. Hier aber hatte es einen anderen Grund: Die neuen Access Switches verfügen über Gigabit Ethernet (1000Base-T). Im Rahmen der Auto-Negotiation tauschen Client und Switch zunächst mittels sogenannter Link Pulses ihre Fähigkeiten aus. Man einigt sich auf das Schnellstmögliche, hier also den 1000Base-T-Standard.
Dieser Vorgang funktioniert auch bei Cable-Sharing, denn dafür werden die zwei Adernpaare des uralten 10Base-T genutzt. Die anschließende Gigabit-Datenübertragung wird aber dank der beiden fehlenden Adernpaare fehlschlagen. Und das wussten bereits die Autoren des Ethernet-Standards. In Kapitel 28.1.4.3 findet sich der folgende Absatz:
“The system administrator/installer must take the cabling capability into consideration when configuring a repeater port’s advertised capability. That is, the advertised capability of a hub port should not result in an operational mode that is not compatible with the cabling.”
Mit anderen Worten: Wenn Sie die beschriebene Konfiguration einsetzen, müssen Sie dem Switch verbieten, Gigabit Ethernet zu nutzen. Man konfiguriere also die Ports auf 100 Mbit/s halbduplex. Ja genau, „halbduplex“. Denn sonst handeln Sie sich mit einem Duplex Mismatch das nächste Problem ein, aber das ist eine andere Geschichte (wenn Sie Näheres dazu wissen möchten, rufen Sie mich an!).
Mindestens genauso interessant finde ich die Sache mit den Telefonen. Ungeachtet der inzwischen weiten Verbreitung von Teams, Webex & Co. werden viele von Ihnen noch ein Desk Phone am Arbeitsplatz haben. Sehr wahrscheinlich handelt es sich um ein modernes VoIP Phone. Um Switch-Ports zu sparen, ist Ihr Client am Telefon angeschlossen. Dazu befindet sich im Telefon ein Ethernet Switch, der die Verbindung vom Client über das Telefon zum LAN-Switch ermöglicht.
Ist Ihnen schon einmal aufgefallen, dass die Performance Ihres Clients zu wünschen übrig lässt? Beim Download ist alles in Ordnung, doch wenn Sie größere Dateien auf dem Server ablegen wollen, dauert es unerträglich lange!
Das könnte am Telefon liegen. Zwei Voraussetzungen müssen hierfür zusammentreffen:
- Das Telefon verfügt über 1000Base-T Ports.
- Das Telefon ist mit Fast Ethernet am LAN-Switch angebunden, weil Sie z.B. Cable-Sharing einsetzen.
Der Client wird sich per Gigabit Ethernet mit dem Telefon verbinden. Wenn der Client Daten sendet, muss sie der Switch im Telefon zwischenspeichern, bevor er sie mit Fast Ethernet weitersendet. Leider verfügen die Switches vieler Telefone nur über ein Minimum an Pufferkapazität. Ich habe es mit meinem Siemens OpenStage 60 ausprobiert. Gerade zwei Pakete kann das Telefon aufnehmen.
TCP-Verbindungen, die der Client mit Servern unterhält, werden sich optimal auf diese Verhältnisse einstellen. Der Client wird immer nur zwei Pakete senden und dann auf eine Bestätigung des Servers warten. Zwei Pakete sind knapp 3000 Byte Nutzlast.
Jetzt stellen Sie sich vor, Client und Telefon befinden sich in einer Außenstelle ohne eigenen Server. Der „Ping“ (Round Trip Time) zum Rechenzentrum beträgt z.B. 5 Millisekunden. Dann werden alle 5 Millisekunden 3000 Byte übertragen – macht 4,8 Mbit/s. Da hilft es nichts, wenn Ihre Außenstelle mit 100 Mbit/s angebunden ist.
Probieren Sie es aus und konfigurieren Sie Telefon oder Client so, dass ausschließlich Fast Ethernet genutzt wird. Nun kann das Telefon jedes empfangene Paket mit derselben Geschwindigkeit weiterschicken. Es braucht nichts zwischengespeichert zu werden. LAN-Switches und WAN-Router besitzen viel größere Puffer, und TCP wird das zu nutzen wissen. Zum Vorteil Ihrer Anwender!
