Unitymedia routing wieder über Österreich?

[floh667]

Ich mags jetzt nicht unbedingt als Störung bezeichnen, aber kann es sein, dass unitymedia seit kurzem wieder über das lästige Österreich peering den traffic routet?
Gestern noch war ich beim online spielen mit einem 10/11er ping unterwegs, heute hab ich festgestellt dass er bei 17ms liegt. Ist meckern auf hohem Niveu, aber wieso muss das denn immer sein..

tracert zu google.de. ab hopp 3 taucht wieder die 84.116.191.170 auf, welche in Österreich sitzt.
Ist das bei euch auch so?

Routenverfolgung zu google.de [172.217.21.195] über maximal 30 Abschnitte:

1 6 ms 8 ms 7 ms HSI-KBW-37-209-92-1.hsi15.kabel-badenwuerttemberg.de [37.209.92.1]
2 7 ms 7 ms 7 ms 172.30.19.33
3 20 ms 19 ms 20 ms 84.116.191.170
4 17 ms 17 ms 16 ms de-str01c-rc1-ae23-0.aorta.net [84.116.191.165]

5 15 ms 15 ms 21 ms de-fra01b-rc1-ae4-0.aorta.net [84.116.140.201]
6 18 ms 17 ms 18 ms de-fra03b-ri1-ae10-0.aorta.net [84.116.132.178]

7 16 ms 16 ms 18 ms 213.46.177.42
8 17 ms 17 ms 17 ms 108.170.252.65
9 16 ms 16 ms 16 ms 108.170.235.247
10 15 ms 15 ms 15 ms fra16s12-in-f195.1e100.net [172.217.21.195]

 

[robert_s]

tracert zu google.de. ab hopp 3 taucht wieder die 84.116.191.170 auf, welche in Österreich sitzt.

Wie kommst Du darauf, dass die in Österreich sitzt?

 

[floh667]

weil www.utrace.de es sagt, so auch https://myip.ms/view/ip_addresses/1416937216 -> IP Range Location: Austria

 

[boba]

Wie kommt es, dass bereits die Latenz zu deiner eigenen öffentlichen IP Adresse (hop 1) 6-8ms ist? Das ist im lokalen LAN üblicherweise unter 1 ms.

 

[Dragon]

weil www.utrace.de es sagt, so auch https://myip.ms/view/ip_addresses/1416937216 -> IP Range Location: Austria

Du weißt, dass diese Seiten sehr ungenau sind? Bei den Routern in Stuttgart und Frankfurt wird bestimmt auch etwas völlig anderes angezeigt?

 

[addicted]

Wie kommt es, dass bereits die Latenz zu deiner eigenen öffentlichen IP Adresse (hop 1) 6-8ms ist? Das ist im lokalen LAN üblicherweise unter 1 ms.

Das könnte ein DSLite-Anschluss sein - der erste Hop ist keine RFC1918-Adresse, wie sie der lokale Router üblicherweise hat.

 

[boba]

So sieht das also bei dslite aus? Habe ich noch nie gesehen, deshalb frage ich so blöd. Ich kenne das nur so, dass der erste Hop die Adresse des lokalen Routers im lokalen LAN ist, selbst wenn von dem es im Tunnel weiter geht. Bei ipv6-Tunneln ist das ja so, und auch wenn man openvpn verwendet.

 

[Dragon]

Nein, das ist kein DSLite. Der traceroute wurde vermutlich direkt vom Router aus gemacht.

 

[robert_s]

weil www.utrace.de es sagt, so auch https://myip.ms/view/ip_addresses/1416937216 -> IP Range Location: Austria

Und https://www.iplocation.net/ fragt mehrere Datenbanken ab, mit den Ergebnissen:

84.116.191.170 United States California San Jose
84.116.191.170 Netherlands North Holland Schiphol-Rijk

Da siehst Du, was diese Geolocation-Datenbanken taugen. Geh' mal davon aus, dass aktuell ein Router in Deutschland diese IP-Adresse verwendet.

 

[floh667]

Hallo
entshculdigt die späte Antwort. Aber Arbeit und so...

Soweit ich weiß haben wir einen ipv4 anschluss, keinen ds lite. Und die tracert Anfrage hab ich ganz normal über meinen Pc getätigt. Bei uns hängt das Modem an einer Sonicwall (router) und ab da gehts per switch in die wohnung. Der router tauchte noch nie in einer tracert abfrage auf, da war schon immer der erste hopp direkt ins kabelbw/unitymedia netzwerk.

Glücklicherweise war es nur ein vorrübergehender Zustand, dass diese komische vermeintliche österreichische IP im routing auftauchte. Nun ist da wieder alles in bester Ordnung

Routenverfolgung zu google.de [172.217.16.163] über maximal 30 Abschnitte:

1 8 ms 7 ms 8 ms HSI-KBW-37-209-92-1.hsi15.kabel-badenwuerttemberg.de [37.209.92.1]
2 9 ms 8 ms 7 ms 172.30.19.33
3 10 ms 11 ms 10 ms de-fra04a-rc1-ae19-0.aorta.net [84.116.191.161]

4 10 ms 11 ms 10 ms de-fra03b-ri1-ae5-0.aorta.net [84.116.133.118]
5 10 ms 10 ms 11 ms 213.46.177.42
6 17 ms 15 ms 21 ms 108.170.252.1
7 10 ms 10 ms 10 ms 64.233.175.171
8 10 ms 10 ms 25 ms fra15s11-in-f163.1e100.net [172.217.16.163]

 

[tq1199]

Glücklicherweise war es nur ein vorrübergehender Zustand, dass diese komische vermeintliche österreichische IP im routing auftauchte. Nun ist da wieder alles in bester Ordnung

<i>
</i> 3 10 ms 11 ms 10 ms de-fra04a-rc1-ae19-0.aorta.net [84.116.191.161] 4 10 ms 11 ms 10 ms de-fra03b-ri1-ae5-0.aorta.net [84.116.133.118]

Wie hier bereits schon erwähnt, ist es von der Datenbank abhängig. Z. B.:

<i>
</i>::~ $ geoiplookup 84.116.191.161
GeoIP Country Edition: AT, Austria

<i>
</i>:~ $ geoiplookup 84.116.133.118
GeoIP Country Edition: AT, Austria

 

[floh667]

wieder etwas gelernt, danke

 

[jeti-power]

Wie hier bereits schon erwähnt, ist es von der Datenbank abhängig. Z. B.:

<i>
</i>::~ $ geoiplookup 84.116.191.161
GeoIP Country Edition: AT, Austria

<i>
</i>:~ $ geoiplookup 84.116.133.118
GeoIP Country Edition: AT, Austria

Auch wenn es halb-offtopic ist:
… wobei ich davon ausgehe, dass du die Maxmind GeoIP(1) City/Country Light Datenbank abgefragt hast. Die Datenbanken werden seit Anfang des Jahres nicht mehr aktualisiert. mmdblookup zusammen mit den GeoIP2 Datenbanken sollte man mittlerweile verwenden.

Dem aktuellen Stand bei Maxmind’s CityLight-Datenbank sieht man, dass er die IP nicht mehr auf ein Land zuordnen kann, sondern nur noch festlegt, dass diese innerhalb der EU verwendet wird:

84.116.191.161 ->

 { "continent": { "code": "EU" <utf8_string> "geoname_id": 6255148 <uint32> "names": { "de": "Europa" <utf8_string> } } "location": { "accuracy_radius": 100 <uint16> "latitude": 47.000000 <double> "longitude": 8.000000 <double> "time_zone": "Europe/Vaduz" <utf8_string> } }

84.116.191.161 ->

 { "continent": { "code": "EU" <utf8_string> "geoname_id": 6255148 <uint32> "names": { "de": "Europa" <utf8_string> } } "location": { "accuracy_radius": 100 <uint16> "latitude": 47.000000 <double> "longitude": 8.000000 <double> "time_zone": "Europe/Vaduz" <utf8_string> } }

Nur als kleine Info