01.03.2021

4503

Probleme im Netzwerk Switche teilweise nicht erreichbar

Guten Morgen,

seit Monaten haben wir hier immer wieder Probleme mit dem Netzwerk, das Problem konnte ich leider aber noch immer nicht finden. Es sind insgesamt 5 Gebäude miteinander verbunden. Leider bricht immer mal wieder die Verbindung zu einem Switch, an dem noch ein weiterer Switch hängt ab.

Alle Switche sind mit Cat 7 Kabeln auf entsprechenden Patchpanels aufgelegt und wurden auch erfolgreich auf Durchgang geprüft.

Einen defekt der Switche kann ich ebenfalls ausschließen, da ich alle bereits testweise ausgetauscht hatte, das Problem aber dennoch auftrat.

Ich vermute, dass hier die Erdung ein Problem sein könnte, da die Netzwerkschränke nur im jeweiligen Gebäude geerdet sind, nicht aber alle miteinander verbunden sind.

Hat jemand von euch noch eine Idee wo hier das Problem schlummern könnte?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 657736

Url: https://administrator.de/forum/probleme-im-netzwerk-switche-teilweise-nicht-erreichbar-657736.html

Ausgedruckt am: 27.12.2024 um 10:12 Uhr

32 Kommentare

Neuester Kommentar

Hallo,

Das mit dem fehlenden Potentialausgleich zerstört Dir im Zweifelsfall die Hardware.

Ansonsten: Welche Switche, welche Topologie?

Grüße

lcer

Im Serverrack hängt ein Netgear XS716T, dieser ist mit einem Netgear GS724Tv4 sowie einem XS708T verbunden. Am GS724Tv4 hängen im Büro 6 PCs, einige Drucker, die Telefonanlage usw. hängen. Außerdem ist eine weitere Halle mit dem GS724Tv4 angeschlossen. Dort hängt ein Einzelbüro an einem Ubiquiti US-8 Switch.

Der XS708T ist in einer Produktionshalle nur als Verteiler, da sonst die Strecken der Cat-Leitungen vermutlich zu lange geworden wären. Daran hängt nochmals ein Netgear XS708T, sowie ein Ubiquiti US-8.

Eben habe ich den XS708T neu gestartet, dann war das Netzwerk ca. 5 Minuten erreichbar, nun ist die Verbindung wieder weg...

Der Switch hat doch bestimmt die Möglichkeit ein Log anzuzeigen, was steht denn da drin?

Guten Morgääähhhhn

Zitat von @hukiman:

Leider bricht immer mal wieder die Verbindung zu einem Switch, an dem noch ein weiterer Switch ....

Es ist definitiv die Verbindung zwischen dem 1. Switch der Kaskade zum (Core)Switch? Du hast zwischen den Gebäuden Kupferleitungen? Wie lang sind die? Die beste Lösung wäre Glasfaser zwischen den Gebäuden, kostet zwar was, aber ob die Abbrüche der letzten Monate so günstig waren?

Ansonsten, wer hat die Kabel verlegt? Wann? Gewährleistung?

Ob ich jetzt ein "Erdungskabel" zur Verbindung einziehe oder Glasfaser ist egal, das eine löst das Problem vielleicht, das andere ziemlich sicher.

Moin,

welcher Elektriker verlegt denn Cat 7 zwischen Gebäuden?

Ich würde mit 2 Media-Converter auf LWL und zurückwandeln um das Problem mit dem Potentialausgleich zu lösen.
Vieleicht sind Deine Probleme dann schon weg.

Mal vor Ort getestet ob der Switch da noch funktioniert?

Stefan

Die Leitungen liegen da schon lange drin... Die Leitungen gingen damals wohl kaum durch die Leerrohre, daher bin ich nicht scharf darauf hier etwas zu tauschen.

Ja, das mit dem Converter wäre eine Möglichkeit, die Netgear Switche haben ohnehin schon 2 Glasfaserports. Ansonsten wäre so ein Netzwerkisolator evtl. noch eine Möglichkeit.

Es würde ja dann auch an einer Seite der Verbindung ein Converter oder Netzwerkisolator ausreichen oder muss das immer beidseitig eingesetzt werden?

Die Zuleitungen müsste ich dann aber in jedem Fall vom Patchpanel nehmen, gibt es da Bauteile fürs Rack um nur die einzelne Leitung aufzulegen? Oder einen Converter, auf den man direkt auflegen kann? Ein weiteres Patchpanel für 1 Kabel wäre wohl etwas oversized.

Moin,
das mit dem Isolator hat den gleichen Effekt.
Ich würde 2 Media-Converter und ein 1m OM4 Kabel (weil ich die haben

) direkt vor dem Switch an dem betroffenen Standort packen.
Stefan

Hallo Stefan,

okay, werde ich versuchen. Mit welchen Convertern und Kabel hast du gute Erfahrungen gemacht? Dann werde ich das testen und wieder berichten.

Die Zuleitung muss dann aber von Patchpanel runter, damit nichts auf die anderen Kabel übertragen wird oder?

Ideal wäre ja ein Converter, auf den man direkt auflegen könnte.

Zitat von @hukiman:
Die Leitungen liegen da schon lange drin...

Frage: Hat das jemals funktioniert? Wielange und mit welcher Geschwindigkeit?
Bezüglich dem "Gebäudeverbindungskabel": Wie schauts da mit der Feuchtigkeit (Eis?) im Rohr und so aus?

Ja, das hat jahrelang ohne Probleme funktioniert. Wie gesagt, die Leitungen habe ich auch durchgemessen, die funktionieren problemlos.

Zitat von @hukiman:
Die Zuleitung muss dann aber von Patchpanel runter, damit nichts auf die anderen Kabel übertragen wird oder?

Ach, das Kabel aus der Wand ist direkt auf dem Patchpanel?
Sorry, dumm von mir, ist natürlich auf dem Patchfeld.
Ja, dann muss da das runter um den gewünschten Effekt zu erziehlen.

Stefan

Ja, genau...

Mit welchen Convertern und Kabel hast du gute Erfahrungen gemacht? Ideal wäre ja ein Converter, auf den man direkt auflegen könnte. Gibt es Keystone Halter für einen einzigen Keystone?

Zitat von @hukiman:
Ja, das hat jahrelang ohne Probleme funktioniert. .....

Ok, wenns jahrelang funktioniert hat ..... knapp funktioniert hat und jetzt, aufgrund von Alterung, Näße, Eis, Länge in der Nähe des Limits eben nicht mehr, dann mußt Du eben das Kabel tauschen.

Aber teste es zuerst mit Stefans Dingern ..... einen Versuch ist es sicher wert.

Hallo,

Zitat von @hukiman:

Ja, das hat jahrelang ohne Probleme funktioniert. Wie gesagt, die Leitungen habe ich auch durchgemessen, die funktionieren problemlos.

Was hat sich denn dann geändert?

Lies bitte die Switch-Logs. Da müsste drinstehen, was mit dem Port passiert.

Was heißt es eigentlich, dass die Verbindung nicht funktioniert? Link weg / Lampe aus oder Lampe an und trotzdem keine Verbindung mit Ping bzw. Webinterface? Wie gesagt, die Logs sollten Dir weiterhelfen.

Wieso hast Du eigentlich noch nicht exakt identifiziert, welcher Link / welches Kabel betroffen ist? Wenn Du sogar schon die Leitungen durchgemessen hast? Es ist jedenfalls sinnvoll zuerst das Problem zu isolieren und dann an der Lösung zu arbeiten. Vielleicht ist der Potentialausgleich ja gar nicht das aktuelle Problem?

Grüße

lcer

noch eine Idee wo hier das Problem schlummern könnte?

Kein oder fehlerhaft designtes Spanning Tree Protokoll. Fehlen eines STP Root und Backup Root Switches mit entsprechender STP Priority. Da passiert dann sowas.
Leider ist die Beschreibung dafür aber zu oberflächlich und man kann nur raten.

Hallo aqui,

STP war auf allen Switches ab Werk schon aktiv, hier habe ich nichts verändert. Anbei ein Screenshot.

Das Problem ist wohl die Verbindung vom "Hauptswitch" XS716T zum "Switch in der Mitte", hier habe ich fast 9000 Link Down events. Hier würde ich jetzt mal mit dem Adapter auf LWL testen.

Was war der schlechteste NEXT Wert?

STP war auf allen Switches ab Werk schon aktiv, hier habe ich nichts verändert

Und genau das ist das Fatale. Vermutlich aus fachlichem Unwissen ist das unterblieben. Damit wird der Root Switch willkürlich nach der niedrigsten Mac Adresse ausgewählt und kann dann der 5 Port Miniswitch bei der Sekretärin auf dem Schreibtisch sein. Ein fataler Fehler !

Der "Hauptswitch" XS716T" hat deshalb eine fehlerhafte STP Konfiguration. RSTP ist schon richtig aber dieser Hauptswitch (Core) muss zwingend eine höhere RSTP Priority haben wie z.B. 8192 (modulo 4096). Damit ist dann sichergestellt das er Root Switch wird im Netz und die Root Uplinks niemals in den Blocking Mode gehen bei einem Topology Change. Jeder "Link Down" Event triggert einen Topology Change der dann für die Dauer von 2-5 Minuten die Uplinks in den STP Blocking Mode versetzt. Genau also dein Verhalten.
Das wäre unterblieben hättest du den Spanning Tree sauber und richtig konfiguriert. Netzwerklaien ignoirieren so etwas fatalerweise oft.
Die STP Priority des Switches wird vermutlich im Advanced Setup gesetzt.

Generell sind aber die "Link Down" Events die Ursache des Übels. Diese lösen die STP Topology Chjanges aus die dann die Blockings und die Unterbrechungen bewirken. Eine Ursachenkette also.
Die "Link Down" Events werden häufig durch defekte Kabel, defekte Ports und defekte optische SFP Transceiver ausgelöst. Hier gilt es also genau rauszufinden welche Ports betroffen sind und das abzustellen.

Zitat von @aqui:

Damit wird der Root Switch willkürlich nach der niedrigsten Mac Adresse ausgewählt ....

Nachdem es jahrelang funktioniert hat und nichts verändert wurde hätte ich jetzt den Fehler nicht im spanning tree gesucht

Nachdem es jahrelang funktioniert hat und nichts verändert wurde

Na ja mal ehrlich... Diese Ammenmärchen Aussage hört jeder Netzwerker gefühlt 10mal am Tag und zu 99,99% stimmt diese nie wie alle wissen.

Irgendwo hat immer einer ein Kabel gezogen, verändert, einen Miniswitch installiert, falsch gesteckt usw. usw.
Der TO hat sicher niemals in der Zeit in irgendwelche Switch Logs gesehen oder kontrolliert was in seiner Infrastruktur passiert....wetten ?!

Mahlzeit,

@gilligan: Ich habe nur mit einem einfachen Gerät getestet, alle 8 Adern sowie die Schirmung sind sauber verbunden. Einen NEXT Wert kann man Gerät nicht ermitteln.

Der Switch kann auch die Kabel prüfen, hier bekomme ich die Leitungslängen angezeigt und als Status bei allen Kabeln Normal. Das Problem ist eurer Meinung nach dann aber die Kabelverbindung? Das heißt, hier sollte ich mit einem anderen Gerät testen? Welche Geräte nutzt ihr für solche Zwecke?

@aqui: Ja, man sollte meinen, dass man so etwas in der Ausbildung zum Betriebsinformatiker lernt, aber dem ist leider nicht so...

In den Advanced Einstellungen kann ich unter CST Configuration die Bridge Priority von 0 bis 61440 verstellen, diese steht auf 32768. Außerdem gibt es einen Punkt MST Configuration, hier steht die Priotity auf 32768. Ansonsten finde ich keine Einstellung in der man explizit eine RSTP Priority einstellen kann...

Die Konfiguration der Switche ist schon komplex, vor allem weil jeder Hersteller natürlich sein eigenes Süppchen kocht und teilweise andere Bezeichnungen verwendet. Und ja, aus Unwissenheit wurde hier nichts verstellt und alles bei den Werkseinstellungen belassen. Kannst du hier eine bestimmte Fortbildung oder ein Buch etc. empfehlen, bei der man sich dieses Wissen aneignen kann?

@Franz-Josef-II Wenn du zitierst, dann bleibe bitte beim Original Text...

Hier nochmal der Aufbau zum Verständnis:

- XS716T als Hauptswitch
--GS724Tv4
---Ubiquiti US-8
--XS708T (hier habe ich die knapp 9000 Links down Ereignisse)
---XS708T
---Ubiquiti US-8

in der Ausbildung zum Betriebsinformatiker lernt, aber dem ist leider nicht so...

Das lernt sogar der FiSi im ersten Lehrjahr schon, denn es gehört zu den Grundpfeilern einer stabilen Netzwerk Installation wie Stoßdämpfer bei der Autokarosserie ! 😉

vor allem weil jeder Hersteller natürlich sein eigenes Süppchen kocht

Das das Quatsch ist weisst du auch selber. RSTP ist mit 802.1w ein weltweiter Standard an den sich alle Hersteller halten. Mit solchen zweifelhaften Aussagen sollte man in einem Administrator Forum immer etwas vorsichtiger sein.

Außerdem gibt es einen Punkt MST Configuration, hier steht die Priotity auf 32768.

MSTP ist Multiple Spanning Tree was mehrere VLANs zu eine STP Instanz zusammenfassen kann im Gegensatz zu anderen klassischen Spanning Tree Protokollen wie STP, RSTP, PVSTP oder PVSTP+
Wie du aber oben in deinem Screenshot selber sehen kannst und STP Operation Mode ist MSTP als Spanning Tree Protokoll bei dir gar nicht aktiv sondern einzig nur RSTP und nix anderes. Der Einwand ist also irrelevant für dein aktuelles Setup.
32768 ist die Default STP Priority die weltweit auf allen Switches so gesetzt ist. Priority Werte gehen von 4096 bis 61440. Kleinere Werte haben die höhere Priority und sie müssen Modulo 4096 vergeben werden.
Erlaubte Werte sind also: 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344 und 61440.

Deshalb die Empfehlung den XS716T als Hauptswitch zwingend auf 8192 zu setzen um diesen dann dediziert als RSTP Root Switch im Netz zu setzen.
Bei einem Priority Gleichstand entscheidet sonst die niedrigeste Mac Adresse ! Deshalb ist es bei dir dann immer völlig willkürlich wenn alle Switches unkonfiguriert den Default Wert haben und ein fataler RSTP Konfig Fehler.

Guckst du zu dem Thema auch hier:
Kaskadierung zwischen zwei HP Procurve 2810-24g Switchen über VLAN
Frage zur Konfiguration von Switchen zur Vermeidung eines Loops bei redundanter Anbindung

Vielen Dank für deinen aufschlussreichen Beitrag! Ich habe den Switch nun so konfiguriert.

Zwecks der Leitung werde ich das jetzt mal mit einem Medienconverter versuchen und auch die Leitung nochmals genauer durchmessen.

Ich würde CISCO empfehlen

auch den Netzwerkkurs, da habe ich einiges gelernt. Ansonsten ein paar Links zu durchlesen.

https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-p ...
https://www.cisco.com/c/de_de/support/docs/lan-switching/spanning-tree-p ...
https://www.ict.tuwien.ac.at/lva/384.081/datacom/07-Spanning-Tree_Detail ...
http://ccna-powertraining.de/wp-content/uploads/2019/07/STP-Konfigurati ...

Zitat von @aqui:
Na ja mal ehrlich... Diese Ammenmärchen Aussage hört jeder Netzwerker gefühlt 10mal am Tag und zu 99,99% stimmt diese nie wie alle wissen.

Das ist schon richtig, .... nur einem Fachmann glaube ich das prinzipiell .... und wenn es nicht stimmt .... er muß wissen, was es sagt und tut .... da bin ich "teflonbeschichtet", es prallt ab

Bei Usern, speziell meinen Usern, schaut die Sache ganz anders aus

Hallo,

Zitat von @hukiman:

Hier nochmal der Aufbau zum Verständnis:

- XS716T als Hauptswitch
--GS724Tv4
---Ubiquiti US-8
--XS708T (hier habe ich die knapp 9000 Links down Ereignisse)
---XS708T
---Ubiquiti US-8

Aldo nach meinem Verständnis müsstest Du doch an 2 Switchen die gleiche Anzahl von Link-Down-Events haben, wenn es am Kabel dazwischen liegt, oder?

Grüße

lcer

Zitat von @hukiman:
@Franz-Josef-II Wenn du zitierst, dann bleibe bitte beim Original Text...

Was habe ich verändert? Ich habe nur das davor und danach weggeschnitten, der Rest ist original übernommen.

Zitat von @hukiman:
Hier nochmal der Aufbau zum Verständnis:

- XS716T als Hauptswitch
--GS724Tv4
---Ubiquiti US-8
--XS708T (hier habe ich die knapp 9000 Links down Ereignisse)
---XS708T
---Ubiquiti US-8

D.h. Hauptswitch -> nächstes Gebäudeswitch -> ein Port geht zum übernächsten Gebäude? Also zwei Gebäude hängen direkt am Hauptswitch und drei Gebäude über den "ersten Nebenswitch"?

Der XS708T mit den knapp 9.000 ..... zum Haupt- oder zum einem der nächsten Switchebene? Da gebe ich Icer00 recht, die Gegenstelle sollte das gleiche anzeigen. Ok, nach nochmaligen durchlesen Haupt- zum ersten Nebenswitch

Du hast eine reine Sternverkabelung? Dann spielt spanning tree eigentlich keine Rolle.

Noch ein Punkt: Die XS-Serie sind 10GBit Switche, brauchst Du die Verbindung als 10GBit ..... oder "nur" "nice-to-have"? Wenn der Uplink mit Kupfer ausgeführt ist, dann dürfens maximal 55m cat7 sein und das wird knapp zwischen zwei Gebäuden.. Nachdem die Verbindung eh nicht stabil ist wirds eher weniger als mehr sein ...... ich bin noch immer für den Tausch auf Glasfaser

Du hast eine reine Sternverkabelung? Dann spielt spanning tree eigentlich keine Rolle.

Das ist sachlich nicht ganz richtig wenn man wie üblich mit Link Redundanz im Netzwerk Backbone arbeitet wie es grundsätzlich in Firmennetzen ja heutzutage üblich ist. Auch wenn dieses keinen LACP Links sind sondern redundante Links mit Spanning Tree.

ich bin noch immer für den Tausch auf Glasfaser

Richtig ! Bei Switch Uplinks untereinander sollte sowas zwingend sein. Ausnahme die Switches stehen nahe beieinander, da verwendet man dann in der Regel immer DAC/Twinax Kabel.
Niemals sollten Infrastruktur Uplinks mit 10G Base T gemacht werden weil man dort keinerlei Garantie auf die Bandbreite hat. 10G Base T ist immer ein Negotiation Verfahren. Ein Knick, falscher Stecker oder länger als 30 Meter und von den 10G kommen nur Bruchteile an. Immer ein absolutes NoGo für die Backbone Vernetzung.

Zitat von @aqui:
Das ist sachlich nicht richtig wenn man wie üblich mit Link Redundnaz im Netzwerk arbeitet wie es grundsätzlich in Firmennetzen ja heutzutage üblich ist:

Wenn man ..... genau das ist die Frage .... und darum habe ich nachgefragt. "Reiner Stern" = ein Core, dann genau eine Verbindung zum nächsten etc, ohne irgendwelche "Nebengeräusche". Nachdem er eh kein Kabel mehr in das Röhrl hineinbringt, wirds wohl keine Redunanz geben. Er wird ja auch keine Portbündelung haben, könnte aber auch sein. Er spricht von einem Hauptswitch und zwei in der nächsten Ebene ohne einer redunanten Verbindung.

Aber weißt eh, das was uns trennt ist die gemeinsame Sprache

Zitat von @aqui:

grundsätzlich in Firmennetzen ....

So wie das Glasfaser zwischen den Gebäuden .... grundsätzlich vorhanden ist?

Zitat von @aqui:
... Switches stehen nahe beieinander ....

Ob zwei unterschiedliche Gebäude noch unter die Definition von "nahe" fallen? Für den Astronomen ganz sicher

Zitat von @hukiman:

@gilligan: Ich habe nur mit einem einfachen Gerät getestet, alle 8 Adern sowie die Schirmung sind sauber verbunden. Einen NEXT Wert kann man Gerät nicht ermitteln.

Sorry, nicht falsch verstehen, solche Tester sind genauso zuverlässig wie ein Spannungsprüfer in der Elektroinstallation. Man kann damit Fehler finden, klare Sache, aber man kann damit niemals den einwandfreien Zustand feststellen! Dazu bedarf es richtiger Messtechnik. Ich habe auch solche eine Gurke im Einsatz, aber bei einem echten Problem "leihe" ich mir Technik und Wissen vom Fachbetrieb. Was der in 10 Minuten ermittelt hat Hand und Fuß und spart mir leicht Stunden.

-teddy

Guten Morgen Zusammen,

wollte nochmal ein kurzes Feedback geben zu meinem Problem. Die Verbindung mit dem unzähligen Link down Ereignissen habe ich nun umgebaut. Das Kabel wurde vom Patchfeld genommen und in einer Dose außerhalb des Netzwerkschrankes aufgelegt. Von dort bin ich mit einem Patchkabel in einen Medienkonverter und von dort per LWL Patchkabel mit Transreceivern in den SFP+ Port des Switches.

Seitdem keinerlei Probleme mehr. (Läuft jetzt seit 4 Tagen ohne ein einziges Link down Ereignis)

Vielen Dank nochmals für eure Hilfe!