Seit einiger Zeit Probleme mit IPv6 zu bestimmtem Provider

Gelöst

Seit einigen Wochen kann ich auf den Webhoster euserv.com nicht mehr per IPv6 zugreifen. Ich war schon mit deren Support in Kontakt, die sagen, das Problem besteht nicht auf deren Seite. Ein IPv6-Ping von meinem Anschluss zum Provider ergibt zwar die IPv6-IP, aber "Zielhost nicht erreichbar". Ein IPv6-Traceroute von meinem Server bei diesem Provider zu meiner lokalen Telekom-IP (IPv6) stoppt bei "be3457.ccr21.ams04.atlas.cogentco.com".

 

Nun frage ich mich, ob ein Routing-Problem von IPv6-Paketen von NRW nach Thüringen (und andersrum) seitens der Telekom bekannt ist.

 

Vielleicht können mir Telekomnutzer (mit aktiviertem IPv6) aus NRW sagen, was folgender Befehl ergibt:

 

ping -6 euserv.com

1 AKZEPTIERTE LÖSUNG

geht am peeringpoint verloren, ob es ein telekom oder ein partner problem ist, ist unklar

E468540B-891A-4587-A0C0-12801AF8733F.jpeg

Schaut mal, ob das Problem auch hier reproduzierbar ist.

https://f-lga1.f.de.net.dtag.de/index.php

 

 

klemmt über ipv6 praktisch überall 

Hab's auch gerade probiert, obwohl vom Handy aus nur suboptimal zu bedienen:

 

PING euserv.com(2a02:180:ffff:1::551f:b968) 56 data bytes From 2003:0:1300:c0c0::1 icmp_seq=1 Destination unreachable: No route --- euserv.com ping statistics --- 1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 68ms

 

Von zwei anderen mir zu Verfügung stehenden ISPs funktioniert es.

Komm ausm Telekom LTE Netz mit reinem IPv6 ohne Probleme hin.
@CyberSW Darf ich fragen, aus welchem Bundesland du es versuchst? Alternativ: NRW ja/nein.

Ich frage mich ja, ob es irgendwo in der Mitte (von Deutschland) klemmt.

Kann man das LTE-Netz der Telekom als eigenständiges Netz sehen oder ist das Routenmäßig wie das "normale" Netz? Ich kenne mich da nicht aus. Zwinkernd

@CyberSW  schrieb:
Komm ausm Telekom LTE Netz mit reinem IPv6 ohne Probleme hin.

Ich nicht. Jedenfalls nicht, wenn ich darauf achte wirklich IPv6 zu nutzen und nicht einen der Tricks (464xlat) nutze.

 

ping -6 euserv.com
PING euserv.com(2a02:180:ffff:1::551f:b968 (2a02:180:ffff:1::551f:b968)) 56 data bytes


ping -4 euserv.com
PING euserv.com (85.31.185.104) 56(84) bytes of data.
64 bytes from skynet3new.web.kundencontroller.de (85.31.185.104): icmp_seq=1 ttl=48 time=56.6 ms
64 bytes from skynet3new.web.kundencontroller.de (85.31.185.104): icmp_seq=2 ttl=48 time=53.6 ms
64 bytes from skynet3new.web.kundencontroller.de (85.31.185.104): icmp_seq=3 ttl=48 time=53.0 ms
64 bytes from skynet3new.web.kundencontroller.de (85.31.185.104): icmp_seq=4 ttl=48 time=54.1 ms
^C
--- euserv.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7115ms
rtt min/avg/max/mdev = 53.001/54.350/56.630/1.3

Bei Routingproblemen dieser Art ist nach meiner bisherigen Erfahrung kein Unterschied bei der Telekom zwischen DSL- und LTE-Anschlüssen festzustellen(auch wenn zwei unterschiedliche Präfixe verwendet werden). Das macht eine Abteiltung bei der Telekom für alle gleich.

LTE wird lediglich strenger gefiltert, so dass auch manchmal essentielle icmp-Nachrichten nicht durchkommen.

thomas@linux-y7a7:~> /usr/sbin/traceroute6 euserv.com
traceroute to euserv.com (2a02:180:ffff:1::551f:b968), 30 hops max, 80 byte packets
 1  2a01:598:b971:d8a4::18 (2a01:598:b971:d8a4::18)  5.767 ms  5.668 ms  5.580 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

thomas@linux-y7a7:~> /usr/sbin/traceroute euserv.com
traceroute to euserv.com (85.31.185.104), 30 hops max, 60 byte packets
 1  192.168.43.136 (192.168.43.136)  44.786 ms  44.731 ms  44.658 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  skynet3new.web.kundencontroller.de (85.31.185.104)  177.018 ms  176.983 ms  176.864 ms
 9  skynet3new.web.kundencontroller.de (85.31.185.104)  176.804 ms  176.716 ms  176.648 ms
10  skynet3new.web.kundencontroller.de (85.31.185.104)  176.588 ms  176.514 ms  176.421 ms
11  skynet3new.web.kundencontroller.de (85.31.185.104)  176.369 ms  176.295 ms  176.223 ms
12  skynet3new.web.kundencontroller.de (85.31.185.104)  176.164 ms  176.078 ms  28.041 ms
13  skynet3new.web.kundencontroller.de (85.31.185.104)  40.525 ms  40.487 ms  40.427 ms
14  skynet3new.web.kundencontroller.de (85.31.185.104)  40.349 ms  50.705 ms  50.673 ms
15  skynet3new.web.kundencontroller.de (85.31.185.104)  50.611 ms  50.538 ms  50.464 ms
16  skynet3new.web.kundencontroller.de (85.31.185.104)  60.581 ms  62.408 ms *
17  * skynet3new.web.kundencontroller.de (85.31.185.104)  58.090 ms  58.926 ms
18  skynet3new.web.kundencontroller.de (85.31.185.104)  58.839 ms * *

Beide traces sind auch von einem "ipv6-only" -Anschluss, wobei beim zweiten das Smartphone IPv4 mittels 464xlat wieder einbringt.

Das Notebook ist via Hotspot/WLAN angeschlossen. Auf meinen blöden Android kann ich seit "Pie" nicht mehr direkt pingen, weil google aus irgendeinem Grund allen Apps die Berechtigung dafür entzogen hat. "Bad system call".

Das nur am Rande. Es ändert aber nicht daran, dass das Peering bei der Telekom zu diesem Host klemmt.


Es ändert aber nicht daran, dass das Peering bei der Telekom zu diesem Host klemmt.


Ist es sinnvoll, das irgendwo zu melden? Das Problem bestand schließlich nicht immer. Erst seit kurzem.

Es ist doch hier gemeldet. Ich gehe mittlerweile davon aus, dass es auch gelesen wird.

Eine Stimme sagte mir, es  könne nicht schaden, wenn man sich (als) Kunde auch bei cogent melden würde.

Konkret wurde empfohlen:

"Tja, wenn Cogent AS35366 zu seinen AS-Sets hinzufügen würde, könnte man auch die vorhandenen route6-objects zum Filter hinzufügen"

Wer wäre hier der Kunde? Die Telekom?

Ein Mitarbeiter der Telekom hat Cogent erreicht. Cogent hat reagiert. So stehen die Chancen gut, dass das Peering in den nächsten Tagen klappt.

 

 

 

Super, das klingt gut!

Ich werde berichten, sobald es wieder geht.

Seit heute Morgen gibt es eine Änderung: Der Provider ist nun scheinbar gar nicht mehr per IPv6 erreichbar. Könnte nun natürlich auch am Provider liegen.


@King555  schrieb:

Seit heute Morgen gibt es eine Änderung: Der Provider ist nun scheinbar gar nicht mehr per IPv6 erreichbar. Könnte nun natürlich auch am Provider liegen.


Glaube ich mittlerweile auch:

 

ping    euserv.com
PING euserv.com(2a02:180:ffff:1::551f:b968 (2a02:180:ffff:1::551f:b968)) 56 data bytes
From po204.ipv6.bbsw-h3-j1cr.as35366.net (2a02:180:6:7::9) icmp_seq=3 Destination unreachable: Unknown code 6
From po204.ipv6.bbsw-h3-j1cr.as35366.net (2a02:180:6:7::9) icmp_seq=15 Destination unreachable: Unknown code 6
From po204.ipv6.bbsw-h3-j1cr.as35366.net (2a02:180:6:7::9) icmp_seq=16 Destination unreachable: Unknown code 6

Identische Fehlermeldung von zwei verschiedenen Nicht-Telekom-Endpunkten.

 

Aus deren Statusseite geht auch nichts richtiges hervor. Das Forum hat einen DB-Fehler....

 

 

Seit heute geht IPv6 endlich wieder! Fröhlich