13
Redundante Clientverkabelung
Hallo zusammen!
Ich bin gerade dabei die Redundanz in unserem Netzwerk zu verbessern.
Ich habe aktuell ca. 40 Ports zu belegen und da ich 2 Ubiquiti USW-Pro-48-POE (600W) Switche habe um die Clients anzubinden war meine Idee beide Switche mit einem Y-Patchkabel zu verbinden. Leider habe ich diese nur als Cat 5E gefunden.
Meine Idee ist also die Switche exakt gleich zu konfigurieren und die beiden Enden des Y in je einen Switch und das einfache Ende in das Patchfeld zu stöpseln. Aber wie verhält sich das? Kann ich damit RSTP in der Redundanz umgehen? Bin nicht immer vor Ort und im Fall, dass doch mal einer ausfällt, wäre das in meinen Augen eine Alternative zu meinem aktuellen unten beschriebenen Ansatz. Bin gespannt ob ihr mich bestätigt oder doch eher davon abratet.
Aktuell habe ich es so gelöst, dass die Switche schon gleich konfiguriert sind aber eben die Kabel entsprechend nur in einem Teil stecken (ca. 50:50). Im Ausfall und meiner Abwesenheit könnte dann jeder Laie (ja ich weiß er sollte schon wissen die Nase vor dem herausziehen zu drücken) die Kabel aus dem ausgefallenen Switch in den jeweils gleichen Port des noch funktionierenden Switch zu stecken. Oder was meint ihr?
Danke allen im Vorraus für Hinweise, konstruktive Kritik .....
Ich bin gerade dabei die Redundanz in unserem Netzwerk zu verbessern.
Ich habe aktuell ca. 40 Ports zu belegen und da ich 2 Ubiquiti USW-Pro-48-POE (600W) Switche habe um die Clients anzubinden war meine Idee beide Switche mit einem Y-Patchkabel zu verbinden. Leider habe ich diese nur als Cat 5E gefunden.
Meine Idee ist also die Switche exakt gleich zu konfigurieren und die beiden Enden des Y in je einen Switch und das einfache Ende in das Patchfeld zu stöpseln. Aber wie verhält sich das? Kann ich damit RSTP in der Redundanz umgehen? Bin nicht immer vor Ort und im Fall, dass doch mal einer ausfällt, wäre das in meinen Augen eine Alternative zu meinem aktuellen unten beschriebenen Ansatz. Bin gespannt ob ihr mich bestätigt oder doch eher davon abratet.
Aktuell habe ich es so gelöst, dass die Switche schon gleich konfiguriert sind aber eben die Kabel entsprechend nur in einem Teil stecken (ca. 50:50). Im Ausfall und meiner Abwesenheit könnte dann jeder Laie (ja ich weiß er sollte schon wissen die Nase vor dem herausziehen zu drücken) die Kabel aus dem ausgefallenen Switch in den jeweils gleichen Port des noch funktionierenden Switch zu stecken. Oder was meint ihr?
Danke allen im Vorraus für Hinweise, konstruktive Kritik .....
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 73614663960
Url: https://administrator.de/forum/redundante-clientverkabelung-73614663960.html
Ausgedruckt am: 22.12.2024 um 05:12 Uhr
13 Kommentare
Neuester Kommentar
Moin,
Y-Kabel im Netzwerk funktionieren nach meinem Kenntnisstand nicht. Diese Splitteradapter sind eigentlich für etwas anderes gedacht und sind beidseitig anzuwenden.
Aber wenn Du einem Client mehr als einen Netzwerkpfad gleichzeitig zuordnen willst, darfst Du nicht vergessen, dass Du eindeutige Unterscheidung brauchst.
Bei guten Switchen ist das so, dass diese über spezielle Stack-kabel zusammengeschlossen werden können und STromversorgung und Netzwerkbetrieb dadurch redundant werden.
Gruß
Andreas
Y-Kabel im Netzwerk funktionieren nach meinem Kenntnisstand nicht. Diese Splitteradapter sind eigentlich für etwas anderes gedacht und sind beidseitig anzuwenden.
Aber wenn Du einem Client mehr als einen Netzwerkpfad gleichzeitig zuordnen willst, darfst Du nicht vergessen, dass Du eindeutige Unterscheidung brauchst.
Bei guten Switchen ist das so, dass diese über spezielle Stack-kabel zusammengeschlossen werden können und STromversorgung und Netzwerkbetrieb dadurch redundant werden.
Gruß
Andreas
1
Moin,
das mit den Y-Kabeln vergiss mal ganz schnell.
ETHERNET ist dafür nicht ausgelegt und die ganzen SpanningTree-Protokolle sind dafür da, redundante Pfade zu erkennen und je nach ST-Protokoll (MSTP, RSTP, ...) entsprechend zu agieren.
Wenn du deinem Switch so wenig traust (was die Ausfallwahrscheinlichkeit betrifft), warum hast du genau den Hersteller/ das Modell gewählt?
Und wenn wirklich ein Switch ausfällt, musst du eh hin fahren.
Wie weit bist du vom Standort entfernt?
Ich würde mir da mal eher einen vor Ort auserkoren, der (unter telefonischer Anleitung) dich unterstützen kann.
Was machst du denn, wenn dir vor Ort ein Rechner ausfällt?
Wenn du wirkliche Redundanz willst:
Meine Meinung: Aufwand lohnt nicht. Wenn du 1,5h entfernt arbeitest: die Leute können sich meistens auch mal anderweitig beschäftigen.
das mit den Y-Kabeln vergiss mal ganz schnell.
ETHERNET ist dafür nicht ausgelegt und die ganzen SpanningTree-Protokolle sind dafür da, redundante Pfade zu erkennen und je nach ST-Protokoll (MSTP, RSTP, ...) entsprechend zu agieren.
Wenn du deinem Switch so wenig traust (was die Ausfallwahrscheinlichkeit betrifft), warum hast du genau den Hersteller/ das Modell gewählt?
Und wenn wirklich ein Switch ausfällt, musst du eh hin fahren.
Wie weit bist du vom Standort entfernt?
Ich würde mir da mal eher einen vor Ort auserkoren, der (unter telefonischer Anleitung) dich unterstützen kann.
Was machst du denn, wenn dir vor Ort ein Rechner ausfällt?
Wenn du wirkliche Redundanz willst:
- Beide Switche stacken
- in jeden Client eine zweite (passende) NIC verbauen und die NICs zu einem TEAM formen. Am Switch dann natürlich auch ein korrektes LAG für die beiden Ports abbilden.
Meine Meinung: Aufwand lohnt nicht. Wenn du 1,5h entfernt arbeitest: die Leute können sich meistens auch mal anderweitig beschäftigen.
Bei guten Switchen ist das so, dass diese über spezielle Stack-kabel zusammengeschlossen werden können
"Gute" Switches benötigen fürs Stacking keine speziellen Kabel sondern erledigen ein Full Stacking über die normale Netzwerk Infrastruktur. 😉So eine o.a. automatische Client Redundanz bekommt man mit der Nutzung eines 2 Port Netzwerk Interfaces (NIC). Ob als Bridge mit STP Umschaltung oder als LACP LAG ist dabei eher eine kosmetische Frage.
Eine Lösung mit einfachen Y Sharing Adaptern (Modularverteiler) und manuellem Umstecken ist aber auch problemlos möglich.
Man nimmt immer 2 davon, verbindet sie über den gemeinsamen RJ-45 Port und steckt eine Seite auf beide Switches. Auf der anderen Seite kann der Client dann auf den 2 Ports die 2 Switches als Anschluss wählen.
Nachteil ist das die Sharing Adapter auf der gemeinsamen Strecke nur 2 Aderpaare pro Port nutzen können, da ja nur 4 Aderpaare (8 Pins) insgesamt verfügbar sind. Das begrenzt dann die Client Bandbreite fest auf 100 Mbit/s.
Wer damit leben kann und Redundanz bevorzugt ist kann das natürlich so machen.
Hey,
Jo, das mit den Y-Patchkabeln ist keine gute Lösung. Es ist zwar besser als gar keine Redundanz, aber es ist nicht so zuverlässig wie ein LAG.
Bei einem LAG werden zwei oder mehr Links zwischen zwei Switches gruppiert, um eine einzige, virtuelle Verbindung zu bilden. Wenn ein Link ausfällt, wird der Datenverkehr automatisch auf den verbleibenden Links umgeleitet. Das sorgt für eine höhere Verfügbarkeit und Leistung.
Ich würde dir also empfehlen, die Switche mit einem LAG zu verbinden. Das ist die zuverlässigste und einfachste Lösung für die Redundanz in deinem Netzwerk.
Ich hab dir hier einen Link zu einer Anleitung für die Einrichtung eines LAG für Ubiquiti rausgesucht: https://support.hostifi.com/en/articles/6454249-unifi-how-to-enable-link ...
Jo, das mit den Y-Patchkabeln ist keine gute Lösung. Es ist zwar besser als gar keine Redundanz, aber es ist nicht so zuverlässig wie ein LAG.
Bei einem LAG werden zwei oder mehr Links zwischen zwei Switches gruppiert, um eine einzige, virtuelle Verbindung zu bilden. Wenn ein Link ausfällt, wird der Datenverkehr automatisch auf den verbleibenden Links umgeleitet. Das sorgt für eine höhere Verfügbarkeit und Leistung.
Ich würde dir also empfehlen, die Switche mit einem LAG zu verbinden. Das ist die zuverlässigste und einfachste Lösung für die Redundanz in deinem Netzwerk.
Ich hab dir hier einen Link zu einer Anleitung für die Einrichtung eines LAG für Ubiquiti rausgesucht: https://support.hostifi.com/en/articles/6454249-unifi-how-to-enable-link ...
1
Zitat von @Cleanairs:
Jo, das mit den Y-Patchkabeln ist keine gute Lösung. Es ist zwar besser als gar keine Redundanz, aber es ist nicht so zuverlässig wie ein LAG.
Es ist schlechter als gar keine Redundanz weil 100 MBit < 1 GBit.Jo, das mit den Y-Patchkabeln ist keine gute Lösung. Es ist zwar besser als gar keine Redundanz, aber es ist nicht so zuverlässig wie ein LAG.
Bei einem LAG werden zwei oder mehr Links zwischen zwei Switches gruppiert, um eine einzige, virtuelle Verbindung zu bilden. Wenn ein Link ausfällt, wird der Datenverkehr automatisch auf den verbleibenden Links umgeleitet. Das sorgt für eine höhere Verfügbarkeit und Leistung.
Ich würde dir also empfehlen, die Switche mit einem LAG zu verbinden. Das ist die zuverlässigste und einfachste Lösung für die Redundanz in deinem Netzwerk.
Ich würde die beiden Switches untereinander hängen und per LAG verbinden aber die Clients nicht. Lass auf jedem Switch eine Reihe frei so das sich die andere Reihe einfach umpatchen lässt, identisch von der Port-Belegung. Jeder Idiot kann bei Switchausfall die eine Reihe Kabel 1 HE versetzt patchen.
1Wenn der LAG auf Switch-Seite aber an zwei verschiedene Geräte läuft dann müssen diese gestacked sein.
Oder zumindestens eins der verbreiteten MLAG Features supporten wie vPC, MCT, vLAG usw. was auch eine Terminierung eines LACP LAGs auf 2 getrennte Switches möglich macht.Billigheimer UBQT kann es aber erwartbar wohl nicht.
Zitat von @ukulele-7:
Ich würde die beiden Switches untereinander hängen und per LAG verbinden aber die Clients nicht. Lass auf jedem Switch eine Reihe frei so das sich die andere Reihe einfach umpatchen lässt, identisch von der Port-Belegung. Jeder Idiot kann bei Switchausfall die eine Reihe Kabel 1 HE versetzt patchen.Genau das ist ja mein derzeitiger Ansatz. Danke das du zumindest ein bisschen gelesen hast was ich geschrieben habe!
1
Hallo,
https://technogecko.net/msft/how-to-enable-nic-teaming-in-windows-8-8-1- ...
Ggf. je nach Client Ausführung wäre das noch eine Möglichkeit. Evtl. auch die Kombination aus allen Verfahren - je nach Client.
Ich kenne leider die Ubiquiti nicht. Wenn man aber einfach Ports disablen kann, kannst du es ja einfach mal mit ausgwählten Clients testen und dich dann für die beste Methode entscheiden.
Y-Adapter hatte ich mal für ein Kamera-Netz nehmen müssen, da mein Kollege nicht an VLAN etc. glaubte. Die Dinger sind besser als ihr Ruf. Nur muss man mit den oben beschriebenen Einschränkungen leben. Ist halt eine andere Art die Adernpaare zu nutzen. Nicht mehr und nicht weniger.
Die Kosten sind ja überschaubar. Würde an deiner Stelle es einfach ausprobieren und dokumentieren. Damit auch deine Kollgen wissen, wo was hin zu patchen ist. Dann sollte schon viel Schärfe rausgenommen sein.
mfg Crusher
https://technogecko.net/msft/how-to-enable-nic-teaming-in-windows-8-8-1- ...
Ggf. je nach Client Ausführung wäre das noch eine Möglichkeit. Evtl. auch die Kombination aus allen Verfahren - je nach Client.
Ich kenne leider die Ubiquiti nicht. Wenn man aber einfach Ports disablen kann, kannst du es ja einfach mal mit ausgwählten Clients testen und dich dann für die beste Methode entscheiden.
Y-Adapter hatte ich mal für ein Kamera-Netz nehmen müssen, da mein Kollege nicht an VLAN etc. glaubte. Die Dinger sind besser als ihr Ruf. Nur muss man mit den oben beschriebenen Einschränkungen leben. Ist halt eine andere Art die Adernpaare zu nutzen. Nicht mehr und nicht weniger.
Die Kosten sind ja überschaubar. Würde an deiner Stelle es einfach ausprobieren und dokumentieren. Damit auch deine Kollgen wissen, wo was hin zu patchen ist. Dann sollte schon viel Schärfe rausgenommen sein.
mfg Crusher
Da der Switch bei Defekt sowieso getauscht werden muss, geht es also "nur" um eine möglichst schnelle Reaktionszeit, dass alle Clients wieder online sind. Meiner Ansicht nach hast du da die Optionen:
A) Wie schon angedacht am Switch umstecken
B) vierzig 8-polige Y-Adapter besorgen (1x female auf 2x Male) und immer nur einen Switch mit Strom versorgen. Die Stromumschaltung dann per Kippschalter oder smart.
C) alle Clients mit zwei Strecken verbinden
Wenn du bei C) die zweite Strecke mit WLAN realisierst, hast du denke ich die höchste Ausfallsicherheit unter Berücksichtigung der Kosten. Allerdings fallen dann Probleme bei der Netzwerkverkabelung einzelner Clients erst auf, wenn das WLAN ausfällt bzw in dem Fall würde ich überwachen, dass wenn der Client online ist, der entsprechende Port auch online ist, wenn man nicht gerade die Clients selbst überwacht.
A) Wie schon angedacht am Switch umstecken
B) vierzig 8-polige Y-Adapter besorgen (1x female auf 2x Male) und immer nur einen Switch mit Strom versorgen. Die Stromumschaltung dann per Kippschalter oder smart.
C) alle Clients mit zwei Strecken verbinden
Wenn du bei C) die zweite Strecke mit WLAN realisierst, hast du denke ich die höchste Ausfallsicherheit unter Berücksichtigung der Kosten. Allerdings fallen dann Probleme bei der Netzwerkverkabelung einzelner Clients erst auf, wenn das WLAN ausfällt bzw in dem Fall würde ich überwachen, dass wenn der Client online ist, der entsprechende Port auch online ist, wenn man nicht gerade die Clients selbst überwacht.
1
Hallo,
ich verstehe den Sinn nicht so ganz.
Was willst du damit bezwecken? Dass es absolut keine Downtime für deine Clients gibt?
Also wenn wir hier von 40 Clients reden, bezweifle ich, dass es sich hier um besonders kritische Sachen handelt.
Zudem sterben Switche ja im Normalfall nicht reihenweise.
Es gibt meiner Meinung nach nur zwei vernünftige Lösungen.
1. WLAN -> Natürlich nicht mit Desktops möglich, aber hier kann man für kleines Geld nachrüsten.
Hat auch noch den Vorteil, dass die Nic des Clients ausfallen kann oder die Verbindung zum Client.
Die APs einfach auf den anderen Switch gesteckt, und schon kann einer der beiden Switche ausfallen.
2. Zweite Nic in den Clients
LG
ich verstehe den Sinn nicht so ganz.
Was willst du damit bezwecken? Dass es absolut keine Downtime für deine Clients gibt?
Also wenn wir hier von 40 Clients reden, bezweifle ich, dass es sich hier um besonders kritische Sachen handelt.
Zudem sterben Switche ja im Normalfall nicht reihenweise.
Es gibt meiner Meinung nach nur zwei vernünftige Lösungen.
1. WLAN -> Natürlich nicht mit Desktops möglich, aber hier kann man für kleines Geld nachrüsten.
Hat auch noch den Vorteil, dass die Nic des Clients ausfallen kann oder die Verbindung zum Client.
Die APs einfach auf den anderen Switch gesteckt, und schon kann einer der beiden Switche ausfallen.
2. Zweite Nic in den Clients
LG
1Genau das ist ja mein derzeitiger Ansatz.
Wie kann ich einen Beitrag als gelöst markieren?1
Den einzelnen Client redudant anzubinden ist fast immer Schwachsinn. Ein LAG mag hier und da mal bei Traffix intensiven Clients Sinn ergeben aber um mich vor einem Ausfall zu schützen stelle ich mir lieber einen Ersatz-Arbeitsplatz hin.
Ein Switch stirbt total selten. Das einzige was ich schon öfter mit uralten Switches hatte war eine leere Knopfzelle, was bei Stromausfall und z.B. LAG am Switch dann zum Loop führen kann oder zumindest z.B. VLAN Konfigurationen zerlegt.
Ursachen für Stillstand wirst du eher bei der Software finden: fehlerhafte Windows Updates, Virenscanner mit fals positive einer Systemdatei, solche Sachen. Dann steht schnell der ganze Laden egal wie viele Leitungen du redundant aufgebaut hast.
Ein Switch stirbt total selten. Das einzige was ich schon öfter mit uralten Switches hatte war eine leere Knopfzelle, was bei Stromausfall und z.B. LAG am Switch dann zum Loop führen kann oder zumindest z.B. VLAN Konfigurationen zerlegt.
Ursachen für Stillstand wirst du eher bei der Software finden: fehlerhafte Windows Updates, Virenscanner mit fals positive einer Systemdatei, solche Sachen. Dann steht schnell der ganze Laden egal wie viele Leitungen du redundant aufgebaut hast.
2
omg - ich habe bei "Y-Patchkabel" aufgehört zu lesen...
1
