25% Packet Loss zu Google?

[WhiteVelvet]

Hallo nochmals,

ich prüfe gerade meine neue Internetleitung durch (siehe Fritz Fon im Nachbar-Thread) und beobachte dabei, dass ich zu google.com einen Packet Loss von 26% habe! Aber zu heise.de sind es 0%. Wie kann das denn sein? Hat nur Google ein Problem? Schade, ich hab gedacht, ich hätte da ein generelles Problem mit der Leitung erkannt...

[lumines]

Wie kann das denn sein? Hat nur Google ein Problem? Schade, ich hab gedacht, ich hätte da ein generelles Problem mit der Leitung erkannt...

Große Diensteanbieter wie Google haben nicht nur einen Server, sondern mehrere und je nach dem routet dich dein Provider unglücklich.

Die Telekom ist z.B. auch bekannt dafür, dass sie ihre Peeringkapazitäten zu Google nicht ausbaut. Wahrscheinlich ist das Netz der Telekom einfach überlastet an der Stelle zu Google. Sieht man auch schön daran, dass manchmal YouTube nur in sehr niedrigen Auflösungen funktioniert.

[Darkman.X]

EDIT: Oh Gott, bin ich langsam. "lumines" hat ja schon alles geschrieben.

Bei mir (o2) keine Probleme. Da du deinen Anbieter nicht nennst, kann man schlecht vergleichen. Google ist aber auch generell schlecht zu vergleichen, weil Google mehrere Rechenzentren und somit auch mehrere IP-Adressen hat.

Bei mir z.B. hat www.google.de die IP-Adresse 74.125.206.94. Bei dir wird es vermutlich eine andere IP-Adresse haben und daher nicht vergleichbar.
google.de (ohne www.) hat die 172.217.18.195.

[WhiteVelvet]

Anbieter ist Telekom und google.com hat hier die 216.58.208.35... wie siehts da bei Euch mit PL aus?

[piefke]

Vodafone

Ping wird ausgeführt für google.com [216.58.214.78] mit 32 Bytes Daten

Ping-Statistik für 216.58.214.78:
Pakete: Gesendet = 67, Empfangen = 67, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 24ms, Maximum = 62ms, Mittelwert = 34ms

[Darkman.X]

@WhiteVelvet: Das bringt dir alles nichts. o2 und Vodafone haben sicherlich ein anderes Routing zur 216.58.208.35 als die Telekom. Selbst innerhalb der Telekom müssen nicht alle Telekom-Kunden das gleiche Routing haben. Da können z.B. alle Telekom-Kunden in Süddeutschland ein anderes Routing zu 216.58.208.35 haben als die Kunden in Norddeutschland (nur als Beispiel). Das Routing-Geschäft ist eine ganz komplizierte Sache.

Ich erwähne es, weil ja nicht zwingend Google selber betroffen sein muss. Vielleicht ist ja ein Router/Knotenpunkt zwischen dir und Google betroffen. Ein evtl. nützlicher Befehl für die Analyse wäre "pathping". Damit wird ein Traceroute durchgeführt (alle Router/Knotenpunkte zwischen dir und 216.58.208.35 auflisten) und jeder Router/Knotenpunkt wird angepingt. Aber Vorsicht: Interessant sind nur die Router mit krummen Verlustangaben, denn bei 100% blockiert der Router einfach nur das Ping-Protokoll.

Hier ein Beispiel, wie es bei mir aussieht:

C:\Users\Darkman>pathping 216.58.208.35

Routenverfolgung zu "fra15s12-in-f3.1e100.net" [216.58.208.35]
über maximal 30 Hops:
0 Darkman.fritz.box [192.168.1.100]
1 fritz.box [192.168.1.1]
2 62.52.201.199
3 ae15-0.02.xd.0176-03.xxxxx.de.net.telefonica.de [62.53.2.26]
4 ae1-0.0001.prrx.02.xxxxx.de.net.telefonica.de [62.53.8.41]
5 213.191.77.79
6 209.85.249.124
7 72.14.233.216
8 209.85.240.154
9 74.125.37.89
10 66.249.95.22
11 216.239.57.142
12 72.14.235.245
13 66.249.94.135
14 fra15s12-in-f3.1e100.net [216.58.208.35]

Berechnung der Statistiken dauert ca. 350 Sekunden...
Quelle zum Abs. Knoten/Verbindung
Abs. Zeit Verl./Ges.= % Verl./Ges.= % Adresse
0 Darkman.fritz.box [192.168.1.100]
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0% fritz.box [192.168.1.1]
0/ 100 = 0% |
2 16ms 0/ 100 = 0% 0/ 100 = 0% 62.52.201.199
0/ 100 = 0% |
3 17ms 0/ 100 = 0% 0/ 100 = 0% ae15-0.02.xd.0176-03.xxxxx.de.net.telefonica.de [62.53.2.26]
0/ 100 = 0% |
4 16ms 0/ 100 = 0% 0/ 100 = 0% ae1-0.0001.prrx.02.xxxxx.de.net.telefonica.de [62.53.8.41]
0/ 100 = 0% |
5 --- 100/ 100 =100% 100/ 100 =100% 213.191.77.79
0/ 100 = 0% |
6 16ms 0/ 100 = 0% 0/ 100 = 0% 209.85.249.124
0/ 100 = 0% |
7 --- 100/ 100 =100% 100/ 100 =100% 72.14.233.216
0/ 100 = 0% |
8 --- 100/ 100 =100% 100/ 100 =100% 209.85.240.154
0/ 100 = 0% |
9 --- 100/ 100 =100% 100/ 100 =100% 74.125.37.89
0/ 100 = 0% |
10 --- 100/ 100 =100% 100/ 100 =100% 66.249.95.22
0/ 100 = 0% |
11 --- 100/ 100 =100% 100/ 100 =100% 216.239.57.142
0/ 100 = 0% |
12 --- 100/ 100 =100% 100/ 100 =100% 72.14.235.245
0/ 100 = 0% |
13 --- 100/ 100 =100% 100/ 100 =100% 66.249.94.135
0/ 100 = 0% |
14 27ms 0/ 100 = 0% 0/ 100 = 0% fra15s12-in-f3.1e100.net [216.58.208.35]

Ablaufverfolgung beendet.

Dort sieht man, dass die ersten 4 Hops im o2/Telefonica-Netz sind (bei dir heißen die Router vermutlich irgendetwas mit "DTAG" im Namen). Alle anderen Hops danach sind vermutlich außerhalb des Telefonica-Netzes, leider identifiziert sich nicht jeder Router mit einem eindeutigen Namen. Wenn also irgendein Eintrag ab dem 5. Hop z.B. 25% Verlust zeigen würde, dann wäre es außerhalb des Anbieter-Netzes, wo der Anbieter theoretisch nichts machen kann.

Man könnte natürlich eine Störung melden und der Anbieter ändert das Routing. Aber ganz ehrlich: Wenn du mit Pech der einzige bist, der eine Störung meldet, dann wird wohl nichts passieren.

[blinki]

Hi, ich hab 02 50Mbit und ich bekomme zu google 0% verlust über ipv4 bei 30 ms Ping und
5% Verlust über ipv6 bei einem ping von 39/1528/95 ms min/max/average

die ip4 ist in meinem fall 216.58.213.206 (aus Düsseldorf)

kann natürlich bereits im Router vergeigt werden, oder nicht?

[konkretor]

wenn du mal ein vpn benutzt, wie sieht es dann aus?

[Gast]

Hallo,

wie misst du den Packet Loss? Mit einem speziellen Programm dass massenweise Pings an ein Ziel sendet, oder nur mit einem "standard" Systemping?

Denn viele Ziele haben bei einer zu grossen Anzahl an ICMP Paketen automatische Filter installiert, die dann die weiteren Anfragen droppen.
Das ist so ziemlich der häufigste Fehler wenn es um Drops geht.

Könntest du mal ein Beispiel-Bild zeigen, wie du das misst?

[Schrotti]

Ich nehme für solche Sachen den Ping Plotter.

[sei laut]

Ich nehme für solche Sachen den Ping Plotter.
Unter Windows (so sieht zumindest dein Screenshot aus) gibts dafür "Pathping". Ist eine Kommandozeilenanwednung.

@Gast: Ich denke nicht. In meinen Augen ist das sehr unüblich, da die großen Router, über die man beim normalen Routing geleitet wird, solche Anfragen im Schlaf beantworten. Das zu blocken wäre unsinnig.

Was natürlich gemacht wird, ist ein ping flooding Schutz, der schlägt aber nicht bei einem pro Sekunde an.

[Gast]

Hallo,

ich nochmal.
Genau solche Sachen wie Ping Plotter können sowas verursachen. Ein normaler Windows Ping wird natürlich nicht geblockt.

Soetwas setzen wir (grosser Provider) ebenfalls im Core ein. Hintergrund ist einfach, dass solch eine Anfrage auf die Backbone Router CPU gehen kann, während ein Transitpaket einfach forgewarded wird.

Rein von der Logik wäre es ja auch seltsam, wenn Pakete irgendwo auf der Strecke (die direkt angepingt wird) droppen würden, während weitergeleitete Pakete problemlos zu 100 Prozent ankommen,

[lumines]

@Gast: Ich denke nicht. In meinen Augen ist das sehr unüblich, da die großen Router, über die man beim normalen Routing geleitet wird, solche Anfragen im Schlaf beantworten. Das zu blocken wäre unsinnig.

Blocken vielleicht nicht, aber Ratelimiting für ICMP ist sehr üblich und für IPv6 sogar explizit erwünscht, wenn man diverse RFCs liest.

Kommt auch drauf an, wie das Ratelimiting implementiert ist. Manche benutzen Token Buckets, andere werden vielleicht nach Bandbreite limitieren. Kann schon sein, dass das an manchen Stellen nicht richtig bemessen wurde und dann ICMP unsinnigerweise zu früh gedroppt wird.