Du hast aber sicherlich "Portweiterleitung aktiv halten alle" auf 30 Sekunden gesetzt?
das sagt mit nichts ... wofür sollte ich Portweiterleitungen brauchen? Ich habe auch keine IP-Telefone im LAN, nur DECT-Schnurlosteile
Beiträge von ::1
-
-
Da die Telefonie nur über IPv4 läuft
... also bei mit läuft sie über IPv6. Sehe ich in den Packet-Traces für SIP-Register, die meine Rufnummer der IPv6-WAN-Portadresse zuordnet. Und schmerzlich auch daran, dass nach Ablauf einer DHCPv6-Lease (soll bei DG gerüchteweise hin und wieder auftreten) die Telefonie nicht mehr geht.
-
Hier meine FRITZ!Box 7590 - Einstellungen, die bei mir (WAN-Port am ONT) funktionieren:
Internetanbieter: weitere Internetanbieter | Deutsche Glasfaser
IPv6-Unterstützung aktiv mit "Native IPv6-Anbindung verwenden" (DS-Lite _nicht_ aktiviert!) und "Globale Adresse automatisch aushandeln" ("DHCPv6 Rapid Commit verwenden" _nicht_ aktiviert).
Aber gut, das stundenlange Warten auf IPv4 und/oder IPv6 von deren "zickigen" DHCP/DHCPv6-Server kenne ich auch (siehe hier).
-
Noch eine Idee:
Unter Heimnetz | Netzwerk | Netzwerkeinstellungen:
Ist für den WAN-Port der "PowerMode" (1GBit/s) aktiviert?
-
Kaum zu glauben, aber wahr, ich hatte gestern die gleichen Meldungen im Log:
Etwa 2,5h ohne IPv6. Wäre nett, das ebenfalls bei DG zu bemängeln. Damit ich nicht so als Einzelkämpfer dastehe.
-
Ok, dann hat sich der Verdacht erledigt. Dann liegt es meines Erachtens an der DHCP Infrastruktur.
Das sehe ich auch so, und ich meine, jeder Netzwerk-Spezialist, der sich mit Netzprotokollen auskennt und Paket-Mitschnitte lesen kann, sollte auch zu diesem Ergebnis kommen. Insofern danke für die Bestätigung hier im Forum!
-
Unsere Erfahrung mit 3 Business-Anschlüssen, die zuerst auch fehleranfällig waren, haben gezeigt, dass der Support so gut wie nichts kann und man den Punkt erreichen muß, an dem sich ein wirklich technisch versierter MA, der auch meistens nicht im Support angesiedelt ist, des Problems annimmt.
Das ist auch meine Intention - in meinen Anfragen bitte ich jedes Mal freundlich erneut darum, die Analyse zum 2nd-Level-Support weiterzuleiten. Vielleicht klappt's ja irgendwann.
-
Aber richtig ist, dass die alle 30 Minuten stattfinden. Bei DHCPv6 sind es alle 18,75 Minuten (1125 Sekunden, halbe Preferred Lifetime).
Hier die T1/T2-Werte für DHCPv6 und DHCPv4, die ich erhalte:
-
Du schreibst in deinem einen Dokument, dass du ein DHCP-Offer für 10.124.1.24 bekommen hast. Das ist ja das völlig falsche Netz. Aus dem 10er Netz bekommen diejenigen eine IP, die im GPON Onboarding Prozess sind und den Aktivierungscode benutzen wollen. Bist du sicher, dass deine physikalische GPON Verbindung stabil stand zu dem Zeitpunkt?
Sorry, das war ein Schreibfehler meinerseits: Richtig ist die Adresse 100.124.1.24. Werde das PDF gleich gegen eine korrigierte Fassung austauschen. Da zu dem Zeitpunkt parallel IPv6-Kommunikation stattfand, bin ich mir auch sicher, dass meine physische GPON-Verbindung stabil stand.
-
DHCP ist meiner Meinung nach bei der Deutschen Glasfaser eine Baustelle. Vielleicht arbeitet gerade mal jemand daran.
Kann ich nur bestätigen! Siehe meine bezügliche Problembeschreibung im angehängten PDF. Bei Bedarf kann ich gerne auch noch die PacketTrace-Dateien (pcap), sowie FritzBox-Eventlog ergänzen. Und das war jetzt bereits das dritte Mal (so alle 2-3 Monate), dass ich stundenlang ohne IPv4- und/oder IPv6-Adressen dastand.
Habe das am 01.10.2022 an die DG per Mail geschickt. Antwort vom 03.10.2022:
"Unsere technische Abteilung hat Ihren Anschluss überprüft und konnte keine Unstimmigkeiten feststellen. Da Sie einen eigenen Router nutzen und wir auf diesen keine Übersicht haben, wenden Sie sich bitte an den Hersteller des Routers."
Diese Antwort war natürlich nicht akzeptabel. Auf meine weiteren Versuche am 03.10. und 18.10 erhielt ich bisher keine Antwort - die stellen sich taub.
Btw: Die Leasedauer ist für beide Protokolle jeweils eine Stunde. Die halbstündigen Renews (nach T1) werden im Eventlog der Fritzbox merkwürdigerweise für IPv6 gar nicht angezeigt und für IPv4 nur alle 12 - 12,5 Stunden.
Ergänzung: Ich denke, das Problem ist PLZ-unabhängig. Mein PLZ-Bereich ist 906xx.
Ergänzung2: Habe auch noch das EventLog der Fritzbox angehängt, das deren Kampf um IPv4- bzw. IPv6-Adressen widerspiegelt
-
Also ich finde es schon auffällig, dass die erreichte Geschwindigkeit in der "schnelleren" Richtung statt des erwarteten theoretischen Werts von 100 MBit/s praktisch nur den Maximalwert von 40 MBit/s erreicht, der exakt dem theoretischen und praktisch ermittelten Maximalwert in der "langsamen" Richtung entspricht. So, als gäbe es da eine Symmetrie-Bedingung, die für beide Richtungen nur den kleineren der beiden richtungsabhängigen Werte aushandelt.
Allerdings finde ich in der Wireguard-Protokoll-Spezifikation (Link, ziemlich schwere Kost) keinerlei Hinweise auf so eine symmetrische Geschwindigkeitsaushandlung - das wäre für ein VPN-Protokoll wohl auch recht ungewöhnlich.
Natürlich könnten die RASPIs auch gerade ihr Limit bei 40 MBit/s erreicht haben, aber das wäre natürlich auch ein merkwürdiger Zufall, dass das gerade der Upload-Geschwindigkeit in der langsameren Richtung entspricht.
Dann noch ein Frage:
UDP/IP-Transport zwischen den RASPIs ist offenbar IPv4. Will heißen, dass wegen CGNAT am DG-Anschluss nur der RASPI am DG-Anschluss die Verbindung zum RASPI am Telekom-Anschluss aufbauen kann. Anderseits bietet ein Telekom-Anschluss auch IPv6. Eventuell könnte man das ja dort aktivieren, um mal eine Transport-Verbindung zwischen des beiden RASPIs mit IPv6 (mit getunneltem IPv4) zu testen? Vielleicht macht das ja einen Unterschied.
-
Zum Beispiel hier
Hm, was soll ich von einer IPv6-Testseite halten, die mir folgendes Ergebnis liefert?
Dann muss ich dort wohl mit IPv5 zugegriffen haben.
Man muss da öfter mal den Retry-Knopf pro Testsektion drücken, um etwas anderes zu sehen zu bekommen - und auch da können die Ergebnisse vom vorhergehenden Versuch abweichen. Mir scheint, die Seite hat erhebliche Ressourcen-Probleme - alles sehr zäh bis gar nicht (Ping- und Speed-Test) funktionierend.
Ich würde eher diese IPv6-Testseite empfehlen: https://test-ipv6.com/
-
Also, zur Abwechslung mal was Positives zum DG-Service:
In der neuesten Version des Kunden-Portals findet man jetzt unter "Mein Postfach" | "Meine Anfragen" eine Liste der Kontakte mit dem Service (über alle Eingangskanäle: E-Mail, Telefon, ...) mit Angabe der Bearbeitungsnummer und im Falle "E-Mail" auch mit Auflistung der ausgetauschten Mail-Inhalte.
Sehr gut!
Ebenfalls positiv zu erwähnen: Bei allen telefonischen Anfragen war die Erreichbarkeit stets hervorragend - kein ewiges Verweilen in einer Warteschlange!
Eine Kritik hätte ich dennoch (und die habe ich auch schon mehrfach gegenüber dem DG-Service geäußert): Die Fälle werden gerne vorzeitig geschlossen, auch wenn die damit verbundenen Probleme noch nicht gelöst sind. Meldet man sich erneut per Mail zu dem Problem, wird selbst dann eine neue Bearbeitungsnummer vergeben, wenn man im Betreff als Referenz die erstmalig vergebene Bearbeitungsnummer angibt. Das schafft aus Kundensicht Verdruss und stiftet Verwirrung, weil der Zusammenhang bzw. Bezug zum Ausgangsproblem verloren geht. Es sollte nicht mein Job als Kunde sein, den Zusammenhang durch Aufsammeln und Benennen aller Bearbeitungsnummern herstellen zu müssen. Da sehe ich noch deutlichen Verbesserungsbedarf im Fall-Management.
-
Nein, wer hätte es gedacht: Ab heute funktioniert das Kundenportal wieder wie es soll
.Gleich mal meine zweite Rufnummer dem 2. SIP-Account zugeordnet.
Auch wenn das jetzt keine Glanzparade von euch war, liebe DG, trotzdem vielen Dank!
-
Ich brauche das Kundenportal eigentlich nur, um meine Rechnungen abzurufen (was immerhin noch funktioniert), ansonsten nur einmalig, um endlich wieder meine zweite Rufnummer dem zweiten SIP-Account ("2. Telefonleitung") zuzuordnen. Das ist aus mir unerfindlichen Gründen auf den Default (beide Rufnummern auf dem 1. SIP-Account) zurückgesetzt worden. Die Kosten von 1,50 €/Monat für den 2. SIP-Account hat man mir immerhin für 3 Monate gutgeschrieben, aber wenn diese Zeit um ist, werde ich das Feature eben kündigen, weil ich keine Lust mehr habe, weiterhin wertvolle Lebenszeit für das Problem zu verschwenden. Die Kundenzufriedenheit scheint DG da wohl nicht sonderlich wichtig zu sein.
Möglicherweise sind wir beide ja auch die einzigen von diesem Problem betroffenen Nutzer (mich wundert schon, dass sich da sonst niemand hier im Forum gemeldet hat), dann ist's aus deren Sicht vermutlich eh egal.
Viel mehr nervt mich, dass ich in den letzten 3 Monaten zweimal (so im Abstand alle paar Wochen) Spaß und Kurzweil hatte mit DHCPv4- und DHCPv6-Leases, die nicht verlängert wurden - kann man schön in Packet-Traces am WAN-Port meiner Fritzbox 7590 mitschneiden: Wenn nach T1 kein Renew erfolgt, wird man schon nervös, ob denn bei T2 wenigstens noch ein Rebind erfolgt. Und wenn die Verbindung erst mal weg ist, wird der Abstand der DHCP-Solicits bei Nichtbeantwortung ja stets verdoppelt, so dass Stunden vergehen können, bis endlich mal wieder was kommt (kürzlich vergingen 5 Stunden, bis ich endlich wieder IPv6-Adressen bekam). Die Schaltfläche "Neu verbinden" wird so zum Angstknopf, den man ungern drückt, wenn man Internet für's Home-Office dringend braucht.
Bei Anruf beim Support bekommt man dann gesagt, dass es am Router liegt, und da das nicht deren Mietrouter ist, lassen sie einen im Regen stehen. Router-Reset hilft manchmal, möglicherweise aber nur, weil man deren DHCP-Server dann mit einer neuen XID zur Mitarbeit motivieren kann, wenigstens für eines der beiden Protokolle IPv4 bzw. IPv6.
Liebe DG: So geht das nicht! Ob ich nach Ablauf der ersten 2 Jahre noch euer Kunde bin, kann ich nicht versprechen.
-
Man muss das als Akt erzwungener Kundenbindung deuten: Das Kündigungsformular (Service | Kündigung) wird mit einem "Bad request" quittiert ...
-
in denen seit 2012 bei Neuanschaffung von Hardware IPv6-Unterstützung zum Pflichtkatalog gehört.
Lach - das habe ich in der Firma (und das ist keine kleine Klitsche), in der ich arbeite und u.a. für IPv6-Einführung zuständig bin, auch mal versucht. In einem Testballon hatten wir Drucker-Herstellern (IPv6-technisch kein großer Anspruch - es müssen ja lediglich Endgeräte-Features unterstützt werden) unseren IPv6-Anforderungskatalog geschickt. Oje - die konnten so gar nichts damit anfangen (was ist SLAAC?) - was da zurück kam, war nur peinlich.
Außerdem, was soll denn genau "IPv6-Unterstützung" sein? Nach welchem Kriterien-Katalog (das hier ist noch das beste, was es da gibt - hingegen ist das hier ziemlicher Müll, wird aber von einigen Herstellern gerne genutzt, um sich mit IPv6-Unterstützung zu schmücken - die bieten dann z.B. IPv6-Internet-Zugangsrouter für SOHO ohne IPv6-Firewallfunktion an)? Welcher Gerätetyp soll genau was können aus dem Zoo von Hunderten IPv6-RFCs, wobei in manchen Fällen je nach Gerät/HW auch nicht der Gesamt-Umfang eines bestimmten RFC erfüllt sein muss? Nachdem meine selbst erarbeitete Excel-Tapete, die Geräte-Typen gegen IPv6-RFCs und RFC-sub-features mit MUST, SHOULD, MAY aufgelisted hat, gefühlt unendlich groß geworden ist, habe ich sie weggeschmissen.
Und hier noch ein Beispiel aus der Praxis: L3-Switch eines namhaften Herstellers verspricht IPv6-Unterstützung - schön, haben wir also eine zukunftsfähige Hardware gekauft! Aber ach: Jetzt haben wir darauf VRF eingerichtet und stellen fest: Bestimmte Features innerhalb eines VRF stehen nur für IPv4 zur Verfügung, nicht aber für IPv6 - das kann das Modell für IPv6 nur im globalen Routing-Kontext. Vielen Dank, lieber Hersteller, wie fühlen uns veralbert!
-
Wäre ein gangbarer Weg die Fritzbox in das 10er-Netz aufzunehmen und den Lancom dann einfach so daran zu hängen?
Also wenn der Lancom weiterhin noch eine Funktion haben soll, die die Fritzbox nicht übernehmen kann, dann macht das keinen Sinn. Andernfalls könnte man die Lancom-Box auch gleich ganz weglassen.
Wenn man also alles so lässt wie es ist, sehe ich zwei Lösungsmöglichkeiten, die oben schon beschrieben sind:
- Du benutzt die bestehende Fritz-Fritz-VPN-Kopplung via IPv4 zu deinem Heimnetz - die funktioniert ja, wie du sagst (wobei nur die Firmen-Fritzbox die Verbindung zur Heim-Fritzbox aufbauen kann, nicht umgekehrt - CGNAT ist da wie eine Diode). Damit kommst du dann von zu Hause aus aber nur in das 192.168-Zwischennetz, nicht jedoch in das 10er-Netz der Firma. Du könntest nun in der Lancom-Box z.B. ein 1:1 NAT einrichten (pro 10er-Adresse eines Dienstes im Firmen-Netz, den du erreichen möchtest, eine 192.168-Adresse aus dem Zwischennetz) und die Lancom Firewall einkommend entsprechend aufmachen. Oder du richtest im Lancom für die IPv4-WAN-Adresse aus dem Zwischennetz Portweiterleitungen zu Diensten im 10er-Netz ein, die du erreichen willst, z.B. für den Zugriff auf einen WTS per RDP (3389\udp) - so einen WTS könntest du dann ja als Sprungserver ins Firmen-Netz verwenden.
- Du verwendest in deinem Heimnetz an einem Desktop-PC einen geeigneten VPN-Client, der via IPv6 (muss in deinem Heimnetz und am dortigen Internetzugang natürlich vorhanden sein) eine VPN-Verbindung zur IPv6-Adresse des WAN-Ports des Lancom aufbaut. Im VPN-Tunnel muss dann IPv4 gesprochen werden. Damit kommst du direkt im 10er-Firmennetz raus. Du brauchst für den WAN-Port des Lancom noch DynDNS, da dessen IPv6-Adresse aus einem /56-Pool kommt, der sich potentiell ändern kann. Dein VPN-Client muss die Gegenstelle dann über den FQDN ansprechen, nicht direkt über die IPv6-Adresse.
-
Bei mir geht's nach wie vor nicht. Hat sich bei Dir etwas getan?
Nein.
Aber "die Experten dort arbeiten ja mit Hochdruck an einer Lösung"
Da können wir uns doch entspannt zurück lehnen.
-
Ja, so eine Nachricht, offenbar basierend auf einem Textbaustein, habe ich auch bekommen. Allerdings erst nach mehreren Anläufen am 06.07.2022, obwohl ich das Problem bereits mit einer sehr genauen Beschreibung am 11.06.2022 gemeldet hatte.
Was ich dabei ärgerlich finde: Wenn sie es doch wissen (und es doch sicherlich auch am 11.06. schon wussten) - wieso schicken sie dann nicht gleich diese Info raus?
"... und probieren Sie im Verlaufe der Tage nochmal" - Welches Wort passt hier wohl nicht?
Ich frage mich, was man bei DG für interne Schwierigkeiten hat, so ein Problem zeitnah zu lösen.
EDIT
Ich muss mich korrigieren: Wie ich eingangs schon geschrieben hatte, wurde ich doch schon am 20.06.2022 informiert dass ...
"Gerne habe ich Ihr Anliegen überprüft und muss Ihnen mitteilen, dass ein paar technische Herausforderungen mit unserem Kundenportal aufgetreten sind. Unser Expertenteam arbeitet schon intensiv daran, dies zu beheben." (Aber auch hier passt ein Wort nicht so recht ...)
Das liegt jetzt doch im Rahmen. Die zweite Nachricht vom 06.07.2022 war nur eine erneute Bestätigung, weil ich ungeduldigerweise nochmals nachgefragt hatte.
/EDIT
