9
Test Netzwerkkarte Windows Zwei Fragen
Bei linux kann man sich mit ifconfig die "drop" Pakete anzeigen.
Gibt es da was für Windows oder einen Wireshark Filter?
Ich vermute in meinem Netz eine defekte Netzwerkkarte.
Da meine managed Switche nichts loggen, muss ich die Suche zu Fuss starten.
Gibt es unter Windows einen Status der mir etwas über den Status der letzten Pakete was sagt?
Zweite Frage:
Wie kann ich Wireshark filtern um sporadische Netzwerkausfälle (vermutlich defekte Pakete) zu finden.
Danke für eure Infos.
Da meine managed Switche nichts loggen, muss ich die Suche zu Fuss starten.
Gibt es unter Windows einen Status der mir etwas über den Status der letzten Pakete was sagt?
Zweite Frage:
Wie kann ich Wireshark filtern um sporadische Netzwerkausfälle (vermutlich defekte Pakete) zu finden.
Danke für eure Infos.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 191220
Url: https://administrator.de/contentid/191220
Printed on: April 26, 2024 at 00:04 o'clock
9 Comments
Latest comment
Hallo nixwissen,
Du könntest, wenn Deine Switche das hergeben und vor allem Dein Rechner an dem Du Sitzt, einen Monitor Port am Switch benutzen! Das ist ein so genannter "mirrored Port", der leitet von allen Packeten die über diesen
Switch gehen eine Kopie an eben diesen von konfigurierten "mirrored Port" oder auch Monitor Port!
Aber das solltest Du mit Deinem Chef und dem Betriebsrat in Eurem Betrieb vorher abklären.
Denn bloß weil Du etwas gut meinst, muss es noch lange nicht von alle Leuten für gut befunden werden.
Das wäre jetzt das einzige was mir einfällt und hier keinen Ärger bringt!!!
Ask WireShark
Vielleicht bringt Dich der Link weiter.
Gruß
Dobby
Du könntest, wenn Deine Switche das hergeben und vor allem Dein Rechner an dem Du Sitzt, einen Monitor Port am Switch benutzen! Das ist ein so genannter "mirrored Port", der leitet von allen Packeten die über diesen
Switch gehen eine Kopie an eben diesen von konfigurierten "mirrored Port" oder auch Monitor Port!
Aber das solltest Du mit Deinem Chef und dem Betriebsrat in Eurem Betrieb vorher abklären.
Denn bloß weil Du etwas gut meinst, muss es noch lange nicht von alle Leuten für gut befunden werden.
Das wäre jetzt das einzige was mir einfällt und hier keinen Ärger bringt!!!
Ask WireShark
Vielleicht bringt Dich der Link weiter.
Gruß
Dobby
Das ist bei Wireshark eben genau von der NIC abhängig. Wenn die keine Runts und Giants und Fragmente anzeigen kann dann zeigt auch WS nix an.
Einen Counter für Droped Pakets gibt es unter Winblows nicht. In der Regel können das aber die Switches sofern du einige einigermaßen gute Hardtware hast und keine Billiggurken ala ProCurve und Co.
Wäre ja auch egal, denn wenn es nur um die Hardware und dessen korrekte Funktion geht kannst du ein Live Linux wie z.B. Knoppix schnell von der CD booten und das damit testen auf der Maschine.
Einen Counter für Droped Pakets gibt es unter Winblows nicht. In der Regel können das aber die Switches sofern du einige einigermaßen gute Hardtware hast und keine Billiggurken ala ProCurve und Co.
Wäre ja auch egal, denn wenn es nur um die Hardware und dessen korrekte Funktion geht kannst du ein Live Linux wie z.B. Knoppix schnell von der CD booten und das damit testen auf der Maschine.
Hi nixwissen,
Dein Name könnte für deine managebaren Switche stehen.
Fehlerhafte Pakete werden nicht weiter verteilt, sondern verworfen. Also nutzt dir auch ein Wireshark bei der ersten Suche nichts.
Aber die Managed Switche haben andere Möglichkeiten, dir die Quelle des Fehlers anzuzeigen: SNMP ist das Mittel der Wahl. Es gibt dafür die OID 1.3.6.1.2.1.2.2.1.y.x um die Interfaces zu loggen.
Die Interfaces haben eine eigene Nummer, das "x" und dann gibt es weitere Informationen
Interface Out Errors 1.3.6.1.2.1.2.2.1.20.x
iflnDiscards 1.3.6.1.2.1.2.2.1.13.x
iflnErrors 1.3.6.1.2.1.2.2.1.14.x
ifOutDiscards 1.3.6.1.2.1.2.2.1.19.X
Das kann man leicht abfragen und loggen.
Anonsten bleibt nur das Webinterface und die Fehlerzähler oder die Console mit den Fehlerzählern des Interfaces. Am Besten alle vorher zurück setzen. sonst sucht man sich dämlich.
Infos über die Switche wären nett und helfen beim Raten....
Gruß
Netman
Dein Name könnte für deine managebaren Switche stehen.
Fehlerhafte Pakete werden nicht weiter verteilt, sondern verworfen. Also nutzt dir auch ein Wireshark bei der ersten Suche nichts.
Aber die Managed Switche haben andere Möglichkeiten, dir die Quelle des Fehlers anzuzeigen: SNMP ist das Mittel der Wahl. Es gibt dafür die OID 1.3.6.1.2.1.2.2.1.y.x um die Interfaces zu loggen.
Die Interfaces haben eine eigene Nummer, das "x" und dann gibt es weitere Informationen
Interface Out Errors 1.3.6.1.2.1.2.2.1.20.x
iflnDiscards 1.3.6.1.2.1.2.2.1.13.x
iflnErrors 1.3.6.1.2.1.2.2.1.14.x
ifOutDiscards 1.3.6.1.2.1.2.2.1.19.X
Das kann man leicht abfragen und loggen.
Anonsten bleibt nur das Webinterface und die Fehlerzähler oder die Console mit den Fehlerzählern des Interfaces. Am Besten alle vorher zurück setzen. sonst sucht man sich dämlich.
Infos über die Switche wären nett und helfen beim Raten....
Gruß
Netman
Na, da habe ich wieder was losgetreten 
Ja, es sind HP ProCurve 4xxx Switche in mehrern Gebäuden.
Tja, ich muss da etwas umdenken wenn es mit Wireshark oder Win nicht geht.
Das mit dem Monitor Port ... da muss ich mich reinlesen.
Ob dies der 12 Jahre alte Switch kann?
SNMP gab nichts interressantes aus.
Ja der Switch müsste eigentlich fehlerhafte Pakete verwerfen.
Der verwirft erst mal alles und Protokolliert nichts, zumindest lese ich nichts raus.
Da heute die Geschichte das erste mal aufgetreten ist, muss ich mir da noch mehr Zeit nehmen den
Fehler einzugrenzen.
Ja, es sind HP ProCurve 4xxx Switche in mehrern Gebäuden.
Tja, ich muss da etwas umdenken wenn es mit Wireshark oder Win nicht geht.
Das mit dem Monitor Port ... da muss ich mich reinlesen.
Ob dies der 12 Jahre alte Switch kann?
SNMP gab nichts interressantes aus.
Ja der Switch müsste eigentlich fehlerhafte Pakete verwerfen.
Der verwirft erst mal alles und Protokolliert nichts, zumindest lese ich nichts raus.
Da heute die Geschichte das erste mal aufgetreten ist, muss ich mir da noch mehr Zeit nehmen den
Fehler einzugrenzen.
Hallo,
um das Pferd mal von hinten aufzuzäumen...
Wie äußert sich denn der Fehler?
Vielleicht kann man das Problem so schon mal eingrenzen...
bramme
um das Pferd mal von hinten aufzuzäumen...
Wie äußert sich denn der Fehler?
Vielleicht kann man das Problem so schon mal eingrenzen...
bramme
die Procurve 4000 Switche können in jedem Falle SNMP.
Deren Webseite/Webconfig kenne ich nicht, aber es gibt eine (Text-) Console und die ist auf jeden Fall aufschlußreich und über Telnet oder seriellen Port erreichbar.
Beim Spiegeln (Portmonitor) musst du aufpassen, ob du wirklich den gesamten Verkehr bekommts. Da gibt es zum Teil Einschränkungen und man bekommt nur eine Richtung aufgezeichnet. Das ist abhängig von der Karte und ob man sich auf der zu überwachenden oder einer anderen befindet.
Fehlerhafte Ethernetpakete bekommt man nie zu sehen, die scheinen aber in der Portstatistik auf. Fehlerhafte IP-Pakete können aber mit dem Wireshark aufgezeichnet werden.
Aber Geduld, wenn es erst nur einmal aufgetreten ist.
Deren Webseite/Webconfig kenne ich nicht, aber es gibt eine (Text-) Console und die ist auf jeden Fall aufschlußreich und über Telnet oder seriellen Port erreichbar.
Beim Spiegeln (Portmonitor) musst du aufpassen, ob du wirklich den gesamten Verkehr bekommts. Da gibt es zum Teil Einschränkungen und man bekommt nur eine Richtung aufgezeichnet. Das ist abhängig von der Karte und ob man sich auf der zu überwachenden oder einer anderen befindet.
Fehlerhafte Ethernetpakete bekommt man nie zu sehen, die scheinen aber in der Portstatistik auf. Fehlerhafte IP-Pakete können aber mit dem Wireshark aufgezeichnet werden.
Aber Geduld, wenn es erst nur einmal aufgetreten ist.
Die Geschichte ist folgende.
Mir brach gestern 3 Mal innerhalb von 6 Stunden das Netzwerk für ca. 3-4 Sec ein.
Jetzt bin ich auf der Suche nach der Ursache, auf unseren Switchen, der ASA und den Events von den Servern fand ich keinerlei Hinweise.
Ich kann nicht mal sagen aus welchem Gebäude der Fehler kam.
Es wurde einfach in dem Zeitfenster des Ausfalls nichts auffälliges geloggt.
Deshalb die Fragen.
Ich bin leider nicht der Wireshark Guru deshalb die Frage nach dem Filter, denn ich dachte so kann ich den Fehler eingrenzen. Da Win die fehlerhaften Pakete nicht protokolliert habe ich eine andere Idee schon verworfen.
Mir brach gestern 3 Mal innerhalb von 6 Stunden das Netzwerk für ca. 3-4 Sec ein.
Jetzt bin ich auf der Suche nach der Ursache, auf unseren Switchen, der ASA und den Events von den Servern fand ich keinerlei Hinweise.
Ich kann nicht mal sagen aus welchem Gebäude der Fehler kam.
Es wurde einfach in dem Zeitfenster des Ausfalls nichts auffälliges geloggt.
Deshalb die Fragen.
Ich bin leider nicht der Wireshark Guru deshalb die Frage nach dem Filter, denn ich dachte so kann ich den Fehler eingrenzen. Da Win die fehlerhaften Pakete nicht protokolliert habe ich eine andere Idee schon verworfen.
Hallo nixwissen,
also das von aqui mit der Linux LiveCD wenn es schnell gehen soll und sonst nichts falsch läuft fände ich
schnell um zusetzen, aber das mit den MIB files und vielleicht einem PRTG von Paessler fände ich für eine langfristige und regelmäßige Überwachung besser.
Eigentlich hat der aqui schon recht wenn die Pakete "gedropped" werden, werden Sie ja auch nicht weiter geleitet und Du siehst sie wirklich nicht, daran habe ich zuerst auch nicht gedacht.
Für eine Punkt zu Punkt (A > B / B > A) Verbindung wäre dieser Filter nicht schlecht, setzt aber auch voraus dass Du den "Störefried" kennst und da dachte ich halt an den s.g. Monitor oder "Mirrored Port"
der Kopien aller Pakete eines Switches auf einen Port lenkt und wenn da nun Dein WireShark dran hängt dachte ich kannst Du das schneller ausfindig machen!
TCP only einstellen
Filter: packet loss and tcp.analysis.lost_segment
Dann unter dem Wort "Wert" also Value nachschauen, nur nützt Dir das so wirklich nichts, denn wenn die Pakete erst gar nicht weitergeleitet werden, werden Sie bestimmt auch nicht an den Monitor Port weitergeleitet!
Gruß
Dobby
also das von aqui mit der Linux LiveCD wenn es schnell gehen soll und sonst nichts falsch läuft fände ich
schnell um zusetzen, aber das mit den MIB files und vielleicht einem PRTG von Paessler fände ich für eine langfristige und regelmäßige Überwachung besser.
Eigentlich hat der aqui schon recht wenn die Pakete "gedropped" werden, werden Sie ja auch nicht weiter geleitet und Du siehst sie wirklich nicht, daran habe ich zuerst auch nicht gedacht.
Für eine Punkt zu Punkt (A > B / B > A) Verbindung wäre dieser Filter nicht schlecht, setzt aber auch voraus dass Du den "Störefried" kennst und da dachte ich halt an den s.g. Monitor oder "Mirrored Port"
der Kopien aller Pakete eines Switches auf einen Port lenkt und wenn da nun Dein WireShark dran hängt dachte ich kannst Du das schneller ausfindig machen!
TCP only einstellen
Filter: packet loss and tcp.analysis.lost_segment
Dann unter dem Wort "Wert" also Value nachschauen, nur nützt Dir das so wirklich nichts, denn wenn die Pakete erst gar nicht weitergeleitet werden, werden Sie bestimmt auch nicht an den Monitor Port weitergeleitet!
Gruß
Dobby
3-4 Sekunden ist auch nicht wirklich etwas Auffälliges. Wenn das Netzwerk tot ist werden auch keine log-Dateien weg geschrieben. Für einen Server müsste schon der Netzwerkport tot sein.
Schon mal an so etwas wie Broadcastbegrenzung gedacht, respektive die entsprechende Einstellung im Switch. Die kann auch mal kurz eine Blockade auslösen.
Schon mal an so etwas wie Broadcastbegrenzung gedacht, respektive die entsprechende Einstellung im Switch. Die kann auch mal kurz eine Blockade auslösen.
