Deutung von traceroute Ausgabe

[christian83]

Hallo zusammen,

ich brauche mal eure Einschätzung bzw. Erklärung. Ich habe bei meinem Provider aktuell das Problem das an meinem Anschluss über den Tag verteilt keine Daten mehr ankommen oder abgehen. Netzinterne Dinge wie ip Tv und Telefonie sind nicht betroffen. Nun habe ich in Rücksprache mit dem Anbieter (regionaler Betreiber mit eigenem Netz und Technik bis in die Wohnung). Abgesprochen das ich die Verbindung mal mit traceroute permanent prüfe. Bei den Aussetzern kommt es dort zu einer Erscheinung von !<0> ab dem dritten Punkt. Mitgeteilt habe ich das Protokoll schon, aber ich würde gerne selbst wissen was es damit Aufsich hat. Google hilft mir nicht wirklich... Habt ihr eine Idee?

traceroute to google.com (172.217.23.142) , 5 relative hops max, 52 byte packets
   1 fritz.box (192.168.178.1) 11.497 ms 16.022 ms 16.747 ms
   2 100.103.0.8 (100.103.0.8) 20.927 ms 22.290 ms 23.044 ms
   3 switch2-v58.net.encoline.de (5.102.160.129) 36.759 ms 37.542 ms 38.145 ms !<0> !<0> !<0> !<0> !<0> !<0>
   6 rudo7-t000-123.net.encoline.de (5.102.160.90) 4.212 ms 56.996 ms 57.749 ms
   7 rudo5-t001-123.net.encoline.de (5.102.160.89) 0.191 ms 0.741 ms 1.233 ms !<0> !<0> !<0> !<0> !<0> !<0> !<0> !<0> !<0>
 11 62.96.222.189 (62.96.222.189) 3.107 ms 1011.697 ms 1014.943 ms
 12 212.74.68.189 (212.74.68.189) 0.580 ms 1.677 ms 2.569 ms
 13 212.74.68.189 (212.74.68.189) 0.248 ms 3.885 ms 5.230 ms
 14 108.170.241.204 (108.170.241.204) 0.232 ms 49.240 ms 50.282 ms
 15 209.85.254.49 (209.85.254.49) 0.248 ms 61.952 ms 63.058 ms
 16 108.170.236.121 (108.170.236.121) 0.232 ms 3013.233 ms 3016.161 ms
 17 209.85.241.230 (209.85.241.230) 0.267 ms 343.353 ms 347.201 ms
 18 108.170.252.65 (108.170.252.65) 0.649 ms 79.141 ms 82.951 ms
 19 216.239.54.63 (216.239.54.63) 1.555 ms 158.020 ms 162.065 ms
 20 fra16s18-in-f142.1e100.net (172.217.23.142) 0.698 ms 52.445 ms 56.177 ms

 

[datasmurf]

Hallo Christian83,

....Google hilft mir nicht wirklich... Habt ihr eine Idee?

Schau besser erst mal in die entsprechende Manpage des Tools.

man traceroute(8)
A reply that returns with a ttl of 1 is a clue this problem exists.  
Traceroute prints a "!" after the time if the ttl is <= 1.
...
           !<num>        ICMP unreachable code <num>.
....
These are defined by RFC1812 (which supersedes RFC1716).
...

https://tools.ietf.org/html/rfc1812#section-4.3.3.1

....
0 (Network Unreachable) ICMP message.
...

Du kannst auch mit mtr Traceroute and ping in a single network diagnostic tool durchgehend die Verbindungsqualität überwachen.

Grüße

Daniel

 

[mark05]

hi

fuer langzeit analyse eignet sich eher mtr , da er packetlost per hop anzeigt.

holger

 

[christian83]

Danke euch beiden. Das hilft mir.

 

[TCM]

packetlost per hop

Packet loss unterwegs ist völlig egal, wenn das Ziel keinen hat. Ist auf den ersten Blick vielleicht verwirrend, aber denk mal drüber nach.

 

[mark05]

hi

naja völlig verwerfen würde ich das nicht, es kann hinweise geben auf probleme.

z.b.

ich habe mal von meinem urlaubsort in brasilien einen mtr zu meiner ip in deutchland gemacht und konnte
so feststellen das der verwendete , locale, internetprovider tagsüber vollkommen überlastete peerings hatte.

sprich er war , ist hoffnungslos überbucht .

zu bestimmten stunden war das weg ..............

holger

 

[TCM]

Nein, wenn deine Pakete am Ziel zu 100% ankommen, dann war da gar nichts überlastet.

Die Pakete gehen doch nicht magisch um die Router dazwischen herum.

 

[mark05]

hi

es geht ja darum , wenn es packetlost gibt , festzustellen wo sie passieren , sie muessen ja nicht
zwansgsweise am ende des weges passieren , und das gilt es darzustellen.


holger

 

[vto]

Ein bisschen ISP-Background:

Ein Traceroute über "das Internet" ist ein Anhaltspunkt, um Routingpfade grob zu verfolgen, mehr nicht. Und selbst dafür ist es trügerisch, einerseits wegen nicht-sichtbaren MPLS-Strecken (kann, muss nicht - abhängig von der Provider-Konfiguration) und andererseits wegen möglicher asymmetrischen oder Multipath-Routen (ECMP usw.).

Jeglicher Packet loss von Zwischen-Hops ist nicht aussagekräftig. Es ist gängige Praxis, dass Backbone-Router über Control Plane Policies die Verarbeitung von Verkehr an die Router selbst - und somit von genau jenen ICMP-Mechanismen, die Traceroute mit gezielten TTL-Werten nutzt - in Form von Rate Limitern begrenzen. Sie antworten also von außen nicht nachvollziehbar gemächlich oder auch mal gar nicht. Das hat aber genau nichts mit dem Forwarden von Nutz-Traffic und der aktuellen Auslastung des Routers oder eines Links zu tun.

Was zählt, ist Packet loss am Endziel und vielleicht noch vom eigenen First Hop, dem CPE (=eigener/ISP Endkunden-Router). Oder natürlich Traceroutes rein im eigenen Netz, wo alle Hops kontrolliert werden und das Verhalten bekannt ist.

Gruß

 

[TCM]

hi

es geht ja darum , wenn es packetlost gibt , festzustellen wo sie passieren , sie muessen ja nicht
zwansgsweise am ende des weges passieren , und das gilt es darzustellen.

holger

Eben das kann ein Traceroute nicht leisten. Wenn eine Analyse, die 0% Loss zum Ziel anzeigt, unterwegs trotzdem >0% Loss haben kann, was willst du dann aus >0% Loss unterwegs rauslesen können, wenn das Ziel mal nicht 0% hat? Hat der Router unterwegs jetzt dein Paket zum Ziel gedroppt oder hat er einfach (wie sonst auch) deine Anfrage mit einem 0-TTL-Paket nicht beantwortet? Das kannst du gar nicht unterscheiden.