[Ungelöst] Defektes Kabel oder Switch erkennen?

[Haldi]

Hallo zusammen.
Mir fällt auf dass das Netzlaufwerk O: öfters einfach den Offenen Ordner schließt (Win11).
Auch die Alarmanlage gibt öfters "Online" Meldungen durch obwohl sie nie offline war.
Ich vermute das wir ein Problem mit einem Kabel oder dem Switch02 haben.
Uptime Kuma stellt kein Problem fest, da er nur alle 20 Sekunden mal pingt.
Wenn ich den Ping Manuel mache sehe ich auch keine Probleme. Also vermutlich nur Millisekunden unterbrüche.

Gibt es Software die ich auf Windows 11 und Debian laufen kann um die Verbindung dieser 2 Parteien exakt zu überwachen?

Den Drecks Switch02 wollte ich schon mal ersetzen. Da aber ein VLAN läuft schlug der erste versuch fehl. Mit nem VLAN kompatiblen Switch hat zwar der up/downstream funktioniert aber sämtliche anderen Geräte am ersatzswitch bekamen keine Verbindung mehr -.-
Das VLAN ist eigentlich ein Überbleibsel von den IP Kameras
das nicht mehr verwendet wird.

Hat jemand Vorschläge?

 

[Liesel Weppen]

Gibt es Software die ich auf Windows 11 und Debian laufen kann um die Verbindung dieser 2 Parteien exakt zu überwachen?

Um eine Verbindung zwischen zwei Geräten überwachen zu können, müsste das Überwachungsgerät zwischen diesen beiden Geräten im Netzwerk stecken.
Einfach ein drittes Gerät an einem Switch kriegt nichtmal mit, was die anderen beiden Geräte treiben.

TCP/IP-Verbindungen sind ausserdem stateless. D.h. es gibt keine permanent "stehende" Verbindung. Wenn der Switch Aussetzer im Millisekundenbereich haben sollte, steigt entweder bei so einem Ausfall nur kurz die Latenz, oder es gibt Paketdrops. Letzteres ist aber unwahrscheinlich, wenn die Ausfälle wirklich nur so kurz wären.
Ersteres könntest du an Pings anhand derer Zeit ggf. trotzdem erkennen. Bei Pings nur alle 20s müsstest du allerdings genau so einen Aussetzer "treffen".

Die einfachste Methode den Switch als Fehlerquelle auszuschließen dürfte sein ihn zu ersetzen. Testweise halt dann erstmal mit einem Gerät was sowieso rumliegt, oder zwei Switches austauschen und gucken obs dann an der Problemstelle wieder läuft... und ggf. sogar ob es mit dem Problemswitch auch an der anderen Stelle Probleme gibt.

 

[Eye-Q]

Wenn der Switch VLANs eingerichtet hat, wird der auch eine Weboberfläche haben, richtig? Gibt es dort nicht die Möglichkeit, ein Ereignisprotokoll einzusehen bzw. herunterzuladen?

Um eine sinnvolle Fehlersuche durchführen zu können, hast Du aber viel zu wenige Infos geliefert. Die schreibst Gerätenamen, als ob wir wissen, was das für jeweilige Geräte sind, wir die verbunden sind etc., dem ist aber nicht der Fall. Auch dass ihr (wer ist "ihr"?) schon mal versucht hattet, den Switch auszutauschen und dass das gescheitert ist, bringt uns nicht weiter, weil wir nicht wissen können, ob der Ersatzswitch auch nur im Ansatz richtig konfiguriert war.

 

[underclocker2k4]

TCP/IP-Verbindungen sind ausserdem stateless. D.h. es gibt keine permanent "stehende" Verbindung.

TCP/IP-Verbindungen sind bitte was?
TCP/IP ist das Paradebeispiel für eine statefull connection.

Difference Between Stateless and Stateful Protocol - GeeksforGeeks

Your All-in-One Learning Portal: GeeksforGeeks is a comprehensive educational platform that empowers learners across domains-spanning computer science and programming, school education, upskilling, commerce, software tools, competitive exams, and more.

www.geeksforgeeks.org

https://medium.com/@moali314/understanding-stateful-vs-stateless-protocols-tcp-udp-and-beyond-45b972c5676b

Ansonsten braucht man auch nicht zwingend eine extra Gerät, um die Verbindungen zu überwachen.
Wenn man Zugriff auf beide Seiten hat, kann man auf beiden Seiten sehen, was rein/raus geht.
Dazu nimmt man wireshark.

Das zeigt bei TCP auch sehr gut an, wenn dort irgendwas passiert. (das sind in der Regel verschwundene Telegramme)
Sprich also, mit geeigneten Filter sieht man auf beiden Seiten den jeweiligen Verkehr. Was bei A raus ist, ist bei B rein und umgekehrt.
Da kann man also nachvollziehen, wenn bei A ein Paket rausgeht, es aber bei B nicht ankommt, dann muss es verschwunden sein.
Es besteht immer noch die Möglichkeit, dass das jeweilige Paket noch oder schon auf dem Rechner verschwindet.
In dem Fall wäre dann natürlich eine Überwachung auf der Leitung besser, weil das Gerät selber ausgeschlossen wird.
Das tut schon ein PC mit 2 NICs, die als bridge eingestellt sind. Dann kann man den Verkehr mithorschen.
Kann man dann 1x vorm und 1x nach dem Switch machen.
TCP hat ja Sequenznummern usw.
Muss man sich mal mit beschäftigen. Trivial ist das nicht, aber durchaus machbar.

Ansonsten kann man natürlich auch ein drittes Gerät an einen Switch anschließen und sich den Verkehr dort anschauen. Dazu muss der Switch lediglich Mirrorport können. Nur wenn das Switch das Problem ist....

Bei der Alarmanlage wirds natürlich schwer mit Wireshark drauf. Da muss man dann zwingend in die Leitung "eintauchen".

Ansonsten ist natürlich immer die einfachste Methode, vermutete Gerät gegen etwas anderes zu tauschen und schauen ob es besser ist. Das ist die trial&error. Nicht "wissenschaftlich", eher Holzhammer, aber oftmals deutlich schneller.

 

[Liesel Weppen]

TCP/IP-Verbindungen sind bitte was?
TCP/IP ist das Paradebeispiel für eine statefull connection.

Was ich damit meinte ist, die Verbindung "steht" nicht dauerhaft. Das die Verbindung weg ist, merkt man nur, wenn auch irgendwas geschickt wird, während die Verbindung weg ist (und selbst nichtmal dann garantiert, weils im Fehlerfall einfach nochmal versucht wird, zumindest mit TCP. UDP dagegen ist fire and forget, da ist das Paket dann einfach weg).
Wenn der Switch kurz mal einen Aussetzer hat, während aber sowieso nicht geschickt wird, dann merkt man das gar nicht und es hat auch keine Auswirkungen auf die Verbindung.

 

[underclocker2k4]

Natürlich steht die Verbindung dauerhaft. Hat der Client eine Verbindung mit dem Server hergestellt, ist das eine Verbindung und der Socket wird solange aufgehalten, wie die Verbindung nicht abgebaut wird. Und der Server oder der Client können jeder Zeit etwas senden, ohne dass die Verbindung/Socket erstmal aufgebaut werden muss.
Der Server hat ne Verbindung und weiß daher, dass jeder Zeit etwas kommen kann. Er weiß nicht wann, aber er weiß, dass auf der Seite des Hörer auch einer den Hörer in der Hand hat und diese Person ist sogar bekannt.
Daher ist die statefull.

UDP hingegen funktioniert da anders. Dort wird einfach ein Socket aufgemacht, aber ohne dass der Server etwas davon weiß. Dann schickt der Client einfach was los. Der Server hingegen hat nicht nur den Port auf "listen" sondern auch auf Empfang. Das heißt, er kann zu jeder Zeit ein Telegramm empfangen, ganz ohne, dass vorher eine Verbindung aufgebaut wurde.
Der Server erwartet also nicht im speziellen, dass ein Telegramm kommen kann, sondern er erwartet, dass bei UDP, prinzipiell von jedem, ein Telegramm kommen, zu jeder Zeit.
Ist also wie ne SMS. Du weißt, dass dein Handy das kann. Du weißt aber nicht wann eine kommt, du weißt auch nicht, wer das sein wird. Das ist, wenn man so will, total random.
Daher ist das stateless.

(halb) Richtig ist, dass das dort nicht ohne Not Telegramme geschickt werden. Wenn von der App nichts gemacht werden soll, dann tut nichts. Die Verbindung ist dennoch offen, sofern die App das will.

Es gibt aber bei TCP/IP dennoch eine keep alive time. Die ist aber idR 2h. Also alle 2h kommt ein Paket, obwohl nichts los ist. Das ist also schon stehend, weil "ständig" Pakete hin und her gehen, obwohl nichts los ist. Nur heißt "ständig" in dem Fall 2h...
(kann man grundsätzlich runterdrehen und wird bei "sensiblen" Verbindungen auch gemacht)

Es ist daher natürlich so, dass, wenn nichts läuft, kein auftretender Fehler detektiert werden kann. Wo nichts ist, kann auch nichts verschwinden.
Wenn er da aber Filetransfer macht, dann laufen da ja, nahezu mit wirespeed, entsprechend Telegramme, d.h. da sollte man dann schon sehen, wenn da was auftritt. Vom nur "Explorer auf haben" wird da sicherlich nichts/kaum zu sehen sein. Der Explorer, als App, schickt natürlich schon Aktualisierungen hin und her. Deswegen fliegt das ja auch weg, wenns zur richtigen Zeit passiert.

 

[Haldi]

Wenn man Zugriff auf beide Seiten hat, kann man auf beiden Seiten sehen, was rein/raus geht.
Dazu nimmt man wireshark. Muss man sich mal mit beschäftigen. Trivial ist das nicht, aber durchaus machbar.

Ähhjaaa...
Auf eine Triviale Lösung hatte ich gehofft...
Hab auf beiden Seiten ein System mit Docker.
Dachte da an so etwas das von A nach B eine Test Verbindung aufbaut und analysiert. Dann kann man das 1-2 Tage laufen lassen und auswerten.

Auch dass ihr (wer ist "ihr"?) schon mal versucht hattet, den Switch auszutauschen und dass das gescheitert ist, bringt uns nicht weiter, weil wir nicht wissen können, ob der Ersatzswitch auch nur im Ansatz richtig konfiguriert war.

Auf der Arbeit. "Wir"...
Und nein. Er war natürlich nicht richtig Konfiguriert. Sonst hätte er ja laufen sollen oder?

Der Betroffene Switch ist ein Zyxel GS1900-24 Rev. A1.
Ich konnte im Syslog eben nichts verdächtiges feststellen. Auch mal Firmware update gemacht.
Daher evtl verdacht auf Kabel mit schwächen...

Ersetzen wollte ich den mit einem TP Link TL-SG108PE der auch VLAN tauglich sein sollte..

 

[Supaman]

TP-Link, die Marke des Vertrauens ... genau das richtige im Business Umfeld

 

[Haldi]

Ey, es war ein Ersatz Test Gerät für 35.-
FALLS es am Switch liegt. Wollte da nicht 450.- ausgeben nur damit sich nichts ändert...

 

[amdfreund]

Was heißt denn öfters? Ist es sekündlich / stündlich / täglich und hat es feste oder wechselnde Intervalle?
Für die Verkabelung gäbe es professionelle Messgeräte, oder den Blindtausch.
Je nach Ausfallintervall könnte vielleicth ein Langzeitping etwas aufzeigen. https://deeken-group.com/2025/09/24/ping-test-cmd/

Netzwerk-Monitoring › Wiki › ubuntuusers.de

wiki.ubuntuusers.de

Das VLAN ist eigentlich ein Überbleibsel von den IP Kameras das nicht mehr verwendet wird.

Dann wäre vielleicht zusätzlich noch eine Netzwerkbereinigung/-neuplanung als Zusatzmaßnahme einzuplanen, denn irgendwelche Geräte werden wohl durch dieses "übrige" VLAN auf "unnötige" Umwege geleitet, was nur durch die fehlende VLAN-Config des Ersatzswitches aufgefallen ist.