Diese Website verwendet Cookies, um Dein Surferlebnis zu verbessern. Durch die weitere Nutzung der Website stimmst Du der Verwendung von Cookies zu.   Erfahre mehr.
Zustimmen
Diese Community verwendet Tracking-Tools Matomo zur Verbesserung des Angebots. Mit Zustimmung hilfst Du uns unsere Seite zu verbessern und akzeptieren unsere Datenschutzerklärung. Vielen Dank!   Erfahren mehr.
Zustimmen Nicht Zustimmen
scoopex666

IPv6 Connectivity gestört

Hallo Kabel Community,

IPv6 funktioniert bei KabelBW seit Monaten irgendwie nur leidlich.
Ich habe das Problem schon ein paar Mal über das Kundencenter/die Störungsmeldung adressiert, man erreicht darüber aber niemanden der das Problem technisch versteht bzw. sich damit wirklich auseinandersetzt.

Seit Monaten gibt es immer wieder Probleme über das IPv6 Protokoll Server im Internet zu erreichen.
Wie es scheint passt da etwas mit Peering/Routing nicht, denn manchmal funktioniert dass dann doch.
Meine Probleme betreffen immer nur IPv6, IPV4 funktioniert immer.
Restarts des KabelBW Routers (FRITZ!Box 6360 Cable, FRITZ!OS:06.52) helfen in seltenen Fällen.
Mein Anschluss verfügt über eine öffentlich geroutete IPv4 und IPv6 Adressen)

Von meinem Linux Laptop zuhause sieht das dann so aus:
(ich verbinde mich zum System 256bit.org, das ich privat utze und über dessen Zustand ich gut Bescheid weiß)
----
# Wie man sieht hat der Server eine IPv6 und eine IPv4 IP
$ host 256bit.org
256bit.org has address 144.76.87.176
256bit.org has IPv6 address 2a01:4f8:192:14af::2
256bit.org mail is handled by 10 www.256bit.org.

# Beim Test mit Ipv6 erreicht kein Ping Paket sein Ziel
$ ping6 -c 20 256bit.org
PING 256bit.org(256bit.org (2a01:4f8:192:14af::2)) 56 data bytes

--- 256bit.org ping statistics ---
20 packets transmitted, 0 received, 100% packet loss, time 19432ms

# Beim Test mit IPv4 erreicht jedes Paket sein Ziel
$ ping -c 20 144.76.87.176
PING 144.76.87.176 (144.76.87.176) 56(84) bytes of data.
64 bytes from 144.76.87.176: icmp_seq=1 ttl=53 time=19.2 ms
64 bytes from 144.76.87.176: icmp_seq=2 ttl=53 time=17.7 ms
64 bytes from 144.76.87.176: icmp_seq=3 ttl=53 time=19.0 ms
64 bytes from 144.76.87.176: icmp_seq=4 ttl=53 time=20.6 ms
64 bytes from 144.76.87.176: icmp_seq=5 ttl=53 time=18.8 ms
64 bytes from 144.76.87.176: icmp_seq=6 ttl=53 time=31.6 ms
64 bytes from 144.76.87.176: icmp_seq=7 ttl=53 time=19.1 ms
64 bytes from 144.76.87.176: icmp_seq=8 ttl=53 time=18.7 ms
64 bytes from 144.76.87.176: icmp_seq=9 ttl=53 time=20.1 ms
64 bytes from 144.76.87.176: icmp_seq=10 ttl=53 time=18.9 ms
64 bytes from 144.76.87.176: icmp_seq=11 ttl=53 time=126 ms
64 bytes from 144.76.87.176: icmp_seq=12 ttl=53 time=80.7 ms
64 bytes from 144.76.87.176: icmp_seq=13 ttl=53 time=21.7 ms
64 bytes from 144.76.87.176: icmp_seq=14 ttl=53 time=37.5 ms
64 bytes from 144.76.87.176: icmp_seq=15 ttl=53 time=21.8 ms
64 bytes from 144.76.87.176: icmp_seq=16 ttl=53 time=18.3 ms
64 bytes from 144.76.87.176: icmp_seq=17 ttl=53 time=24.6 ms
64 bytes from 144.76.87.176: icmp_seq=18 ttl=53 time=18.7 ms
64 bytes from 144.76.87.176: icmp_seq=19 ttl=53 time=20.9 ms
64 bytes from 144.76.87.176: icmp_seq=20 ttl=53 time=20.5 ms

--- 144.76.87.176 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19028ms
rtt min/avg/max/mdev = 17.735/29.771/126.022/25.995 ms

# der Traceroute geht ins Leere
$ traceroute6 256bit.org
traceroute to (2a01:4f8:192:14af::2) from 2a02:8070:248d:ac00:a5a9:51e8:bf4e:d9da, 30 hops max, 24 byte packets
1 fritz.box (2a02:8070:248d:ac00:9ec7:a6ff:fe2b:7b5d) 1,939 ms 1,191 ms 1,533 ms
2 * * *
3 * * *
4 * * *
...
...
25 * * *
26 * * *
27 * * *

# Die Paketloss Rate auf 2001:730:2d00::5474:807d sieht nicht gut aus
$ mtr 256bit.org
My traceroute [v0.87]
nb18 (: Sat Nov 4 10:05:16 2017
Resolver error: No error returned but no answers given. of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. fritz.box 0.7% 409 2.4 3.2 0.8 370.1 19.6
2. 2a02:8070:2400::1 0.0% 409 10.2 14.9 8.2 626.3 34.6
3. 2a02:8070:20fb:2882::1 33.8% 409 13.5 14.2 8.4 534.8 32.0
4. 2001:730:2d00::5474:807d 0.2% 409 14.7 17.2 11.5 443.3 22.2
5. 2001:730:2d00::5474:8066 0.0% 409 13.3 17.8 11.9 356.4 19.1
6. 2001:730:2d00::5474:8001 0.0% 408 14.3 16.5 11.6 265.6 14.2
7. 2001:730:2d02:6::d52e:b38a 0.0% 408 12.5 16.3 11.7 175.7 10.2
8. 2a01:3e0:ff20::ae 0.0% 408 15.2 16.8 11.5 154.8 13.5
9. core24.fsn1.hetzner.com 0.2% 408 27.1 21.4 16.6 122.3 9.1
10. ex9k2.dc10.fsn1.hetzner.com 0.0% 408 23.1 22.5 16.2 543.4 32.0
11. 256bit.org 0.2% 408 19.3 21.7 15.9 451.8 26.9
----

Zeitgleich funktioniert das von einem System an einem anderen Ort (ein Server in Stuttgart auf den ich via SSH eingeloggt bin) zeitglich problemlos
----
$ ping6 -c 20 2a01:4f8:192:14af::2
PING 2a01:4f8:192:14af::2(2a01:4f8:192:14af::2) 56 data bytes
64 bytes from 2a01:4f8:192:14af::2: icmp_seq=1 ttl=56 time=13.8 ms
64 bytes from 2a01:4f8:192:14af::2: icmp_seq=2 ttl=56 time=8.90 ms
64 bytes from 2a01:4f8:192:14af::2: icmp_seq=3 ttl=56 time=8.90 ms
...
...
64 bytes from 2a01:4f8:192:14af::2: icmp_seq=18 ttl=56 time=8.89 ms
64 bytes from 2a01:4f8:192:14af::2: icmp_seq=19 ttl=56 time=8.90 ms
64 bytes from 2a01:4f8:192:14af::2: icmp_seq=20 ttl=56 time=8.91 ms

--- 2a01:4f8:192:14af::2 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19025ms
rtt min/avg/max/mdev = 8.889/9.186/13.861/1.081 ms
----

Kennt ihr diese Probleme auch bzw. wie seid ihr da weitergekommen?

Grüße
Marc
Speichern Abbrechen
Konnte dir geholfen werden?
  • Ja
Dieser Beitrag wurde geschlossen.
Es ist nicht möglich, Kommentare zu schreiben. Du kannst aber jederzeit eine Frage stellen.
Frage stellen
2 Kommentare
2017-11-04T11:11:45Z
  • Samstag, 04.11.2017 um 12:11 Uhr
Wenn Du beim direkten Unternehmenskontakt nicht weiter kommst, ist die Idee die Probleme hier zu veröffentlichen ganz hilfreich. Damit können sachkundige Kunden das Problem bestätigen oder es als Einzelfall herausstellen.
Mein Beitrag fällt es etwas bescheiden aus. Ich kann sagen, dass es bei der Telekom (LTE und DSL) funktioniert, so dass es wahrscheinlich ist, dass UM der Verursacher ist.
2017-11-04T11:22:26Z
  • Samstag, 04.11.2017 um 12:22 Uhr
Eine weitere Idee wäre noch Kontakt mit den Leuten vom ripe Atlas aufzunehmen. Wenn man dort bei den Proben aufgenommen wird, hat man eine gute Chance den schwarzen Peter zu identifizieren. Diese Argumente (unabhängige Messergebnisse) kann man dann an die beteiligten ISP herantragen. Vielleicht reagieren sie dann besser.