dropped packets?

oelk · 21 Mai 2014

Hallo,

bei einigen Installationen bekomme ich über

Code:

ifconfig eth0

in der Zeile RX bei dropped ganz ordentlich was angezeigt.

Das hier

Code:

ethtool -S eth0 | egrep -i '(error|fail|drop)'

nennt mir aber den wert 0.

Switches sind von http://alliedtelesis.de/, aber schon etwas älter.
Netzwerkkarten sind meistens Intel 82579V, bei RTL8169 habe ich es aber auch schonn beobachtet.

Wie ist das zu erklären?

MfG

spoensche · 22 Mai 2014

Poste mal die Ausgabe der von dir ausgeführten Befehle. Kannst du dir die Logs von den Switchen ansehen? Wenn ja poste sie mal bitte.

oelk · 22 Mai 2014

Hallo spoensche,

argh, gerade nicht greifbar,
kommt morgen vom Kunden.

Von den Switches kann ich nix kriegen, die sind nicht managebar.

Ich bin leider keine Spezialist von tcpdump oder wireshark,
sonst hätte ich das schon selbst herausgefunden.

MfG

oelk · 23 Mai 2014

Moin,

also ein 'ifconfig' bringt:

Code:

eth0      Link encap:Ethernet  Hardware Adresse 00:30:48:B0:76:34  
          inet Adresse:192.168.0.99  Bcast:192.168.0.255  Maske:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:53439212 errors:0 dropped:1835798 overruns:0 frame:0
          TX packets:53052461 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:1000 
          RX bytes:39700840664 (37861.6 Mb)  TX bytes:65180215188 (62160.6 Mb)
          Interrupt:16 Speicher:d0180000-d01a0000 

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:11446 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11446 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 Sendewarteschlangenlänge:0 
          RX bytes:2527022 (2.4 Mb)  TX bytes:2527022 (2.4 Mb)

Ein 'netstat -s | egrep -i '(error|fail|drop)' ' bringt:

Code:

    6050 input ICMP message failed.
    0 ICMP messages failed
    11 failed connection attempts
    0 packet receive errors
    RcvbufErrors: 0
    SndbufErrors: 0
    InErrors: 0
    RcvbufErrors: 0
    SndbufErrors: 0
    TCPRenoFailures: 0
    TCPSackFailures: 5
    TCPLossFailures: 0
    TCPRenoRecoveryFail: 0
    TCPSackRecoveryFail: 0
    TCPSchedulerFailed: 0
    TCPAbortFailed: 0
    TCPBacklogDrop: 0
    TCPMinTTLDrop: 0
    TCPDeferAcceptDrop: 0
    TCPReqQFullDrop: 0
    TCPRetransFail: 0

Ein Kollege sieht das in den SAMBA-Puffern begründet, kann ich nicht bestätigen.
Wenn ich eine solche Maschine frisch installiere, minimal und nichts auf dem Netz mache,
fängt er schon an dropped hoch zu zählen. Da ist SAMBA noch nicht mal installiert
und lsof -Pi zeigt keine aktive Verbindungen.

MfG

spoensche · 25 Mai 2014

oelk schrieb:
Ein 'netstat -s | egrep -i '(error|fail|drop)' ' bringt:

Code:

6050 input ICMP message failed. 11 failed connection attempts TCPSackFailures: 5

Die hohe Anzahl an fehlerhaften eigehenden ICMP Nachrichten kann die Folge von fehlerhatfen ICMP-Paketen, z.B. Bad Checksum etc. sein.
Der Zähler hat im normalen Betrieb einen sehr niedrigen Wert bzw. ist gleich 0. Wenn die hohe Anzahl der fehlerhaften ICMP Pakete nur bei diesem Rechner auftritt, dann ist möglicherweise die Netzwerkkarte defekt. dann steck einfach mal das Kabel um und überprüfe, ob der Fehler weiterhin auftritt. Wenn nicht, musst du die anderen Rechner im Netz kontrollieren, ob sie auch eine solch hohe Fehlerrate haben.

oelk schrieb:
Ein Kollege sieht das in den SAMBA-Puffern begründet, kann ich nicht bestätigen.
Wenn ich eine solche Maschine frisch installiere, minimal und nichts auf dem Netz mache,
fängt er schon an dropped hoch zu zählen. Da ist SAMBA noch nicht mal installiert
und lsof -Pi zeigt keine aktive Verbindungen.

Die Samba Puffer haben mit dem Problem rein gar nichts am Hut, weil die Fehler auf der untersten Schicht auftreten. (Bitübertragungsschicht oder auf dem Networklayer)

oelk · 25 Mai 2014

Hallo spoensche,

danke das wollte ich hören.

Der 16er Switch von http://www.alliedtelesis.com/ ist zweifelhaft,
eine Kabelstrecke eines Windows-Clients ist nachweislich schlecht.

Erstaunlicherweise haben wir relativ viele Kunden mit solchen Problemen.
Mit einem Switch von Netgear, D-Link oder TP-Link (aktuelle Modelle)
lässt die Werte schlagartig gegen null laufen.
Sollten da in ca 400 Rechnern/Servern die Netzwerkkarten defekt sein?

Danke
MfG

oelk · 26 Mai 2014

Nachtrag:
erstaunlicherweise zeigen hier alle Maschinen 'dropped packets'
im Hausnetz (mit Proxy und NAC-Switches).
Die ganz ruhig und machen nix und kriegen permanent Pakete.
Auch hier Allied Telesis.

Wieviel hängt von der jeweiligen Netzwerkkarte ab.

MfG

spoensche · 28 Mai 2014

oelk schrieb:
Der 16er Switch von http://www.alliedtelesis.com/ ist zweifelhaft,
eine Kabelstrecke eines Windows-Clients ist nachweislich schlecht.

Hm, die Kabelstecke weniger,eher das Betriebsystem. Warum sollte das Kabel mit vollem Einsatz arbeiten, wenn es bei einem nachweislich schlechten System auch weniger Aufwand reicht?

Und jetzt wieder zum Thema

oelk schrieb:
Erstaunlicherweise haben wir relativ viele Kunden mit solchen Problemen.
Mit einem Switch von Netgear, D-Link oder TP-Link (aktuelle Modelle)
lässt die Werte schlagartig gegen null laufen.

Der Einsatz von Netgear und D-Link Switchen ist nicht zu empfehlen, weil Netgear, nach dem Bekannt werden des eingebauten Backdoor, diesen nicht entfernt sondern versteckt. So nach dem Motto Doof Kunde merkt es eh nicht. Kein Einsatz von D-Link, weil sie eher durch katastrophale Sicherheitslücken, quer durch die Produktreihe, auf sich aufmerksam machen und dabei den Eindruck erwecken, dass es sich um Features handelt.

Bei TP-Link hat man neben einem guten Preis Leistungsverhältnis zusätzlich die Möglichkeit das Gerät mit OpenWRT zu betreiben.

oelk schrieb:
Sollten da in ca 400 Rechnern/Servern die Netzwerkkarten defekt sein?

Nein. Der Switch von allied telesis ist das Problem, wie du es bei deinen Tests ja auch festgestellt hast. So viel Pech kann man nicht haben, das bei 400 Servern die Netzwerkkarten von hier auf jetzt aus heiterem Himmel gleichzeitig den Geist aufgeben.

Du könntest zusätzlich noch einen weiteren Test durchführen und zwar mit einem Laptop. Du gehst dabei wie bei deinen Tests mit den Servern vor, nur eben mit Laptop. Wenn das Problem dann auch auftritt, dann hast du 100%ige Sicherheit, dass es nicht an den Servern liegen kann.
Evtl. ist es auch sinnvoll die Tests mit anderen Netzwerkkabel durchzuführen. Dafür reicht ja ein Server und der Laptop.

Bevor du nach den Tests dem Hersteller den Switch um die Ohren feuerst, solltest du noch prüfen, sofern möglich, ob evtl. ein Firmware Update verfügbar ist. Es ist durchaus auch möglich, dass ein Bug in der Firmware die Ursache ist.

PS:
Gib lieber ein bisschen mehr Geld für einen managebaren Switch aus. Dafür hast du dann die Möglichkeit dir die Logs des Switches anzusehen und mögliche Fehler und Defekte zu erkennen, sparst die aufwendigeren tagelangen Tests die im Endeffekt teurer sind als ein managebarer Switch. Zusätzlich kannst du z.B. auch mehrere Netze auf VLAN's aufteilen und festlegen welche VLANS auf welchem Port mit wem kommunizieren dürfen.

oelk · 28 Mai 2014

Hallo spoensche

spoensche schrieb:
Der Einsatz von Netgear und D-Link Switchen ist nicht zu empfehlen, weil Netgear, nach dem Bekannt werden des eingebauten Backdoor, diesen nicht entfernt sondern versteckt. So nach dem Motto Doof Kunde merkt es eh nicht. Kein Einsatz von D-Link, weil sie eher durch katastrophale Sicherheitslücken, quer durch die Produktreihe, auf sich aufmerksam machen und dabei den Eindruck erwecken, dass es sich um Features handelt.

Das sind alles nur Switches, keine DSL-Router. Die bieten nix aktiv im Internet an, ntp holt nur die Zeit.
Da mach ich mir weniger einen Kopf.

spoensche schrieb:
Bei TP-Link hat man neben einem guten Preis Leistungsverhältnis zusätzlich die Möglichkeit das Gerät mit OpenWRT zu betreiben.

Da bin ich auch Deiner Meinung. Ich hab's leider nicht zu entscheiden.

spoensche schrieb:
Du könntest zusätzlich noch einen weiteren Test durchführen und zwar mit einem Laptop. Du gehst dabei wie bei deinen Tests mit den Servern vor, nur eben mit Laptop. Wenn das Problem dann auch auftritt, dann hast du 100%ige Sicherheit, dass es nicht an den Servern liegen kann.
Evtl. ist es auch sinnvoll die Tests mit anderen Netzwerkkabel durchzuführen. Dafür reicht ja ein Server und der Laptop.

So etwas ähnliches hatte ich schon hinter mir. Supermicro NL wollte von mir einen Test
mit netperf wegen der onboard Karten, rausgekommen ist letztendlich nichts.
Da sind dann Begriffe aufgetaucht, die mir nichts sagten, der zeitliche Rahmen war dann auch erschöpft.

spoensche schrieb:
Bevor du nach den Tests dem Hersteller den Switch um die Ohren feuerst, solltest du noch prüfen, sofern möglich, ob evtl. ein Firmware Update verfügbar ist. Es ist durchaus auch möglich, dass ein Bug in der Firmware die Ursache ist.

Da die nicht mehr gebaut und supported werden, dürfte es da nix gehen.
Firmware gibt's für die unmanaged Switches nicht.

MfG

spoensche · 29 Mai 2014

oelk schrieb:
Hallo spoensche

spoensche schrieb:

Der Einsatz von Netgear und D-Link Switchen ist nicht zu empfehlen, weil Netgear, nach dem Bekannt werden des eingebauten Backdoor, diesen nicht entfernt sondern versteckt. So nach dem Motto Doof Kunde merkt es eh nicht. Kein Einsatz von D-Link, weil sie eher durch katastrophale Sicherheitslücken, quer durch die Produktreihe, auf sich aufmerksam machen und dabei den Eindruck erwecken, dass es sich um Features handelt.

Zum Vergrößern anklicken....

Das sind alles nur Switches, keine DSL-Router. Die bieten nix aktiv im Internet an, ntp holt nur die Zeit.
Da mach ich mir weniger einen Kopf.

Ja es sind Switche. Aber diese Switche haben eine Firmware und die kann durch Sicherheitslücken kompromittiert werden. Es gibt doch nichts praktischeres als einen Switch dem man dank einer Sicherheitslücke einen Sniffer unterschieben kann der dann A): sämtlichen Verkehr abhört, B) den Verkehr nacht interessanten Daten untersucht und C) die Daten an an dessen Besitzer übermittelt. Interessant wird es wenn dann auf einmal sensible Daten im Internet auftauchen, man daraufhin das komplette LAN auf den Kopf stellt, aber nichts findet und daraufhin die Kunden weglaufen, weil sie kein Vertrauen mehr haben, die Aufträge ausbleiben und am Ende alles aus ist.

Beispiel Netgear: Ein 5 Port Switch, managebar, lies es zu, das man mit bestimmten SNMP Paketen das Passwort auslesen konnte und der Switch verteilte es anschließend sogar noch im LAN.

Das sollte dir schon bewusst sein.

oelk schrieb:
spoensche schrieb:

Bei TP-Link hat man neben einem guten Preis Leistungsverhältnis zusätzlich die Möglichkeit das Gerät mit OpenWRT zu betreiben.

Zum Vergrößern anklicken....

Da bin ich auch Deiner Meinung. Ich hab's leider nicht zu entscheiden.

Stimmt, aber du kannst darauf hinweisen.

oelk schrieb:
Da sind dann Begriffe aufgetaucht, die mir nichts sagten, der zeitliche Rahmen war dann auch erschöpft.

Welche Begriffe waren das? Evtl. können wir sie dir erklären.

oelk schrieb:
Da die nicht mehr gebaut und supported werden, dürfte es da nix gehen.
Firmware gibt's für die unmanaged Switches nicht.

Da wird dann wohl nichts anderes übrig bleiben als deinen Vorgesetzten zu informieren, dass die Switche die Ursache sind und ausgetauscht werden müssen/sollten.