Unifi sucht Tester für DS-Lite i. V. m. PPPoE

    Erst einmal vielen Dank für die ausführliche Analyse!

    Zitat von ::1

    Überprüfe bitte an deinen Clients, ...

    1. ... ob sie jeweils (mindestens) über eine globale IPv6-Adresse verfügen, die mit "2a01:41e" beginnt, und ...
    2. ... ob sie jeweils über ein IPv6-Standardgateway verfügen, das der linklokalen (fe80...) IPv6-Adresse des LAN-Interface deines Routers entspricht.

    Diese beiden Punkte habe ich jetzt gelöst, die einzelnen VLANs zeigen jetzt die externe IPv6-Adresse an:

    Bei den VLANs kann ich folgende Einstellungen bezgl. IPv6 vornehmen. Da kann ich nicht herausfinden, was richtig ist oder ob das wie eingestellt passt:


    Und bei der WAN-Verbindung gibt es folgende IPv6-Einstellungen:

    Da ich meine VLANs erst noch umorganisieren muss, konnte ich die Konfiguration nur rudimentär testen. So wie es aussieht, läuft es jedoch noch immer nicht ohne Probleme.

    Zitat von ::1

    Ich vermute, in deinem Router ist für IPv4 noch NAT aktiv, so dass er die Absende-Adressen aus deinem LAN durch die Tunneladresse 192.0.0.2 ersetzt. Dies widerspricht dem DS-Lite-Funktionsprinzip.

    Bitte überprüfe das, und falls aktiv, schalte NAT im Router ab.

    Was ist mit diesem Punkt?

    Zitat von ::1

    Alternativ kann ein LAN-Client die IPv4-Adresse bzw. IPv6-Adresse des LAN-Interface deines Routers als DNS-Server verwenden (die Werte werden in der Regel dynamisch zugewiesen). In diesem Fall greift die DNS-Proxy-Funktion des Routers: Er sendet einkommende DNS-Requests von LAN-Clients im Standardfall von seiner WAN6-Adresse via IPv6 an DNS1/DNS2 oder ggf. an andere von dir im Router statisch konfigurierte IPv6-DNS-Server weiter (z.B. die IPv6-DNS-Resolver von Cloudflare: 2606:4700:4700::1111 und 2606:4700:4700::1001).

    Dein Router wird zur Namensauflösung standardmäßig die dynamisch zugewiesenen ISP-Server DNS1/DNS2 verwenden. Falls dein Router es ermöglicht, würde ich evtl. stattdessen im Router statisch die beiden Cloudflare-DNS-Server 2606:4700:4700::1111 und 2606:4700:4700::1001 eintragen. Der Mitschnitt zeigte ja Probleme mit den DNS-Antworten von DNS1 - die ließen sich somit umgehen. Dazu müsstest du m.E. in der WAN-Konfiguration die Option "Automatischer DNS-Server" deaktivieren und anschließend die IPv6-Adressen der Cloudflare-DNS-Server eintippen.

    Zitat von kostolany25

    So wie es aussieht, läuft es jedoch noch immer nicht ohne Probleme.

    Und welche Probleme sind das jetzt genau?

    Nachtrag:

    Ich denke gerade noch über die MTU nach: Wegen des PPPoE+PPP-Vorspanns (8 Byte) müsste man die MTU für das WAN-Interface auf 1500-8=1492 absenken.

    Für das IPv4-in-IPv6-Tunnel-Interface müsste man noch weitere 40 Bytes für den IPv6-Header abziehen. Das ergäbe eine nur für den getunnelten IPv4-Traffic maßgebliche MTU von 1492-40=1452.

    Da die MTU für ein Interface protokollunabhängig ist, müsste man folglich das Minimum {1452, 1492} = 1452 einstellen.

    Kannst du in deinem Router für das WAN-Interface (eth4) eine MTU von 1452 konfigurieren?

    2 Mal editiert, zuletzt von ::1 (28. Dezember 2025 um 22:24) aus folgendem Grund: Typos

    Bist Du sicher mit den 1492 für IPv4? Wegen DS-Lite findet PPPoE doch ausschließlich auf der Ebene von IPv6 statt und für das getunnelte IPv4 stünde die MTU-Size von 1500 zur Verfügung.

    Nachtrag:

    So interpretieren ich zumindest die Angabe der Fritze, die bei DGN/DS-Lite im IPv4-Bereich eine MTU-Size von 1500 angibt. Kann natürlich nur eine Anzeige des Defaults sein. Arithmetisch hast Du Recht die 1500 müssten in 2 Päckchen aufgeteilt (fragmentiert) sein.

    2 Mal editiert, zuletzt von HubeBube (28. Dezember 2025 um 22:50)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Wuerde da nicht auf den ISP vertrauen, sondern das selber nachmessen.

    Und Achtung, wennman z.B. PPPoE auth eth0 betreibt, sollte die MTU fuer das pppoe Interface meist in der Tat bei 1492 liegen, aber die MTU fuer eth0 muss bei 1500 bleiben, weil der pppoe header innerhalb der eth0 MTU "lebt".

    M.E. ist die MTU nur für Layer-3 Protokolle (IPv4, IPv6) relevant und sagt diesen, wie groß sie ihre Pakete inkl. Header werden lassen können, damit sie ohne Fragmentierung in die direkt darunter liegende L2-Ebene (oder um Falle von Tunneln eine Pseudo-L2-Ebene) verpackt werden können. Und nur diese L3-Protokolle haben (via ICMP und ICMPv6) entsprechende Control Plane-Funktionen (Path-MTU-Discovery), um diese MTUs der next hop-Interfaces eines Datenpfades zielspezifisch zu ermitteln.

    Im DS-Lite-over PPPoE-Router ist das für des Senden/Weiterleiten von IPv6-Paketen der Wert 1492 an der Schnittstelle "PPP|PPPoe|Ethernet" und für das Senden/Weiterleiten von IPv4 der Wert 1452 am Tunnel-Interface "IPv6|PPP|PPPoe|Ethernet".

    Ich wüsste jedoch nicht, dass man diese Werte (und dies auch noch protokoll-spezifisch) an den genannten Schnittstellen in so einem Router eingeben könnte. MTUs kann man nach meiner Kenntnis immer nur für ein physisches Interface definieren, und das wäre dann hier das Ethernet-Interface eth4 der WAN-Schnittstelle. Dort wäre folglich der Minimum-Wert von 1452 zu konfigurieren.

    Aber ich lasse mich hier auch gerne eines besseren belehren:

    Falls der Router es ermöglicht, MTU=1492 für die (logische) PPP-Schnittstelle und MTU=1452 für die (logische) Tunnel-Schnittstelle zu konfigurieren, wäre das die beste Lösung.

    Einmal editiert, zuletzt von ::1 (29. Dezember 2025 um 01:20)

    Ich wiederhole meine Empfehlung, Messen statt annehmen. MTU ist Ethernet Nutzlast und es ist diskutierbar ob das nicht von der L3 IP Layer selber behandelt werden sollte, statt von L4, aber die Trennung von L3 und L4 ist mehr historisch gewachsen als sinnvoll designed.

    Die IETF schlaegt fuer DS lite vor (rfc6333), dass ISPs den IPv6 Tunnel mit Baby Jumboframes so konfigurieren, dass die IPv6 Nutzlast fuer getunneltes IPv4 1500 Bytes gross ist, alternative muss der ISP defragmentieren:


  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Ja, habe ich auch gelesen. Werden Jumbos nicht unterstützt, hat man für IPv6 eine MTU von 1500, bzw. von 1492, wenn PPPoE mit im Spiel ist. Heißt aber für jedes zu tunnelnde IPv4-Paket >1452, daß der Router als Tunnel-Endpunkt auf IPv6-Ebene fragmentieren, und der AFTR als der andere Tunnel-Endpunkt die Fragmente wieder reassemblieren muss. Das wäre vermeidbar, wenn die IPv4-Sender im LAN lernen würden, keine IPv4-Pakete größer als 1452 zu senden.

    Das mit der Fragmentierung ist dann das Problem des ISPs, ist der zu braesig Jumboframes zu konfigurieren ist das IMHO sein selbstgewaehltes Schicksal. Aehnliches gilt uebrigens auch fuer PPPoE (rfc4638)... hat die Telekom wohl mal angedacht, aber dann wieder fallen gelassen.


    Und was den Rest angeht, bleibe ich bei lieber messen als nur anzunehmen...

    Zitat von ::1

    Was ist mit diesem Punkt?

    NAT habe ich nun komplett ausgeschaltet, ohne dass dies nachvollziehbar Auswirkungen hat. D. h., nach wie vor sind viele Internetseiten nicht erreichbar. Auch die Seite U. a. auch die Seite dieses Forums oder z. B. test-ipv6.com. DNS habe ich dabei schon auf die Cloudfare-DNS umgestellt.


    Zitat von ::1

    Kannst du in deinem Router für das WAN-Interface (eth4) eine MTU von 1452 konfigurieren?

    Nein, die einstellbaren Parameter sind in folgendem Bild zu sehen:

    Zur Info: Im TP-Link-Router ist bei MTU ein Wert von 1480 (vor-)eingestellt. Zudem ist dort bei „MLD-Proxy“ noch ein Haken gesetzt. Vielleicht ist das noch relevant?

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Hast Du zufaelligerweise ein Linux zur Hand? Dann waeren ein Paar tracepath Tests aufschlussreich:

    Code
    tracepath -b -4 one.one.one.one
tracepath -b -6 one.one.one.one

    Tracepath laeuft mit normalen Userrechten und repotiert unter anderen die Pfad-MTU.

    Das sieht dann z.B. so aus:

    Der Host in meinem LAN kann da erfolgreich mit MTU 1500 arbeiten und zeigt das auch an, ab dem PPPoE-Router geht es dann aus Sicht des Endhosts mit MTU 1492 weiter... Da Endpunkte oft gar nicht auf die Tracepath Probes antworten, ist das Ende oft eine etwas unelegante lange liste von no reply Hops, aber das kann man hier ignorieren. Fuer Deinen Anschluss waere es interessant zu wissen welche pmtu im LAN ab Deinem Router und nach dem AFTR verwendet wird und zwar getrennt fuer IPv4 und IPv6...


    Alternativ kann man das auch per Hand mit ping machen, Anleitung z.B.: hier

    Einmal editiert, zuletzt von pufferueberlauf (29. Dezember 2025 um 12:01)

    Zitat von kostolany25

    Auch die Seite U. a. auch die Seite dieses Forums oder z. B. test-ipv6.com.

    Die Seite ist nur via IPv4 zu erreichen - das bedeutet, dass dein IPv4 (zumindest partiell) nicht funktioniert.

    Zitat von kostolany25

    NAT habe ich nun komplett ausgeschaltet, ohne dass dies nachvollziehbar Auswirkungen hat.

    So soll es sein - es entlastet nur deinen Router.

    Zitat von kostolany25

    Nein, die einstellbaren Parameter sind in folgendem Bild zu sehen:

    Kannst du mit einer SSH-Session auf die Kommandozeile deines Routers gehen? Die bietet möglicherweise mehr Konfigurationsmöglichkeiten als das Web-GUI. Aber ein mögliches MTU-Problem kann man ggf. auch später analysieren. Vielleicht ist dein Router auch so schlau, an dem genannten Schnittstellen die passenden MTU automatisch zu konfigurieren. Die könnte man dann ggf. durch Anzeige der konkretem Interface-Konfigurationen an der Kommandozeile sichtbar machen.

    Mich würde interessieren, woran es bei IPv4 noch hakt. Kannst du an einem LAN-PC mal einen Dauerping ping -t test-ipv6.com starten, und am Router wieder den Traffic am WAN-Interface eth4 mitschneiden? 30 Sekunden müssten reichen.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Um bzgl. MTU mal ein wenig herumzuspielen bzw. die Limits zu testen, kann man an einem LAN-PC gezielt PING-Pakete mit konfigurierbaren Paketgrößen generieren, um so herauszufinden, welche maximalen Paketgrößen zu ausgewählten Internet-Zielen "über die Leitung" gehen können.

    Z.B. an einem Windows-PC kennt das PING-Kommando die Option -l size, in der "size" die Anzahl der Bytes angibt, die man als "Nutzlast" in ein ICMP-Echo- bzw. ICMPv6-Echo-Paket stecken möchte. Da der ICMP- bzw. ICMv6-Header eines Echo-Pakets 8 Bytes, und ein IPv4- bzw. IPv6-Header 20 bzw. 40 Bytes lang sind, erzeugt man bei Angabe von -l size ...

    • ... im Fall von IPv4 ein ICMP-Echo-Paket der Gesamtlänge 20+8+size = size+28
    • ... im Fall von IPv6 ein ICMPv6-Echo-Paket der Gesamtlänge 40+8+size = size+48

    Z.B. an meinem Internetzugang (DG) habe ich eine WAN-MTU von 1500, die ich im Falle von IPv4 mit size=1500-28=1472 und im Falle von IPv6 mit size=1500-48=1452 jeweils voll ausnutzen würde. Mit size=1473 für IPv4 bzw. size=1453 für IPv6 hätte ich aber den Bogen überspannt.

    Zur Demo nehme ich mal das Internet-Ziel google.com, dass für beide Protokolle pingbar ist:

    • IPv4: google.com = 142.251.141.110
    • IPv6: google.com = 2a00:1450:4001:813::200e

    Test für IPv4 mit WAN-MTU=1500:

    Hier wird schön gezeigt, wie ein IPv4-Paket (mit gesetztem DF-Flag, erreicht über die Option -f) der Länge 1500 (size=1472) gerade noch über die Leitung geht, ein Paket mit der Länge 1501 (size=1473) aber gedropt wird.

    Der IPv4-Destination-Cache meines Windows-PC zeigt mir entsprechend eine dynamisch ermittelte Path-MTU (PMTU) von 1500 für das IPv4-Google-Ziel 142.251.141.110 an:

    Code
    C:\>netsh int ip sh dest

Schnittstelle 10: Ethernet


PMTU Zieladresse                           Adresse des n. Hops
---- --------------------------------------------- -------------------------
:    :                                             :
1500 142.251.141.110                               192.168.178.1
:    :                                             :


    Test für IPv6 mit WAN-MTU=1500:

    Analog das Ganze für IPv6:

    Und hierzu passend der IPv6-Destination-Cache meines Windows-PC:

    Code
    C:\>netsh int ipv6 sh dest

Schnittstelle 10: Ethernet


PMTU Zieladresse                           Adresse des n. Hops
---- --------------------------------------------- -------------------------
:    :                                             :
1500 2a00:1450:4001:813::200e                      fe80::e208:55ff:fe3e:b83c
:    :                                             :

    IPv6 kennt kein DF-Flag, daher kann man hier keine Option -f verwenden. Aufgrund der PMTU=1500 für die Zieladresse 2a00:1450:4001:813::200e weiß der PC aber, dass er ein IPv6-Paket der Größe 1501 fragmentieren muss. In einem parallel von mir erstellten Paket-Mitschnitt sieht man auch, dass tatsächlich zwei kleinere IPv6-Fragmente von jedem ICMPv6-Echo-Paket erzeugt werden. Die Google-Gegenstelle mag aber offensichtlich die IPv6-Fragmente eines ICMPv6-Echo-Pakets nicht wieder zusammenzusetzen und antwortet stattdessen gar nicht (was ich als "Zeitüberschreitung der Anforderung sehe").

    Test-Vorschläge für den DS-Lite over PPPoE-Anschluss:

    Interessant wäre nun mal, diese Tests an einem LAN-Rechner hinter dem DS-Lite-Router für folgende "sizes" auszuprobieren:

    IPv6:

    • size=1444 (Gesamt-Paketlänge = 1444+48=1492): ping -6 -n 4 -l 1444 google.com
    • size=1445 (Gesamt-Paketlänge = 1444+48=1493): ping -6 -n 4 -l 1445 google.com

    IPv4:

    • size=1424 (Gesamt-Paketlänge = 1424+28=1452): ping -4 -n 4 -f -l 1424 google.com
    • size=1425 (Gesamt-Paketlänge = 1425+28=1453): ping -4 -n 4 -f -l 1425 google.com
    • size=1472 (Gesamt-Paketlänge = 1472+28=1500): ping -4 -n 4 -f -l 1472 google.com

    Einmal editiert, zuletzt von ::1 (29. Dezember 2025 um 13:42)

    Ok, das kann ich machen. Jedoch nur über WLAN, da mein Notebook keinen LAN-Anschluss hat und ich keinen Adapter LAN/USB-C habe. Alternativ könnte ich es über einen MAC machen, welcher über LAN verbunden ist, da funktionieren jedoch die Befehle nicht.

    Ich schicke Dir dann die Protokolle!

    kostolany25 : Noch ein Nachtrag zu #159:

    Du scheinst im LAN eine falsch konfigurierte IP-Route für das Zielnetz 192.168.178.0/24 (Standard LAN-Adresse einer AVM-Fritzbox) zu haben, die dazu führt, dass Pakete zu Zieladressen in diesem Netzbereich über die DS-Lite-Verbindung zum Internet (also getunnelt zum AFTR) gesendet werden.

    Man sieht (wiederholt) TCP-SYN-Pakete zum Aufbau von TCP-Verbindungen zu folgenden Adressen:Ports ...

    192.168.178.1:49000
    192.168.178.39:5001
    192.168.178.39:8443
    192.168.178.64:80
    192.168.178.61:80
    192.168.178.55:80
    192.168.178.76:2001
    192.168.178.76:8701
    192.168.178.193:8000

    ... und zahlreiche Retransmits dieser SYN-Pakete, auf die natürlich niemand antworten kann:

    Das Gute ist aber, dass diese TCP-SYN-Pakete sämtlich die MSS-Option (Maximum Segment Size) = 1412 enthalten:

    Eine TCP-Segment der maximalen Größe von MSS=1412 Bytes ergibt zusammen mit einem TCP-Header (20 Bytes) und einem IP-Header (20 Bytes) ein IP-Paket der Länge 1452 Bytes. Und das ist genau die MTU des 4-in-6-Tunnel-Interface für DS-Lite over PPPoE.

    Welcher LAN-Client diese Irrläufer auch immer gesendet hat: Er hat also per Path-MTU-Discovery offenbar schon die Längenbegrenzung von IPv4-Paketen auf maximal 1452 Bytes gelernt.

    Einmal editiert, zuletzt von ::1 (29. Dezember 2025 um 17:04)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
    Zitat von ::1

    Test-Vorschläge für den DS-Lite over PPPoE-Anschluss:

    Interessant wäre nun mal, diese Tests an einem LAN-Rechner hinter dem DS-Lite-Router für folgende "sizes" auszuprobieren:

    IPv6:

    • size=1444 (Gesamt-Paketlänge = 1444+48=1492): ping -6 -n 4 -l 1444 google.com
    • size=1445 (Gesamt-Paketlänge = 1444+48=1493): ping -6 -n 4 -l 1445 google.com

    IPv4:

    • size=1424 (Gesamt-Paketlänge = 1424+28=1452): ping -4 -n 4 -f -l 1424 google.com
    • size=1425 (Gesamt-Paketlänge = 1425+28=1453): ping -4 -n 4 -f -l 1425 google.com
    • size=1472 (Gesamt-Paketlänge = 1472+28=1500): ping -4 -n 4 -f -l 1472 google.com


    Bei IPv4 funktioniert es nur mit 1424, bei allen anderen Größen kommt der Hinweis auf die Fragmentierung.

    bei IPv6 funktioniert es nur mit 1444, bei den anderen Größen kommt die Meldung „Allgemeiner Fehler“.

    Zitat von kostolany25

    Bei IPv4 funktioniert es nur mit 1424, bei allen anderen Größen kommt der Hinweis auf die Fragmentierung.

    bei IPv6 funktioniert es nur mit 1444, bei den anderen Größen kommt die Meldung „Allgemeiner Fehler“.

    So habe ich es erwartet.

    Kannst du nach einem Ping für IPv4 bzw. IPv6 auch mal in den IPv4- bzw. IPv6-Destination-Cache des pingenden Rechners nach den Einträgen für die jeweils aufgelöste IPv4- bzw. IPv6-Adresse des Ping-Ziels (google.com?) schauen, ob für diese als Path-MTU (PMTU) jeweils 1452 bzw. 1492 eingetragen ist?

    If so: Dann ist alles gut, und wir brauchen nicht weiter das MTU-Thema zu reiten.

    Nachtrag:

    Bedeutet somit auch, dass purtel.com keine Jumbo-Frames für die WAN-Strecke verwendet.

    Einmal editiert, zuletzt von ::1 (29. Dezember 2025 um 17:19)

    Zitat von ::1

    So habe ich es erwartet.

    Kannst du nach einem Ping für IPv4 bzw. IPv6 auch mal in den IPv4- bzw. IPv6-Destination-Cache des pingenden Rechners nach den Einträgen für die jeweils aufgelöste IPv4- bzw. IPv6-Adresse des Ping-Ziels (google.com?) schauen, ob für diese als Path-MTU (PMTU) jeweils 1452 bzw. 1492 eingetragen ist?

    If so: Dann ist alles gut, und wir brauchen nicht weiter das MTU-Thema zu reiten.

    Nachtrag:

    Bedeutet somit auch, dass purtel.com keine Jumbo-Frames für die WAN-Strecke verwendet.

    Ich werde verrückt! Im Destination-Cache tauchen beide IP-Adressen nicht auf 🤬

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Mir ist aktuell völlig unklar, woher das kommen soll 🤔

    Ich habe auf meiner Synology einige Docker laufen, ggf. rührt das daher? Wobei mich die Anzahl der IP-Adressen doch erstaunt. Ich begebe mich mal auf die Suche.

    Zitat von kostolany25

    Mir ist aktuell völlig unklar, woher das kommen soll 🤔

    Ich habe auf meiner Synology einige Docker laufen, ggf. rührt das daher? Wobei mich die Anzahl der IP-Adressen doch erstaunt. Ich begebe mich mal auf die Suche.

    Das scheint (überwiegend) von einer uralten IO-Broker-VM zu kommen. Habe diese mal gestoppt.

    Zur Info: Aktuell funktioniert alles ohne Fehler, obwohl ich keine Änderungen vorgenommen habe. Mal sehen, wie lange.