Ich hätte jetzt schon erwartet, daß Zugriffe von Kunde zu Kunde unterbunden werden...
Das wird ja bei Providern, die öffentliche IP-Adressen verteilen, auch nicht gemacht. Es gibt einen Grund, warum ich immer davor warne, WAN und LAN Netz zu vermischen. Die Verbindung zwischen den Kunden kann nämlich auch auf Layer 2 vorhanden sein. Solche Fälle gabs schon bei DSL Anbietern, und plötzlich konnten Leute in die Netzwerkumgebung ihrer Nachbarn schauen.
Wir machen dazu wohl besser ein eigenes Thema auf...
Ich hätte jetzt schon erwartet, daß Zugriffe von Kunde zu Kunde unterbunden werden...
Ah, ich sehe beide Optionen als nachvollziehbar an.
Andererseits eröffnen sich da ganz neue Möglichkeiten, wäre mal interessant, ob die Bandbreitenbegrenzung da intern auch schon greift
Mit hoher Sicherheit ja... (zumindest bei PON Anschluessen, bei AON Anschluessen am selben Zugangsswitch vielleicht nicht).
Die in jeden BNG integrierte CGNAT-Funktion ist dabei nicht involviert, weil die IP-Zieladressen der anderen Kunden ebenfalls in 100.64.0.0/10 liegen.
Muesste dann nicht die DG ein flaches Subnetz nutzen, bei dem jede 100.er Adresse nur einmal im gesamten DG Netz verwendet wird?
Muesste dann nicht die DG ein flaches Subnetz nutzen, bei dem jede 100.er Adresse nur einmal im gesamten DG Netz verwendet wird?
Nö, warum? Ich sehe es so: Der 100.64.0.0/10-Space zerfällt in überlappungsfreie Pools, wobei jedem BNG ein eindeutiger Pool zugeordnet wird, aus dem er IP-Adressen zur Zuweisung an die WAN-Ports der Kundenrouter auswählt.
Die BNG und vorgelagerte interne Router müssen dann (zweckmäßigerweise über ein dynamisches Routing-Protokoll) untereinander nur wissen/lernen, welcher Pool auf welchem BNG liegt, um IP-Pakete mit IP-Zieladressen aus so einem Pool ebenda hin zu routen.
Aber genau das fuehrt dazu, dass jede 100er Adresse nur einmal verwendet werden kann, aber ein /10 hat "nur" ca. 4 Millionen Adressen, d.h. entweder will die DG unter 4 Millionen Kunden bleiben oder sie braucht Plaene dazu die 100er Adressen mehrfach zu verwenden, oder?
So gesehen ist es ein reines Transportnetz. Ich wüsste nicht, weshalb das je BNG exklusiv sein muss.
Ja, ein 10.64.0.0/10 reicht theoretisch nur für 2^22 Kundenanschlüsse. Aber, man kann ja, wenn nötig, mehrere solcher 10.64-Domänen etablieren. Eine (direkte, NAT-freie) Lateral-Kommunikation zwischen zwei Kundenanschlüssen in verschiedenen 10.64-Domänen ist dann aber nicht mehr möglich.
Ich wüsste nicht, weshalb das je BNG exklusiv sein muss.
Ja, müsste eigentlich nicht exklusiv sein, aber dann wäre auch keine (direkte, NAT-freie) Lateral-Kommunikation zwischen zwei Kundenanschlüssen an zwei verschiedenen BNG innerhalb derselben 10.64-Domäne möglich. Das widerspricht aber der Erfahrung.
Nachtrag:
Zu "Das widerspricht aber der Erfahrung." ist anzumerken, dass ich eine Lateral-Kommunikation zwischen zwei Kundenanschlüssen an zwei verschiedenen BNG bisher nur für IPv6 verifizieren konnte. Für IPv4 ist das nicht möglich, da ich natürlich nicht an die WAN-IPv4-Adresse eines anderen Kundenrouters heran komme, wenn mir diese der Besitzer nicht mitteilt. WAN-IPv6-Adressen von ausgewählten DG-Kundenanschlüssen kann ich jedoch relativ leicht über öffentlich zugängliche Informationen von RIPE-Atlas-Probes an DG-Anschlüssen in Verbindung mit externen Traceroutes ermitteln.
Mich hats jetzt auch erwischt in 41xxx. Ich habe hinter dem Modem eine Fritzbox 7690, und erhalte keine IPv6-Adresse mehr (vermutlich seit Freitag). Ist mir erst aufgefallen, weil mein VPN ins Heimnetz nicht mehr läuft...
Die Box zeigt zwei Meldungen an:
Internetverbindung IPv6 konnte nicht hergestellt werden: Keine Antwort vom DHCPv6-Server (SOL)
Internetverbindung IPv6: DHCPv6-Fehler mit Fehlergrund 8 (Sorry, no prefixes could be allocated.)
Die DG schreibt wieder nur Anleitungen, dass das Modem neugestartet werden soll und mein Router ja das Problem ist, da sie ja eine IPv6 per DHCP verteilen würden. Allerdings erhalte ich von der DG ja keine.
Gibts da Stichwörter mit denen ich zu einem kompetenterem Servicelevel weiter komme oder muss ich es einfach immer wieder versuchen?
Gibts da Stichwörter mit denen ich zu einem kompetenterem Servicelevel weiter komme oder muss ich es einfach immer wieder versuchen?
Vielleicht nutzt es, die Fritzbox-Hilfetexte zu den beiden Fehlermeldungen zu zitieren. Die müssten ja sinngemäß darauf hinweisen, dass das Problem beim ISP liegt.
Und das wirst du vermutlich mehfach wiederholen müssen...
Mich hats jetzt auch erwischt in 41xxx. Ich habe hinter dem Modem eine Fritzbox 7690, und erhalte keine IPv6-Adresse mehr (vermutlich seit Freitag). Ist mir erst aufgefallen, weil mein VPN ins Heimnetz nicht mehr läuft...
Die Box zeigt zwei Meldungen an:
Die DG schreibt wieder nur Anleitungen, dass das Modem neugestartet werden soll und mein Router ja das Problem ist, da sie ja eine IPv6 per DHCP verteilen würden. Allerdings erhalte ich von der DG ja keine.
Gibts da Stichwörter mit denen ich zu einem kompetenterem Servicelevel weiter komme oder muss ich es einfach immer wieder versuchen?
keine Adresse bekommen ist aber ein anderes Problem, hier geht es eigentlich ausschließlich darum, daß wir sehr wohl eine Adresse bekommen, aber der Zugriff trotzdem nicht funktioniert.
Ist ja hervorragend, bei DG hat man im Kundencenter jetzt nur noch die Möglichkeit, über einen Messenger Nachrichten zu schreiben, und da landet man erstmal bei einer KI 🤮
Ausgerechnet bei der DG würde ich das als Verbesserung sehen, da wurdest du zuvor ja mit überhaupt keiner Intelligenz konfrontiert.
Ja, und wenn man das liest, dann weiß man auch, auf welcher Seite des Telefons die Intelligenz fehlt.
Wenn die KI nur mit den üblichen Standardantworten ("Hammer") für jedwedes Problem (alles ist ein "Nagel") trainiert wurde, wird sie nicht viel bringen - als Kunde wird es nur mühseliger, den nicht zutreffenden Abfragebaum zu durchlaufen, bis man endlich frei formulieren kann, was das Problem ist, und vielleicht noch Dateien anhängen darf.
Traumhaft für DG: Die Rate der abgeschreckten Kunden dürfte steigen.
Kundenseitig wächst hingegen die Frustration in allen Fällen, in denen die "Hammer"-Lösung nichts zu Beseitigung von Problemen beiträgt, deren Ursache auf DG-Seite zu finden und zu beheben ist. Im Zweifelsfall wird man das durch den KI-Abwimmeler noch nicht mal mehr formulieren/mitteilen können.
Schöne neue KI-Welt: Im Service-Bereich (nicht nur bei DG) dürfte das zu enormem Wachstum der Service-Wüsten beitragen.
Die Servicewüste war doch schon vollendet oder was genau hab ich jetzt verpasst? Der durchschnittliche Kunde wird seine Mühe haben, dem System nach drei ungerechtfertigt geschlossenen Tickets zum selben Sachverhalt noch zu trauen. Die KI macht da keinen Unterschied mehr.
Was bei der DG noch fehlt, ist die Offenbarung, ob sie wirklich nicht mehr Provider sein und die Kunden zu den alternativen Providern kriegen möchte. Die Indizien sind ja vorhanden.
Ich muss nochmal korrigieren. Ich habe die FB nochmal neu gestartet, ich erhalte eine IPv6 Adresse (Internetverbindung IPv6 wurde erfolgreich hergestellt. IP-Adresse: fd3f:d5f8...), gefolgt von Fehlergrund 8. Unter Verbindungsdetails steht auch Internet, IPv6: Nicht verbunden.
Das ist allerdings eine Unique Local Address (ULA). Diese wird von deinem Router vergeben und nicht vom Provider.
Oder es ist ein lustiger DG-Fehler neuer Art...
Die Servicewüste war doch schon vollendet oder was genau hab ich jetzt verpasst?
Ja, da hast du was verpasst. Hier tauchen sicher zuweilen einzelne Problemfälle auf, aber über die tausenden problemlosen Supportfälle berichtet niemand. Und wenn man dann noch die dazunimmt, wo einfach nur jemand vergessen hat, den richtigen Stecker in die richtige Dose zu stecken (meistens sind es sogar die Stromkabel), dann werden solche Äußerungen eher lächerlich.
In welchem Umfang du damit Mitarbeiter, die sich wirklich den A... für die Kunden aufreißen, persönlich beleidigst, darfst du dir selber ausmalen. So viel zum Thema, auf welcher Seite die Intelligenz fehlt.
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
