Beiträge von ::1

Zitat von HubeBube

Ein DG Mietrouter konfiguriert via TR069/TR369 die Telefonie. Es ist sogar abträglich für die Stabilität die portierten Rufnummern manuell zu konfigurieren. Wie das mit zusätzlichen Rufnummern von anderen SIP/VoIP-Providern bei Mietroutern von DG gehandhabt wird, weiss ich nicht.

Unabhängig davon müssten doch aber die DG-Rufnummern in der Fritzbox unter "Telefonie | Eigene Rufnummern" mit dem Status "grün" angezeigt werden, nachdem diese sich erfolgreich via SIP registriert haben.

UST Kannst du das bestätigen?

Zitat

Ich habe diese Umstellung vorgenommen.

Ja, und wird dir als aktuelle Geschwindigkeit des LAN-Adapters auch 1 GBit/s im System angezeigt?

Siehe unter: Einstellungen - Netzwerk und Internet - Ethernet - Aggregierte Verbindungsgeschwindigkeit: Hier sollte 1000/1000 (Mbps) angezeigt werden.

Welche Ergebnisse liefert nun ein erneuter Speedtest?

Also bei der Leistungsklasse deines Desktops hat er doch bestimmt eine Onboard-Netzkarte. Für die kannst du die Geschwindigkeit in den Eigenschaften des LAN-Treibers (Registerkarte "Erweitert" - Geräte-Manager unter z.B. "Speed&Duplex" oder ähnliches: Dort würde ich fest "1.0 Gbps Full Duplex" einstellen) einstellen.

Zitat von UST

Kannst du die Stelle zitieren, aus der für dich ersichtlich ist, dass wir eine 2. Internetverbindung für die Telefonie eingerichtet haben?

Wie von mir schon erwähnt, kann man das deiner FB-Ereignisanzeige ("Internetverbindung (Telefonie)") entnehmen.

Zitat von UST

Meinst die Probleme kommen daher, dass die Endgeräte die mögliche Leistung des Anschlusses nicht verarbeiten können?

Exakt! Und man/ich weiß auch nicht, ob dein WLAN über 100 MBit/s kommt.

Stelle also erst Mal sicher, von einem LAN-PC mit GBit-Ethernetadapter zu messen und prüfe für den LAN-Port an der Fritzbox, an dem dieser Rechner hängt, ober er sich im "Power Mode" (und nicht etwa im "Green Mode") befindet.

Zitat von UST

aber deshalb sollte die Leiung ja trotzdem funktionieren. Eine Erklärung für die Telefonieproblematik wäre das jedenfalls nicht.

Ja, deine permanenten Internetverbindungsabbrüche sind nebulös - aber sie treten lt. der gezeigten Ereignisanzeige immer zeitgleich für Internetverbindung (=IPv4), Internetverbindung IPv6 und Internetverbindung (Telefonie) (=IPv4) auf, was für keine Einzelursachen bezogen auf die jeweiligen Verbindungen schließen lässt (etwa DHCP- oder DHCPv6-Lease-Timeouts). Es muss da eine gemeinsame protokoll- bzw. VLAN-unabhängige (Trennung von Internet und Telefonie bei Mietrouter per VLAN) Ursache geben, die es gilt herauszufinden.

Es wäre interessant zu ermitteln, ob dein Router die Internetverbindungen abbricht, oder ob diese durch die Gegenstelle abgebrochen wird. Darüber gibt die Ereignisanzeige der FB aber leider keine Auskunft. Es würde da ein Paketmitschnitt am WAN-Port der FB helfen, das wäre allerdings technisch herausfordernd ...

Zitat von pufferueberlauf

aber fuehrt zu eigenartigen Subthreads, so wie hier wo er nicht mal darlegt wie er zu der Ueberzeugung gekommen ist, dass "Du [...] eine zweite Internetverbindung für die Telefonie eingerichtet [hast]".

Ich möchte ihn nicht verteidigen, aber das kann man der gezeigten Fritzbox-Ereignisanzeige entnehmen - aus der hätte ich jetzt auch auf einen Mietrouter geschlossen.

Zitat von UST

im Anhang ein aktueller Speedtest direkt über die Fritzbox.

Das ist nicht "direkt über die Fritzbox", sondern von dem PC aus, an dem du sitzt.

Zitat von UST

Leider kann ich mit meinem Rechner noch keine Serieenmessung per Breitband für einen Bericht an die Bundesnetzagentur machen, da ich erst meine Ethernetschnittstelle aufrüsten muss, damit sie auch die volle Bandbreite verarbeiten könnte, falls sie denn ankäme. Aktuell gehen rechnerseitig nur 100 Mbits, aber die Leitung liefert ja zur Zeit sogar noch weniger.

Ähm, das heißt, alle Messungen, die du bisher gezeigt hast, wurden mit diesem PC erstellt, der per LAN-Adapter nur 100 MBit/s hergibt?

Zitat von UST

Seit letztem Sonntag (31.08.25) haben wir aber nun das Problem, dass die Leistung der Internetleitung sehr massive Schwankungen zeigt. Wenn man Seiten aufruft, laden sie entweder schnell, sehr langsam oder es kommt die Meldung, dass die Seite nicht erreichbar sei. Kurze Zeit später, ist die Seite sofort zu erreichen, hängt aber dann evtl. später wieder.

So was in der Art könnte auftreten, wenn sowohl IPv4, als auch IPv6 konfiguriert ist, WAN-seitig aber plötzlich (eben seit 31.08.25) IPv6 nicht mehr funktioniert (sowas soll bei DG ja hin und wieder auftreten ...).

UST :

Hast du in deinem LAN beide Protokolle (IPv4 und IPv6) aktiv?

Das kannst du z.B. an einem Windows-PC in deinem LAN durch Eingabe des Kommandos ipconfig herausfinden:

C:\>ipconfig

Windows-IP-Konfiguration


Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix: fritz.box
   IPv6-Adresse. . . . . . . . . . . : 2a00:6020:XXXX:XX00:YYYY:YYff:fed7:ac6f
   IPv6-Adresse. . . . . . . . . . . : fdXX:XXXX:XXXX:0:YYYY:YYff:fed7:ac6f
   Temporäre IPv6-Adresse. . . . . . : 2a00:6020:XXXX:XX00:e87d:8c25:6308:8e12
   Temporäre IPv6-Adresse. . . . . . : fdXX:XXXX:XXXX:0:e87d:8c25:6308:8e12
   Verbindungslokale IPv6-Adresse  . : fe80::YYYY:YYff:fed7:ac6f%10
   IPv4-Adresse  . . . . . . . . . . : 192.168.178.10
   Subnetzmaske  . . . . . . . . . . : 255.255.255.224
   Standardgateway . . . . . . . . . : fe80::ZZZZ:ZZff:feZZ:ZZZZ%10
                                       192.168.178.1

Wenn hier sowohl eine IPv4-Adresse, als auch eine oder mehrere IPv6-Adressen (die mit 2a00:6020 beginnen) angezeigt werden, dann führe bitte mal folgende Kommandos aus:

C:\>ping -4 google.com

Ping wird ausgeführt für google.com [142.250.185.206] mit 32 Bytes Daten:
Antwort von 142.250.185.206: Bytes=32 Zeit=7ms TTL=118
Antwort von 142.250.185.206: Bytes=32 Zeit=6ms TTL=118
Antwort von 142.250.185.206: Bytes=32 Zeit=5ms TTL=118
Antwort von 142.250.185.206: Bytes=32 Zeit=6ms TTL=118

Ping-Statistik für 142.250.185.206:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 5ms, Maximum = 7ms, Mittelwert = 6ms

C:\>ping -6 google.com

Ping wird ausgeführt für google.com [2a00:1450:4001:812::200e] mit 32 Bytes Daten:
Antwort von 2a00:1450:4001:812::200e: Zeit=8ms
Antwort von 2a00:1450:4001:812::200e: Zeit=5ms
Antwort von 2a00:1450:4001:812::200e: Zeit=5ms
Antwort von 2a00:1450:4001:812::200e: Zeit=6ms

Ping-Statistik für 2a00:1450:4001:812::200e:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 5ms, Maximum = 8ms, Mittelwert = 6ms

Die Ergebnisse beider Kommandos sollten so sein, wie hier gezeigt. Falls ggf. IPv6 nicht funktioniert, wie eingangs evtl. vermutet, müsse der zweite Befehl ping -6 google.com statt der 4 Ping-Antworten Fehlermeldungen generieren.

Zitat von UST

Die Telefon/DECT-Leuchte an der Fritzbox leuchtet nur, wenn man telefoniert (angerufen wurde) oder versucht ausgehend anzurufen. Legt man auf, erlischt die Leuchte wieder.

Das ist normal und kein Fehler. Das Leuchten der LED signalisiert ein gerade stattfindendes Telefongespräch.

Was für ein Glasfaser-Tarif wurde denn gebucht?
Die gezeigten Messungen würden für einen DG-basic-Tarif sprechen (100/50).

Die LAN-LED meines Nokia-ONT (G-010G-Q) flackert auch, d.h. sie weist Helligkeits-Schwankungen auf, ist aber niemals dunkel/aus. Ich denke mal, diese Art des Flackerns repräsentiert Datenübertragungs-Aktivität. Ich habe keinerlei Probleme mit meinem DG-Anschluss

Laut https://www.router-faq.de/?id=fb&fb=fbdate wurde die Fritzbox am 20.04.2022 hergestellt:

Ein defektes 2,4GHz-WLAN (Link) ist somit relativ unwahrscheinlich.

Zitat von topas-rec

Es scheint, als würde eine Änderung (auf LLT?) der DUID die RA erneut starten lassen.

Dass die DG-Gegenstelle (das BNG) erst dann valide RA sendet (unabhängig von der DUID-Thematik), nachdem per DHCPv6 IPv6-Adressen zugewiesen wurden, ist gegen alle Standards. Da wundert es nicht, dass so manche regelkonform arbeitenden Kundenrouter scheitern, eine IPv6-Verbindung zu DG herzustellen (nämlich alle die, die erst brav bis Sankt Nimmerlein auf RA warten, bevor sie (dadurch instruiert) eine IPv6-Adresse für das WAN-Interface per DHCPv6 anfordern).

Zitat von topas-rec

Stellt ihr DHCP ein, oder wartet ihr auf die RA und dann passiert die DHCP Abfrage automatisch (weil das managed Bit gesetzt ist)?

Das ist genau die Kernfrage!

Laut Theorie sollte eine IPv6-Initialisierung eines Netz-Interfaces in etwa so erfolgen:

• Es wird zunächst eine linklokale IPv6-Adresse (fe80...) generiert: fe80::[IID]/64. Für die Generierung einer Interface-ID [IID] gibt es mehrere Varianten, die älteste lautet "modified EUI64". Es folgt noch eine DAA (duplicate address detection) für diese Adresse.
• Falls das Interface statisch mit einer globalen IPv6-Adresse und einem Standard-Gateway versehen ist, erfolgt auch für die globale IPv6-Adresse eine DAA. Der Prozess ist hier dann aber (im Gegensatz zu einer statischen IPv4-Konfiguration) nicht zu Ende (IPv6-Adressierungsverfahren sind additiv!):
• Das Interface sendet in kurzer Abfolge mehrere RS (Router Solicitation). Kommen keine RA-Antworten (kein Router im angeschlossenen Netz oder Router ist nicht für das Senden von RA konfiguriert), ist der Vorgang hier zu Ende.
• Andernfalls werden erhaltene RA (solicited als Antworten auf RS, oder unsolicited - sendet der Router periodisch in gewissen Zeitabständen) ausgewertet:
• Je nach Inhalt des RA (M-Flag, O-Flag, enthaltene PIO mit L-Flag und A-Flag) entscheidet sich, ob, und wenn ja, wie weitere globale IPv6-Adressen (zusätzlich!) generiert werden. Da gibt es jetzt viele Varianten. Ich erwähne hier nur die DG-Variante:
• DG-RA:
  
  Es ist das M-Flag gesetzt (was implizit auch O=1 bedeutet, auch wenn das O-Flag nicht explizit gesetzt ist): Heißt: Frag per DHCPv6 nach einer IPv6-Host-Adresse (.../128!) und nach weiteren DHCPv6-Optionen (hier die IPv6-DNS-Resolver-Adressen).
  
  Es ist keine PIO enthalten: Es wird kein LAN-Präfix für den WAN-Link (d.h. hier: keine Präfix-Länge) passend zur DHCPv6-Adresse mitgegeben. Das WAN-Interface hat somit nur eine IPv6-Hostadresse .../128 (was in einer Fritzbox z.B. falsch als .../64 dargestellt wird).
  
  Die Router-Lifetime ist >0 (z.B. 1800s): Das bedeutet: Verwende die linklokale Quell-Adresse des RA (diese werden immer von der linklokalen Adresse des Routers gesendet) als IPv6-Standardgateway.

In der Praxis verhalten sich die IPv6-Implementierungen allerdings häufig nicht standardkonform: Eine Fritzbox versucht z.B. bereits auch dann eine dynamische Konfiguration per DHCPv6, wenn sie noch gar kein RA erhalten hat, das sie (per gesetztem M-Flag) dazu angewiesen hätte. Auch Windows hat da so seine Eigenheiten.

Zitat von topas-rec

Meine Router Software (NetworkManager) nimmt aber keine RA an, wenn die Verbindung auf DHCP steht.

Das wäre allerdings nicht standard-konform: Bei einer dynamischen Interface-Konfiguration per DHCPv6 müssen auch RA angenommen werden, denn das wäre die einzige Möglichkeit, dem Interface ein IPv6-Standardgateway und ggf. per PIO-Option (ohne gesetztes A-Flag) eine Prefix-Länge mitzuteilen. Für diese beiden Werte gibt es bei DHCPv6 (im Gegensatz zu DHCPv4) keine entsprechenden Optionen: Sie müssen aus RA gelernt werden, DHCPv6 vergibt nur IPv6-Host-Adressen (=/128).

Zitat von topas-rec

Nachdem ich alles wieder zurückgebaut hatte (zurück von DHCP auf SLAAC und von DUID-LLT auf NetworkManager-Standard DUID Einstellung) und den Router neu gestartet habe, lief die Verbindung auch wieder mit SLAAC (inklusive Präfix-Auslieferung).

Verstehe ich das richtig (?):

Dein Router am DG-Anschluss benutzt für die Konfiguration einer WAN-Port-Adresse SLAAC? Und dein Präfix für das LAN fordert er per DHCPv6-PD (IA_PD) an? Ich wusste bisher nicht, dass DG für die WAN-Port-Konfiguration überhaupt SLAAC unterstützt. Das widerspräche auch den Informationen, die DG in einem RA sendet: Dort steht das M-Flag auf 1 (=heißt: mach bitte DHCPv6), und es enthält auch keine PIO-Option, aus der dein Router per SLAAC eine globale IPv6-Adresse generieren könnte.

Oder ist es so, dass dein Router gar keine globale WAN-Port-IPv6-Adresse hat, sondern dort nur über eine link-lokale fe80-Adresse verfügt? Das wäre ja auch denkbar. Globale IPv6-Adressen hättest du dann nur auf der LAN-Seite, und wenn dein Router selbst ins Internet spricht, verwendet er seine LAN-Adresse als Source.

Zitat von kammann

Um mal wieder auf die Störung bei der DG zurückzukommen: Wo macht denn eigentlich die DG ihr CGNAT für IPv4? Ist das immer noch zentral in Frankfurt und Düsseldorf für alle DG Kunden in ganz Deutschland? Bei der Telekom ist das dezentral über ganz Deutschland verteilt. Mein DG Anschluss im südlichen Bayern wird über die (interne) DG-IP 100.124.1.24 (1. Hop nach dem Router) geroutet. Habt ihr aus anderen Regionen andere Adressen?

Die Adressen aus 100.64.0.0/10 (100.64.0.0 - 100.127.255.255) sind ja nicht öffentlich, sondern "IPv4 shared address space". Der nächste Hop nach deinem Router (bei dir 100.124.1.24, bei mir: 100.124.1.26 - Raum Nürnberg/Fürth) müsste das BNG sein, an dem dein Anschluss hängt. Ob das BNG selbst bereits (dezentral) CGNAT durchführt (ich vermute es), ist anhand der Traceroutes leider nicht zu erkennen. Es könnte auch einer der beiden nächsten Hops sein, von denen man im Traceroute nur "Zeitüberschreitungen" sieht - ich gehe davon aus, dass diese Hops noch zur DG-Infrastruktur gehören.

Zitat von HubeBube

und einer ASA (gibt es die überhaupt noch bzw. noch Support?)

ASA lebt als "Cisco Secure Firewall" weiter - ist einfach nicht tot zu kriegen.

Zitat von HubeBube

mit Microsoft Direct Access gab es keine Probleme

Soweit ich mich mal damit befasst und es hoffentlich einigermaßen richtig verstanden habe (es gab dazu mal Vorträge auf einem der "IPv6-Kongresse" in Frankfurt, die der Heise-Verlag so zwischen 2008 und 2014 veranstaltet hat), baut MS-DA extrem stark auf IPv6-Tansition-Technologien auf. Bei reinen IPv4- oder IPv6-Szenarien sah es mit MS-DA dann recht mau aus. Ist mein Eindruck richtig?

Zitat von HubeBube

Ich sehe in den Logs/Ereignissen meiner Glasfaserfritze an der Faser nichts, was auf einen Ausfall hindeutet. Noch nicht einmal ein neues Lease in dem erwähnten Zeitraum.

Ist bei meiner Fritze auch so - die Störung lag folglich ausschließlich innerhalb der DG-Infrastruktur. Die IPv4-DNS-Resolver der DG waren bspw. erreichbar.

Zitat von user

wenn man sich auf https://stat.ripe.net/resource/AS60294#tab=measurements wahllos Probes anschaut, wird es eine deutschlandweite(?) Störung gewesen sein.

Hinweis: Bezüglich IPv4 laufen viele Probes an DG-Anschlüssen im AS8899. Nur bzgl. IPv6 liegen sie (bisher) stets im AS60294.

Zitat von HubeBube

Hm, egal ob DS-Lite, DS mit oder ohne CGNAT, keine Remote Dial-In/VPN Lösung sollte damit ein technisches Problem haben.

Da habe ich gegenteilige Erfahrungen aus früheren Zeiten: Da gab es mit einem IPsec-VPN-Client via IPv4 (+CGNAT) Verbindungsabbrüche.

Ich habe es mir so erklärt:

Mit NAT (am Heimrouter) und CGNAT (beim ISP) muss IPsec mit "NAT-Traversal", also ESP/UDP/IPv4 bzw. IKE/UDP:4500 arbeiten. Dazu müssen aber die Timeouts der UDP-NAT-Sessions im heimischen NAT-Router bzw. im CGNAT beim ISP länger sein, als die Zeitintervalle zwischen zwei Keep-Alives, die die VPN-Peers untereinander senden, um die ESP-SAs am Leben zu erhalten. Auf die UDP-Session-Timeouts am CGNAT habe ich aber keinen Einfluss. Vermutlich ist die UDP-Sessiondauer am CGNAT im Vergleich zum Zeitintervall zwischen zwei Keep-Alives kürzer gewesen ...