Warum O2
Warenkorb
Service
Gelöst

IPv6-Verbindungsaufbau sehr langsam


Benutzerebene 1

Seit dieser Wochen scheinen (einige?) IPv6-Pakete vom HomeSpot und/oder LTE-Netz nicht mehr durchgelassen zu werden.

Beispielweise kommt ein Ping per IPv6 zu google.com nicht durch:

ping -6 -c 10 google.com
PING google.com(fra15s22-in-x0e.1e100.net (2a00:1450:4001:81f::200e)) 56 data bytes

--- google.com ping statistics ---
10 packets transmitted, 0 received, 100% packet loss, time 9196ms

Per IPv4 geht es:

ping -4 -c 10 google.com
PING google.com (172.217.23.174) 56(84) bytes of data.
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=1 ttl=112 time=29.5 ms
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=2 ttl=112 time=44.3 ms
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=3 ttl=112 time=43.2 ms
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=4 ttl=112 time=35.1 ms
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=5 ttl=112 time=33.0 ms
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=6 ttl=112 time=39.9 ms
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=7 ttl=112 time=57.9 ms
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=8 ttl=112 time=48.7 ms
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=9 ttl=112 time=68.2 ms
64 bytes from fra15s22-in-f174.1e100.net (172.217.23.174): icmp_seq=10 ttl=112 time=65.3 ms

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 29.595/46.560/68.282/12.725 ms

Wie man sehen kann liegt es nicht an der Adressauflösung selbst. Die funktioniert relativ flott:

time nslookup google.com
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: google.com
Address: 172.217.23.174
Name: google.com
Address: 2a00:1450:4001:81f::200e


real 0m0,051s
user 0m0,012s
sys 0m0,000s

Gleiches gilt auch für ausgehende SSH-Verbindungen per IPv6:

time ssh -6 -T git@gitlab.com
ssh: connect to host gitlab.com port 22: Connection timed out

real 2m10,079s
user 0m0,004s
sys 0m0,004s

Per IPv4 geht es:

time ssh -4 -T git@gitlab.com
Welcome to GitLab, @ountenzwei!

real 0m1,470s
user 0m0,017s
sys 0m0,006s

Was kann ich tun, um das zu beheben?

icon

Lösung von ountenzwei 26 September 2020, 12:29

Zur Antwort springen

22 Antworten

Benutzerebene 1

Das Phänomen ist unabhängig vom Betriebssystem des Endgeräts (getestet unter Windows, Mac OS, Ubuntu und Arch Linux).

Benutzerebene 7
Abzeichen +4

Ipv6 unterstützt keinen Ping

 

Benutzerebene 1

@Denner Danke für deine schnelle Antwort auf meine Frage!

Deine Antwort ist aber leider weder hilfreich noch richtig. Hier die Ausgabe von Ping außerhalb des o2-Netz:

ping -6 -c 10 google.com
PING google.com(fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e)) 56 data bytes
64 bytes from fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e): icmp_seq=1 ttl=113 time=10.2 ms
64 bytes from fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e): icmp_seq=2 ttl=113 time=10.0 ms
64 bytes from fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e): icmp_seq=3 ttl=113 time=9.89 ms
64 bytes from fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e): icmp_seq=4 ttl=113 time=10.0 ms
64 bytes from fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e): icmp_seq=5 ttl=113 time=9.89 ms
64 bytes from fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e): icmp_seq=6 ttl=113 time=9.85 ms
64 bytes from fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e): icmp_seq=7 ttl=113 time=10.0 ms
64 bytes from fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e): icmp_seq=9 ttl=113 time=9.88 ms
64 bytes from fra16s18-in-x0e.1e100.net (2a00:1450:4001:81e::200e): icmp_seq=10 ttl=113 time=9.88 ms

--- google.com ping statistics ---
10 packets transmitted, 9 received, 10% packet loss, time 9010ms
rtt min/avg/max/mdev = 9.851/9.980/10.230/0.137 ms

 

Benutzerebene 7
Abzeichen +4

Meines Wissens werden die icmp Pakete verworfen, weil nicht benötigt, aber egal, im dsl Bereich funktionieren Ping versuche, wobei ich nicht weiß, ob die nicht per ipv4 unterstützt werden. 

Benutzerebene 1

@Denner Das Ping ist mir tatsächlich auch eigentlich egal und ich habe es nur als Demonstration genutzt, dass die Pakete verschwinden. Was mich stört, ist, dass SSH-Verbindungen nicht mehr möglich sind und damit beispielsweise die Nutzung von Git auch nicht mehr.

Wie schon in der ursprünglichen Frage geschrieben, ist das Phänomen neu seit dieser Woche. Vorher funktionierte beides problemlos.

Benutzerebene 1

Meines Wissens werden die icmp Pakete verworfen, weil nicht benötigt, aber egal, im dsl Bereich funktionieren Ping versuche, wobei ich nicht weiß, ob die nicht per ipv4 unterstützt werden. 


@Denner Dass die Pakete nicht benötigt werden und üblicherweise verworfen stimmt übrigens auch nicht. Die Pakete sind für das Funktionieren von IPv6 sogar notwendig:

Im Gegensatz zum ICMP bei IPv4 ist ICMPv6 zwingend für den Betrieb von IPv6 nötig. Ein generelles Blockieren von ICMPv6 auf der Firewall führt dazu, dass IPv6 nicht funktioniert (vgl. RFC 4890).

(https://de.wikipedia.org/wiki/ICMPv6)

Benutzerebene 7
Abzeichen

Ipv6 unterstützt keinen Ping

 

Doch Denner, tut es!

Hallo @ountenzwei,

tut mir leid, dass du warten musstest.

Wie ich sehe, hast du am 27.08. sowie erneut heute, jeweils eine Störungsmeldung an die Kollegen der Technik weitergeleitet. Dort wird dein Anliegen bearbeitet, auch wenn du vielleicht bisher keine weiterführenden Infos dazu erhalten hast. Wir können diesen Vorgang hier leider nicht beschleunigen. Sofern die Kollegen final keinen Fehler finden können, worüber du dann auch eine Info erhältst, von deiner Seite aus dieser aber weiterhin feststellbar ist, schreibe uns hier bitte nochmal und wir versuchen, eine erneute Prüfung anzustoßen.

Da die Kollegen bereits dran sind, kann ich dich derzeit nur um Geduld bitten.

VG
Dennis

Benutzerebene 1

@o2_Dennis Danke für die Antwort!

 

Die von mir gemeldete Störung, die zu diesem Post gehört ist HDIT-1047689. Dazu habe ich am 31.08. die Rückmeldung bekommen:

auch nach intensiver Prüfung (Nr. HDIT-1047689) konnten wir keine technische Beeinträchtigung unseres Netzes feststellen

Das klang für mich danach als wären die Kollegen jetzt nicht mehr dran. Leider tritt das oben beschriebene Problem aber immer noch auf.

Die Störung, die ich heute gemeldet habe (hoher Paketverlust–auch über IPv4, HDIT-1052673) hat mit dem oben beschriebenen Problem nichts zu tun.

Benutzerebene 1

Die Störung, die ich heute gemeldet habe (hoher Paketverlust–auch über IPv4, HDIT-1052673) hat mit dem oben beschriebenen Problem nichts zu tun.

 

Dafür habe ich jetzt einen separaten Post gemacht: https://hilfe.o2online.de/o2-homespot-o2-my-data-spot-21/hoher-paketverlust-per-homespot-lte-543178

Benutzerebene 1

@o2_Dennis Gibt es hier noch etwas, das ich tun kann? Das Problem tritt immer noch auf. Macht es Sinn noch einmal eine Störung zu melden, nachdem HDIT-1047689 als erledigt markiert wurde?

Hallo @ountenzwei ,

 

könntest du heute ein Beispiel anfertigen (gerne beide Varianten, Ping und SSH)?

Ich leite es dann weiter.

Damit ich es richtig verstehe und weitergebe: Du wechselst per Menü manuell zwischen IPv4 und 6?

 

Wir eröffnen mit den Daten eine Fehlermeldung, schicken diese mit deinen Daten (1:1 kopiert) dann an die Fachabteilung.

Sollte dies nicht klappen, würde im 2. Schritt die Anfrage per Mail an die Netzabteilung erfolgen können (auch über uns).

 

Viele Grüße,

Kurt

Benutzerebene 1

könntest du heute ein Beispiel anfertigen (gerne beide Varianten, Ping und SSH)?

@o2_Kurt klar:

 

Ping IPv4:

ping -4 -c 4 google.com
PING google.com (172.217.22.110) 56(84) bytes of data.
64 bytes from fra15s18-in-f110.1e100.net (172.217.22.110): icmp_seq=1 ttl=111 time=33.9 ms
64 bytes from fra15s18-in-f110.1e100.net (172.217.22.110): icmp_seq=2 ttl=111 time=59.4 ms
64 bytes from fra15s18-in-f110.1e100.net (172.217.22.110): icmp_seq=3 ttl=111 time=41.5 ms
64 bytes from fra15s18-in-f110.1e100.net (172.217.22.110): icmp_seq=4 ttl=111 time=70.3 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 33.951/51.318/70.361/14.372 ms

Ping IPv6:

ping -6 -c 4 google.com
PING google.com(fra15s18-in-x0e.1e100.net (2a00:1450:4001:81d::200e)) 56 data bytes

--- google.com ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3055ms

SSH IPv6

ssh -4 -T git@gitlab.com
Welcome to GitLab, @ountenzwei!

SSH IPv4

ssh -6 -T git@gitlab.com
ssh: connect to host gitlab.com port 22: Connection timed out

Du wechselst per Menü manuell zwischen IPv4 und 6?

Ich habe die Tools von der Konsole aus benutzt. Das -4 bzw. -6 wechselt jeweils den Modus von IPv4 auf IPv6 bei Ping und SSH.

 

Zum Vergleich hier noch einmal die Ausgabe der Befehle von oben auf einem anderen System außerhalb des o2-Netz.

 

Ping IPv6:

ping -6 -c 4 google.com
PING google.com(fra16s08-in-x0e.1e100.net (2a00:1450:4001:817::200e)) 56 data bytes
64 bytes from fra16s08-in-x0e.1e100.net (2a00:1450:4001:817::200e): icmp_seq=1 ttl=115 time=1.92 ms
64 bytes from fra16s08-in-x0e.1e100.net (2a00:1450:4001:817::200e): icmp_seq=2 ttl=115 time=1.26 ms
64 bytes from fra16s08-in-x0e.1e100.net (2a00:1450:4001:817::200e): icmp_seq=3 ttl=115 time=1.45 ms
64 bytes from fra16s08-in-x0e.1e100.net (2a00:1450:4001:817::200e): icmp_seq=4 ttl=115 time=1.25 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 1.251/1.473/1.922/0.270 ms

SSH IPv6:

ssh -6 -T git@gitlab.com
Welcome to GitLab, @ountenzwei!

 

Hi @ountenzwei ,

 

danke dir!

Ich werde sicher nochmal mit Rückfragen aufschlagen, aber für heute Abend ist es erstmal weitergeleitet :hugging:

 

Viele Grüße,

Kurt

Benutzerebene 4

Ich möchte das Thema hier nicht kapern, allerdings würde ich gerne wissen:

Gibts nur eine IPv6, oder ein ganzes Prefix (wie groß?). Ich find hier im tcpdump nicht ansatzweise IPv6, obwohl meine Bridge das aktiviert hat… bin neidisch ;)

Benutzerebene 1

@ausdemdorf Mir geht es hier um ausgehende IPv6-Verbindungen. Wie das gemappt war als es vor zwei Wochen noch funktioniert hat, weiß ich nicht. Für IPv4 scheint bei LTE mindestens ein privates Netz von o2 dazwischen zu sitzen (10.* und 172.*):

 

tracepath -4 google.com
1?: [LOCALHOST] pmtu 1500
1: o2.spot 3.469ms
1: o2.spot 3.919ms
2: no reply
3: 172.21.0.1 43.698ms
4: 10.81.7.109 39.196ms
5: 10.81.85.22 37.039ms asymm 6
6: 62.53.143.242 30.336ms
7: ae10-0.0001.prrx.13.fra.de.net.telefonica.de 43.041ms asymm 11
8: 72.14.202.76 38.883ms asymm 16

 

Benutzerebene 1

@o2_Kurt@o2_Tobias Könnt ihr bitte den anderen Beitrag von mir wieder öffnen: https://hilfe.o2online.de/o2-homespot-o2-my-data-spot-21/hoher-paketverlust-per-homespot-lte-543178?postid=2166698#post2166698

 

Die beiden Probleme haben nichts miteinander zu tun, wie ich schon letzte Woche erklärt habe: https://hilfe.o2online.de/o2-homespot-o2-my-data-spot-21/ipv6-verbindungsaufbau-sehr-langsam-542713?postid=2163263#post2163263

 

In diesen Beitrag hier geht es um dauerhaften 100%-Paketverlust von IPv6. In dem anderen verlinkten geht es um Paketverlust bei IPv4.

@ountenzwei 

 

Der andere Beitrag ist schon wieder auf. :relaxed:

 

Gruß,

Michi

Benutzerebene 1

@o2_Kurt Gibt es schon Neuigkeiten von der Fachabteilung?

@o2_KurtGibt es schon Neuigkeiten von der Fachabteilung?


Hi @ountenzwei ,

 

nein - aber:

Die Meldung wurde erst einer größeren zugeordnet, welche nun weiter eskaliert wurde und als Netzwerkfehler geführt wird.

 

Keine dieser beiden Meldungen können wir nachvollziehen, ich würde es aber auf jeden Fall Fortschritt nennen :hugging:

 

@ausdemdorf Da bin ich leider überfragt. Wir können zu IPv6 noch keinerlei Details einsehen (wobei wir die IPs ja generell nicht einsehen können) und haben auch noch keine Infos über den Aufbau oder die aktuelle Umsetzung von IPv6 bekommen, auf meiner Data Spot-Karte habe ich die öffentlich-dynamische IPv4, weshalb IPv6 wohl nicht freigeschaltet wurde.

 

Viele Grüße,

Kurt

Benutzerebene 1

Das Problem ist wohl jetzt behoben:

ping -6 -c 10 google.com
PING google.com(fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e)) 56 data bytes
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=1 ttl=111 time=32.4 ms
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=2 ttl=111 time=30.2 ms
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=3 ttl=111 time=40.7 ms
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=4 ttl=111 time=38.6 ms
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=5 ttl=111 time=44.4 ms
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=6 ttl=111 time=34.1 ms
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=7 ttl=111 time=34.1 ms
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=8 ttl=111 time=31.8 ms
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=9 ttl=111 time=30.0 ms
64 bytes from fra15s46-in-x0e.1e100.net (2a00:1450:4001:808::200e): icmp_seq=10 ttl=111 time=41.7 ms

--- google.com ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9013ms
rtt min/avg/max/mdev = 30.068/35.833/44.407/4.891 ms

 

time ssh -6 -T git@gitlab.com
Welcome to GitLab, @ountenzwei!

real 0m0,335s
user 0m0,000s
sys 0m0,008s

 

HI @ountenzwei ,

 

oh super!

:hugging:  Freut mich, dass es erledigt werden konnte!

 

Viele Grüße,

Kurt

 

 

Deine Antwort