Beiträge von ::1

Zitat

nur zum Verständnis... Was hat es mit dem 7000er Bereich auf sich? ist das schlechter wenn man da drin landet?

Siehe hier.

Ja, DG meldet ein Ende der oben gezeigten Störung in meinem Großraum Nürnberg für 06.02.2025 02:32 Uhr. Um 02:59 Uhr konnte meine FRITZ!Box dann wieder erfolgreich IPv6-Adressen beziehen.

Ich fragte nur deshalb, weil ich die Vermutung geäußert hatte, dass einige der hier im Forum diskutieren Fälle mit IPv6-Problemen auf den IPv6-Range 2a00:6020:7000::/36 einzugrenzen waren und DG dort vermutlich eine neue Adressvergabe-Strategie als in anderen IPv6-Ranges eingeführt hat. Möglicherweise haben sich die Probleme der anderen Fälle aus 2a00:6020:7000::/36 nun ja auch gelöst.

Es gibt für meinen "Großraum Nürnberg" nun immerhin schon eine Störungsmeldung auf der DG-Site:

Als Betreiber einer RIPE-Atlas-Probe habe ich für AS60294 der DG genauer noch einen weiteren Probe-Betreiber an einem DG-Anschluss gefunden, dessen Probe-Messungen zu IPv6 (IPv6-PING der DNS-Root-Nameserver) ab 04.02.2025 02:00:00 wie bei meiner Probe abbrechen.

Es scheinen die Anschlüsse im IPv6-Range "Nuernberg-BNG-Cluster2" = 2a00:6020:4700::/40 betroffen zu sein.

Zitat von webwe

Und siehe da nun kann ich mit IPv6 meine Fritzbox tadellos erreichen.

Site2Site, wireguard VPN und mein (temporärer) Zugang mit HTTPS sind alle funktionsfähig.

Nur interessehalber:

Du hast immer noch ein LAN-Präfix (/56) aus 2a00:6020:7380::/41 und eine WAN-Port-Adresse 2a00:6020:7380::/112?

Hallo zusammen,

es scheint, dass einige DG-Kunden seit 04.02.2025 (etwa 02:00 Uhr) von einem IPv6-Ausfall betroffen sind (z.B. SirfNix in #22, Taxan4711 in #30 und DigiAndi in #1), so auch ich.

Meine Fritzbox (kundeneigener Router mit WAN-Port am ONT) sagt:

Und ein Paketmitschnitt am WAN-Port zeigt:

Ich erhalte regelmäßig Router-Advertisements von der Gegenstelle (mit validem Inhalt: Gesetztes M-Flag und "Router lifetime" > 0 (1800s)). Mein Router sendet brav (und inzwischen mit maximalem Zeitabstand von 1 Stunde) DHCPv6-Solicits, erhält allerdings keine Antworten. Diese Situation kenne ich nur allzu gut, trat in der Vergangenheit schon gelegentlich auf, jedoch in meinem Fall noch nie so lang anhaltend wie aktuell.

Natürlich habe ich auf der DG-Site nach Störungsmeldungen gesucht, jedoch keine meinen Standort betreffende gefunden.

Vielleicht können weitere Betroffene ihre jeweiligen Fälle in diesem Thread ergänzen ...

Zitat von Zaphod

, dann in letzter Konsequenz Kündigung.

Das würde ich trotz allem berechtigten Ärger über DG doch besser unterlassen, insbesondere dann, wenn DG dein Glasfaser-Monopolist ist. Vorschlag: Bestell dir den DG-Fritzbox-Mietrouter für eine minimale Laufzeit - dann ist DG in der Pflicht, dir IPv6 bereitzustellen (und kann sich nicht mit der Begründung "kundeneigener Router" herausreden) - und du hast dann m.E. einen deutlich wirkungsvolleren Hebel, im Falle der Nichterfüllung den Monatsbeitrag zu senken.

Zitat von west

Ich meine Präfixlänge

Gemäß deinem beigefügten Bild ist die Antwort natürlich: /64

Aber du möchtest vermutlich die Größe des PD-Blocks für die LAN-Adressierung erfahren, also ob das ein üblicher /56 oder ggf. nur ein sparsamer /60 ist?

Zitat von jokergermany

Hab VLAN ID 200 wieder reingenommen beim Router
Wenn du Port-based VLAN meinst, dass steht schon drin:
https://www.glasfaserforum.de/attachment/4628-grafik-png/

Satz 1: Ok, dann muss Port 26 ein "tagged member" von VLAN 200 sein, wie eingestellt.

Satz 2: Ja, das meinte ich: PVID = Port-based VLAN, obwohl diese Einstellung für tagged Ports nicht mehr so relevant ist (deckt den Fall ab, welchem VLAN ein Frame zugeordnet werden soll, wenn es untagged zum Port herein kommt - sowas sollte nicht mehr auftreten, wenn der Router mit VLAN 200 getaggte Frames sendet)

Zitat von jokergermany

Dass habe ich jetzt eingestellt und im Router die Vlan ID 200 raus genommen, aber es funktioniert noch nicht.

Port 26 muss ein "untagged member" von VLAN 200 sein, wenn du im Router VLAN 200 herausgenommen hast. Außerdem musst du die PVID von Port 26 auf VLAN 200 einstellen.

Ok, dann müssen die Ethernet-Frames ingress/egress am SFT-Port mit VLAN 200 getagged sein.

Verwende also statt VLAN 100 das VLAN 200.

Außerdem muss der SFP-Port nun ein "tagged member" von VLAN 200 sein.

Den Router-Port kannst du auf "untagged member" von VLAN 200 belassen. Dann brauchst du am WAN-Port des Routers nichts mit VLAN konfigureren.

Zitat von jokergermany

So richtig verstanden habe ich noch nicht wann man PVLans verwendet und wann Port based Vlans.

Verstehe ja das Problem an Tag based Vlans, aber nicht so wirklich den Unterschied zwischen PVLans und Port based Vlans...

Ich erkläre jetzt nicht PVLAN, weil du das nicht brauchst. Setze deinen Switch bitte wieder auf den Ausgangszustand.

Lösung mit Standard-VLAN: Ich gehe davon aus, dass es in deinem Switch ein Default-VLAN gibt (häufig VLAN 1 - schau mal in Manual, ob es dazu Infos gibt), und dass alle Ports Access-Ports für das Default-VLAN darstellen. Dann kann jeder Port mit jedem anderen kommunizieren.

Denke dir jetzt ein VLAN aus, das nicht dem Default-VLAN entspricht. Ich nehme jetzt bspw. mal VLAN 100. Jetzt konfiguriere den Uplink-Port für das SFP-Modul und den gewünschten Port für den Router-Anschluss als Access-Ports für VLAN 100. Fertig. Die Bezeichnung "Access-Port" kommt aus der Cisco-Welt, bei deinem Switch heißt das vermutlich anders, schau im Manual: Soweit ich es (kurz überflogen) sehe, ist bei deinem Switch das Default-VLAN=1. Füge also ein VLAN 100 (oder etwas ungleich 1) hinzu und deklariere die beiden Ports als "untagged members" von VLAN 100. Die PVID für diese beiden Ports muss auch auf VLAN 100 gesetzt werden.

Zitat von jokergermany

Doch ist sehr relevant, sollte ich wirklich das ONT durch ein SFP Modul ersetzen.
Weil der Switch ja switchen soll, bloß eben nicht die Glasfaser, die darf nur zu nem anderen RJ45 Port gehen und von da aus zum Wan Port des Routers.

Ja, das machst du mit Standard-VLANs, wie oben schon von Anderen kommentiert. Dazu brauchst du keine "PVLANs".

"Isolation cannot be set for all SFP ports"
Generally, it is necessary to ensure that the uplink port is in the allowed forwarding"

Zitat von jokergermany

Da muss ich mir nochmal genau anschauen was damit genau gemeint ist und was der unterschied zwischen vlan und isolate ist...

Laut Manual gehe ich davon aus, dass es sich hier um "isolated private VLAN (PVLAN)" handelt. Die allgemeine Theorie dazu findest du in RFC5517, wobei der Switch keine Community-Ports unterstützt. Die Aussage in dem Manual besagt m.E., dass mindestens einer der Uplink-Ports ein Promiscuous-Port (im RFC-Sprech) sein muss ("is in the allowed forwarding" im Manual-Sprech).

Ich gehe aber davon aus, dass isolated PVLAN für dich nicht relevant ist. Da lt. Manual "By default, all ports are not isolated" gilt, kannst du das Thema somit ignorieren.

Was mich stutzig macht: Die Fritzbox 7590AX am DG-Anschluss hat kein aktiviertes IPv6 (laut einem der Screenshots). Wenn du nun an deinem Windows-PC, wie gezeigt, NSLOOKUP aufrufst, meldet sich als DNS-Resolver allerdings eine "fritz.box" mit einer IPv6-ULA-Adresse fd98:...

Das kann nicht die 7590AX sein (denn die hat IPv6 nicht aktiviert), es ist dann wohl die 7590 am Telekom-Anschluss.

Wie ist dein Windows-PC denn angeschlossen, nur über WLAN? Und wenn ja, welches WLAN? Die Fritzbox 7590AX hat wohl ein WLAN mit der SSID "FRITZ!Box 7590 HE" - ich hoffe, das WLAN deiner Fritzbox 7590 am Telekom-Anschluss hat eine andere SSID?

Vorschlag: Sorge für einen Test erst Mal für eine sauber getrennte Netzumgebung für den DG-Anschluss: Wähle in der Fritzbox 7590AX vorerst eine WLAN-SSID, die sich von der WLAN-SSID der Fritzbox 7590 am Telekom-Anschluss unterscheidet. Stelle sicher, dass keine LAN-Ports der beiden Fritzboxen miteinander (direkt, oder über einen Switch) verbunden sind. Schließe einen Windows-PC zum Testen entweder über WLAN (WLAN-SSID der Fritzbox 7590AX!) oder per Ethernet-Kabel (in diesem Fall bitte den WLAN-Adapter des Windows-PC deaktivieren) an die Fritzbox 7590AX an.

Und dann nochmal testen. Es wäre auch gut, in der Fritzbox 7590AX IPv6 zu aktivieren. Und wenn man wirklich wissen will, was auf der DG-Verbindung passiert, wäre eine Paketmitschnitt am WAN-Port der Fritzbox 7590AX nicht schlecht.

Ich möchte nochmal auf meinen Kommentar oben hinweisen:

Zitat von ::1

Aus der Info für das FRITZ!OS-Update 8.02:

Code

# Weitere Verbesserungen im FRITZ!OS 8.02

## Telefonie:
...

## Internet:
...
- **Behoben** keine Internetverbindung nach Update auf FRITZ!OS 8.00 bei fehlendem Kennwort in den Zugangsdaten

Ein Update auf Version 8.02 könnte das Problem also beseitigen. Müsste man sich jetzt halt über einen anderen Internetzugang von https://ftp.avm.de/fritzbox/ herunterladen und in der FRITZ!Box als Datei einspielen.

Aus der Info für das FRITZ!OS-Update 8.02:

# Weitere Verbesserungen im FRITZ!OS 8.02

## Telefonie:
...

## Internet:
...
- **Behoben** keine Internetverbindung nach Update auf FRITZ!OS 8.00 bei fehlendem Kennwort in den Zugangsdaten

Ein Update auf Version 8.02 könnte das Problem also beseitigen. Müsste man sich jetzt halt über einen anderen Internetzugang von https://ftp.avm.de/fritzbox/ herunterladen und in der FRITZ!Box als Datei einspielen.

Zitat von geckoespresso

9.|-- 2a00:6020:0:1d::2

Na, immerhin kommt man ja schon mal in das DG-Netz (2a00:6020::/32), erst danach wird's "dunkel". Es kann allerdings auch sein, dass alle folgenden Hops/Router in der DG-Infrastruktur dahingehend konfiguriert sind, nach dem Droppen der Traceroute-Pakete keine ICMPv6-time-exceeded Messages zurückzuschicken.

Bei mehreren Fällen der letzten Zeit mit IPv6-Problemen am DG-Anschluss ist mir folgende Gemeinsamkeit aufgefallen:

• Alle PD-LAN-Präfixe liegen im Bereich 2a00:6020:7000::/36.
• Etwas genauer: 2 Fälle im Bereich 2a00:6020:7380::/41, der aktuelle Fall des OP im Bereich 2a00:6020:7680::/41
• Örtlich ist das (zumindest für den Bereich 2a00:6020:7380::/41) wohl im Umfeld Tübingen/Stuttgart.

Ich habe generelle Analysen im DG-Range 2a00:6020::/32 durchgeführt und bin dabei für die Sub-Ranges

• 2a00:6020:4000::/36
• 2a00:6020:5000::/36
• 2a00:6020:8000::/36
• 2a00:6020:a000::/36
• 2a00:6020:b000::/36
• 2a00:6020:d000::/36

zu folgender Systematik gekommen:

1. Jeder /36-Range wird in 2^5=32 /41-Ranges unterteilt.
2. Jeder /41-Range umfasst bis zu 2^15=32768 Kundenanschlüsse mit jeweils einem PD-LAN-Präfix der Größe /56. Die Kundenanschlüsse in einem /41-Range liegen hinter demselben BNG, dessen interne IPv6-Adresse in 2a00:6020:ffff:ffff::/112 liegt. Beispielweise hat man die folgenden Zuordnungen von /41-Ranges zu BNG-Adressen:
   2a00:6020:4000::/41 - 2a00:6020:ffff:ffff::19
   2a00:6020:4080::/41 - 2a00:6020:ffff:ffff::1a
   2a00:6020:4100::/41 - 2a00:6020:ffff:ffff::1b
   2a00:6020:4180::/41 - 2a00:6020:ffff:ffff::1c
   :
   2a00:6020:d280::/41 - 2a00:6020:ffff:ffff::6
3. Die WAN-IP-Adressen am Kunden-Router liegen für die oben gelisteten /36-Blöcke stets in 2a00:6020:1000::/48. Auch hier gibt es genauer Sub-Ranges für jeden /41- Block:
   2a00:6020:4000::/41 - 2a00:6020:1000:30::/112
   2a00:6020:4080::/41 - 2a00:6020:1000:31::/112
   2a00:6020:4100::/41 - 2a00:6020:1000:32::/112
   2a00:6020:4180::/41 - 2a00:6020:1000:33::/112
   :
   2a00:6020:d280::/41 - 2a00:6020:1000:1d::/112
   
   Es ist meistens sogar möglich, die vollständige WAN-Port-Adresse aus dem jeweiligen /112-Block algorithmisch aus dem /56-PD-LAN-Präfix zu bestimmen (ich habe allerdings auch Abweichungen von der folgenden Regel gefunden) - die letzten 4 Hexziffern der WAN-Port-Adresse ergeben sich aus den Hexziffern WXYZ im /56-PD-LAN-Präfix 2a00:6020:PQWX:YZ00::/56 (ggf. führende "0" ergänzen) durch Addition von 0x10, nachdem man zuvor, falls =0xWXYZ > 0x8000, noch 0x8000 abgezogen hat.
4. Der Block 2a00:6020:7000::/36 in den Problemfällen ist nun offenbar neu. Er wird vermutlich zwar auch in /41-Blöcke mit je bis zu 32768 Kundenanschlüssen eingeteilt, jedoch liegen die WAN-Port-Adressen hier nicht mehr in 2a00:6020:1000::/48, sondern nun im ersten /112-Subrange des jeweiligen /41-Blockes:
   2a00:6020:7380::/41 - 2a00:6020:7380::/112
   2a00:6020:7680::/41 - 2a00:6020:7680::/112
   
   Hier führt DG offenbar ein modifiziertes IPv6-Adress-Konzept ein. In sämtlichen Traceroutes zu Zielen in 2a00:6020:7000::/36, die ich durchgeführt habe, ist mir aufgefallen, dass ich keinen last hop im AS60294 oder AS8899 der DG sehe. Irgendwas scheint dort also noch schief zu laufen.

Zitat von DrFroeschle

vielen Dank für Ihre Nachricht. Ihnen steht bei Deutsche Glasfaser ein CGN Dualstack Lite Anschluss zur Verfügung.

Wäre mir neu, dass es sich bei DG um einen DS-Lite-Anschluss handelt. Aber könnte ja sein, dass das jetzt bei neueren Anschlüssen so ist? Dann müsste man in der FRITZ!Box mal eine DS-Lite-Konfiguration probieren.