Deutsche Glasfaser IPv6 Ausfälle

[meyergru]

Vielleicht kann mir ja hier einer der DG-Nutzer helfen:

Ich habe zwei (!) relativ neue DG-Glasfaseranschlüsse mit jeweils 1000 MBit/s an zwei OpnSenses hängen. Beim ersten kam es von Zeit zu Zeit zu Ausfällen der IPv6-Connectivity (ca. 3 mal täglich), wobei die IPv4 funktionierte - wohlgemerkt, DS-Lite, also CG-NAT.

Beim zweiten Anschluss (ganz frisch) konnte ich das auch bemerken, allerdings kann ich es inzwischen provozieren, indem ich mit dem OOKLA Speedtest Client unter Linux einen Test starte (von hier: https://www.speedtest.net/de/apps/cli). Nach spätestens 5 Starts hängt dann die gesamte IPv6-Verbindung (da ich via IPv6 auf den Zielrechner gehe) und von außen gesehen ist beim letzten Router vor der Ziel-IP Schluss:

Code: [Select]

                                  My traceroute  [v0.93]
xyz.test.de (2a01:7778:243:420d::xxxx)                      2023-03-09T19:39:16+0100
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                 Packets               Pings
 Host                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 2a01:4f8::a:24:a                            0.0%    20    0.5   1.3   0.4  12.9   2.8
 2. core24.fsn1.hetzner.com                     0.0%    20    0.3   5.5   0.3  29.4   8.6
 3. 2a01:4f8:0:3::4c2                           0.0%    19    5.0   5.0   4.9   5.1   0.0
 4. pr1.int63-fra.dg-w.de                      73.7%    19    5.9   5.9   5.7   6.0   0.1
 5. 2a00:6020:0:d::2                           15.8%    19    6.0   6.1   5.9   6.3   0.1
 6. 2a00:6020:ffff:ffff::31                     5.3%    19    9.7   9.6   9.3  10.3   0.2
 7. (waiting for reply)

Normal kommt bei Nummer 7 die Ziel-IP. Von innen sieht man auch, dass IPv6 down ist (z.B. zeigt https://wieistmeineip.de dann nur eine IPv4). Das Problem heilt sich nach einigen Minuten selbst, indem die OpnSense wieder die selbe IPv6 zugewiesen bekommt.

Es ist NICHT der Router, weil der erste Anschluss einen anderen hat (anderer Ort). Ich glaube auch nicht, dass die Ethernet- oder Glasfaser-Verbindung zusammenbricht, da IPv4 ja weiterläuft. Nur per IPv6 geht zeitweise nichts.


Ich hoffe, dass ich alles richtig konfiguriert habe, normalerweise funktioniert ja auch alles, die Aussetzer sind
sporadisch - bis zur Entdeckung, dass Speedtest das auslöst konnte ich es nicht mal reproduzieren.

Die einzige Besonderheit in meiner Konfiguration ist, dass ich nur einen IPv6-Präfix verlange, d.h. die OpnSense selbst nutzt ihre LAN-IPv6-Adresse, nicht die WAN-Adresse. Das macht es m.E. einfacher, bei einem DynDNS den richtigen Präfix zu zeigen, nämlich den, den auch die Clients im LAN haben - sonst wäre es ja ein anderer Präfix.

Ich denke, dass das Problem vielen DG-Kunden nicht auffallen würde, da bei ausgehenden Verbindungen ja ein IPv4-Fallback gemacht wird. Aufgrund CG-NAT bin ich aber für eingehende Verbindungen auf IPv6 angewiesen.

Bevor ich jetzt ein Fass bei DG aufmache: Beobachtet jemand das selbe Problem oder mache ich was falsch?

[tiermutter]

Interessant...
Ich habe privat DG300 und OPNsense, auf Arbeit DG600 (vorher 1000) und eine securepoint hinter einer Fritte. Daheim habe ich keinerlei Probleme, hatte aber vor 2022 immer wieder mit v6 zu kämpfen, allerdings nur nach reboot der Sense etc. 2022 habe ich komplett neu aufgesetzt, seither ist hier alles gut.
Auf der Arbeit verliere ich seit den letzten Monaten aber auch immer wieder die v6, dauert ein paar Minuten und es ist wieder fein. Habe mich darum aber noch nicht intensiv gekümmert, da mein Rechner momentan mit zwei Interfaces angebunden ist (eins über DSL und eins über Glasfaser)... Könnte aber durchaus das gleiche Problem sein wie bei dir, weiß natürlich nicht ob es mit dem traffic im Zusammenhang steht.

Daheim mit der Sense (also wo keine Probleme) beziehe ich nicht nur das prefix, aber hier ist es auch wie du sagst: ich würde es nicht mitbekommen, wenn ich daheim bin und v6 ausfällt... Da ich aber mobil und auch auf Arbeit dauerhaft mit dem VPN über v6 verbunden bin, würde es mir hier durchaus auffallen und das ist es noch nie...

[tiermutter]

Wenn ich so darüber nachdenke ist es in den letzten zwei Wochen sogar schlimmer geworden mit den v6 Ausfällen, da ich dss VPN zuletzt fast nur noch über das heimische LTE failover aufbaue.
Dachte bislang es läge an meinen zwei Interfaces auf der Arbeit... Muss ich mal genauer beobachten...

[meyergru]

Nicht wahr? Ich habe aktuell die Gelegenheit, bei DG richtig Druck deswegen auszuüben, weil ich Bekannte/Familie in einem aktuellen Ausbaugebiet habe. Wenn jemand hier das Problem nochmals bestätigt (wie es reproduziert werden kann, habe ich ja geschrieben), würde ich ein Ticket eröffnen und keinen Zweifel daran lassen, dass der (oder besser: die) Verträge trotz Mindestlaufzeit bei derartigen Mängeln selbstverständlich gekündigt werden können.

Meinen Freund mit dem ersten DG-Vertrag hat man vor ein paar Monaten natürlich abgewimmelt - er hatte im Gegensatz zu allen anderen von mir beratenen potentiellen DG-Kunden aber einen Wechsel unterschrieben. Den Fehler wiederholen meine Freunde und Familie nicht - der Telekom-Anschluss läuft nämlich noch.

Abgesehen davon ist ein ISP, dessen größtes Autonomes System eine /18 ist, für mich ohnehin schwer vermittelbar, da DS-Lite nicht mal gegen Geld abgewählt werden kann.

Und die Politik ist sauer darüber, dass die Glasfaseranbieter entgegen den einschlägigen Gesetzen versuchen, die freie Providerwahl zu behindern (beispielsweise, indem sie für jedes Ausbaugebiet separate Vereinbarungen von anderen Anbietern fordern). Damit wird hoffentlich bald Schluss sein.

Im Zweifel gilt also: Mängelbedingte Kündigung, kurz warten, bis die Rechtslage eine Anmietung der ausgebauten Glasfaser durch Telekom usw. ermöglicht und dann dort zuschlagen.

[meyergru]

P.S.: Die IPv6-Adresse ist es nicht. Auch mit tritt das Problem auf. Hätte mich auch gewundert.

[tiermutter]

Ich muss Dich wohl leider enttäuschen...

Rechner (Win10) eingeschaltet, v6 vorhanden aber keine Konnektivität.
Zweites Interface getrennt (also nur an DG hängend) weiterhin ohne Konnektivität.
v6 de- und reaktiviert, v6 läuft.
Mehrfach Speedtests gestartet, teils unterschiedliche Seiten parallel, läuft.

Ich werde jetzt nochmal beobachten wie es aussieht, wenn es mal wieder ausfällt. Ich hatte früher schon ein oder zwei Mal geschaut, da hat mir immer nur am Rechner die v6 gefehlt, bei der Fritte hingegen war alles ok. Hier kann ich jeweils aber auch einfach zu langsam gewesen sein, denn kurz nachdem ich geschaut hatte lief v6 wieder.

Laut Log der Fritte wurde die v6 allerdings zuletzt Ende letzten Jahres bezogen, weiß aber auch nicht wie ich das Log deuten soll.

[meyergru]

Mit der Browser-Version von Speedtest unter Windows hatte ich auch nie Probleme, nur mit der Kommandozeile unter Linux. Wie gesagt, nach mehrfachen Aufrufen gibt es dann Stress. Wenn man das mit -vvv aufruft, sieht man auch, dass dort tatsächlich per IPv6 zugegriffen wird.

Kann ja auch sein, dass der Typ der Zugangs-Hardware bei Dir ein anderer ist, den Anschluss gibt es ja schon länger, meine sind ziemlich neu.

Mir sieht das echt so aus, als ob die IPv6-Implementierung da buggy ist und die Gegenstelle irgendwann "vergisst".

[tiermutter]

Hm, nen Linux habe ich hier auf Arbeit nicht, müsste daheim eins fertigmachen und mitbringen 

So alt ist der Anschluss auf Arbeit aber auch nicht, dürfte nicht älter sein als 08/2022, wobei das hiesige Netz schon deutlich länger verfügbar ist.
Daheim habe ich ein Modem von (?) bekommen, hat ein eher abgerundetes Gehäusedesign, auf arbeit haben wir ein Nokia in eher kantigem Design. Beide Anschlüsse sind "mit kundeneigenem Router".

[tiermutter]

Tja, wie es nunmal so ist... sonst habe ich 3-5 Ausfälle an einem Arbeitstag und kaum achtet man mal drauf, passiert gar nichts... ich werd mir das doch wohl nicht eingebildet haben?! 

[meyergru]

Ich hatte heute auch schon wieder einen Ausfall "unprovoziert", allerdings auf der stärker genutzten Leitung. Meine beiden ONTs sind auch beide Nokia G-010G-R (schwarz), ich würde aber annehmen, dass die nicht das Problem verursachen, da IPv4 ja funktioniert. Ich hatte auch mal eine kleinere MSS probiert.

Mir scheint da eher der ONU auszuticken und die IPv6-Dienste einzustellen. Ein Paketdump zeigt das vermutete Verhalten: ab einem bestimmten Zeitpunkt kommt es zu Fehlern (TCP Retries) und dann zu einem Ausfall der IPv6-Konnektivität. Konkret gehen keine IPv6-Pakete mehr ein, die OpnSense schickt irgendwann nur noch IPv6 Neighbor Solicitations an den DG-Router, die nicht beantwortet werden. Währenddessen läuft der IPv4-Traffic ohne Unterbrechung weiter.

Ich habe inzwischen festgestellt, dass jede (starke) Nutzung (auch mit IPv4) die IPv6-Verbindung zusammenbrechen lässt. Ticket ist eröffnet.

[meyergru]

Ich habe inzwischen noch ein bisschen weiter experimentiert. Ich nutze normalerweise den Traffic Shaper der OpnSense, um den Bufferbloat ein bisschen einzudämmen.

Wenn ich das komplett abschalte, kann ich das Problem nicht mehr so einfach triggern.

Eine weitere Sache, die mir aufgefallen ist: Mit eingeschalteten Shaper und mit "speedtest -vvv" bekomme ich teilweise schon so Verbindungsabbrüche (sieht man in der Browserversion unter Windows nicht):

Code: [Select]

[info] Final Ping: 5.94 ms
[info] Stage 1 completed
Idle Latency:     5.97 ms   (jitter: 0.21ms, low: 5.94ms, high: 6.39ms)
[info] Starting stage 2 of type 3
[warning] Receive error: 11 (Resource temporarily unavailable)ency: 6.28 ms
[info] Connection 1 failed. Added connection and continuing test.
[warning] Receive error: 11 (Resource temporarily unavailable)
[warning] Receive error: 11 (Resource temporarily unavailable)
[info] Connection 2 failed. Added connection and continuing test.
[info] Connection 3 failed. Added connection and continuing test.
[warning] Receive error: 11 (Resource temporarily unavailable)ency: 6.19 ms
[info] Connection 4 failed. Added connection and continuing test.
[warning] Receive error: 11 (Resource temporarily unavailable)ency: 6.19 ms
[warning] Receive error: 11 (Resource temporarily unavailable)
    Download: FAILED
[warning] Receive error: 11 (Resource temporarily unavailable)
[error] Cannot read:

Ohne Traffic Shaper scheint das zu gehen. Der eigentliche Bufferbloat-Test https://www.waveform.com/tools/bufferbloat bleibt mit "Warming Up" hängen. Ich dachte, es hätte etwas mit den ECN-Flags zu tun und habe das abgeschaltet, es hilft aber nichts. Mir ist schleierhaft, wieso Traffic Shaping solche Effekte auslösen kann, zumal die Limits auf dem Niveau der echten Leitungsgeschwindigkeit lagen.

Bei meinem anderen Provider (M-Net) funktioniert das alles ohne Probleme...