Packetloss, quantelnd


#1

Hat jemand einen Tipp, wie man da weiter debuggen könnte?
(Es besteht Zugriff auf den Router, der die ffrl-gretunnel baut)

Und nein, es betrifft allem Anschein mehrere ffrl-AS-Bleche, neanderfunk (2a03:2260:300e::/48) ist hier nur ein willkürlich gewähltes Beispiel.

Und ja, die beiden Probes liefen parallel, auf dem gleichen clientdevice, das definitiv nur “über Freifunk” angeschlossen ist.


#2

p.s Echte Aussetzer gab es in dem Zeitraum nicht.

der wget-spiderrequest (test alle 5 Minuten) auf ipv4 und ipv6 einer bekannten Webseite mit Timeout 1000ms und 2 maxTries hat immer funktioniert spätestens im zweiten Versuch.


#3

MTR ist ja immer so eine Sache, hast du mal einen normalen Dauerping getestet?


#4

leicht OT, aber was sind die Probleme die du damit siehst?


#5

ich hab z.t. auch bei mtr Packetloss auf manchen Strecken bei 50% und mehr… Die Verbindung ist aber absolut stabil (surfen, Downloads, Videostream & co gehen total problemlos) und ein “normaler” Ping hat nahezu 0% packetloss. Wo das herkommt hab ich nie analysiert aber ich denke darauf will @MPW hinaus

mfg

Christian


#6

hm, das hatte ich noch nie, und ich nutze es bei Freifunk und beruflich sehr häufig…


#7

@rotanid, die Jungs die Netzwerk professionell machen, können das sicher besser erklären, aber soweit ich es verstanden habe: MTR ist darauf angewiesen, dass dir die Hosts sagen, wenn die TTL eines Paketes abgelaufen ist. Nicht alle Hosts bzw. Router tun das immer, manche maximal alle x Sekunden.

Es ist schon ein gutes Tool, hat aber seine Tücken bei der Interpretation.

Viele Grüße und einen guten Start in die Woche!

Matthias


#8

Das gilt für MTR wie für tracer[ou]t[e]. Router sollen routen, Fehlermeldungen senden sie ggf. nur verzögert/nicht für jedes Paket/nur x Pakete pro Zeiteinheit. Tracer senden wiederum für jeden Hop ein neues Paket, welches am Ende des Lebenszyklus mit »Lebensdauer erreicht« vom Router beantwortet werden muß. Während für jedes “ping mail.4830.org” genau ein (ICMP-) Paket auf die Reise geht, sind es bei einem herkömlichen traceroute wie unten z. B. 21 Pakete: eins mit Lebensdauer 1 (Hop), wird von 192.168.5.33 mit “Lebensdauer überrschritten” beantwortet. Das nächste mit Lebensdauer 2 Hops, wird von 192.168.177.11 mit “Lebensdauer überrschritten” beantwortet. Und so weiter, bis bei Paketen mit Lebensdauer 7 sich dann das Zielsystem (mit »alles angekommen hier bei W.X.Y.Z) meldet:

wusel@ysabell:~$ traceroute mail.4830.org
traceroute to mail.4830.org (193.26.120.251), 30 hops max, 60 byte packets
 1  192.168.5.33 (192.168.5.33)  3.038 ms  3.004 ms  2.976 ms
 2  192.168.177.11 (192.168.177.11)  2.967 ms  3.007 ms  5.913 ms
 3  62.155.243.28 (62.155.243.28)  10.673 ms  10.658 ms  10.631 ms
 4  217.239.40.10 (217.239.40.10)  17.987 ms  17.969 ms  17.944 ms
 5  bgp-ber01.4830.org (193.34.79.248)  20.568 ms  20.553 ms  20.521 ms
 6  de2.as206946.net (193.26.120.246)  43.655 ms  40.355 ms  40.325 ms
 7  mail.4830.org (193.26.120.251)  42.962 ms  42.962 ms  47.532 ms

#9

Der Unterschied ist, dass bei einem normalen Traceroute eine Rückmeldung über die abgelaufene TTL ausreicht, wohingegen beim MTR das sekündlich erforderlich ist und das machen nicht alle Geräte mit.