Ähm, aber bitte auch mit IA_NA, wie sich das gehört! Und nicht so plain hier rein posten - das ist ziemlich mühsam zu analysieren. Aber du kannst mir gerne eine PCAP-Datei (oder in anderes Wireshark-lesbares Format) des Mitschnitts per PM schicken, so dass ich das mit Wireshark anschauen kann. Und mir etwas Zeit zum Anschauen lassen.
Ja, icmp, icmp6, dhcpv4, dhcpv6 solle reichen.
Ähm, aber bitte auch mit IA_NA, wie sich das gehört! Und nicht so plain hier rein posten - das ist ziemlich mühsam zu analysieren. Aber du kannst mir gerne eine PCAP-Datei (oder in anderes Wireshark-lesbares Format) des Mitschnitts per PM schicken, so dass ich das mit Wireshark anschauen kann. Und mir etwas Zeit zum Anschauen lassen.
Ja, icmp, icmp6, dhcpv4, dhcpv6 solle reichen.
Ja klar. Ich schicke ne pcapng. Mit IA_NA, arp mach ich dann auch noch dazu.
Falls jemand anderes noch an dem Capture interessiert ist:
Ich lese gleich nochmal das DHCP RFC. Beim Neustart kommen die DHCP messages von 100.72.224.1, aber als DHCP server wird 192.168.101.1 genannt und 100.127.140.129 als relay.
Bin mir unsicher ob das Verhalten richtig ist, dass mein client den renewal direkt and 192.168.101.1 richtet. Ich kriege immerhin den renewal...
Client ist systemd-networkd in Version 255.
Yes, it looks like this is correct, the client should send the renewal to the DHCP server address (192.168.101.1). Which makes it extremely weird that DG would use an RFC 1918 address. What if you use 192.168.101.0/24 in your LAN?
EDIT: Sorry ausversehen auf Englisch geswitcht. LOL. Aber das renewal über 192.168.101.1 ist korrekt. Aber das wird halt problematisch wenn man 192.168.101.0/24 in LAN verwendet. DG sollte keine RFC1918 für DHCP server auf WAN Seite verwenden.
Ja, habe auch nochmal tatsächlich im RFC2131 nachlesen müssen.
Die DHCP-Antworten kommen vom IPv4-Default-Gateway 100.72.224.1, das dir auch als Option 3 zugewiesen wird - soweit normal (ist bei meinem DG-Anschluss ebenso).
Habe ich so an meinem Anschluss nicht - aber kann ok sein, da DG an neuen Anschlüssen wie deinem hier evtl. eine geänderte Vorgehensweise hat.
Du bekommst ja schlussendlich auch valide IPv4-Werte zugewiesen, mit denen du prinzipiell arbeiten kannst.
Dass du die DNS-Server (Option 6: 185.22.44.50, 185.22.45.50) damit nicht erreichst, ist natürlich ein Fehler auf der DG-Seite, denn ausgewählte IP-Ziele im Internet kannst du ja erfolgreich pingen.
IPv6: Soweit eigentlich alles mustergültig - nur für IA_NA wieder relativ kurze Timer, während du für IA_PD schon den Stundenwert bekommst. Muss in Folge schon ein Renew für IA_NA nach 5 Minuten erfolgen. Auch die ICMPv6-RA mustergültig.
PINGv6 von der WAN-Adresse funktioniert. Du müsstest halt noch mal mitschneiden, dass ausgehende IPv6-Pings aus deinem LAN nicht beantwortet werden.
Und wie in meinem letzten Post schon angemerkt, ist das IPv6-Renew-Verhalten wackelig.
Aber das wird halt problematisch wenn man 192.168.101.0/24 in LAN verwendet.
Stimme zu, falls ein DHCPv4-Renew per Unicast dahin geschickt würde. Kannst du ja evtl. mal mitschneiden...
Stimme zu, falls ein DHCPv4-Renew per Unicast dahin geschickt würde. Kannst du ja evtl. mal mitschneiden...
Wenn ich das RFC2131 (DHCP) richtig verstehe ist das so.
von RFC 2131 4.4.5
> At time T1 the client moves to RENEWING state and sends (via unicast)
> a DHCPREQUEST message to the server to extend its lease.
Also laut RFC soll der client per unicast an 192.168.101.1 den renewal schicken. Das macht mein Client auch. Also sobald man 192.168.101.0/24 bei sich irgendwo verwendet gibt das Probleme. Würde dann im rebind enden, also halb so wild?
Ich mache morgen nochmal nen Capture mit allem drin.
Ich nehme an alles was ich machen kann ist warten? Bringt druck etwas? Oder hat jemand einen Trick wie man irgendwie seinen Anschluss dazu bringen kann in irgendeiner Form neu konfiguriert zu werden?
Ich habe mal eine KI bemüht anlässlich einer anderen Angelegenheit, meinen Anschluss betreffend (Anstieg der Latenz von vormals 8-10 ms auf nun dauerhaft 20-24 ms ab 06.08.2029 01:30 UTC, wunderbar per Datensammlung per RIPE-Atlas-Probe nachweisbar), wie man den sinnlosen 1st-level-Support der DG am besten umgehen könnte (die KI meinte, dass man Support-Tickets, in denen der Kunde Begriffe verwendet, die auf Netzwerk-Expertise hindeuten, sogleich aussortiert und schließt).
Die KI schlug z.B. vor, das Problem in Foren wie diesem hier darzustellen, weil da ggf. Mitarbeiter der DG (inoffiziell) mitlesen und ggf. eine kurzen Weg zum 2nd- oder gar 3rd-Level-Support herstellen könnten - weiß nicht, gibt es hier im Forum jemanden? fiberv6 würde sich für Unterstützung freuen.
Ansonsten schlug die KI noch den Schriftweg vor mit folgendem Entwurf eines Anschreibens:
Hier ist eine rechtlich fundierte und technisch unmissverständliche Vorlage für Ihr Einschreiben. Der Text ist so formuliert, dass er die Scan-Software der Poststelle triggert, um direkt in der Beschwerde- und Netzmanagement-Abteilung zu landen, anstatt im Standard-Kundenservice.
________________________________________
Absender:
[Ihr Vorname Nachname]
[Ihre Straße und Hausnummer]
[Ihre PLZ und Ort]
[Ihre E-Mail-Adresse]
[Ihre Telefonnummer] [1, 2]
Empfänger:
Deutsche Glasfaser Wholesale GmbH
– Abteilungsleitung Netzbetrieb / Core Network Engineering –
– Qualitätsmanagement & Beschwerdeabteilung –
Am Kuhm 31
46325 Borken
[Ihr Wohnort], den [Aktuelles Datum, z. B. 20.08.2026]
Per Einwurfeinschreiben
Formelle Störungsanzeige wegen erheblicher Leistungsminderung (Routing-Fehler am BNG)
Kundennummer: [Ihre Kundennummer]
Vertragsnummer: [Ihre Vertragsnummer, falls zur Hand]
Anschlussadresse: [Straße, PLZ, Ort Ihres Anschlusses]
Sehr geehrte Damen und Herren, [3]
...
Und hier kannst/solltest du dich mit aller Fachlichkeit einbringen, um das Problem inklusive Nachweisen zu beschreiben,
Also sobald man 192.168.101.0/24 bei sich irgendwo verwendet gibt das Probleme. Würde dann im rebind enden,
Ja, würde ich auch so sehen - aber ist wahrlich nicht im Sinne des Erfinders.
Vielleicht verschwindet das auch alles, nachdem DG auf ihrer Seite deinen Anschluss (hoffentlich bald) ordentlich konfiguriert. Nicht funktionierendes IPv6 ist evtl. aussitzbar, und es kann sein, dass sich das nach ein paar Wochen/Monaten von selbst in Luft auflöst (ich denke, DG weiß sehr genau um seine IPv6-Provisionierungsprobleme). Aber Nicht-Erreichbarkeit ihrer IPv4-DNS-Resolver ist nicht akzeptabel - ok, du kannst/musst einstweilen als Workaround andere DNS-Resolver verwenden. Und Nicht-Erreichbarkeit der Login-Seite für das Kundenportal ist auch untragbar (Workaround über anderen Internetzugang).
Ich habe mal eine KI bemüht anlässlich einer anderen Angelegenheit, meinen Anschluss betreffend (Anstieg der Latenz von vormals 8-10 ms auf nun dauerhaft 20-24 ms ab 06.08.2029 01:30 UTC, wunderbar per Datensammlung per RIPE-Atlas-Probe nachweisbar), wie man den sinnlosen 1st-level-Support der DG am besten umgehen könnte (die KI meinte, dass man Support-Tickets, in denen der Kunde Begriffe verwendet, die auf Netzwerk-Expertise hindeuten, sogleich aussortiert und schließt).
Klar, auch bei der DG sitzt nur ein LLM, dass deine Tickets liest und schließt.
Hier ist eine rechtlich fundierte und technisch unmissverständliche Vorlage für Ihr Einschreiben. Der Text ist so formuliert, dass er die Scan-Software der Poststelle triggert, um direkt in der Beschwerde- und Netzmanagement-Abteilung zu landen, anstatt im Standard-Kundenservice.
Da hat dein LLM Quatsch gelernt. Der richtige Ansprechpartner ist die Rechtsabteilung und die erreicht man zuverlässig mit einer Anwaltskanzlei im Briefkopf.
Denn hier schickt man dem Vertragspartner eine Mängelrüge und kürzt das Entgelt wegen Minderleistung, notfalls bis auf Null, wenn der Anschluss völlig unbrauchbar ist. Anschließend macht man Schadenersatz wegen Nichterfüllung geltend.
Und mit Netzwerkexpertise kann man den Anspruch ja problemlos nachweisen. Dort gehört das auch hin, nicht zum 1st Level. Das ist kein technisches Problem, sondern ein rechtliches und das ist NICHT deine Expertise, hol dir Hilfe!
Falls in den anderen Themen wieder die seltsamen Fragen kommen, warum die Leute auf Gedeih und Verderb lieber bei der Telekom bleiben und Glasfaseranbieter nicht mit der Kneifzange anrühren, hier im Thema findet man die Antwort.
Die Leute die bei der Telekom bleiben, wissen gar nicht wie das bei anderen ISP ablaeuft... da koennen die IPv4/6 Probleme der DG schlicht keine echte Rolle spur ielen, und es isg ja nicht so, dass die Telekom nicht auch Ptrobleme haette die man selbst mit Rechtshilfe beheben kann (vorsaetzliches Unterpeering, aber das ist OT und weitere Diskussion sei darueber sollte in einem anderen Thread gefuehrt werden).
Da hat dein LLM Quatsch gelernt. Der richtige Ansprechpartner ist die Rechtsabteilung und die erreicht man zuverlässig mit einer Anwaltskanzlei im Briefkopf.
Tja, so ein (nicht mein) LLM weiß eben auch nicht immer, was richtig ist. Wie gut, dass du es uns nun so eindringlich mitgeteilt hast.
Tja, das Wort "Einschreiben" hat das LLM halt aus irgendwelchen Foren gelernt und als "Lösung" halluziniert. Das LLM hat auch noch eine "Beschwerde- und Netzmanagement-Abteilung" halluziniert, die es unter einer Adresse in Deutschland so gar nicht gibt.
Alle großen Betreiber außer die Telekom lassen ihr Netz aus direkt aus Indien managen. Dorthin kommst du gar nicht erst durch.
Also ich habe jetzt nochmal bei der Hotline angerufen und habe es dieses mal geschafft das mein Fall dem 2nd level support weitergeleitet wird und bekomme da hoffentlich einen Rückruf.
Ich habe dieses mal die Geschwindigkeitsproblematik 50/25 weggelassen und lediglich das ipv6 routing und die Problematik mit den ipv4 DNS servern angesprochen. Letztes mal hatte ich die 50/25 Geschwindigkeit genannt und dann ging das Gespräch nur noch in die Richtung wie Gemessen wurde, etc.
Kleines Update:
Noch nichts vom Support. Aber habe jetzt nochmal länger (ca. 3 Stunden) den ONT aus gehabt. Speed ist jetzt immerhin korrekt (945 down 500 up). Am ipv6 / ipv4 routing hat sich nichts geändert.
Immerhin ein Fortschritt - und eine Sorge weniger.
Vielleicht noch ein(e) Gedanke/Idee:
Dein vRouter verwendet für DHCPv6 einen Client-Identifier des DUID-Typs 2 (DUID-EN), vgl. RFC9915 (chapter 11). Der ist eher ungewöhnlich. Üblicher sind die Typen 1 (DUID-LLT) und 3 (DUID-LL). Der DHCPv6-Server verwendet seinerseits einen Server-Identifier des Typs 3.
Vielleicht ist es einen Versuch wert, wenn du den DUID-Typ mal auf Typ 1 oder Typ 3 umstellst, sofern das bei deinem System möglich ist?
Ergänzung:
Das wird nicht das IPv6-Routing-Problem lösen - aber möglicherweise funktionieren dann die DHCPv6-Renews auf Anhieb.
Ich schaue mir den Vorschlag mal an, ob ich das so konfigurieren kann.
DHCPv6 Renews sehen jetzt aber soweit OK aus. Bisher haben alle geklappt (seit 15:36). Bei dem Neustart gab es sowohl für IA_NA, IA_PD, und bei der ipv4 eine Lease Time von 10 Minuten. Nach dem ersten Renewal (nach 5 Minuten) dann jeweils 1 Stunde. Und so läuft es jetzt vorerst korrekt mit einem Renewal alle 30 Minuten.
Vielleicht ist das einfach das Verhalten bei neuen Anschlüssen, dass die Lease Time zunächst 10 Minuten, und dann ab dem ersten Renewal 1 Stunde beträgt.
Vielleicht ist das einfach das Verhalten bei neuen Anschlüssen, dass die Lease Time zunächst 10 Minuten, und dann ab dem ersten Renewal 1 Stunde beträgt.
Danke für das Feedback! Dann scheint DUID-Type 2 auch ok zu sein.
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum
