Beiträge von ::1

Zitat

Ich verstehe deren System nicht.

Siehe hierzu die Hinweise von HubeBube in #10: Ticket via DG Portal offen halten durch den Punkt "Nachfrage zu Ticket #...".

Bei denen ist jedes Ticket immer ein neues Problem ...

Zitat

Ich kann in eine Nachricht im Ticketsystem nicht mal alles Schreiben was ich an Details gesammelt haben und übermitteln möchte. Auch den Packet-Capture kann ich nicht als pcap oder zip sondern nur als Textdatei anhängen.

PDF als Attach werden m.W. akzeptiert: Du kannst das Problem z.B. in einem Word-Dokument ausführlich beschreiben (und den Packet-Capture als Bild dort einfügen, das ist aussagekräftig genug) und dieses als PDF speichern. Im Ticket dann nur eine Kurz-Darstellung mir Verweis auf das PDF.

Lazze : Mit dem DNSsec-Validator (https://dnsviz.net/d/www.glasfaserforum.de/dnssec/) wird mir aktuell folgendes Problem angezeigt:

Mit einem Mouseover auf NSEC3 bekommt man sinngemäß die Diagnose:

"NSEC3 record(s) proving non-existence (NODATA) of glasfaserforum.de/DS"

Es liegt vermutlich daran, dass "glasfaserforum.de" an meinem Windows-PC mit dem dort verwendeten DNSsec-validierenden Resolver unbound zeitweise nicht auflösbar ist (ich muss den unbound-Dienst dann immer stoppen und neu starten ).

Zitat von themaze

In der Tat habe ich ein komplexeres Netzwerk aber nur einen OPNsense Router welcher direkt am Modem hängt mit mehreren Netzwerke. Das mit den Interfaces ist soweit kein Problem bei wechselnden Adressen. Nur Jetzt wo IPv6 ins und vom Internet Tot ist, ist das nervig.

Vielleicht noch ein Hinweis, aber vermutlich muss ich dir das gar nicht erzählen:

Ich würde parallel zu dynamisch zugewiesenen globalen IPv6-Adressen im LAN noch permanent ULA (fd00::/8 -> fdxx:xxxx:xxxx::/48 (xx:xxxx:xxxx auswürfeln) -> LAN1: fdxx:xxxx:xxxx:1::/64, LAN2: fdxx:xxxx:xxxx:2::/64, LAN3: fdxx:xxxx:xxxx:3::/64, ...) verwenden.

Die sind fest und immer verfügbar. Sie werden bei rein LAN-interner Kommunikation bevorzugt genutzt und sind dynamisch in einem lokalen DNS-Server registrier- und somit in einer LAN-internen DNS-Domain komfortabel auflösbar . Voraussetzung ist bei allen Endgeräten allerdings eine aktuelle Default Policy Table (kann man sich unter Windows via netsh int ipv6 show pref anzeigen lassen), die einen Eintrag für fc00::/7 enthält - zur Not muss man diesen von Hand ergänzen, falls das jeweilige System dafür eine Schnittstelle bietet (problematisch bei IOT-Geräten wie Druckern usw., aber die spricht man halt zur Not ausschließlich via IPv4 an)

So könntest du das Inside-Interface deines Proxies (falls "one-armed" ULA als secondary IPv6 address) stets über eine feste ULA adressieren.

Zitat von themaze

Gibt es Business Tarife (von der DG) mit fixen Prefixen für Ottonormalos?

Kann ich nicht sagen - aber DG berät dich hier bestimmt hervorragend bei der Auswahl eines geeigneten Business-Tarifs.
Mir ist jedenfalls nicht bekannt, dass DG gegen einen geringfügigen Aufpreis feste IPv6-Adressen an Privat-Anschlüssen bereitstellt.

Das ist dann wohl das LAN-Interface deines Routers.

Hier das Ping-Ergebnis an meinem DG-Anschluss

Und so sieht es aus Sicht von London und Amsterdam aus:

Aber es bestätigt meine Vermutung aus #11.

Zitat von themaze

Anhand des Suffixes erkenne ich dass es mein Reverseproxy ist.

Die scheinst ein komplexeres strukturiertes LAN mit mehreren LAN-Segmenten (VLANs) und evtl. nachgelagerten Routern zu betreiben?

So etwas ist m.E. nicht gut verträglich mit wechselnden IPv6-LAN-Präfixen - da muss man sich (zu) sehr darauf verlassen, dass die dynamischen Prozesse, die mit einem Präfix-Wechsel ausgelöst werden, auch zuverlässig funktionieren (z.B. nachgelagerte IPv6-PD an sekundäre LAN-Router, DynDNS für von außen erreichbare LAN-Instanzen, dynamische Anpassung von Firewall-/Proxy-Regeln, usw.)

In solchen Fällen wäre m.E. ein Business-Anschluss mit festen IPv6-Adressen die bessere Wahl.

Zitat von archerbyte

Bis lang hatte ich zuhause eine eigene VPN (OpenVPN) und hab mit DynDNS (DuckDNS) meine IP auflösen können und konnte immer auf mein Netzwerk zugreifen. Seit kurzem haben wir Glasfaser von der deutschen Glasfaser bekommen und jetzt klappt gar nichts mehr.

Ich nutze einen TP-Link MR550.

Wie schon in den anderen Kommentaren erklärt, wird dein Szenario, wenn überhaupt, an einem DG-Anschluss aufgrund von CGNAT nur noch mit IPv6 funktionieren.

Voraussetzung dafür ist aber ein stabiles IPv6. Falls die IPv6-Adresse des WAN-Ports deines Routers mit "2a00:6020:1000:" beginnt, ist die Chance für stabiles IPv6 sehr hoch, denn dann liegt die ältere/frühere Adressierungs-Systematik vor, bei der man auch nach Neuverbindungen i.d.R. stets dieselben IPv6-Adressen für LAN und WAN zugewiesen bekommt (also quasistatische Adressen - allerdings ist das seitens DG nicht garantiert).

Andernfalls hast du einen DG-Anschluss mit neuer Adressierung-Systematik. Wie erst vor kurzem gelernt, zeichnet der sich dadurch aus, dass du bei einer Neuverbindung häufig neue IPv6-Adressen für LAN und WAN bekommst, bzw. DG auch Zwangstrennungen in gewissen Zeitabständen durchführt, die im Ergebnis ebenfalls zu geänderten IPv6-Adressen führen. Und diese Neuanschlüsse fallen in letzter Zeit dadurch negativ auf, dass IPv6 schlicht nicht funktioniert.

Nun kannst du bzgl. deiner OpenVPN-Verbindung argumentieren: Kein Problem, ich habe ja DynDNS!

Richtig - DynDNS ist in Verbindung mit IPv6 aber variantenreicher in der Umsetzung, insbesondere weil der Endpunkt der OpenVPN-Verbindung nicht zwingenderweise mit der WAN-Adresse des Routers zusammenfällt (der Router also zugleich der OpenVPN-Peer ist), sondern auch im LAN hinter dem Router liegen kann (weil die IPv6-LAN-Adressen per Definition öffentlich erreichbar sind).

Der zweite Fall führt dann zu der Frage, wer DynDNS macht: Das OpenVPN-Gerät im LAN für seine LAN-IPv6-Adresse? Oder der Router stellvertretend für das OpenVPN-Gerät, d.h. der Router muss nicht deine IPv6-WAN-Adresse, sondern die IPv6-LAN-Adresse des OpenVPN-Geräts im DynDNS registrieren. Ob dein TP-Link MR550 das kann, sei mal dahingestellt. Hinzu kommt dann ja auch noch die Thematik, dass in der Firewall des Routers eine Freischaltung für den Zugriff von außen auf dein OpenVPN-Gerät vorhanden sein muss (bei IPv4 würde man hier eine "Portweiterleitung" einrichten - dies "Denke" bei IPv6 bitte komplett vergessen), die der Router bei einem IPv6-Adresswechsel auch dynamisch anpassen können muss. Eine Fritzbox kann das z.B. dadurch, dass die Freigabe nur den IPv6-Host-Identifier des OpenVPN-Geräts enthält und der IPv6-LAN-Präfix dynamisch ergänzt wird. Aber auch das scheitert, wenn der Hersteller des OpenVPN-Geräts sich dem aktuell bei mehreren Herstellern zu beobachtenden Trend anschließt, den IPv6-Host-Identifier nicht mehr konstant nur aus der MAC-Adresse des Gerätes zu erzeugen, sondern ihn zusätzlich vom zugewiesenen IPv6-LAN-Präfix abhängig zu machen.

Am besten wird daher das OpenVPN-Szenario mit IPv6 nur dann betriebssicher funktionieren, wenn OpenVPN direkt im Router terminiert wird und somit nur die IPv6-WAN-Adresse des Routers im DynDNS registriert werden muss (so, wie man es auch von IPv4 kennnt). Falls TP-Link MR550 das nicht kann, wäre ggf. also ein neuer Router fällig, der auch VPN-Funktionen mitbringt.

Noch ein Nachtrag zu ICMPv6-WAN.zip:

Der Mitschnitt enthält auch 8 ICMPv6-Errors (Wireshark-Filter: icmpv6.type==1) des Typs 1 (Destination Unreachable) mit dem Code 1 (Administratively prohibited):

Deine Versuche, von deiner LAN-IPv6-Adresse 2a00:6020:9842:f02:7d80:ff4:59e6:f151 eine TCP-Connection zu [2a00:6020:9841:8245::4c51]:443 aufzubauen (vermutlich das DG-Kundennetz deines erwähnten Freundes), werden von dessen Router (mit der WAN-Adresse=2a00:6020:9800::1e1) geblockt. Dieser sendet daraufhin den erwähnten ICMPv6-Error (von seiner WAN-Adresse) an deine LAN-IPv6-Adresse zurück.

Das bedeutet:

Der BNG-Cluster, an dem eure Anschlüsse hängen, kennt eure PD-LAN-Präfixe (deiner: 2a00:6020:9842:f00::/56 - der deines Freundes: 2a00:6020:9841:8200::/56), und kann sie untereinander routen. Beide LAN-Präfixe liegen im übergeordneten Block 2a00:6020:9800::/41 - /41 ist nach meinen Analysen bei DG die Grundgröße pro BNG-Cluster, an dem theoretisch maximal 2^(56-41) = 32.767 Kundenanschlüsse hängen können (-1 für dem ersten /56, in dem die WAN-Adressen der Anschlüsse liegen).

Wie schon weiter oben von mir vermutet, fehlen in der DG-Infrastruktur "hinter" dem BNG-Cluster offenbar Routing-Informationen, die eurer beide PD-LAN-Präfixe zu dem zuständigen BNG-Cluster forwarden. Der Block für die WAN-Adressen (2a00:6020:9800::/56 bzw. genauer: 2a00:6020:9800::/112) scheint allerdings sehr wohl zu diesem BNG-Cluster geroutet zu werden.

Andererseits würde ich nicht erwarten, dass DG die einzelnen Sub-Ranges so selektiv routet - mit einer einzigen Route für den Gesamtblock 2a00:6020:9800::/41 wäre es ja auch getan - insofern etwas verwunderlich.

Mich wundert noch ein wenig die IPv6-LAN-Adresse des Freundes: 2a00:6020:9841:8245::/64. Wenn der den PD-Block 2a00:6020:9841:8200::/56 zugewiesen bekommen hat, wäre er mit dem Index 45 für die daraus abgeleitete /64-LAN-Adresse recht weit weg von der 0, die z.B. eine Fritzbox wählt. Hat der Freund tatsächlich ein PD-LAN-Präfix der Größe /56 zugewiesen bekommen? Oder hat er tatsächlich nur den minimalen Block der Größe /64 (also konkret 2a00:6020:9841:8245::/64) von der DG erhalten? Dieses Phänomen gab es kürzlich in einem anderen Fall.

Deine ICMPv6-WAN.zip bzw. der zugehörige Screenshot sind für jeden technisch versierten Netzwerker bzw. Sachverständigen ein klarer Beweis, dass es in der DG-internen Infrastruktur ein Problem mit dem (Rückwärts-)Routing deines PD-LAN-Präfix gibt. Es ist dabei wichtig, eine Auswahl prominenter IPv6-Ziele auszuwählen, damit sich DG nicht herausreden kann, dass die Ziele bzgl. IPv6 nicht zuverlässig antworten würden. Andere gute Ziele wären bspw. die 13 DNS-Root-Nameserver (a.root-servers.net - m.root-servers.net).

Ja, mit dem 1st-Level-DG-Support ist es schwierig, die scheinen nur angelernte Kenntnisse zu Glasfaser-Problemen (also L1-L2) zu haben. Jedes Problem ab L3 (z.B. IPv4 geht, IPv6 aber nicht) führt zu Überforderung bzw. wird dann kochrezeptartig mit unpassenden/sinnlosen Lösungsvorschlägen zu L2-Problemem (z.B. Router und/oder Modem zurücksetzen) aus der Textbausteinsammlung beantwortet.

Ich würde zur Schonung der eigenen Nerven vermeiden, mich dort wegen dieses Problems telefonisch zu melden. Alles nur schriftlich via deren Ticket-System. Und wenn ein Ticket ohne Lösung einfach geschlossen wird, ein neues mit Bezug auf alle vorher geschlossenen Tickets aufmachen.

Deine ZIP-Datei nebst Screenshot würde ich an ein Ticket anhängen.

Wichtig für Regress-Forderungen (solche würde ich in dem Ticket auch androhen) ist auch das Datum des ersten Tickets zu dem Problem, weil es den Startpunkt des Zeitraumes markiert, ab dem die laut Leistungsbeschreibung/AGB zugesagte und bezahlte Leistung (IPv6) eben nicht zur Verfügung steht.

HubeBube hat hier schon an verschiedenen Stellen erläutert, wie man in solchen Situationen am besten vorgeht.

Zitat von themaze

Ich habe seit der Anschluss besteht (Ende Oktober), immer eine neue Adresse bekommen wenn ich mich neu verbinde. Das veränderte verhalten ist jetzt, dass ich nicht bei jedem Reconnect eine neue Adresse bekomme, sondern nur wenn dieser ein paar Stunden her ist.

Danke für die Klarstellung - mit dem neuen Konzept wirft DG also die "quasistatischen" IPv6-Adressen über Bord, vermeintlich zugunsten von Privacy.

Frage: Führt DG jetzt auch in gewissen Zeitabständen Zwangstrennungen durch, um dir neue IPv6-Adressen zu verpassen?

Zitat von themaze

Zu erwähnen ist dass mein Router ein DCHPv6-Release zu den Adressen schickt bevor er sie erneut Anfragt.

So sollte es sein.

Zitat von themaze

Habe gerade einen Mitschnitt gemacht, hier eine RA der Gegenstelle:

Das sieht alles gut aus. Wichtig sind das gesetzte M-Flag und eine Router lifetime >0. Der Wert 4500s ist dabei recht lang (bei meinem DG-Anschluss sind es 1800s). Vermutlich werden RA daher auch nur in großen Zeitabständen (etwa alle 25 Min.?) erhalten?

Dein Router leitet daraus das IPv6-Standardgateway fe80::22 ab, das zeigt er evtl. auch irgendwo in der Web-GUI oder an der Console (Auslesen der IPv6-Routingtabelle, dort die Default-Route "::/0 next hop fe80::22") an.

Was du als Nachweis gegenüber DG (dort dem 2nd-Level-Support, so sie einen haben) machen kannst:

• Starte an einem LAN-PC (in mehreren Terminalfenstern) Dauerpings auf mehrere "well known" IPv6-Ziele, z.B. unter Windows:
  ping -6 -t google.com
  ping -6 -t facebook.com
  ping -6 -t wikipedia.org
• Führe einen Paketmitschnitt am WAN-Port des Routers durch und lass den vielleicht eine Minute laufen.

In der Anzeige des Mitschnitts mittels Wireshark setze des Ansichtsfilter icmpv6.

Du müsstest dann sehen, dass der Router die Pings des LAN-PC über die WAN-Strecke zur DG-Gegenstelle (verpackt in Ethernet-Frames mit der Ethernet-Zieladresse: 20:00:00:00:32:02, hat der Router durch NS/NA (MAC-Adressauflösung) aus der Gateway-Adresse fe80::22 ermittelt) sendet, von dort aber niemals Ping-Antworten zurück kommen. Das wäre der sichere Beleg, dass dein Router korrekt arbeitet und das (Rückwärts-)Routing-Problem auf der Seite der DG liegt.

Ok, du bekommst einen /56 als LAN-Präfix - so sollte es sein.

Und es scheint so zu sein, dass du mit jedem Reconnect eine neue Kombination von LAN-Präfix (jetzt: 2a00:6020:9842:f00::/56) und WAN-Adresse (jetzt 2a00:6020:9800::26c) bekommst - ob das auf einen Fehler hindeutet (bei Anschlüssen nach altem Adresskonzept bekommt man nach Reconnects i.d.R. stets dieselben IPv6-Adressen), oder ob das Bestandteil eben dieses neuen Konzepts ist (das vermute ich, siehe dieser DG-Anschluss mit RIPE-Atlas-Probe, für den auch das neue Konzept gilt), vermag ich nicht zu sagen.

Zitat von themaze

Ich habe gerade eben einen Freund der im gleiche Ort mit dem gleichen DG Ausbautrupp angeschlossen wurde, gefragt, ob er mir einen Traceroute von seinem Rechner schicken kann. Sein PC zeigt das gleiche Ergebnis. fc00::1 als 2. Hop und dann nichts.

Das heißt. der Freund hat das gleiche Problem wie du? Oder kann er nur deine Adressen nicht erreichen, IPv6-Ziele im Internet aber schon?

Ich kann von meinem DG-Anschluss deine WAN-Adresse (2a00:6020:9800::26c) aktuell auch nicht pingen, normalerweise erreicht man andere DG-Kundenanschlüsse. Aber möglicherweise ist diese Adresse ja schon nicht mehr aktuell.

Viel schlauer werde ich durch deine gezeigten Ergebnisse nicht.

Vielleicht (nur zur Kontrolle) noch folgende Frage: Du hast ja schon diverse Paketmitschnitte am WAN-Port gemacht. Siehst du dort in regelmäßigen Zeitabständen (default so alle 10 Min) sog. Router-Advertisments, die die DG-Gegenstelle sendet (Suchfilter in Wireshark: icmpv6.type==134). Falls ja, zeig mal den ICMPv6-Inhalt eines RA.

Dein LAN-Präfix scheint 2a00:6020:9842:1000::/56 zu sein?
Oder wurde dir, wie in einem anderen Problemfall, von DG nur ein LAN-Präfix der Größe /64 (konkret: 2a00:6020:9842:1002::/64) zugewiesen?

Es sieht so aus, als würde dein LAN-Präfix seitens DG aktuell nicht zu dem BNG-Cluster (der für 2a00:6020:9800::/41 zuständig ist) geroutet, an dem dein Anschluss hängt. Der Range 2a00:6020:9800::/112, in dem sich die WAN-Adressen der Kunden-Anschlüsse befinden (bei dir: 2a00:6020:9800::26d) scheint hingegen korrekt geroutet zu werden.

Das könnte man evtl. verifizieren, indem du die Firewall deines OPNsense für ICMPv6-Echo zu einem LAN-Gerät deiner Wahl öffnest und das WAN-Interface deines OPNsense so konfigurierst, dass es eine ICMPv6-Fehlermeldung für "Time exceeded" sendet, wenn es ICMPv6-Pakete verwirft, die es wegen ablaufendem Hop-Count nicht ins LAN weiterleiten kann. Dann müsste dein Router bei funktionierendem IPv6 in Traceroutes von außen (z.B. von hier) zur IPv6-Adresse deines LAN-Gerätes auftauchen.

Wenn dein Router in dieses Traceroutes hingegen nicht auftaucht, wäre das m.E. ein Beleg für meine Vermutung.

Zitat von Nagal

Es wurde zwar angezeigt in der Systemmeldung das die neuen DNS Server Einstellungen übernommen wurden, aber irgendwie ignoriert die FritzBox 5690Pro das ganze und es kommt immer wieder zu DNS Störungen.

Ich erinnere mich bei meiner früheren FB 7590, bei der das Problem auch auftrat, dass das ein Bug im FRITZ!OS war, der mit der nächsten FRITZ!OS-Version behoben wurde.

Workaround war laut Empfehlung von AVM, den Haken bei "Bei DNS-Störungen auf öffentliche DNS-Server zurückgreifen" einfach herauszunehmen. Welche DNS-Server du verwendest, ist dabei egal, ich würde hier wieder zur Standardeinstellung "Vom Internetanbieter zugewiesene DNSv6-Server verwenden (empfohlen)" zurückkehren.

Und klar, sofern du noch nicht die neueste FRITZ!OS-Version für dein Modell verwendest -> OS aktualisieren!

Dein Anschluss scheint an einem BNG-Cluster der DG zu hängen, auf dem sie ihr "neues" IPv6-Adresskonzept anwendet, welches hier im Forum schon öfter durch Nicht-Funktionieren von IPv6 aufgefallen ist. Das sehe ich anhand der WAN-Adresse deines Routers, die im ersten /56-Block (genauer: im Block 2a00:6020:5c80::/112) des übergeordneten Block 2a00:6020:5c80::/41 liegt, aus dem die DG ihren Kunden an diesem BNG-Cluster die /56-Blöcke für das LAN zuweist (bei dir: 2a00:6020:5cc0:100::/56). In Traceroutes zeigen sich die BNG-Cluster mit "neuem" Adresskonzept stets mit der Adresse "fc00::1"

Ich kann von meiner Seite (auch DG-Anschluss, aber nach "altem" Adress-Konzept) z.B. die WAN-Adresse 2a00:6020:5c80::100 pingen - vielleicht ist das ja sogar dein Anschluss.

Dein Test zeigt, dass "inbound-IPv6" nur bis zum WAN-Port funktioniert. Ob auch dein LAN dahinter von außen erreichbar ist, müsstest du mal durch Öffnen der FB-Firewall (z.B. für ein ICMPv6 echo/Pingv6) für ein LAN-Gerät deiner Wahl testen.

Etwas merkwürdig finde ich die Wahl des /64 für dein LAN aus dem 2a00:6020:5cc0:100::/56-Block: Dies ist bei dir der Index 44, so dass sich daraus eine LAN-Adresse 2a00:6020:5cc0:144::/64 ergibt. Normalerweise würde eine FB den Index 00 wählen, so dass sich die LAN-Adresse 2a00:6020:5cc0:100::/64 (und 2a00:6020:5cc0:101::/64 für das Gäste-LAN) ergäbe. Es sei denn, du hast eine Router-Kaskade, und deine FB ist der nachgelagerte Router, an den du einen Teilblock aus 2a00:6020:5cc0:100::/56 per DHCPv6-PD delegiert hast (z.B. 2a00:6020:5cc0:144::/62). Liege ich da evtl. richtig?

Wenn outbound-IPv6 nicht funktioniert, dann liegt das vermutlich daran, dass dein Router/FB keine IPv6-RA (Router-Advertisments) von der DG-Gegenstelle (eben dem BNG) erhält, so dass keine IPv6-Default-Route gelernt werden kann. Das müsste man durch einen Paketmitschnitt am WAN-Port eruieren.

Nachtrag:

Sorry, habe ich übersehen:

Laut deiner FB-Ereignisanzeige weist dir DG gar kein /56 zu, sondern nur explizit den /64: 2a00:6020:5cc0:144::/64. Also wenn das jetzt Teil des "neuen" IPv6-Adresskonzepts ist, wäre das gelinde gesagt doch etwas "sparsam". Laut meinen Beobachtungen an einem anderen DG-Anschluss (dieser hier: RIPE-Atlas Probe #1001325) scheinen auch die zugewiesenen IPv6-Adressen nicht mehr "quasi-statisch" zu sein, die wechseln bei Neuverbindungen öfters.

Der hier hängt auch an deinem BNG-Cluster (100.124.1.11, 2a00:6020:ffff:ffff::e):

Die Paketverluste sind hier stark abhängig vom Ziel (die man einzeln sehen kann. wenn man in der Legende auf das jeweilige Ziel klickt:

• wikipedia.org (v4): Viel Verluste bis Mitte 06/25, danach deutlich weniger.
• google,com (v4): Mäßige Zunahme ab 09/25
• alle übrigen: relativ gleichmäßig verteilt
• alle: Zwischen 07/25 und 09/25 eine Phase der geringsten Verluste.

Aber schau dir mal eine Probe am Anschluss eines anderen Providers an, z.B. den hier (Telekom):

Das sieht auch nicht viel besser aus.

Ich halte die Aussagekraft solcher Messungen für sehr begrenzt.

Habe mal eine IPv6-Vergleichsmessung zu one.one.one.one (2606:4700:4700::1001) gemacht analog deiner Messung im Screenshot 174352:

Also ein paar Paketverluste habe ich auch, wenn auch deutlich geringer als bei dir.

Habe auch einen DG-Classic-Tarif 400/200, hänge aber am BNG-Cluster 100.124.1.26/2a00:6020:ffff:ffff::23 (BNG-Cluster 2 Nürnberg).

Zitat von lp24db

::1 hast du eine Idee, was das sein könnte? Oder wo man ansetzen könnte? Bandbreiten-Tests sind 100%. Ich bekomme genau das, was vertraglich zugesichert ist.

Naja, Ideen kann man viele haben. Mir fällt hierzu dieser Thread ein. Dort lagen die Dinge zwar etwas anders (Netz mit ~100 Clients an einem Privat-Anschluss), aber die Ursache könnte doch in beiden Fällen am IPv4-CGNAT des DG zu suchen sein - die Hintergründe habe ich in jenem Thread in meinen Beiträgen #10 und #14 erläutert.

Insofern wäre es mal interessant, deine Messungen im Vergleich einmal via IPv4 und einmal via IPv6 für ein Internet-Ziel durchzuführen, das dual-stack, also über beide Protokolle erreichbar ist. Treten bei zwei Vergleichsmessungen zu demselben Internet-Ziel Verluste signifikant nur via IPv4, nicht jedoch via IPv6 auf, wäre das zumindest ein Hinweis, dass es am CGNAT liegen könnte.

Zitat von lp24db

DG-CGN ist (denke ich) der NAT Router von der DG, also der erste Hop, den ich im MTR sehen kann

Ich habe mich ein wenig mit der Adress-Systematik der DG u.a. auf Basis von RIPE-Atlas-Probes an DG-Anschlüssen befasst und kann daher mit einiger Sicherheit sagen:

1. Hop 2 (100.124.1.11) ist lediglich die der Kundenseite zugewandte IPv4-Adresse des "BNG-Cluster-1" der DG in Frankfurt (dieser BNG-Cluster hat auf der dem Internet zugewandten Seite die IPv6-Adresse 2a00:6020:ffff:ffff::e). Der BNG-Cluster ist aber nicht zugleich die CGNAT-Instanz.
   
2. Folglich ist die CGNAT-Instanz der Hop 3 oder der Hop 4, wobei ich auf Hop 3 tippe. Hop 4 wäre dann der letzte DG-BGP-Router am DE-CIX Frankfurt.

Wenn meine Analyse richtig und dein Anschluss keine der berühmten Ausnahmen von der Regel ist, müsstest du einen IPv6-LAN-Range (/56) aus dem IPv6-Block 2a00:6020:5080::/41 (also einen der /56-Blöcke aus 2a00:6020:5080::/56 bis 2a00:6020:50ff:ff00::/56) und eine WAN-Adresse der Form 2a00:6020:1000:41::WXYZ haben.

Die folgenden beiden public Atlas-Probes hängen ebenfalls am BNG-Cluster deines DG-Anschlusses: #10214 und #53040. Die IPv4-Traceroute-Messungen dieser Probes stimmen für die Hops 2-4 mit deiner Messung überein (Klicke auf einen Messdatenpunkt und dann auf "SHOW TRACEROUTES" in 10214-Built-ins-v4 bzw. 53014-Built-ins-v4, um die Traceroutes anzuzeigen).

Woher weiß ich, dass die BNG-Cluster kein CGNAT-machen?

Antwort:

Es gibt Atlas-Probes an DG-Kundenanschlüssen, die an verschiedenen BNG-Clustern hängen, aber dieselbe public IPv4-Adresse besitzen. Da diese public IPv4-Adresse nicht gleichzeitig durch zwei verschiedene BNG-Cluster verwendet werden kann, muss der NAT-Schritt folglich an einer nachgelagerten Instanz erfolgen.

Beispiel:

• Probe #28672: public IPv4=94.31.112.13, BNG-Cluster: 100.124.1.27 / 2a00:6020:ffff:ffff::24 - BNG-Cluster-2 Nürnberg
• Probe #31836: public IPv4=94.31.112.13, BNG-Cluster: 100.124.1.24 / 2a00:6020:ffff:ffff::21 - BNG-Cluster-1 Nürnberg

Zitat von Tuffi

Mir ist gerade, das auf der Übersichtsseite der Fritzbox der WAN-Anschluss auf 100 Mbit/s steht. Ich vermute, das der Genexis "einen weg hat".

Schau doch mal in deiner Fritzbox unter "Heimnetz | Netzwerk | Netzwerkeinstellungen" und dort unter der Überschrift "LAN-Einstellungen", ob für den WAN-Port dummerweise der "Green Mode" anstelle des "Power Mode" aktiviert ist. Falls ja, auf "Power Mode" umschalten.

Zitat von HubeBube

Anleitung siehe hier: Deutsche Glasfaser: Umstellung NT/7590 auf 5530 Fiber

Wenn ich es richtig sehe, fehlt der Beschreibung der allerwichtigste Punkt:

Bevor man überhaupt anfängt, ist der DG die Modem-ID des Routers zu nennen und abzuwarten, bis man von DG eine Bestätigungsmail inklusive Umstellungsanleitung bekommen hat.