Beiträge von frank_m

Zitat von BartBert

Nach Bestätigung war ich nach 5 Minuten online, IPv4 und IPv6. Mit der FB 5590 über WAN funktioniert es also wieder!

Dort solltest du nun nach 60 Minuten Wartezeit auch deinen TP-Link Router anschließen können!

Zitat von BartBert

Wenn ich jetzt den TP Link zum Laufen bekommen möchte, werde ich diesen vermutlich auch zuerst onboarden müssen, oder?

Nein. Man muss den Router nicht onboarden, sondern nur das Modem. Also entweder den Nokia ONT oder das SFP Modul der Fritzbox. Wenn nun der Nokia ONT aktiv ist, dann musst du für einen Router-Tausch lediglich die 60 Minuten Wartezeit beachten.

Dass es auf dem TP-Link keine IPv6 gibt, ist normal. Im Aktivierungsnetz werden keine IPv6 verteilt. Die einzige Adresse, die dort aufrufbar ist, ist http://activation.deutsche-glasfaser.de über das 10.x.y.z Netz. x, y und z unterschieden sich ja nach Anschlussbereich.

Um es einzugrenzen, müssen wir die Kette Schritt für Schritt durchgehen. Also würde ich noch mal die Fritzbox oder den TP-Link hinter dem Nokia ONT Anschließen. Dann brauchen wir folgende Infos:

• Welche WAN Adresse, Gateway und DNS Server hat der Router per DHCP bekommen? Wie sehen die WAN DNS Einstellungen im Router aus?
• Welches interne Netz benutzt er, was ist seine Adresse und was davon verteilt er per DHCP? Was verteilt er als DNS Server im LAN?
• Welche Adresse, Gateway und DNS-Server bekommt das Endgerät am Router?
• Was ergibt ein nslookup activation.deutsche-glasfaser.de auf dem Endgerät?
• Was exakt passiert beim Aufruf von http://activation.deutsche-glasfaser.de/?

Oben bekommst du eine IP aus dem Aktivierungsnetz der DG (10.x.y.z). Bist du sicher, dass da nicht einfach ein Adress-Konflikt oder DNS Problem vorliegt? Mit der Adresse müsste der Zugriff auf http://activation.deutsche-glasfaser.de/ möglich sein, wenn die DNS Auflösung klappt. Dafür muss der per DHCP übermittelte DNS Server benutzt werden.

Der Fibertwist ist schon ein Modem. Daran kannst du also einen Router anschließen, der Ethernet als WAN Port hat.

Du musst allerdings die erforderlichen Verbindungsparameter des Providers herausfinden, also

• PPPoE oder IPoE
• VLAN Konfiguration, ggf. auch für die Telefonie
• IPv4, IPv6, CGNAT oder DS-Lite?
• Zugangsdaten für Internet und/oder Telefon

Und das muss der Router natürlich auch können. Die Erfahrung lehrt, das Kombination aus PPPoE und DS-Lite Probleme machen kann.

Zitat von pufferueberlauf

Wir wissen alle ob der Problematik "Ratenlimitierung von ICMP-Beantwortung und ICMP-Depriorisierung" wenn ein Hop tatsaechlich fuer X% Verlust verantwortlich ist, dann sieht man das daran, dass alle Hops dahinter ebenfalls mindestens X% Verlust zeigen... also genau das Bild das in allen Traces von Joosen zu sehen ist...

Aber wenn der Hop unmittelbar vor dieser Kette eine höhere Verlustrate zeigt, weißt du halt nicht, ob er nicht auch für die Verluste der folgenden Hops verantwortlich ist.

Zitat von pufferueberlauf

Gerade Fritzboxen sind da oft relativ restriktiv... Traceroute/pingplotter/mtr/troppy arbeiten alle ueber TTL Expiration und nicht ueber ICMP Echo requests und bei den ICMP Fehlermeldungen haben Fritzboxen, meine ich, Ratenlimits...

Ja, haben sie.

Auf deinem ersten Hop zum lokalen Router hast du schon 80% Paketverlust. Das macht es enorm schwierig, einzuschätzen, was von den Verlusten lokal erzeugt wird, und was im Netz hinter deinem Router.

Auf die Packet Loss Angaben der Atlas Nodes würde ich nicht zu viel geben. Das sieht bei mir so aus:

Und der Packet Loss Test so:

Atlas: Katastrophe. Realität: keinerlei Problem. Die Pakete gehen sonstwo verloren, aber nicht im Einflussbereich meines Anschlusses.

Inet-only steht da, sobald das Onboarding erfolgreich war.

Wir hatten schon einige Fälle, wo das Onboarding störrisch war, und geholfen hat dann der Werksreset. Wenn ich mich recht erinnere, hatten wir sogar schon einen Fall, da hat jemand im Modus "DG Router" einen eigenen ONT registriert. Das Problem war dann, dass die Telefonie nicht mehr funktionierte, weil die Zugangsdaten fehlten. Da hat derjenige dann doch auf "kundeneigener Router" umgestellt, und damit ging es dann wieder.

Zitat von Bulldog66

Also von managed-cpe auf kundeneigener Router - Anschlussmodell fibre twist (NT).

Die Angaben passen aber nicht zusammen.

Es gibt zum einen "kundeneigener Router" oder "DG Router" und im anderen Feld "managed-cpe" oder "inet-only". Die Umstellung von "DG Router" auf "kundeneigener Router" muss vom Service vorgenommen werden. Der Wechsel von "maneged-cpe" auf "inet-only" erfolgt automatisch beim erfolgreichen Onboarding eines eigenen ONTs. Das hatten wir schon hier im Forum, sowohl bei der 5530 als auch bei der 5590. Wichtig bei beiden Routern (und vermutlich auch bei der 5690): Unmittelbar vor dem Onboarding Versuch auf der Seite der DG MUSS UNBEDINGT ein Reset auf Werkseinstellungen durchgeführt werden! Sonst scheitert das Onboarding mit dem Code der DG.

Ist der Code aktuell? Man kann jeden Code nur einmal verwenden.

Was passiert, wenn du http://activation.deutsche-glasfaser.de/ aufrufst?

Zeig mal Screenshots von der Aktivierungsseite, wo du den Code eingeben kannst.

Zitat von Bulldog66

Und da ist liegt der Unterschied. Der ganze Aktivierungsprozess kann gar nicht starten, bzw. richtig funktionieren.

Doch, wenn dein Anschluss auf "kundeneigener Router" steht, dann wird das klappen. Glaubs uns. Du kannst auf der Aktivierungsseite mit deinem Aktivierungscode den neuen ONT aktivieren.

Dann kannst du die Wechselprozedur gefahrlos durchziehen. Halte dich am besten an die Anleitungen hier im Forum, alternativ ist die bei AVM fast genauso gut.

Steht dein Anschluss im Kundencenter auf "kundeneigener Router"?

Der Punkt ist, dass das hinterlegen der Modem ID bei der DG nicht zielführend ist, denn der Wechsel des ONTs passiert über die Aktivierungsseite. Zeige bitte mal Screenshots davon, was dir dort beim Wechselprozess angezeigt wird.

Du kannst doch jederzeit in Sekunden wieder zurück.

Wenn DNS nicht funktioniert, ist das für viele Probleme verantwortlich. Aber es ist auch eines der am leichtesten zu lösenden Probleme, da es zahlreiche alternative öffentliche DNS Server gibt.

Allerdings ist DNS auch das erste Glied in der Kette einer Internetverbindung, und deshalb fallen generelle Probleme mit der Verbindung als erstes beim DNS auf. Deshalb bin ich immer skeptisch, wenn jemand über DNS Probleme berichtet. Da kann auch mehr dahinter stecken.

Wenn es eine DNS Störung ist, dann stelle andere DNS Server ein, und das Problem ist gelöst.

Allerdings bin ich skeptisch, dass das alles ist.

Zitat von lp24db

Bandbreiten-Tests sind 100%. Ich bekomme genau das, was vertraglich zugesichert ist.

Das ist aber ein Zeichen dafür, dass es auf TCP Ebene keine Paketverluste gibt. Auf sowas reagieren Speedtests recht empfindlich.

Zitat von ::1

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).

Deren Packet Losses sind unauffällig, jedenfalls deutlich besser, als die hier im Thread.

Wie sieht die Statistik aus, wenn ihr kein ICMP, sondern UDP Pakete verwendet? ICMP ist immer heikel, und bei 0.5% braucht man da schon sehr viele Pakete, um auf belastbare Aussagen zu kommen (jedenfalls mehr als 400). Versuche mal mtr mit UDP oder auch mal mit TCP.

ICMPs dürfen deine Firewall ungehindert passieren, ohne burst Regel und so? Bei so Tracing Programmen kann genau sowas problematisch sein, wie ich schon mal schmerzhaft spüren musste.