JerryWho

Dieses Thema wird immer verworrener: Heute gab es den ganzen Tag eigentlich kaum eine Zeit, in der die Anbindung konstant war. Die folgende Smokeping-Grafik verdeutlicht dies:

Nur nachts von 0:00 Uhr bis morgens bis ca. 9:00 Uhr "rauchte" es nicht und es traten keine Paketverluste auf. Dies passt zu der seit gestern abend durchgeführten Messung per Smokeping auf ICMP-Basis:

Nachts ist alles im Lack; es treten keine Paketverluste auf. Tagsüber raucht es zwar nicht mehr, aber statt des Grüns wird die Kurve türkis: Paketeverluste.

Betrachten wir nun mal den Lauf der Pakete genauer. Ein mtr -r -c 250 www.jerrywho.de erbrachte eben die folgenden Daten:

HOST: firewall                    Loss%   Snt   Last   Avg  Best  Wrst StDev   1. ???                          100.0   250    0.0   0.0   0.0   0.0   0.0   2. 217.0.66.2                    0.0%   250    6.5   7.0   6.0  86.0   5.1   3. l-eb1.L.DE.net.DTAG.DE        0.0%   250   13.2  13.5  12.1  91.8   5.3   4. 62.156.139.98                 5.2%   250   14.0  15.0  13.8  93.0   5.2   5. kpn.dhk.nbg.v-bone.net        6.8%   250   14.8  15.4  13.8  94.3   5.9   6. AS33956.RS8000.v-bone.net    12.8%   250   15.5 107.4  14.3 3779. 500.0   7. m15s09.vlinux.de              6.8%   250   14.7  15.8  14.1  95.2   9.0    

• Diese Daten habe ich direkt von meiner Astaro Firewall aus gewonnen. Da bei der Astaro normalerweise kein mtr mitgeliefert wird, habe ich auf einem anderen Linux-System das mtr statisch kompiliert. (Per LDFLAGS=-static ./configure -without-gtk –with-curses )
• Von einem System hinter der Firewall findet man Paketverluste direkt von der Firewall. Das kann ich nicht ganz nachvollziehen, da selbst ein Flood-ping (per ping -f) zu keinen Paketverlusten führt. Da ich aber diesen Effekt, vom ersten Hop Paketverluste gemeldet zu bekommen, auch auf einem ganz anderen System in einem anderen Netz gesehen habe, tippe ich hier auf einen Fehler im mtr.

Betrachtet man sich die Hops oben, so sieht man, dass das Übel an der vierten Stelle am Hop 62.156.139.98 seinen Lauf nimmt. Dieser gehört noch zum Netz der DTAG. Die Paketverluste aller dahinterliegenden Hops lassen sich durch den Fehler weiter vorne erklären.

Aber wie kann es dann sein, dass der sechste Hop (AS33956.RS8000.v-bone.net) mehr Paketverluste vorzuweisen hat als der siebente (m15s09.vlinux.de)? Sollte dies ein Einzelfall sein?

Hier sieht man, dass bei diesem Hop immer Paketverluste bestanden, auch zu den nächtlichen Stunden, an denen der dahinterliegende Hop keine Paketverluste hatte.

Herr Vollmar von vollmar.net, der mir immer innerhalb kurzer Zeit antwortet, richtete auch ein Smokeping ein, das von seiner Seite den aus seiner Sicht letzten Hop überwacht. Dies ist nicht etwa die 217.0.66.2 sondern die 217.0.66.1. Er tippt auf ein Problem bei der DTAG in Frankfurt. Der augenscheinliche Überltäter (62.156.139.98) scheint dem Namen des nächsten Hops nach aber bereits in Nürnberg zu stehen.

Ich bin von der Theorie noch nicht überzeugt, dass es ein Problem in Ffm mit dem DSL-Anschluss ist. Sieht man sich das HTTP-Smokeping an, das auf einen Frankfurter Server geht, so sieht man, dass da alles im grünen Bereich ist. (Achtung andere Zeitskala!)

Mal schauen, was denn die T-com zu meinem Phänomen sagt.