Die Telekom hilft Community zieht um und ist bis zum 8. Januar 2025 nur eingeschränkt zugänglich.
Gelöst
Hohe Latenz innerhalb des DTAG Netzes
vor 5 Jahren
Hallo,
seit kurzem bin ich wie so viele aufs Home-Office angewiesen und muss mich per VPN zu meinem (französischen) Arbeitgeber verbinden. Meine Arbeit wird leider durchaus von hoher Latenz negativ beeinflusst, drum habe ich mich mit meinen Kollegen zwegs der Latenzzeiten zum VPN Endpoint ausgetauscht. Zuerst dachte ich 80ms von München bis Frankreich wären normal, jedoch sprachen meine Kollegen von weniger als 50 ms (iwo aus Italien) und weniger als 40 ms (Unitymedia, Ulm). Besagte Kollegen haben durch die deutlich geringere Latenz weniger Probleme beim Arbeiten und können auch effektiver Arbeiten. Also habe ich ein paar Traces gemacht um das Problem genauer zu beleuchten. Hier ein Trace von meinem Raspberrypi zum VPN Endpoint (Raspi3(München)->Wired Ethernet->Fritz!Box 7490-> ONT ->Fibre-> DTAG ->GTT->Endpoint(nahe Paris)):
My traceroute [v0.92] pi (192.168.2.5) 2020-04-04T21:44:10+0200 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.2.1 0.0% 287 0.7 0.6 0.5 1.1 0.1 2. 62.155.242.38 0.0% 287 1.9 2.6 1.0 41.8 3.9 3. 217.239.55.38 0.0% 287 12.6 12.6 11.8 30.8 1.2 4. 80.157.204.58 0.7% 287 64.7 65.7 59.3 98.4 4.0 5. 89.149.184.106 0.7% 287 79.0 81.1 75.2 114.0 4.8 6. 194.183.116.178 0.3% 287 79.8 79.5 75.0 80.8 0.9 7. ???
Der VPN Endpoint antwortet nicht auf Ping - daher die ???. Der Endpoint kann auch nur IPv4. Ich darf leider die IP/DNS des VPN Endpoints hier nicht veröffentlichen, ich denke aber es wäre kein Problem diese einem Service-Techniker auf Anfrage weiterzugeben. Um die Probleme nachzuvollziehen könnte daher vorerst die IP von Hop 6 ausreichen.
Was hier auffällt, ist der ungewöhnlich hohe Latenzgewinn von >50ms zwischen 217.239.55.38 und 80.157.204.58. Beide IPs gehören meinen Recherchen zurfolge der DTAG und sind beide irgendwo in Deutschland verortet (GeoLocation Provider geben sehr verschiedene Ergebnisse diesbezüglich). Aber auch der Latenzgewinn von >10ms zwischen dem zweiten und dritten Hop ist vergleichsweise enttäuschend.
Dass es anders geht kann man am folgenden Trace sehen, dieser wurde über einen weiteren Raspberrypi in Ingolstadt gemacht, der allerdings nicht am DTAG Netz hängt, sondern bei Com-IN (Raspi0(Ingolstadt)->WiFi->AP->WiredEthernet->Fritz!Box 7490-> ONT ->Fibre->Com-IN->GTT->Endpoint). Da die Route bis zum VPN endpoint hier anders verläuft, habe ich hier eine Traceroute bis zu Hop 6 aus dem letzten Trace gemacht (194.183.116.178). Siehe da, 18 ms (ich weiß, da fehlt noch ein Hop, dafür WiFi):
My traceroute [v0.87] raspberrypi (0.0.0.0) Sat Apr 4 21:44:33 2020 Keys: Help Display mode Restart statistics Order of fields quit Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 192.168.2.1 0.0% 552 5.2 5.1 2.0 10.6 1.1 2. 185.39.84.8 0.0% 552 6.9 9.9 6.7 74.0 9.7 3. 80.255.15.169 0.2% 552 7.0 9.0 6.8 38.2 3.6 4. 87.119.97.189 0.0% 551 7.0 9.8 6.8 64.4 5.4 5. 89.149.184.106 0.0% 551 20.9 18.2 15.9 46.9 3.5 6. ???
Nehme ich von hier (Ingolstadt, Com-IN) die direkte Route, gehts statt über GTT über COLT und ich lande ca. bei 23ms Latenz am VPN Endpoint. Mit 12ms von München nach Ingolstadt könnte man fast über ein VPN Umweg nachdenken, aber das ist keine Lösung, nur ein Workaround
Daher meine Frage: Wäre es möglich die Routen innerhalb des DTAG Netzes so hinzubiegen, dass diese vergleichweise große Latenz zu GTT nach Frankreich wegfällt?
Vielen Dank & liebe Grüße!
1021
0
11
Akzeptierte Lösungen
Alle Antworten
Sortieren
Älteste zuerst
Neueste zuerst
Älteste zuerst
Autor
Das könnte Ihnen auch weiterhelfen
vor 4 Jahren
2358
0
3
vor einem Jahr
195
0
6
1805
6
3
vor 9 Jahren
11408
2
1