crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
crumb.isLink crumb.isFinalCrumb crumb.getClass crumb.css crumb.separatorCss crumb.getCss crumb.finalCrumb crumb.getText crumb.getIsLink crumb.getWrapperCss crumb.type crumb.url crumb.getUrl crumb.getType crumb.hashCode crumb.equals crumb.toString crumb.wrapperCss crumb.text crumb.getSeparatorCss crumb.class
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
Gelöst! Gehe zu Lösung.
Seit heute geht IPv6 endlich wieder!
13.10.2018 20:25
geht am peeringpoint verloren, ob es ein telekom oder ein partner problem ist, ist unklar
13.10.2018 21:05
13.10.2018 21:10
klemmt über ipv6 praktisch überall
13.10.2018 21:18
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.
13.10.2018 22:05
13.10.2018 22:56
13.10.2018 23:06
@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
13.10.2018 23:17 Zuletzt bearbeitet: 13.10.2018 23:20 durch den Autor
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.
14.10.2018 17:34
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.
14.10.2018 18:01
Es ist doch hier gemeldet. Ich gehe mittlerweile davon aus, dass es auch gelesen wird.
14.10.2018 18:04
17.10.2018 12:59
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"
17.10.2018 18:41
19.10.2018 10:53 Zuletzt bearbeitet: 19.10.2018 10:54 durch den Autor
Ein Mitarbeiter der Telekom hat Cogent erreicht. Cogent hat reagiert. So stehen die Chancen gut, dass das Peering in den nächsten Tagen klappt.
20.10.2018 18:30
24.10.2018 17:58
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.
25.10.2018 15:01 Zuletzt bearbeitet: 25.10.2018 15:23 durch den Autor
@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!
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Informieren Sie sich über unsere aktuellen Internet-Angebote.