Beiträge von user

    Auf der Website meiner RIPE-Atlas-Probe (ist doch gut, so ein Ding zu haben), sehe ich für meinen DG-Anschluss (Raum Fürth - PLZ 9061X) einen IPv4-Ausfall von ~ 12:32 bis ~ 13:04 UTC, also MESZ: 14:32- 15:04:

    Und ich kann diesen Post hier jetzt nur schreiben, weil IPv4 aktuell wieder funktioniert.
    Wie schön wäre doch, wenn ww.glasfaserforum.de endlich auch via IPv6 erreichbar wäre!

    Gute Idee,

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

    RIPE Atlas - RIPE Network Coordination Centre
    RIPE Atlas is the RIPE NCC's main Internet data measurement system.
    atlas.ripe.net
    RIPE Atlas - RIPE Network Coordination Centre
    RIPE Atlas is the RIPE NCC's main Internet data measurement system.
    atlas.ripe.net

    Hi RnBnpx,

    willkommen im Club. :)

    Ich behelfe mir seit dem Fr,28.1.2022 mit einem Workaround.

    Im einstelligen Sekundentakt (abseits der propagierten leasetime 3600sek bzw. T1 1800sek) werden DHCPv6 renews versendet, damit der IPv6 Verkehr nicht nach wenigen Minuten (nach letzten DHCPv6 renew) versiegt.

    Vom First Level Support ist keine Hilfe zu erwarten, nicht mal eine Stellungnahme.

    Hi RnBnpx,

    siehe Nachbarfaden. :)

    Ich beobachte diesen fehlerhaften Zustand seit Fr,28.1.2022.

    Das Aussetzen des IPv6 Traffic kann durch ein DHCPv6 renew "geheilt" werden. Es hält dann aber nur ~3 Minuten an.

    Sprich, ich behelfe mir derzeit damit, im einstelligen Sekundentakt (abseits der leasetime 3600sek bzw. T1 1800sek) DHCPv6 renews zu versenden.

    Maximale Downloadrate per Einzelverbindung ist schon möglich.

    Wer noch weitere Quellen mit interessanten DG Übergabepunkten abseits von FRA kennt, immer her damit.

    Der Fehler ist inzwischen wieder aufgetreten.

    IPv6 Pakete werden ~3min nach letzten DHCPv6 renew/reply nicht mehr durchgeleitet.

    Da die Leasetime 3600sek beträgt und nur alle 1800sek (T1 50%) ein DHCPv6 renew/reply durchgeführt wird, ist IPv6 damit praktisch nicht nutzbar.

    Ein Client erzwungendes DHCPv6 renew alle z.B. 60sek führt dennoch nach ~3min zum Aussetzen der IPv6 Durchleitung.

    Die Wartezeit bis zum nächsten "heilenden" DHCPv6 renew/reply wird zwar verkürzt, aber der Fehler bleibt bestehen, nach ~3min ist der IPv6 Aussetzer wieder da.

    Seit Fr,28.1.2022 ~4:00 MEZ konnten erkennbare Aussetzer im IPv6 Traffic festgestellt werden.

    Der Höhepunkt war nun heute Nacht Fr,18.2.2022 Punkt 0:00 MEZ der Komplettausfall von IPv6.

    Seit Heute Nachmittag funktioniert nun endlich IPv6 ohne Aussetzer wieder.

    IPv4 funktionierte die gesamte Zeit über. Ticket mit Details an DG First Support waren wirkungslos, oder es war zumindest intern bekannt, konnte nicht zeitnah abgestellt werden.

    An der DG Leitung gibt es weiterhin das Problem, dass der IPv6 Traffic sporadisch aussetzt.

    Der IPv4 Traffic ist davon nicht betroffen. Von einem Problem (im IPv6 Stack) auf meiner Seite gehe ich nicht aus, da es ohne HW/SW Änderung bis zum Beginn des Problems funktioniert hat.

    Der First Support von DG ist undienlich. Wiederholte technische detaillierte Analyse wird mit Reset des NT begegnet. Sprich primitivste Ebene einer Problembewältigung seitens DG.

    Das sporadische Aussetzen des IPv6 Traffic kann durch einen dhcpv6 renew "geheilt" werden.

    Sprich, es findet jetzt im Sekundentakt ein dhcpv6 renew statt, damit mögliche sporadische Aussetzer im IPv6 Stack so kurz wie möglich sind.

    Der Grund eines solchen technischen Fehlverhaltens seitens DG fällt mir schwer zu erdenken.

    Ich habe die Thematik,

    das die zuständigen DNS Server (dnsauth001.dg-w.de.[185.22.44.49] und dnsauth002.dg-w.de.[185.22.45.49]) für z.B. speed.deutsche-glasfaser.de

    nicht mehr auf Anfragen aus dem deutschen Glasfaser client Netz [100.64/10 CGnet] antworten.

    Ein eigener DNS Resolver fällt dann bei deutsche glasfaser Domains auf die Nase.

    Die von DG gestellten semi-public DNS resolver (185.22.44.50 und 185.22.45.50) für die DG Clients funktionieren,

    aber wer will heute noch ISP oder fremd gestellte Resolver benutzen.

    Hi,

    ich habe Fragen zur technischen Umsetzung vom Anbieter Deutsche Glasfaser.

    Leider sind die Informationen aus DG_Leistungsbeschreibung.pdf und DG_Schnittstellenbeschreibung_2.pdf nicht abschließend ergiebig,

    auch wurden meine Fragen vom DG Support bisher nicht beantwortet.

    Vielleicht hat jemand mit einem neueren DG Anschluss oder mehr technischen Hintergrundwissen Antworten.

    1) kann/darf man nach der Installation der ONT Box, die Box eigenmächtig im Haus/Keller versetzen?

    Laut Schnittstellenbeschreibung soll das LWL Kabel zwischen HÜP und ONT ein LC/APC-SC/APC G.657 Patchkabel sein?

    2) ist es derzeit schon möglich die gestellte ONT Box (Glasfaser zu Ethernet) durch ein _eigenes_ GPON SFP Modul (z.B. durch ein MikroTik SFP GPON) zu ersetzen?

    3) IPv4 Stack ist nativ umgesetzt? kein PPPoE, kein 4in6?

    3a) es wird eine IPv4 aus dem cgnat 10.64.0.0/10 Netz per DHCPv4 propagiert?

    3b) diese cgnat IPv4 verändert sich je DHCP Request oder Zeitraum oder nie?

    4) IPv6 Stack ist nativ umgesetzt? kein PPPoE, kein 6to4?

    4a) wird ein öffentlich geroutetes IPv6 Präfix bereitgestellt?

    4b) werden mehrere IPv6 Präfixe bereitgestellt?

    4c) welche Länge hat das IPv6 Präfix? /56?

    4d) wie wird das/die Präfix(e) propagiert? per DHCPv6 oder (SLAAC/NDP/ICMPv6) oder DHCPv6-PD ? Oder beides bei mehreren Präfixen?

    5) gibt es eine Beschränkung der maximalen MTU Größe bei IPv4/IPv6? Ggf. maximal beim cgnat IPv4 Stack?

    6) mittlerer Stromverbrauch der ONT Box?

    7) Erfahrungen ob es gegen Geld eine öffentliche IPv4 hinzugebucht werden kann?