Beiträge von frank_m

Das sieht wirklich anders aus. Vielleicht wären die Details der Paketeinhalte hilfreich.

Was man sieht: Bei dir redet die Infrastruktur auf IPv6, das ist ansonsten im Thread anders. Man sieht, dass dein Endgerät ein Solicit losschickt und ein Reply vom Server bekommt, offenbar auch mit Adresse. Das ist für Rapid Commit normal. 25 Sekunden später schickt dein Gerät ein Release, was auch bestätigt wird, um 17 Sekunden später wieder ein Solicit zu senden. Die IPv6 Adresse wird also von deiner Seite aus verworfen.

Man erkennt nicht, warum dein Gerät ein Release schickt. Vielleicht ist es mit der Antwort nicht glücklich. Das müsste man sich näher ansehen.

Was ist das für ein Endgerät? Unterstützt es Rapid Commit?

Zitat von maik6849

Natürlich ist das ganze trotzdem zu gebrauchen, wenn auch mit minimalen Nachteilen.

Die Nachteile können gravierend sein, wenn du dich durchs Forum liest:

• Langsame Downloadraten
• Langsame Uploadraten
• miese Sprachqualität bei Telefonaten, bis hin zu Verbindungsabbrüchen

Es macht schon Sinn, den Traffic Shaper richtig einzustellen.

Immer bedenken: Der Ausbaustatus wird anhand der "Homes passed" und nicht anhand der "Homes connected" Variable bemessen.

Ich würde zunächst mit der Fritzbox direkt am ONT testen. GANZ WICHTIG: Die Fritzbox muss vorher auf Werkseinstellungen zurückgesetzt werden. Der Wechsel von DSL zu Glasfaser bei gleicher Konfiguration funktioniert nicht.

Zitat von Antek

bei mir hat diese Einstellung an der Fritzbox geholfen

IPv6 mit Tunnelprotokoll verwenden aktivieren und dann Aktivierung des Tunnelkprotokolls 6to4

Das kann nicht sein. Für 6to4 braucht man eine öffentliche IPv4-Adresse, und die hat man bei der Deutschen Glasfaser nicht. Diese Einstellung macht garantiert alles nur schlimmer, dann besser IPv6 ganz deaktivieren.

Die richtigen Einstellungen für Deutsche Glasfaser sind immer noch: IPv6 aktivieren und dann "Native IPv4-Anbindung verwenden". Vor allem von Tunnel-Protokollen sollte man die Finger lassen, wenn man nicht exakt weiß, was man tut und was sie bewirken.

Das BGP Tool von HE spuckt sie auch aus.

Zitat von UST

Dabei ist mir bei den Ereignissen die Info im Anhang aufgefallen. Soll ich daraus schließen können, dass der Provider das Problem von außerhalb behoben hat, in dem er die Einstellungen der Fritzbox geändert hat?

Unwahrscheinlich. Der Beschreibung zufolge sind die Probleme eher auf der physikalischen Schicht zu suchen. Dafür kann der Provider keine Konfigurationsdaten in eine Fritzbox übertragen. Die Autokonfiguration betrifft eher Internet-Zugang und Telefonie.

Zitat von h4haase

- ONT (Genexis FiberTwist): beide LED grün dauerleuchtend.

Was ist denn das für ein Telekom-Anschluss mit einem Fibertwist? Das ist mehr als ungewöhnlich. Hast du das Onboarding dafür selber durchgeführt? Üblicherweise kommen andere GPON Modems an Telekom Anschlüssen zum Einsatz.

Die Verbindung zwischen Fritzbox und ONT funktioniert einwandfrei?

VLAN Einstellungen passen?

Und das Ding war immer dazwischen, auch wenn du mit anderen Routern getestet hast?

Vor allem wirft es ein neues Licht auf die Geschwindigkeitseinbrüche. Wie kommt denn die AON Faser in die UDM? Per SFP Modul? Wenn ja, welches?

Im Mobilfunk kommt aber kein PPP zum Einsatz. Die PPP Verbindungen, die man früher für Mobilfunkzugänge benutzt hat, existierten nur zwischen PC und Modem. Auf dem Mobilfunk-Link kommen andere Mechanismen zum Einsatz. Folglich kann man das Szenario nicht mit einer PPPOE Glasfaserverbindung vergleichen.

Ich bin bei ::1 in Beitrag #7. Die PPPOE Verbindung terminiert auf dem Bridge-Router, damit ist dort auch die IP. Wenn es kein Subnetz mit weiteren öffentlichen IPs gibt, sehe ich keine Möglichkeit, eine öffentliche IP an die UDM weiterzuleiten. Selbst wenn man irgendwie ein Konstrukt aus PPPOE Interface und LAN Interface in einer Bridge bauen würde, würde das am Ende nicht funktionieren, die IP ist immer noch auf dem Bridge Router.

Entweder kümmert man sich um die Performance-Probleme der UDM, oder man macht NAT auf dem Bridge Router und gibt die Verbindung per Exposed Host an die UDM. Warum funktioniert der Exposed Host bei euch nicht?

Sieht gut aus.

Zitat von xrandr

Ob es am Ende Verzögerung durch überlasteten oder unglücklich konfigurierten AFTR bei DS-Lite oder "reinen" NAT44-Service bei Dual-Stack mit privater IPv4 gibt ist vermutlich egal.

Wir haben hier im Forum schon beides gesehen. Das liegt dann weniger an der Technologie, die zum Einsatz kommt, als an der Bereitschaft des Providers, ausreichend Kapazitäten zur Verfügung zu stellen. Wobei man ggf. Störungen ausnehmen muss, wir hatten auch Fälle, da war es zwei Tage schlecht und dann wieder gut. Da ist vermutlich einfach was kaputt gegangen und musste repariert werden.

Zitat von xrandr

Was mich mal interessiert: Können sich CG-NAT-Kunden untereinander (bem selben Anbieter) per privater IPv4 erreichen; hat das mal jemand ausprobiert?

Genau, bei der DG geht das. Deshalb empfehle ich auch immer, trotz providerseitigem NAT die eigene Firewall nicht zu vernachlässigen und keine Harakiri Verkabelungen zu machen, wo LAN und WAN vermischt werden (z.B., um Status-Informationen eines Modems auszulesen). Die "Nachbarn" können einem nämlich trotzdem auf den Rechner schauen.

Die Frage ist, welchen Nachteil doppeltes NAT hat, zumal wenn man - wie bei DS-Lite - keinen Einfluss auf den NAT Router hat. Ja, man muss es auf dem Schirm haben, wenn man Dinge konfiguriert, aber am Ende hat es keine Nachteile gegenüber DS-Lite.

Bei DS-Lite sehe ich es eher kritisch, dass im Falle eines IPv6-Ausfalls die gesamte Internetverbindung weg ist. Bei CG-NAT hat man dann noch IPv4, und merkt im Zweifel nicht mal, dass IPv6 nicht funktioniert.

Wegen der DNS Server würde ich jetzt auch keinen Aufstand machen: Jede Störungsmeldung birgt ja auch das Risiko, dass Dinge verschlimmbessert werden, und es gibt nur wenige Dinge, die einfacher zu korrigieren sind, als ein DNS Server. Unter Berücksichtigung des eher fragwürdigen Vorgehens der CUII würde ich grundsätzlich keine DNS Server benutzen, die unter deren Einfluss stehen. Damit ist auch der EU Server raus.

Am besten ist ein lokaler Pi-Hole mit einem Unbound. Dann entscheidet man selber, welche Seiten geblockt werden.

Zitat von UST

Wenn diese MAC-Adresse nicht vom Provider freigegeben ist, wird das doch wohl auch nicht funktionieren oder?

Die MAC Adresse ist irrelevant. Der ONT muss bei der DG provisioniert werden, und wenn es sich dabei um ein von der DG freigegebenes Modell handelt, geht das einfach übers Online Onboarding. Anleitungen gibt es hier im Forum und im DG Kundenportal.

Zitat von xrandr

Das dürfte der neue, baugleiche ONT zu seinem jetzigen sein. Er hat aber einen "Miet-Router" und nicht "eigener Router" - geht das dann auch?

Würde ich erwarten. Einen Versuch ist es wert. Schief gehen kann ja nichts.

Zitat von UST

Ich habe in der Zwischenzeit ein neues Nokia Modem und einen Kabeltester gekauft und erhalten. Das Modem kann ich leider nicht benutzen, da dies wohl erst providerseitig freigegeben und integriert werden müsste.

Ist das ein ONT wie er auch von der DG eingesetzt wird? Dann sollte er sich übers Onboarding freischalten lassen.

Zitat von Schlammdackel

Jetzt läuft "IPv6-Anbindung mit Tunnelprotokoll verwenden" (6to4), mal sehen...

Das ist das Schlimmste, was du tun kannst. Stell es auf jeden Fall auf "Native IPv4-Anbindung verwenden" zurück.

Das sagt der richtige ...