Ubuntu 14.04 - ICMP Packet loss

Hallo zusammen,

ich habe Probleme mit meinem Root-Server bei Netcup.de
Die Verbindung hakt immer wieder, selbst SSH kommt ins Stocken.

Nun soll ich ins Rettungssystem booten (ein kleines Linux) um auszuschliessen, dass meine Installation daran schuld ist.
Auf dem Server ist openssh, LAMP, Postfix TCPDUMP, MTR, ETHSTATUS installiert.

ein MTR vom root auf www.microsoft.com zeigt mir immer wieder packetloss schon zum ersten Hop hin.
Umgekehrt, von meinem PC aus, auch immer wieder packetloss zu 188.68.54.154
Auch von Kabel Deutschland aus immer wieder packet loss auf den Server. Liegt also nicht an meinem Anbieter (T-Offline)

Wenn ich mir nen TCPDUMP des ICMP Traffics ansehe, fallen mir auch immer wieder Lücken auf.

Da ich aktuell etliche User darauf habe, möchte ich gerne darauf verzichten den Server ins Rettungssystem zu booten.

Jemand ne Idee, was da meine Pakete verschlucken könnte ?
Oder wo ich ansetzen könnte ?
Traffic dümpelt unter 50kB/sek hin, ausgelastet ist die GBit/s Anbindung nicht.

Danke und Grüße, Henere

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 300267

Url: https://administrator.de/forum/ubuntu-14-04-icmp-packet-loss-300267.html

Ausgedruckt am: 10.05.2025 um 12:05 Uhr

4 Kommentare

Neuester Kommentar

Jemand ne Idee, was da meine Pakete verschlucken könnte ?

Eine etwas naive Frage bei solch banaler Schilderung. Dein Korizont beschränkt sich ja rein auf dein Server System. Was mit dem Hoster Netzwerk an sich ist oder dessen Peering Anbing lässt du vollkommen außer Acht oder kommt in deinen Überlegungen ja gar nicht vor.
Was erwartest du also für eine zielführende Antwort auf deine Frage bei der Informationslage. Will man alle möglichen Optionen berücksichtigen ware das ein 2 Seiten Dokument hier.
Logisch das dir keiner sowas aufzählt, denn als Netzwerk weisst du das im Layer 2 genauso viele Problem wie im Layer 3 auftreten können, deine Server Probleme nochmal gar nicht angesprochen.

Gehe besser also strategisch vor und mache einen Traceroute auf das Ziel und checke wo die größte Verzögerung passiert. Dort ist meistens auch das Problem.
Pingplotter und ander Tools helfen ebenso. Dabei ist es wichtig das du abgehende ICMP Pakete am Client siehst und checkst ob die exakt am Server auftauchen.
Es geht doch zuallererst mal darum nachzuweisen das die Fehler in der Hoster Infrastruktur oder derer seiner ISP Peers liegen...oder auch nicht.
Ist es letzteres gehst du dann erst beim Server ins Eingemachte.

Servus,

ja das ist mir schon klar. Ich meinte mit verschlucken, die lokale Seite.
MTR habe ich von beiden Seiten mehrfach angefertigt. (Server wie auch zu Hause).
Kann halt leider bei dem Hoster kein Fluke in die Leitung stecken, noch auf die Switche unterwegs zugreifen.
TCPDUMP / MTR ist so fast die einzige Möglichkeit die mir zur Verfügung steht. Wo die Pakete verschwinden kann ich damit aber auch nicht feststellen.

Mein MTR von zu Hause sieht aber komischerweise so aus: (keine Ahnung, warum die ersten Hops nicht antworten)

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                   No response from host -  100 | 1567 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 | 1567 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 | 1567 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 | 1567 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 | 1567 |    0 |    0 |    0 |    0 |    0 |
|                  www.edvservice-jung.de -    8 | 1567 | 1457 |   17 |   38 |  165 |   20 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir  ( stanimir@cr.nivis.com )

Ein traceroute von hier aus dann so:

Routenverfolgung zu www.edvservice-jung.de [188.68.54.154]
über maximal 30 Hops:

  <1 ms    <1 ms    <1 ms  fritzbox.edvservice-jung.de [192.168.200.250]
  25 ms    24 ms    25 ms  217.0.117.200
  26 ms    25 ms    25 ms  87.190.176.134
  29 ms    28 ms    28 ms  217.239.44.190
  33 ms    32 ms    32 ms  gw-dtag.ffm.netcup.net [87.128.237.166]
  32 ms    31 ms    32 ms  www.edvservice-jung.de [188.68.54.154]

Letzte Antwort vom Provider:

vielen Dank für Ihre Rückmeldung. Aktuell können wir einen erhöhten Ping Ihres Systems nachvollziehen. Sollten sich die schlechten Pingwerte sowie Paketloss auch nach einem Start in das Rettungssystem bestätigen, so kann ich Ihnen den Umzug auf ein anderes Hostsystem anbieten um zu prüfen, ob es dort ebenfalls zu dem selben Verhalten kommt. Bei anderen Kunden auf dem aktuellen Wirtsystem ist kein erhöhter Ping sowie Paketloss zu verzeichnen.

Eine mögliche Lösung in diesem Fall könnte auch der Wechsel des Netzwerktreibers im VCP bringen, wenn Ihnen dies möglich ist.

Wenn ich den Netzwerkkartentreiber tauschen müßte... dann hat doch der Hoster einen Fehler gemacht in der Bereitstellung seiner Pakete, oder ?
Es ging halt bis gestern vormittag ohne Probleme.

Grüße, Henere

Update: (beim Schreiben dieses Textes, neue Mail vom Provider

ich habe soeben eine Optimierung an Ihrem Server vorgenommen. Aktuell haben sich dadurch allem Anschein nach die Pingwerte stabilisiert. Wir behalten Ihren Server dennoch weiterhin im Auge.

Na, schaun mer mal ...

Ich kann den Packetloss von der Telekom aus nicht nachvollziehen:

~# mtr --interval 0.2 --report --report-cycles 500 188.68.54.154
HOST: grob-gw                     Loss%   Snt   Last   Avg  Best  Wrst StDev
|-- 87.186.224.133             0.0%   500   18.2  18.3  18.0  19.3   0.2
|-- 87.190.177.170             0.0%   500   18.8  19.1  18.5  24.1   0.5
|-- f-ed8-i.F.DE.NET.DTAG.DE   0.0%   500   23.2  23.6  22.6  58.7   3.3
|-- gw-dtag.ffm.netcup.net     0.0%   500   26.4  27.9  26.3  57.8   5.1
|-- www.edvservice-jung.de     0.0%   500   26.8  26.8  26.3  30.8   0.4

Von Level3 auch nicht:

~# mtr -i 0.2 --report --report-cycles 200 188.68.54.154
HOST: grob-s2                     Loss%   Snt   Last   Avg  Best  Wrst StDev

|-- xe-9-1-2.edge4.dus1.level  0.0%   200    1.2   1.4   1.0  25.7   1.8
|-- ae-2-70.edge6.Frankfurt1.  0.0%   200    4.8   4.9   4.6  13.1   0.9
|-- ae-2-70.edge6.Frankfurt1.  0.0%   200    4.7   5.2   4.5  39.5   3.1
|-- gw-level3.ffm.netcup.net   0.0%   200    8.4  10.8   8.1  45.2   7.1
|-- www.edvservice-jung.de     0.0%   200    8.2   8.3   8.0  10.3   0.2

Für den Fall, dass das Problem nur zu bestimmten Zeiten auftritt:

Mache von immer den selben Quellen aus einen MTR zum Server und vergleiche die Latenzzeiten. Erhöhte Latenzzeiten (im Vergleich zum vorherigen MTR ohne Störung) weisen auf überlastete Strecken hin.
Versuche benachbarte IP-Adressen ebenfalls zu testen - wenn bei denen das selbe Problem auftritt, kannst du deinen Server definitiv als Ursache ausschließen.
Versuche den Zeitraum einzugrenzen und gib Netcup einen Hinweis, dass sie das mal prüfen sollen - eventuell ist das ein wiederkehrendes Phänomen, welches z.B. aufgrund von vielen parallelen Remote-Backups auftritt.
Falls das bis jetzt eine einzige Störung war: Es kann nunmal passieren, dass Probleme bei einzelnen Uplinks auftreten, die dann erstmal behoben werden müssen. Wenn das nicht wieder auftritt, hefte es ab unter "Internet ist nunmal so"

Servus Lordgurke,

Wenn Du den MTR erst nach meinem post gemacht hast, da hatte der Provider ja irgendwas schon gedreht. Aktuell habe ich einen loss von unter 1%
3800 gesendet und "nur" 34 drops zum ersten Hop. Wobei mir das eigentlich schon zuviel ist. Wenn ich das bei mir zu Hause mache, habe ich 0,0 drops.

Naja, ich würde fast sage, der Drops ist erstmal gelutscht, mal schauen was die Zukunft so bringt. Werde das weiter im Auge behalten.

Danke euch und
Grüße, Henere

Frage Netzwerke Überwachung

Mehr von Henere

TrendNet Webcam - Probleme beim einrichtenHenere - 6 Kommentare

Webcam Empfehlung gesuchtHenere - 5 Kommentare

WSUS - Updates werden nicht geladenHenere - 8 Kommentare

ToolGetExchangeStatusForWatcher.exeHenere - 12 Kommentare

Heiß diskutiert