Der Paketverlust tritt am Zielsystem auf. Es handelt sich also nicht um den Fall, dass das ICMP Ratelimit auf den Routern, wie so oft, als Paketverlust misinterpretiert wird.
Dann läge es aber nicht im Backbone, sondern am Zielsystem.
Pings sind grundsätzlich ungeeignet, um auf Paketverluste zurückzuschließen. Die geringe Priorisierung von Ping betrifft ja nicht nur Router, sondern auch Server.
Wie sieht es mit TCP Verbindungen zum Ziel aus? Anhand von Retransmissions und TCP Statusmeldungen kann man tatsächlich auf solche Probleme zurückschließen. Das lässt sich z.B. mit Hilfe von Wireshark Auswertungen analysieren.
Hallo,
ich habe hier ähnliche Probleme insbesondere zu meinem Server bei Hetzner. Es kommt zu vielen Paketverlusten und die Verbindung bricht dadurch immer wieder zusammen.
Dann läge es aber nicht im Backbone, sondern am Zielsystem.
Gebe dir zwar grundsätzlich Recht, allerdings antworten die gleichen Server (sowie ein eigener Server bei Hetzner) an anderen Anschlüssen sehr wohl zu 100% auf ICMP. Server die das nicht tun, sind natürlich kein geeignetes Messinstrument.
Somit geht entweder das Paket auf dem Hinweg oder auf dem Rückweg zu verschiedenen Destinationen verloren.
Und ja, ich sehe das gleiche Verhalten wie klar-schiff. SSH Verbindung bricht teilweise ab und hat starke "ruckler". Das passt sehr gut zu den ICMP Ergebnissen 
Gebe dir zwar grundsätzlich Recht, allerdings antworten die gleichen Server (sowie ein eigener Server bei Hetzner) an anderen Anschlüssen sehr wohl zu 100% auf ICMP.
Das heißt aber immer noch nicht, dass sie im DG Backbone verloren gehen. Im trace oben tritt das Problem ab dem letzten Router vorm Ziel auf und damit hinter dem DG Netz.
Grundsätzlich verfügt TCP über Retransmissions und ähnliche Mechanismen. Paketverluste auf der Verbindung führen also erst mal nicht zu Verbindungsabbrüchen, z.B. bei SSH. Ruckler schon eher.
Und damit sind wir bei meiner ersten Antwort: Wireshark/tcpdump ist nun das Mittel der Wahl, sich das näher anzusehen. Am besten gleichzeitig auf beiden Seiten, um sehen zu können, was jeweils ankommt oder abgesendet wird.
Ich sehe ebenfalls stark schwankende Paketverluste (1%-20%) bei UDP-iperf3 mit vorgegebener niedriger Bandbreite. Die Verluste treten bei Verbindungen von Servern in verschiedenen Rechenzentren (Frankfurt und Nürnberg) auf. Der gleiche Test abwechselnd über einen anderen Provider verliert keine Pakete. Auch vom Glasfaseranschluss zum Server und von Server zu Server geht nichts verloren.
Edit: Die Übergabe findet in Frankfurt oder am AMS-IX statt und die Fremdnetze sind verschieden.
Ich hab gerade in die Munin-Statistik meines vServers gesehen und sehe da seit 13 Uhr heute steigende Latenzen beim Einsammeln der Munin Daten aus meinen Heimnetzen:
Davon sind laut munin-update.log verschiedene Ziele betroffen, die der Server abklappert, u.a. auch mein eigenes Zuhause am DG Anschluss, aber z.B. auch meine Mutter an einem Telekom Anschluss.
Außerdem betreibe ich zu Hause auf meinen Raspi einen RIPE ATLAS Software Probe. Dort sehe ich seit dem Vormittag leicht erhöhte Pings zu verschiedenen Zielen, hier mal als Beispiel zu einem RIPE Server in Nürnberg (die -1 ist ein Paketverlust):
Die anderen Statistiken sehen ähnlich aus. Es betrifft IPv4 und IPv6, aber IPv4 ein wenig schlimmer.
Irgendwo scheint es tatsächlich zu haken im Internet. Es scheint aber nicht ausschließlich die DG zu betreffen.
Wahrscheinlich sind wie üblich nicht alle gleich stark oder überhaupt betroffen. Hier am DG-Anschluss sind die Paketverluste jedenfalls nicht nur sehr eindeutig messbar sondern auch deutlich spürbar, z.B. durch häufige Verzögerungen beim einfachen Websurfen und andauernde Lags von SSH-Verbindungen. Am DSL Anschluss läuft alles wie geschmiert.
Das heißt aber immer noch nicht, dass sie im DG Backbone verloren gehen. Im trace oben tritt das Problem ab dem letzten Router vorm Ziel auf und damit hinter dem DG Netz
Son ICMP Paket hat auch ein Rückweg ;). Es kann also sein, dass das Paket zwar beim vorletzten HOP ankommt, allerdings das Paket auf dem Rückweg durchs DG Backbone gedroppt wird. Dementsprechend ist das kein Argument, dass die These widerlegt
Dagegen spricht allerdings, dass die geringe Priorität von ICMP sich eher auf das Erzeugen von Paketen und weniger auf das Routen von Paketen bezieht. Wenn ein Paket erst mal unterwegs ist, dann steigt die Wahrscheinlichkeit deutlich, dass es auch ankommt.
Deshalb sind traceroutes noch mal weniger aussagekräftig, als Pings, und die sind weniger aussagekräftig als TCP/UDP Pakete.
Bei mir hat sich das Problem seit Mitternacht erledigt.
Hier wurde es ab Mitternacht besser und ab ca. 1 Uhr war kein Packet Loss mehr messbar. Seit etwas über einer Stunde gehen aber wieder vereinzelt Pakete verloren. Ich orakel mal, dass die niedrigere Auslastung die Ursache kaschiert hat und mit steigender Auslastung auch die Paketverluste wieder ansteigen werden.
Edit: Und so ist es. Vom Server zum Glasfaseranschluss rund 10% Packet Loss. Vom Server zum DSL-Anschluss kein Packet Loss.
Ja, läuft unterirdisch aktuell. Meine Linuxdistribution hat ihre Updates gerade mit satten 7MBit/s geladen.
Meine außen erreichbaren Server (u.a. ein relativ gut besuchtes Forum) lasse ich gerade über mein VDSL Backup laufen.
Bei meinem Ping Monitoring sind Cloudflare DNS unauffällig, heise.de hat aber merklich Loss.
Ich bin jetzt inzwischen auf die DayFlat der Telekom umgestiegen. Das Internet fühlt sich wie zu ISDN Zeiten an, mit Bildern die langsam von oben nach unten laden
Ja, daran war es mir hauptsächlich gestern auch zuerst aufgefallen. Auf Twitter herumgesurft und immer gesehen, wie sich die Bilder von oben nach unten aufgebaut haben. War schon richtig nostalgisch 
Auch wenn ich gerade nur einen unqualifizierten Speedtest, nämlich den von DG angebotenen Ookla-Test, gemacht habe, kann ich bestätigen das irgendwo "der Wurm" drin ist. Nach dem Test stimmt die Downloadraten (400 Mbps), die Uploadrate liegt zwischen 20 und 50 Mbps (anstatt 200) und der Jitter ist im hohen zweistelligen, wenn nicht gar dreistelligen Bereich!
die Uploadrate liegt zwischen 20 und 50 Mbps (anstatt 200) und der Jitter ist im hohen zweistelligen, wenn nicht gar dreistelligen Bereich!
Das ist ja interessant. Bei uns ist der Download und nicht der Upload betroffen.
Bei mir allerdings nicht so schlimm. Die Bandbreiten, die mir zustehen, erreiche ich immer noch locker in beiden Richtungen, deshalb funktioniert auch Streaming und so noch. Ich kann es allerdings im Delay und bei den Paketverlusten sehen.
Das ist ein schönes Beispiel, warum Speedtests so wenig aussagekräftig sind. Ich kann mit Ookla und günstig gelegenem Testserver meine Tarifbandbreite in beiden Richtungen abrufen. Gleichzeitig fühlen sich große Teile des deutschen Internets träger an als zu ADSL-Zeiten. Dieses Forum ist beispielsweise kaum benutzbar. Das gibt auch die Breitbandmessung der BNA wieder: Rund ein Prozent der Tarifbandbreite im Download bei 75ms Ping. Der Upload ist aber voll da.
shavenne hat mich eben angeschrieben und gefragt, ob ich mal schauen kann.
Es ist grauenhaft auch bei uns...
Hat eigentlich irgendwer die Störung gemeldet hier? Ich hab eh schon ein anderes Ticket offen und mag da nur ungern wieder Chaos verursachen (Erfahrung und so 
).
Hab den Eindruck es fängt gerade langsam wieder an.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
