107023
Oct 01, 2013
12644
10
0
Hoher Packet Drop auf divesen NiCs
Hallo Zusammen,
ich habe auf verschiedenen Servern und Netzwerkkarten einen sehr hohen Anteil an verworfenen Datenpaketen
- bsp. RX packets:12384198 errors:0 dropped:533245 overruns:0 frame:0
Was ich auch beobachte, dass sehr viele tcp incorrect cksum via tcpdump zu sehen sind.
- rx/tx checksumming wurde deaktiviert
Was noch seltsam ist, ist incorrect cksum auf einem lo gerät.
- bsp. 127.0.0.1.3306 > 127.0.0.1.47317: Flags [P.], cksum 0xfe33 (incorrect -> 0xb94c),
Da die Pakete schon an der NIC gedroppt werden, habe ich wohl keine Chance diese via tcpdump zu analysieren oder hat jemand eine idee?
Es fällt mir gerade schwer herauszufinden, wie ich ein eventuelles defektes Gerät oder Kabel lokalisieren kann.
Hat jemand eine Idee?
VG Andreas
ich habe auf verschiedenen Servern und Netzwerkkarten einen sehr hohen Anteil an verworfenen Datenpaketen
- bsp. RX packets:12384198 errors:0 dropped:533245 overruns:0 frame:0
Was ich auch beobachte, dass sehr viele tcp incorrect cksum via tcpdump zu sehen sind.
- rx/tx checksumming wurde deaktiviert
Was noch seltsam ist, ist incorrect cksum auf einem lo gerät.
- bsp. 127.0.0.1.3306 > 127.0.0.1.47317: Flags [P.], cksum 0xfe33 (incorrect -> 0xb94c),
Da die Pakete schon an der NIC gedroppt werden, habe ich wohl keine Chance diese via tcpdump zu analysieren oder hat jemand eine idee?
Es fällt mir gerade schwer herauszufinden, wie ich ein eventuelles defektes Gerät oder Kabel lokalisieren kann.
Hat jemand eine Idee?
VG Andreas
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: 218270
Url: https://administrator.de/contentid/218270
Printed on: April 20, 2024 at 03:04 o'clock
10 Comments
Latest comment
Hi Andreas,
Woher hast du denn diese Information?
Aus dem Switch?
Live via SNMP oder von der Web-Oberfläche?
Grundsätzlich ist es sinnvoll, wenn man sich über hohe Zählerstände ärgert erst einmal ein Reset der Zähler durch zu führen.
Wo kann so was herkommen?
tcp incorrect checksum wirst du wohl nur bei Glück/Pech lokal sehen. Diese gehen auch nicht in die Zähler von Switchen oder so ein. Aber es ist ein Zeichen, dass du zu viel gedreht hast oder gar einen Virus dein eigen nennst. Das passiert im TCP-Stack.
CRC-Fehler sind noch leidlich erklärbar.
Wenn du mehr Details brauchst, dann musst du unbedingt einen verdächtigen Port spiegeln. CRC-Fehler werden vom Switch nicht weiter geleitet, aber tcp-checksum Fehler schon.
Dann nimm wireshark. Das hat mehr Möglichkeiten.
Gruß
Netman
Woher hast du denn diese Information?
Aus dem Switch?
Live via SNMP oder von der Web-Oberfläche?
Grundsätzlich ist es sinnvoll, wenn man sich über hohe Zählerstände ärgert erst einmal ein Reset der Zähler durch zu führen.
Wo kann so was herkommen?
- Defekte NICs oder Switchports
- HDX-FDX Missmatch.
tcp incorrect checksum wirst du wohl nur bei Glück/Pech lokal sehen. Diese gehen auch nicht in die Zähler von Switchen oder so ein. Aber es ist ein Zeichen, dass du zu viel gedreht hast oder gar einen Virus dein eigen nennst. Das passiert im TCP-Stack.
CRC-Fehler sind noch leidlich erklärbar.
Wenn du mehr Details brauchst, dann musst du unbedingt einen verdächtigen Port spiegeln. CRC-Fehler werden vom Switch nicht weiter geleitet, aber tcp-checksum Fehler schon.
Dann nimm wireshark. Das hat mehr Möglichkeiten.
Gruß
Netman
Hallo,
So etwas ist oft die Nadel im Heuhaufen suchen. Ein Kunde von uns hatte extrem schlechte Verkabelung im Gebäude, welches das gleiche Problem verursacht haben. Ein anderer Kunde hatte in jedem Büro Switche stehen. Den Rest kann man sich denken.
Wie sieht die Verkabelung aus bei den Ports, die du eingegrenzt hast? Kurze Wege direkt im Serverraum oder weitaus mehr?
Sonst kann ich auch nur noch DrNetman zustimmen.
Gruß Sven
So etwas ist oft die Nadel im Heuhaufen suchen. Ein Kunde von uns hatte extrem schlechte Verkabelung im Gebäude, welches das gleiche Problem verursacht haben. Ein anderer Kunde hatte in jedem Büro Switche stehen. Den Rest kann man sich denken.
Wie sieht die Verkabelung aus bei den Ports, die du eingegrenzt hast? Kurze Wege direkt im Serverraum oder weitaus mehr?
Sonst kann ich auch nur noch DrNetman zustimmen.
Gruß Sven
Hi,
Eventuell könntest du mal Wireshark auf dem betroffenen System einsetzen. Ich hab schonmal viele Checksum errors gesehen wenn Offloading auf der NIC aktiv ist. Wireshark schreibt die Info ins Log mit rein.
Edit: Hier ein Link dazu http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html
Eventuell könntest du mal Wireshark auf dem betroffenen System einsetzen. Ich hab schonmal viele Checksum errors gesehen wenn Offloading auf der NIC aktiv ist. Wireshark schreibt die Info ins Log mit rein.
Edit: Hier ein Link dazu http://www.wireshark.org/docs/wsug_html_chunked/ChAdvChecksums.html
Hi Netman,
Die infos ziehe ich mir aktuell aus verschiedenen Linux Server mittels „ifconfig“ und „tcpdump“.
Die zwei Server die mir zur Verfügung stehen haben verschiedene Netzwerkkarten, TL-8139/8139C/8139C+ in einem Standserver (HomePcUmbau) und Broadcom Corporation NetXtreme II BCM5708 in ein BM x3550 M2. Beide haben das gleiche Problem.
An den NICs wurde erst später mittels ethtool gedreht, ich habe rx cksum offload deaktviert um die fals positiv Meldungen in tcpdump zu verhindern. Das war es aber auch schon.
Ich denke es muss ein defekter Switch, Port, NIC, Kabel sein, oder sogar eine Konfiguration auf einem Router. Die frage ist nur, wie kann ich das defekte Gerät einkreisen?
Gruß Andreas
Die infos ziehe ich mir aktuell aus verschiedenen Linux Server mittels „ifconfig“ und „tcpdump“.
Die zwei Server die mir zur Verfügung stehen haben verschiedene Netzwerkkarten, TL-8139/8139C/8139C+ in einem Standserver (HomePcUmbau) und Broadcom Corporation NetXtreme II BCM5708 in ein BM x3550 M2. Beide haben das gleiche Problem.
An den NICs wurde erst später mittels ethtool gedreht, ich habe rx cksum offload deaktviert um die fals positiv Meldungen in tcpdump zu verhindern. Das war es aber auch schon.
Ich denke es muss ein defekter Switch, Port, NIC, Kabel sein, oder sogar eine Konfiguration auf einem Router. Die frage ist nur, wie kann ich das defekte Gerät einkreisen?
Gruß Andreas
Zitat von @Bitboy:
Hi,
Eventuell könntest du mal Wireshark auf dem betroffenen System einsetzen. Ich hab schonmal viele Checksum errors gesehen wenn
Offloading auf der NIC aktiv ist. Wireshark schreibt die Info ins Log mit rein.
Hi,
Eventuell könntest du mal Wireshark auf dem betroffenen System einsetzen. Ich hab schonmal viele Checksum errors gesehen wenn
Offloading auf der NIC aktiv ist. Wireshark schreibt die Info ins Log mit rein.
hab auf den Servern keine GUI, aber tcpdump ist ja das worauf Wireshark aufsetzt. Das Chksu Offloading habe ich schon deaktiviert.
Interessant sind auch die cksum errors auf dem loopback device!
Du solltest die Vollduplex- und Autosensing Konfigurationen überprüfen. Geschwindigkeit? Jumbopacket Konfiguration ....
Und was bitte sagen denn die Switches?
Wireshark ist auf dem Switchport besser aufgehoben als auf einem Server, der ja aproduktiv arbeiten und sich nicht selbst überwachen soll.
GRuß
Netman
Und was bitte sagen denn die Switches?
Wireshark ist auf dem Switchport besser aufgehoben als auf einem Server, der ja aproduktiv arbeiten und sich nicht selbst überwachen soll.
GRuß
Netman
1
Hallo,
ich hatte ähnliches Problem mit einem def. ProCurve nach nem Gewitter - da hat mir eine überspannung router und 1nen port am procurve geschossen und auf 4-5 anderen Ports hatte ich Packetverluste.
Von was für einen Umgebung reden wir denn? wenn du 1-2 24 Port switches hast würd ich einfach mal einen neuen testen - via try & error.
ist IMHO schneller als rumsniffen und protokolle studieren ...
LG
ich hatte ähnliches Problem mit einem def. ProCurve nach nem Gewitter - da hat mir eine überspannung router und 1nen port am procurve geschossen und auf 4-5 anderen Ports hatte ich Packetverluste.
Von was für einen Umgebung reden wir denn? wenn du 1-2 24 Port switches hast würd ich einfach mal einen neuen testen - via try & error.
ist IMHO schneller als rumsniffen und protokolle studieren ...
LG
Zitat von @Aufmuckn:
Hallo,
ich hatte ähnliches Problem mit einem def. ProCurve nach nem Gewitter - da hat mir eine überspannung router und 1nen
port am procurve geschossen und auf 4-5 anderen Ports hatte ich Packetverluste.
Von was für einen Umgebung reden wir denn? wenn du 1-2 24 Port switches hast würd ich einfach mal einen neuen testen -
via try & error.
ist IMHO schneller als rumsniffen und protokolle studieren ...
LG
Hallo,
ich hatte ähnliches Problem mit einem def. ProCurve nach nem Gewitter - da hat mir eine überspannung router und 1nen
port am procurve geschossen und auf 4-5 anderen Ports hatte ich Packetverluste.
Von was für einen Umgebung reden wir denn? wenn du 1-2 24 Port switches hast würd ich einfach mal einen neuen testen -
via try & error.
ist IMHO schneller als rumsniffen und protokolle studieren ...
LG
Hi Mike,
das ist gerade das Problem! Ich bin zum Optimieren und Dokumentieren bei einem WISP Provider. Die zwei Server haben auch unterschiedliche Subnetze und Inet Uplinks. Es ist auch sehr viel gebridged. Auf dem IBM Server habe ich KVM (oVirt) installiert und begonnen diverse OEL6 Server zu installieren. Bei Upgrades, kommt es hin und wieder vor, das Pakete nicht heruntergeladen werden konnten. Da der repo Server mein eigener ist und auf einem Cluster läuft macht deiser eigentlich keine Probleme. Auf Grund dessen, habe ich die NICs angeschaut und eben festgestellt, dass bei dem frischen Installiertem IBM schon mächtig viel Pakete gedroppt wurden.
eth0 RX packets:4339117 errors:0 dropped:169422 overruns:0 frame:0
eth1 RX packets:3323265 errors:0 dropped:219778 overruns:0 frame:0
Bei anderen Server sieht es genauso aus, nur geht dort auch noch die NIC hin und wieder down und up. für ein paar sekunden.
Da das Netzwerk extrem heterogen aufgebaut ist, Trendnet Switche (Smart Web Managed) und einfache Zyxel (auch Webmanaged) die als Core Bezeichnet werden sowie Mikrotik und diverse andere Netzwerkgeräte, SMC, Lancom, Ubiquiti, etc.
Das macht es mir nicht gerade einfach
Da ich jetzt nicht alles auseinander rupfen möchte, versuche ich eben durch sniffen einen Anhaltspunkt zu finden.
Das Problem ist eben, dass ich eine Möglichkeit suche an ein gedropptes Datenpaket zu kommen. Ein Port Spiegel wird da ebenfalls wenig bringen, die Pakete werden ja von der NIC gedroppt. Außer man könnte dies ausschalten.
ideen? (Schauen ob Fluke ein Messgerät hat oder Netzwerk einmal Neu
)VG Andreas
Ein Netzwerk Plan wär Super in dem Fall
und mit wireshark solltest ja an alle Pakete kommen....
und mit wireshark solltest ja an alle Pakete kommen....
Wenn du schon ein sogenanntes heterogenes Netzwerk, also einen gewachsenen Mix aus nicht harmonierenden Komponenten hast, dann macht es doch Sinn erst einmal zu checken, wie das Netzwerk so an Struktur, oder Reststruktur aufgebaut ist.
Dann frage nach, mit wie vielen NICs deine Server angebunden sind.
Bei einem Nicht-Sauber-Managebaren-Netz sind Redundanzen und Loops nicht genau zu unterschieden.
Und prüfe bitte wirklich alle angeschlossen Ports nach festen Konfigurationen!
Dann frage nach, mit wie vielen NICs deine Server angebunden sind.
Bei einem Nicht-Sauber-Managebaren-Netz sind Redundanzen und Loops nicht genau zu unterschieden.
Und prüfe bitte wirklich alle angeschlossen Ports nach festen Konfigurationen!
