O2 DSL IPv6 : Immer wieder TCP Verbindungsreset bei Zugriff auf Cloudflare IPv6 Adressen.

Seit einigen Tagen, eventuell Wochen, habe ich immer wieder Probleme, dass Webseiten beim Laden abbrechen. Nach einiger Analyse, scheint es so zu sein, dass das Seiten betrifft, die über cloudflare IPv6 angebunden sind, und sehr “nahe” am O2 Netz dran sind (ping ist 20 ms). Z.B. diese Seite hier, über wget geladen, hat gerade in mehr als 30% der Fälle einen Verbindungsabbruch:

wget --progress=dot  -O/dev/null -6 https://understandingwar.org
--2023-07-11 13:41:13--  https://understandingwar.org/
Resolving understandingwar.org (understandingwar.org)... 2606:4700:10::ac43:1963, 2606:4700:10::6816:4e94, 2606:4700:10::6816:4f94
Connecting to understandingwar.org (understandingwar.org)|2606:4700:10::ac43:1963|:443... connected.
GnuTLS: Error in the pull function.
Unable to establish SSL connection.

Wenn ich das mit tcpdump aufzeichne, dann sehe ich, dass der Webserver, nach dem TLS “Client Hello” sofort mit TCP Reset antwortet. Da der Ping sehr kurz ist, sieht das für mich so aus, als wenn da irgendwelche caching proxies innerhalb des O2 Netzes die Verbindung abwürgen. Irgendein falsch konfigurierter DoS Schutz oder sowas.

Die gesamte Verbindung unfasst nur 5 IP Pakete, die laut tcpdump so hier aussehen (habe meine eigene IPv6 Adresse zum Schutz der Privatsphäre teilw. maskiert):

13:41:13.758458 IP6 (flowlabel 0xae106, hlim 64, next-header TCP (6) payload length: 40) 2a01:c23:6201:cdfa:xxxx:xxxx:xxxx:xxxx.51626 > 2606:4700:10::ac43:1963.443: Flags , cksum 0xd15d (correct), seq 1270541620, win 64440, options wmss 1432,sackOK,TS val 253607283 ecr 0,nop,wscale 7], length 0
13:41:13.779305 IP6 (flowlabel 0x3155e, hlim 60, next-header TCP (6) payload length: 40) 2606:4700:10::ac43:1963.443 > 2a01:c23:6201:cdfa:xxxx:xxxx:xxxx:xxxx.51626: Flags :S.], cksum 0xe235 (correct), seq 444079287, ack 1270541621, win 64704, options wmss 1360,sackOK,TS val 3377262036 ecr 253607283,nop,wscale 13], length 0
13:41:13.779416 IP6 (flowlabel 0xae106, hlim 64, next-header TCP (6) payload length: 32) 2a01:c23:6201:cdfa:xxxx:xxxx:xxxx:xxxx.51626 > 2606:4700:10::ac43:1963.443: Flags 4.], cksum 0x0b58 (correct), ack 1, win 504, options ,nop,nop,TS val 253607304 ecr 3377262036], length 0
13:41:13.779987 IP6 (flowlabel 0xae106, hlim 64, next-header TCP (6) payload length: 549) 2a01:c23:6201:cdfa:xxxx:xxxx:xxxx:xxxx.51626 > 2606:4700:10::ac43:1963.443: Flags 4P.], cksum 0x6c52 (correct), seq 1:518, ack 1, win 504, options ,nop,nop,TS val 253607304 ecr 3377262036], length 517
13:41:13.803474 IP6 (flowlabel 0xc032e, hlim 61, next-header TCP (6) payload length: 20) 2606:4700:10::ac43:1963.443 > 2a01:c23:6201:cdfa:xxxx:xxxx:xxxx:xxxx.51626: Flags :r], cksum 0x032b (correct), seq 444079288, win 0, length 0

~~Das ganze läuft bei mir unter Linux direkt mit einem DSL-Modem, da ist auf meiner Seite kein Router etc. dazwischen, dem man die Schuld in die Schuhe schieben kann.~~

~~Die Route zu dem Webserver ist laut traceroute folgende:~~

traceroute to 2606:4700:10::ac43:1963 (2606:4700:10::ac43:1963), 30 hops max, 80 byte packets
 1  2a02:3001::240 (2a02:3001::240)  12.686 ms  12.600 ms  12.638 ms
 2  * 2a02:3001::2df (2a02:3001::2df)  10.637 ms *
 3  * * *
 4  * * *
 5  2a02:3001::280 (2a02:3001::280)  21.089 ms 2a02:3001::22d (2a02:3001::22d)  21.389 ms 2a02:3001::3f (2a02:3001::3f)  20.939 ms
 6  * 2a02:3040:0:10::39 (2a02:3040:0:10::39)  26.972 ms *
 7  2400:cb00:470:3:: (2400:cb00:470:3::)  33.382 ms 2400:cb00:100:1024::ac44:6d1c (2400:cb00:100:1024::ac44:6d1c)  23.924 ms 2400:cb00:100:1024::ac44:6d12 (2400:cb00:100:1024::ac44:6d12)  26.544 ms

Seite 2 / 2

xkcd.com hat bei mir auch dieselben Probleme wie die anderen Cloudflare Seiten hier im Thread. Mittlerweile habe ich IPv6 im Browser deaktiviert, ist mit dem Packetloss nicht wirklich benutzbar. In Firefox geht das über about:config → network.dns.disableIPv6.

Ich bin sehr froh, dass ich diesen Thread gefunden habe, weil ich bei mir ebenfalls Probleme sehe und es inzwischen immer gravierendere Auswirkungen hat. Ja, ich bin auch in Berlin mit VDSL + Fritzbox.

Ich habe die Probleme v.a. mit fastly bemerkt. Mein Anwendungsfall ist aber nicht der Browser, sondern v.a. github und pypi. Meistens funktioniert die Verbindung auch, aber gefühlt in 10-20% der Fälle die Verbindung ab. Vermutlich habe ich das Problem auch im Browser schon gesehen, aber ignoriert oder auf mein Handy geschoben (Symptome: lange Wartezeiten bis zum Laden einzelner Seiten, z.T. werden Grafiken oder CSS nicht geladen).

Ich kann ggf. gerne mehr traces usw. zur Verfügung stellen.

Wie geht es denn den anderen Berlinern hier im Thread beim Zugriff auf xkcd.com?

Ich habe bei mir gerade einen Test gemacht mit

curl -s -6 https://xkcd.com > /dev/null

und anschließend den returncode unter Linux ausgewertet.

Bei 100 Versuchen gab es 46 Fehlschläge, sollte also ziemlich gut zu reproduzieren sein.

Update: Spaßeshalber noch mal mit 1000 Versuchen durchlaufen lassen, Fehlerquote 47,8%.

ist mit dem Packetloss nicht wirklich benutzbar

vorsicht, das ist kein Packetloss, sondern es wird “Serverseitig” (bzw. irgendwo auf dem Netzwerkpfad) ein Reset gesendet. Das ist etwas anderes als Packetverlust.

Hoffentlich gibt es bald eine Rückmeldung dazu, ein Moderator hatte ja vor etwa einem Monat erneut intern nachgefragt.

Hier scheint das Problem auch vorhanden zu sein, ebenfalls nähe Berlin.

Jedoch fehlt dort Traceroute und IPv6 Adressen, sowie Infos wo genau das Spiel hinspricht. Jedoch führte das deaktivieren von IPv6 dazu, dass keine Verbindungsprobleme mehr auffielen.

Start: 2024-10-07T08:45:05+0200
HOST: compi                       Loss%   Snt   Last
  1. AS6805   fritz.box            0.0%     2    1.0
  2. AS6805   2a02:3001::124       0.0%     2    7.5
  3. AS6805   2a02:3001::1ca       0.0%     2    8.5
  4. AS???    ???                 100.0     2    0.0
  5. AS???    ???                 100.0     2    0.0
  6. AS6805   2a02:3001::26a       0.0%     2   17.6
  7. AS6805   2a02:3001::6d        0.0%     2   16.0
  8. AS???    2620:11a:c000:214:f  0.0%     2   16.0
  9. AS54113  2a04:4e42:600::67    0.0%     2   15.7

Vermutlich ist der traceroute gar nicht so interessant, aber mal der Vollständigkeit halber (einige Spalten hinten wegen besserer Lesbarkeit entfernt).

Danke dir, @derp_96883 :-)

Damit lässt sich doch schon mal was anfangen und einen ersten Verdacht habe ich da auch schon.

Auch, wenn wir selbst da nicht eingreifen können, kennen wir da doch den einen und anderen Menschen, der sich das gerne mal anschaut. Mit den Traces sollte sich da bestimmt etwas heraus bekommen lassen.

Vermute gerade, dass es sich um das Problem handelt, was hier beschrieben wird: TCP Reset wegen Anycast Shift. Also ein Problem mit Anycast Routing nah am oder im O2 Netz.

Deswegen betrifft das Cloudflare, Neocities und Fastly: das sind alles potentielle Anycast IPv6 Adressen. Da sitzt dann also irgendwo im Pfad von Berlin nach Frankfurt ein ECMP Router, der das “Client Hello” an den falschen Anycast-host routed. Und der antwortet dann halt mit RST, weil der von nichts weiß, weil das initiale SYN bei einem anderen Host gelandet war?

Können wir das Problem denn aktuell noch bei Cloudflare nachvollziehen? Die initial genannten Domains funktionieren bei mir problemlos.

Was allerdings nicht funktioniert sind xkcd.com, gnome.org, pypi (download) und (Teile von) github. Diese Domains laufen alle über fastly.

@o2_Lars Vielleicht könnt ihr da noch mal reinschauen?

Können wir das Problem denn aktuell noch bei Cloudflare nachvollziehen? Die initial genannten Domains funktionieren bei mir problemlos.

Was allerdings nicht funktioniert sind xkcd.com, gnome.org, pypi (download) und (Teile von) github. Diese Domains laufen alle über fastly.

@o2_Lars Vielleicht könnt ihr da noch mal reinschauen?

Also ich bekomme stochastische IPv6 TCP Resets z.B. bei nextspaceflight.com. Die IPv6 gehört zu Google. Die entsprechende IPv6 Adresse wird im DNS auch reverse aufgelöst zu “any-in-2001-4860-4802-32--15.1e100.net.”. Die heißt sogar “any-”, wie in Anycast.

Traceroute liefert je nach Aufruf verschiedene Pfade. Das wäre ein weiteres Indiz für Anycast Shift (je nach Routing-Pfad kommt er womöglich bei einem anderen Anycast-Host raus).

$ wget -6 -O/dev/null https://nextspaceflight.com
--2024-10-10 08:20:57--  https://nextspaceflight.com/
Resolving nextspaceflight.com (nextspaceflight.com)... 2001:4860:4802:32::15, 2001:4860:4802:34::15, 2001:4860:4802:36::15, ...
Connecting to nextspaceflight.com (nextspaceflight.com)|2001:4860:4802:32::15|:443... connected.
GnuTLS: Error in the pull function.
Unable to establish SSL connection.

$ traceroute 2001:4860:4802:32::15
traceroute to 2001:4860:4802:32::15 (2001:4860:4802:32::15), 30 hops max, 80 byte packets
 1  2a02:3001::240 (2a02:3001::240)  55.037 ms  54.948 ms  55.031 ms
 2  2a02:3001::2df (2a02:3001::2df)  12.179 ms *  12.059 ms
 3  loopback0.0003.corx.01.ber.de.net.telefonica.de (::ffff:62.52.192.168)  21.897 ms  20.818 ms *
 4  * * *
 5  2a02:3001::1b7 (2a02:3001::1b7)  16.491 ms 2a02:3001::22d (2a02:3001::22d)  22.885 ms 2a02:3001::280 (2a02:3001::280)  22.839 ms
 6  * * *
 7  2a00:1450:8116::1 (2a00:1450:8116::1)  22.538 ms 2a00:1450:809c::1 (2a00:1450:809c::1)  22.525 ms 2001:4860:1:1::56a (2001:4860:1:1::56a)  22.869 ms
 8  any-in-2001-4860-4802-32--15.1e100.net (2001:4860:4802:32::15)  21.545 ms  21.528 ms 2a00:1450:8063::1 (2a00:1450:8063::1)  22.277 ms

$ traceroute 2001:4860:4802:32::15
traceroute to 2001:4860:4802:32::15 (2001:4860:4802:32::15), 30 hops max, 80 byte packets
 1  2a02:3001::240 (2a02:3001::240)  30.048 ms  30.113 ms  30.051 ms
 2  * 2a02:3001::2df (2a02:3001::2df)  12.399 ms  12.155 ms
 3  loopback0.0003.corx.01.ber.de.net.telefonica.de (::ffff:62.52.192.168)  21.379 ms * *
 4  * loopback0.0003.corx.01.ham.de.net.telefonica.de (::ffff:62.52.192.179)  20.940 ms *
 5  2a02:3001::280 (2a02:3001::280)  22.900 ms 2a02:3001::22d (2a02:3001::22d)  22.847 ms 2a02:3001::1b7 (2a02:3001::1b7)  15.948 ms
 6  * 2001:4860:1:1::ff1 (2001:4860:1:1::ff1)  19.875 ms *
 7  2001:4860:0:1::8123 (2001:4860:0:1::8123)  17.387 ms 2001:4860:1:1::ff0 (2001:4860:1:1::ff0)  14.866 ms *
 8  2001:4860:0:1::1c5b (2001:4860:0:1::1c5b)  18.095 ms 2001:4860:0:1::21a5 (2001:4860:0:1::21a5)  20.468 ms 2001:4860:0:1::878b (2001:4860:0:1::878b)  15.824 ms
 9  any-in-2001-4860-4802-32--15.1e100.net (2001:4860:4802:32::15)  20.961 ms  20.848 ms 2001:4860:0:1::5321 (2001:4860:0:1::5321)  14.760 ms

$ traceroute 2001:4860:4802:32::15
traceroute to 2001:4860:4802:32::15 (2001:4860:4802:32::15), 30 hops max, 80 byte packets
 1  2a02:3001::240 (2a02:3001::240)  30.570 ms  30.514 ms  30.451 ms
 2  2a02:3001::2df (2a02:3001::2df)  12.065 ms  13.144 ms *
 3  loopback0.0003.corx.01.ber.de.net.telefonica.de (::ffff:62.52.192.168)  21.493 ms  22.566 ms *
 4  loopback0.0003.corx.01.ham.de.net.telefonica.de (::ffff:62.52.192.179)  20.166 ms *  21.472 ms
 5  2a02:3001::1b8 (2a02:3001::1b8)  16.652 ms 2a02:3001::1b7 (2a02:3001::1b7)  18.380 ms 2a02:3001::22d (2a02:3001::22d)  22.922 ms
 6  2001:4860:1:1::ff1 (2001:4860:1:1::ff1)  18.274 ms *  18.256 ms
 7  2001:4860:0:1::8123 (2001:4860:0:1::8123)  17.437 ms 2001:4860:1:1::56a (2001:4860:1:1::56a)  22.339 ms 2001:4860:1:1::ff0 (2001:4860:1:1::ff0)  14.614 ms
 8  2001:4860:0:1::8123 (2001:4860:0:1::8123)  19.795 ms  19.598 ms any-in-2001-4860-4802-32--15.1e100.net (2001:4860:4802:32::15)  20.496 ms

Des weiteren gleiches Problem z.B. bei edition.cnn.com . Die ist bei Fastly gehostet. Bei Cloudflare gehosteten Webseiten kann ich das Problem derzeit auch nicht nachstellen.

Hmm, ich habe das gerade nachgeprüft und Stand jetzt (10.10.2024, 08:30) sehe ich bei mir gar “connection reset” mehr - auch bei Seiten, die zuvor nicht funktionierten.

Interessanterweise ist der traceroute zu xkcd.com jetzt auch einige Hops kürzer:

$ mtr -6 --report --ipinfo 0 -n --report-cycles=2 2a04:4e42:600::67
Start: 2024-10-10T08:33:24+0200
HOST: compi                       Loss%   Snt   Last   Avg  
  1. AS6805   2a02:3100:154b:400:  0.0%     2    1.0   1.0  
  2. AS6805   2a02:3001::2c0       0.0%     2    5.7   5.9  
  3. AS6805   2a02:3001::6d        0.0%     2   16.3  16.5  
  4. AS???    2620:11a:c000:214:f  0.0%     2   15.6  16.0  
  5. AS54113  2a04:4e42:600::67    0.0%     2   15.5  16.0

Sollte das Problem also zumindest bei mir gelöst sein? Das wäre jedenfalls eine sehr, sehr gute Nachricht. Na ja, ich werde den Tag aber nicht vor dem Abend loben und später noch mal schauen (bzw. es würde mir sicher im Laufe des Tages durch Fehler auffallen).

Hier ist ein interessantes Paper zum Thema Stabilität von Anycast für TCP Verbindungen: Does Anycast Hang up on You?

Wenn man das so liest, stehen einem die Haare zu Berge. In der Zusammenfassung steht da:

Consistent with wide use of anycast in CDNs, we found that anycast almost always works—98% of vantage points (VPs) see few or no changes. However, we found a few VPs—about 1%—that see frequent route changes and so are anycast unstable.

(Fettdruck von mir)

Mein Interpretation des Papers ist in etwa: für die großen CDNs (sowas wie Cloudflare, Fastly etc). ist Anycast total hip; allerdings erkaufen die sich die tolle Skalierbarkeit ihrers Netzwerks damit, dass potentiell 1% der User unter instabilen Verbindungen leiden. Zu diesen 1% gehören z.B. wir Internet-User im O2-Netz in Berlin.

Wir nörgeln dann bei unserem Provider rum, und der Provider muss dann die Anycast-Probleme debuggen, und sein Route-Balancing anpassen, damit die CDNs wieder gehen. Dabei ist der Provider gar nicht wirklich schuld. TCP Anycast hat, so wie das derzeit ausgerollt wird, einfach keine saubere Stabilitätsgarantie. Solange da keine besseren Technologien existieren, müssen die Provider (und wir User) die Suppe auslöffeln, die uns die CDNs eingebrockt haben.

Früher wurde das load-balancing nur via DNS gemacht (Akamai macht das immer noch so?), da gab es keine derartigen Probleme. Vergleich der Ansätze z.B. hier erläutert.

Andererseits find ich, dass das auch ziemlich armseeliges Monitoring auf Seiten von z.B. Fastly ist: das Auftreten von Anycast Flips könnten die eigentlich in ihrem Netzwerk trivial feststellen, wenn die da nur ein bischen Metadaten zu TCP SYN und RST Paketen aufzeichen und ab und zu analysieren.

tmHmm, ich habe das gerade nachgeprüft und Stand jetzt (10.10.2024, 08:30) sehe ich bei mir gar “connection reset” mehr - auch bei Seiten, die zuvor nicht funktionierten.

Interessanterweise ist der traceroute zu xkcd.com jetzt auch einige Hops kürzer:

$ mtr -6 --report --ipinfo 0 -n --report-cycles=2 2a04:4e42:600::67
Start: 2024-10-10T08:33:24+0200
HOST: compi                       Loss%   Snt   Last   Avg  
  1. AS6805   2a02:3100:154b:400:  0.0%     2    1.0   1.0  
  2. AS6805   2a02:3001::2c0       0.0%     2    5.7   5.9  
  3. AS6805   2a02:3001::6d        0.0%     2   16.3  16.5  
  4. AS???    2620:11a:c000:214:f  0.0%     2   15.6  16.0  
  5. AS54113  2a04:4e42:600::67    0.0%     2   15.5  16.0

Also bei mir nach wie vor das gleiche Problem, bei der gleichen IPv6, die du benutzt:

$ https_proxy= curl --resolve xkcd.com:443:2a04:4e42:600::67 https://xkcd.com > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to xkcd.com:443

der MTR Aufruf liefert bei mir folgenden Trace:

$ mtr -6 --report --ipinfo 0 -n --report-cycles=2 2a04:4e42:600::67
Start: 2024-10-10T09:14:30+0200
HOST: xyz                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::240       0.0%     2   11.5  15.4  11.5  19.3   5.5
  2. AS6805   2a02:3001::2df      50.0%     2   12.1  12.1  12.1  12.1   0.0
  3. AS???    ???                 100.0     2    0.0   0.0   0.0   0.0   0.0
  4. AS???    ???                 100.0     2    0.0   0.0   0.0   0.0   0.0
  5. AS6805   2a02:3001::280       0.0%     2   23.1  23.0  23.0  23.1   0.1
  6. AS6805   2a02:3001::1a2       0.0%     2   21.6  21.8  21.6  22.1   0.4
  7. AS???    2620:11a:c000:720:f  0.0%     2   21.6  21.9  21.6  22.1   0.4
  8. AS54113  2a04:4e42:600::67    0.0%     2   21.4  21.3  21.2  21.4   0.1

(mit dem normalen traceroute, endet der trace nach dem 6. Host)

Ahh, wir machen das falsch. MTR kann auch TCP-Pakete tracen. Wenn wir die obige IP Adresse tracen, wie TCP Traffic an Port 443 geroutet wird, dann bekommen wir eine instabiles routing (Abweichung ab Host 5). Außerdem sehen wir jetzt die hops 3-4, die das normale ping-basierte MTR nicht auflöst. Man braucht BTW option --report-wide um vollständige IPv6 adressen zu sehen.

$ mtr -6 --tcp -P443 --report --report-wide --ipinfo 0 -n --report-cycles=2 2a04:4e42:600::67
Start: 2024-10-10T09:22:31+0200
HOST: xyz                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::240             0.0%     2   12.1  12.1  12.1  12.2   0.1
  2. AS6805   2a02:3001::2df             0.0%     2   12.7  12.7  12.7  12.7   0.0
  3. AS???    ::ffff:62.52.192.168      50.0%     2   23.3  23.3  23.3  23.3   0.0
  4. AS???    ::ffff:62.52.193.55        0.0%     2  1037. 529.9  22.7 1037. 717.2
  5. AS6805   2a02:3001::26b             0.0%     2   23.3  23.2  23.1  23.3   0.1
        2a02:3001::280
     AS6805   2a02:3001::280
  6. AS6805   2a02:3001::1a2             0.0%     2   21.3  21.6  21.3  21.9   0.4
  7. AS???    2620:11a:c000:720:fa57::   0.0%     2  1037. 529.8  22.5 1037. 717.5
  8. AS54113  2a04:4e42:600::67          0.0%     2   21.7  21.5  21.2  21.7   0.4

$ mtr -6 --tcp -P443 --report --report-wide --ipinfo 0 -n --report-cycles=2 2a04:4e42:600::67
Start: 2024-10-10T09:22:42+0200
HOST: xyz                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::240             0.0%     2   71.4  41.9  12.4  71.4  41.8
  2. AS6805   2a02:3001::2df            50.0%     2  1038. 1038. 1038. 1038.   0.0
  3. AS???    ::ffff:62.52.192.168       0.0%     2  1051. 1044. 1037. 1051.   9.2
  4. AS???    ::ffff:62.52.193.55        0.0%     2   22.5  23.3  22.5  24.2   1.2
  5. AS6805   2a02:3001::26a             0.0%     2   23.1  23.1  23.1  23.1   0.1
  6. AS6805   2a02:3001::1a2             0.0%     2   21.9  22.0  21.9  22.1   0.1
  7. AS???    2620:11a:c000:720:fa57::   0.0%     2   21.3  21.5  21.3  21.6   0.2
        2620:11a:c000:214:fa57::
     AS???    2620:11a:c000:214:fa57::
  8. AS54113  2a04:4e42:600::67          0.0%     2   21.5  21.6  21.5  21.7   0.1

Ich verwende oft:

-ezb6w -c 100

allerdings meist mit ICMP...

Gestern gab es absolut keine Probleme - leider heute wieder das gleiche Fehlerbild (und ein anderes routing):

$ mtr -6 --udp --report --report-wide --ipinfo 0 -n --report-cycl
Start: 2024-10-11T08:05:45+0200
HOST: compi                                          Loss%   Snt   Last   Avg 
 1. AS6805   2a01:c23:5dc8:4c00:[redacted]            0.0%     2    1.1   1.1 
 2. AS6805   2a02:3001::23f                           0.0%     2   10.4   9.1 
 3. AS6805   2a02:3001::2df                          50.0%     2    8.0   8.0 
 4. AS???    ::ffff:62.52.192.168                     0.0%     2   18.4  18.5 
 5. AS???    ::ffff:62.52.193.55                     50.0%     2   18.2  18.2 
 6. AS6805   2a02:3001::22d                           0.0%     2   19.0  18.8 
 7. AS6805   2a02:3001::1a2                           0.0%     2   17.8  17.7 
 8. AS???    ???                                     100.0     2    0.0   0.0 
 9. AS54113  2a04:4e42:400::67                        0.0%     2   17.0  17.0

Der trace ist auch nicht konsistent, regelmäßig tauchen verschiedene Hops auf.

Hier eine Liste der Webseiten, die bei mir genau jetzt betroffen sind und nicht verlässlich aufgerufen werden (wenn IPv6 eingeschaltet ist):

xkcd.com (fastly)
edition.cnn.com (fastly)
nextspaceflight.com (google)
pages.github.io (github)

Fehler (IPv6 RST) passiert so alle 25-50% der Versuche. Hier nur mal die Fehlerversuche, ganz verschiedene IPv6 Adressen betroffen.

$ https_proxy= curl -6 -v https://xkcd.com > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2a04:4e42:400::67:443...
* Connected to xkcd.com (2a04:4e42:400::67) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
} }5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} }512 bytes data]
* OpenSSL SSL_connect: Connection reset by peer in connection to xkcd.com:443 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to xkcd.com:443 

$ https_proxy= curl -6 -v https://pages.github.io > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2606:50c0:8003::153:443...
* Connected to pages.github.io (2606:50c0:8003::153) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
} }5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} }512 bytes data]
* OpenSSL SSL_connect: Connection reset by peer in connection to pages.github.io:443 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to pages.github.io:443 

$ https_proxy= curl -6 -v https://edition.cnn.com
*   Trying 2a04:4e42:600::773:443...
* Connected to edition.cnn.com (2a04:4e42:600::773) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to edition.cnn.com:443 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to edition.cnn.com:443 

$ https_proxy= curl -6 -v https://nextspaceflight.com
*   Trying 2001:4860:4802:38::15:443...
* Connected to nextspaceflight.com (2001:4860:4802:38::15) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* OpenSSL SSL_connect: Connection reset by peer in connection to nextspaceflight.com:443 
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to nextspaceflight.com:443

Hier die traces für die entsprechenden IPv6 Adressen

$ mtr -6 --tcp -P443 --report --report-wide --ipinfo 0 -n --report-cycles=2 2606:50c0:8003::153
Start: 2024-10-11T13:05:30+0200
HOST: abc                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::23e             0.0%     2   26.0  29.5  26.0  33.0   4.9
  2. AS6805   2a02:3001::2df            50.0%     2   12.0  12.0  12.0  12.0   0.0
  3. AS???    ::ffff:62.52.192.168       0.0%     2  1025. 524.2  22.6 1025. 709.5
  4. AS???    ::ffff:62.52.193.55        0.0%     2   22.3  23.0  22.3  23.7   1.0
  5. AS6805   2a02:3001::280             0.0%     2   23.1  23.0  23.0  23.1   0.1
        2a02:3001::22d           
     AS6805   2a02:3001::22d
  6. AS6805   2a02:3001::1a2             0.0%     2   21.8  21.4  21.1  21.8   0.5
  7. AS???    2620:11a:c000:214:fa57::   0.0%     2   21.7  21.6  21.4  21.7   0.2
  8. AS54113  2606:50c0:8003::153        0.0%     2   21.7  21.6  21.4  21.7   0.2

$ mtr -6 -P443 -T --report --ipinfo 0 -n --report-cycles=2 2001:4860:4802:38::15
Start: 2024-10-11T13:07:45+0200
HOST: abc                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::23e       0.0%     2   12.3  17.9  12.3  23.5   7.9
  2. AS6805   2a02:3001::2df       0.0%     2  3058. 1535.  12.4 3058. 2153.7
  3. AS???    ::ffff:62.52.192.16 50.0%     2  3048. 3048. 3048. 3048.   0.0
  4. AS???    ::ffff:62.52.192.17 50.0%     2   18.6  18.6  18.6  18.6   0.0
  5. AS6805   2a02:3001::1b8       0.0%     2   18.5  18.8  18.5  19.1   0.4
  6. AS15169  2001:4860:1:1::56b  50.0%     2   21.9  21.9  21.9  21.9   0.0
  7. AS15169  2001:4860:1:1::ff0   0.0%     2  1209. 615.4  21.3 1209. 840.1
        2001:4860:0:1::5917              
     AS15169  2001:4860:0:1::5917
  8. AS15169  2001:4860:0:1::5919  0.0%     2   22.9  22.1  21.3  22.9   1.2
        2001:4860:0:1::509d              
     AS15169  2001:4860:0:1::509d
  9. AS15169  2001:4860:4802:38::  0.0%     2   19.8  21.1  19.8  22.4   1.8
        2001:4860:0:1::17bf              
     AS15169  2001:4860:0:1::17bf

$ mtr -6 -P443 -T --report --ipinfo 0 -n --report-cycles=2 2a04:4e42:600::773
Start: 2024-10-11T13:08:31+0200
HOST: abc                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::23e       0.0%     2   11.7  15.6  11.7  19.5   5.5
  2. AS6805   2a02:3001::2df       0.0%     2  3049. 1531.  12.7 3049. 2147.5
  3. AS???    ::ffff:62.52.192.16  0.0%     2  3045. 1533.  22.4 3045. 2137.6
  4. AS???    ::ffff:62.52.193.55 50.0%     2   22.0  22.0  22.0  22.0   0.0
  5. AS6805   2a02:3001::26a       0.0%     2   23.2  23.4  23.2  23.5   0.2
  6. AS6805   2a02:3001::1a2       0.0%     2   21.4  21.6  21.4  21.7   0.2
        2a02:3001::6d                    
     AS6805   2a02:3001::6d
  7. AS???    2620:11a:c000:720:f  0.0%     2  1051. 536.2  21.0 1051. 728.6
  8. AS54113  2a04:4e42:600::773   0.0%     2   20.9  21.3  20.9  21.6   0.5

$ mtr -6 -P443 -T --report --ipinfo 0 -n --report-cycles=2 2a04:4e42:400::67
Start: 2024-10-11T13:09:44+0200
HOST: abc                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   2a02:3001::23e       0.0%     2   17.4  14.6  11.9  17.4   3.9
  2. AS6805   2a02:3001::2df      50.0%     2  1032. 1032. 1032. 1032.   0.0
  3. AS???    ::ffff:62.52.192.16  0.0%     2  3054. 1538.  22.8 3054. 2143.4
  4. AS???    ::ffff:62.52.193.55  0.0%     2  3050. 1536.  22.3 3050. 2141.1
  5. AS6805   2a02:3001::280       0.0%     2   23.5  23.3  23.1  23.5   0.3
        2a02:3001::26b                   
     AS6805   2a02:3001::26b
  6. AS6805   2a02:3001::1a2       0.0%     2   21.4  21.4  21.4  21.4   0.0
  7. AS???    2620:11a:c000:214:f  0.0%     2   21.5  21.4  21.3  21.5   0.1
        2620:11a:c000:720:fa57::         
     AS???    2620:11a:c000:720:fa57::
  8. AS54113  2a04:4e42:400::67    0.0%     2   21.1  21.1  21.1  21.1   0.0

Zumindest pages.github.io liegt auch bei fastly (sieht man auch beim mtr)

Ansonsten wäre es vielleicht an der Zeit, auch mal ein issue über den normalen Telefonsupport aufzumachen mit Verweis auf diesen Thread?

Hallo allerseits,

das sind wirklich Einblicke, da bin ich persönlich auch nur noch Ansatzweise in der Lage, die komplett zu verstehen. Muss ich ja aber auch nicht, dafür haben wir ja Leute :-)

Ich habe eure Erkenntnisse noch einmal an passende Stellen angebracht, sobald ich da ein paar meehr Einblicke und Antworten zurück erhalte, melde ich mich auf jeden Fall erneut.

Ich weiß, das ganze ist etwas langwierig, wir bleiben aber dennoch auch weiterhin dran :-)

Gruß,

Lars

Also jetzt aktuell tritt das Problem bei pages.github.com wieder auf:

$ https_proxy= curl -v -6 https://pages.github.com > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 2606:50c0:8003::153:443...
* Connected to pages.github.com (2606:50c0:8003::153) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* OpenSSL SSL_connect: Connection reset by peer in connection to pages.github.com:443 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection to pages.github.com:443

mtr zeigt auch eine Vielzahl von Routen zum Ziel.

$ mtr --report --tcp -P443 2606:50c0:8003::153:443
Start: 2024-10-25T22:01:54+0200
HOST: abc                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 2a02:3001::23e             0.0%    10   16.9  31.4  16.9  54.1  11.4
  2.|-- 2a02:3001::2df            40.0%    10  3056. 1699.  12.4 3056. 1522.1
  3.|-- loopback0.0003.corx.01.be  0.0%    10  7256. 2166.  22.3 7256. 2783.4
  4.|-- lo0.02.rl2t.99.gut.de.net  0.0%    10  3061. 1439.  22.2 7104. 2344.8
  5.|-- 2a02:3001::26a             0.0%    10   23.0  22.9  22.5  23.7   0.4
        2a02:3001::280                   
        2a02:3001::26b                   
        2a02:3001::22d                   
  6.|-- 2a02:3001::1a2             0.0%    10   22.0  22.2  20.9  27.5   1.9
        2a02:3001::6d                    
  7.|-- 2620:11a:c000:720:fa57::   0.0%    10  1032. 1149.  21.0 7218. 2192.0
        2620:11a:c000:214:fa57::         
  8.|-- 2606:50c0:8003::153:443    0.0%    10   21.4  21.4  21.0  21.6   0.2

In Suedniedersachsen (O2 PoP in Hamburg):

user@computer ~ % https_proxy= curl -v -6 https://pages.github.com > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Host pages.github.com:443 was resolved.
* IPv6: 2606:50c0:8000::153, 2606:50c0:8001::153, 2606:50c0:8002::153, 2606:50c0:8003::153
* IPv4: (none)
*   Trying [2606:50c0:8000::153]:443...
* Connected to pages.github.com (2606:50c0:8000::153) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
} [321 bytes data]
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* (304) (IN), TLS handshake, Server hello (2):
{ [122 bytes data]
* (304) (IN), TLS handshake, Unknown (8):
{ [19 bytes data]
* (304) (IN), TLS handshake, Certificate (11):
{ [3099 bytes data]
* (304) (IN), TLS handshake, CERT verify (15):
{ [264 bytes data]
* (304) (IN), TLS handshake, Finished (20):
{ [36 bytes data]
* (304) (OUT), TLS handshake, Finished (20):
} [36 bytes data]
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256 / [blank] / UNDEF
* ALPN: server accepted h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=*.github.io
*  start date: Mar 15 00:00:00 2024 GMT
*  expire date: Mar 14 23:59:59 2025 GMT
*  subjectAltName: host "pages.github.com" matched cert's "*.github.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert Global G2 TLS RSA SHA256 2020 CA1
*  SSL certificate verify ok.
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://pages.github.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: pages.github.com]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [user-agent: curl/8.7.1]
* [HTTP/2] [1] [accept: */*]
> GET / HTTP/2
> Host: pages.github.com
> User-Agent: curl/8.7.1
> Accept: */*
> 
* Request completely sent off
< HTTP/2 200 
< server: GitHub.com
< content-type: text/html; charset=utf-8
< x-origin-cache: HIT
< last-modified: Sat, 26 Oct 2024 06:03:32 GMT
< access-control-allow-origin: *
< etag: "671c8634-381d"
< expires: Sat, 26 Oct 2024 06:16:42 GMT
< cache-control: max-age=600
< x-proxy-cache: MISS
< x-github-request-id: ED18:188DEC:3049388:3152519:671C86F2
< accept-ranges: bytes
< date: Sat, 26 Oct 2024 10:07:16 GMT
< via: 1.1 varnish
< age: 465
< x-served-by: cache-fra-etou8220114-FRA
< x-cache: HIT
< x-cache-hits: 1
< x-timer: S1729937237.607600,VS0,VE2
< vary: Accept-Encoding
< x-fastly-request-id: 1fe68fd5060d2a7b6a1e149a1a6421b2ba6f59a4
< content-length: 14365
< 
{ [983 bytes data]
100 14365  100 14365    0     0   100k      0 --:--:-- --:--:-- --:--:--  100k
* Connection #0 to host pages.github.com left intact

dass es Dir gross helfen wird, aber in Suedniedersachsachsen läuft alles wie es soll:

Aber trotzdem multiple hops:

user@computer ~ % sudo mtr -ezbw --tcp -P443 2606:50c0:8003::153:443          
Password:
Start: 2024-10-26T12:09:33+0200
HOST: 123-1234567.local                                                                                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS6805   dynamic-2a01-0c23-94d7-2600-0000-0000-0000-0001.c23.pool.telefonica.de (2a01:c23:94d7:2600::1)   0.0%    10    1.3   1.1   0.7   1.4   0.3
  2. AS6805   2a02:3001::11f                                                                                   0.0%    10   12.1  41.6  11.9  91.5  32.1
  3. AS6805   2a02:3001::1b7                                                                                  20.0%    10  4016. 2014.  11.9 4016. 1774.3
  4. AS???    ???                                                                                             100.0    10    0.0   0.0   0.0   0.0   0.0
  5. AS???    ???                                                                                             100.0    10    0.0   0.0   0.0   0.0   0.0
  6. AS6805   2a02:3001::22d                                                                                   0.0%    10   20.5  20.2  18.7  22.0   0.9
        2a02:3001::280                                                                                 
       [MPLS: Lbl 16839 TC 0 S u TTL 1]
       [MPLS: Lbl 2 TC 0 S u TTL 3]
     AS6805   2a02:3001::280
       [MPLS: Lbl 16839 TC 0 S u TTL 1]
       [MPLS: Lbl 2 TC 0 S u TTL 3]
        2a02:3001::26a                                                                                 
     AS6805   2a02:3001::26a
       [MPLS: Lbl 16902 TC 0 S u TTL 1]
       [MPLS: Lbl 2 TC 0 S u TTL 3]
        2a02:3001::26b                                                                                 
     AS6805   2a02:3001::26b
       [MPLS: Lbl 16902 TC 0 S u TTL 1]
       [MPLS: Lbl 2 TC 0 S u TTL 3]
  7. AS6805   2a02:3001::6d                                                                                    0.0%    10   19.1  18.3  17.3  19.2   0.8
        2a02:3001::1a2                                                                                 
     AS6805   2a02:3001::1a2
  8. AS???    2620:11a:c000:214:fa57::                                                                        40.0%    10   18.9  18.5  17.3  21.0   1.4
        2620:11a:c000:720:fa57::                                                                       
     AS???    2620:11a:c000:720:fa57::
  9. AS54113  2606:50c0:8003::153:443                                                                          0.0%    10   19.0  18.9  17.7  21.2   0.9

Ich hab das Problem jetzt mal beim Fastly support unter https://support.fastly.com/hc/en-us über das support-formular geschildert. Bin richtig überrascht, dass das geht, auch wenn man gar keinen Fastly Account hat. Jetzt bin ich gespannt, ob da außer der Ticket-Confirmation Email noch irgendwas sachdienliches zurückkommt.

Irgendwie hoffe ich ja, dass ich irgendwann dieses Jahr IPv6 wieder für mein Heimnetz aktivieren kann.

Aktuell habe ich auch wieder Probleme mit Cloudflare (fastly sowieso):

$ mtr -z -6 -c 2 --report pre-commit.com
Start: 2024-11-04T11:16:03+0100
HOST: compi                       Loss%   Snt   Last   Avg
  1. AS6805   fritz.box            0.0%     2    1.0   1.0
  2. AS6805   2a02:3001::23e       0.0%     2   11.6  14.1
  3. AS6805   2a02:3001::2df      50.0%     2    8.1   8.1
  4. AS???    ::ffff:62.52.192.16  0.0%     2   16.4  16.8
  5. AS???    ::ffff:62.52.193.55  0.0%     2   18.4  18.3
  6. AS6805   2a02:3001::26a       0.0%     2   17.5  18.1
  7. AS???    ???                 100.0     2    0.0   0.0
  8. AS13335  2a06:98c1:3121::3    0.0%     2   16.5  17.2

Symptome: Webseite lädt im Browser nicht bzw. nur unvollständig.

Ich verstehe, dass das Problem nicht einfach zu beheben ist, aber ipv6 ist für mich im täglichen Arbeiten inzwischen unverzichtbar, daher bereite ich gerade die Kündigung bei o2 vor. Es macht einfach keinen Sinn, im Durchschnitt 1-2 Arbeitsstunden pro Woche zu verlieren, weil irgendwelche Prozesse wieder nicht durchlaufen.

Deine Antwort

Anmelden

Werde Teil der O₂ Community!

Scanne Datei nach Viren

Diese Datei kann nicht heruntergeladen werden