Forenbeiträge und Diagramme zur Fehlersuche
Manchmal hilft es einen Forenbeitrag zu schreiben, wenn es bei einem Problem partout nicht weitergeht. Die Erfahrung die ich damit manches mal schon gemacht habe war, dass es reicht ihn zu schreiben. Oft sieht man dabei das Problem/den Fehler/was auch immer 😉 noch einmal aus einer anderen Perspektive und kommt wieder einen Schritt weiter.
Die abgespeckte Form davon ist es aus meiner Sicht das Problem grafisch darzustellen, z.B. bei Netzwerkproblemen, in dem man die Wege der Pakete grafisch darstellt, und daran kommentiert mit welchen verschiedenen Clients auf welchen Verbindungen welche Fehler auftreten, bzw. nicht auftreten.
Anbei ein Beispiel dafür anhand des Netzwerkproblems, dass ich derzeit habe. Von Zeit zu Zeit „fliegen alle Clients“ (auch die Nicht-Lenovo Geräte) aus dem WLAN.
In einem solchen Fall ist es oft hilfreich gezielt Informationen zu sammeln, d.h. den Fehler einzugrenzen, und die gesammelten Informationen in eine Struktur zu bringen.
Textdarstellung (z.B Forenbeitrag)
Verschiedene Clients im WLAN erreichen über das WLAN das Internet nicht mehr, selbst die Fritzbox können sie nicht mehr via ping erreichen. Andere Geräte im gleichen Netz, egal ob am gleichen Switch wie der AccessPoint mit dem sie verbunden sind, oder an einem anderen Switch, erreichen sie noch(z.B. die Lancom Firewall). Ebenfalls tritt das Problem nicht bei Geräten auf, die direkt via Kabel angebunden sind.
Diagram
Eine Grafik kann hier auch eine große Hilfe sein, z.B. des Netzwerkaufbaus um sich zu verdeutlichen, welche Datenpakete welche Wege nehmen.
Mein Netzwerkaufbau dazu schaut so aus. Die Pfeile entsprechen dabei den physikalischen Verbindungen und dem Datenfluss (nur ist der bidirektional).
Das brachte mich in diesem Fall jedoch nicht weiter, also schnell noch das erwünschte/unerwünschte Verhalten an den jeweiligen Stellen ergänzt, indem ich schaue was im Fehlerfall erreichbar/nicht erreichbar ist.
Das Ergebnis fließt in das Diagramm mit ein
Nicht wirklich schlauer, aber um ein schönes Diagram reicher. 🙂
Hier kann es auch hilfreich sein noch einmal die Textform mit dem Diagram abzugleichen.
Es bricht der Ping zur Lancom manchmal ab.
Faktisch sollte es nicht an der Lancom liegen, denn dann gäbe es mit dem Client2 auch Probleme, der ebenfalls über die Lancom läuft.
Alleine an dem Unifi AP scheint es aber auch nicht zu liegen, ansonsten würde ja der Ping zum Unifi-Controller (192.168.11.107) ebenfalls Fehler aufweisen.
Das tut er jedoch nicht, während der ping auf die FritzBox bereits scheitert.
Selten (1-2 Mal pro Stunde) ist jedoch gar kein ping mehr von einem Client im WLAN möglich, da selbiger die Verbindung zum Controller verliert/abbricht(?).
Suche nach weiteren Informationen
Das Ereignisprotokoll von Windows kann bei der Fehlersuche manchmal recht hilfreich sein
Im Ereignisprotkoll unter Windows steht kurz davor meist
Protokollname: System
Quelle: Microsoft-Windows-DNS-Client
Datum: 29.08.2021 17:39:01
Ereignis-ID: 1014
Aufgabenkategorie:(1014)
Ebene: Warnung
Schlüsselwörter:(268435456)
Benutzer: Netzwerkdienst
Computer: LAPTOP-PBDNHAS6
Beschreibung:
Zeitüberschreitung bei der Namensauflösung für den Namen ipv4only.arpa, nachdem keiner der konfigurierten DNS-Server geantwortet hat.
Ereignis-XML:
1014 0 3 1014 0 0x4000000010000000 2448 System LAPTOP-PBDNHAS6 ipv4only.arpa 128 02000000C0A80BFE000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Weitere Einträge mit zeitlichen Bezug lassen sich keine finden. Hier hilft es also wenig.
Was ist erreichbar und was nicht?
Weiter mit der Frage: Was ist erreichbar und was nicht? Wann ist dem so, ich bringe also noch einen weiteren Client mit dazu, diese Mal Linux.
Die Clients pingen jetzt an:
Den AccessPoint
den Switch an dem der AP hängt
den Controller für den Switch (Kabelclient),
einen weiteren Client im Netz
einen Client im WLAN
die Lancom Firewall und
die Fritzbox.
Es ergibt sich grundlegend folgendes Diagram
Zwischenfazit
Es gibt keine Probleme bei der Kommunikation im LAN!
Switch und Lancom sind damit weitgehend nicht mehr verdächtig, ebenso die Kommunikation zwischen Lancom und Fritzbox. Erst sobald das WLAN hinzukommt treten Fehler auf. Der Verdacht fällt auf den AP (und die Verbindung zum AP, d.h. Port am Switch, Kabel zum POE-Injektor, POE Injektor, Kabel zum AP, AP selbst).
Im WLAN ist das Fehlerbild jedoch uneinheitlich zwischen den nun drei WLAN Clients. Da aber drei Clienst sich immer gegenseitig erreichen, liegt der Fehler vermutlich nicht beim AP selbst. Ebenso zeigt der dritte WLAN Client die gleich Ergebnisse wie der zweite WLAN-Client.
Also kommt hinzu den AP einmal von einem Client im LAN aus anzupingen. Vielleicht verliert ja der AP manchmal die Verbindung zum Switch und aus irgendeinem Grund fiel das bei den pings des ersten WLAN Clients nicht auf. Das kann ungünstiges Timing sein, dass der Fehler genau beim Passieren der Pakete Client 1 WLAN nicht auftritt oder nur zu selten.
Hinzu kommt also die Idee, den AP aus dem LAN anzupingen um festzustellen, ob der AP zeitweise die Anbindung zum Switch verliert.
Dem ist genau so, damit erhärtet sich der Verdacht, dass es ein Problem zwischen Switch und WLAN AP gibt.
Konkret befinden sich dort POE-Injektor, wie oben bereits erwähnt:
Switchport, Kabel zum POE Injektor, POE Injektor, Kabel zum AP.
Also geht es nun daran einzeln auszuschließen:
Da ein anderes an den Port angeschlossene Gerät keine Probleme hat, wird es vermutlich nicht am Port liegen.
Kabel sind unwarscheinlich, da sie sich nicht bewegen scheidet ein Kabelbruch fast aus. Hier wäre auch die Verbindung vermutlich häufiger unterbrochen und ließe sich nicht auf bestimmte Ziele eingrenzen.
POE-Injektor-getauscht->es läuft wieder stabil!
Fazit
Ein nicht mehr stabil laufender POE-Injektor kann viele lustige Fehler auslösen und ist nicht immer so ganz einfach ausfindig zu machen. 🙂
Der Befehl ping ist in einfachen Netzwerk praktisch, sobald jedoch Firewallregeln angewandt werden, die ICMP beeinflussen, kann das Verhalten mancher „Pings“ verändert werden. Ebenso hilft anstatt eines pings traceroute (bzw. unter Windows tracert) bei komplexeren Fehler häufig besser weiter.
In diesem Fall wäre die Ausgabe
traceroute google.de
traceroute to google.de (142.250.185.99), 30 hops max, 60 byte packets
1 192.168.11.254 (192.168.11.254) 2.307 ms 2.431 ms 2.413 ms
2 192.168.9.1 (192.168.9.1) 3.541 ms 3.771 ms 4.046 ms
*** aus dem eigenen LAN raus ***und das die Pakete erst über die Lancom und anschließend über die Fritzbox laufen war recht erwartbar, ebenso, dass sie esim Fehlerfall nicht können.