[Gelöst] Deutsche Glasfaser: Seltsame DHCP-Antworten und Fritzbox-Verhalten

  • Hallo zusammen,


    Ich helfe in meinem seit nun ca. 1 Jahr bestehenden Neuausbaugebiet der Deutsche Glasfaser desöfteren im Familienkreis und Freundeskreis, kundeneigene Router - in der Regel Fritzboxen - an den DG-NTs einzurichten. Bisher habe ich jeden Anschluss zum laufen gebracht, doch bei einem sehr guten Freund habe ich nun eine harte Nuss:

    Mein Freund bat mich um Hilfe, weil seit einigen Tagen zwar sein Telefon funktioniert, jedoch sein Internetzugang nicht, davor funktionierte alles monatelang bestens. Allein diese Fehlerbeschreibung ist schon sehr interessant, denn das muss ja bedeuten, dass seine Fritzbox 7490 die er an diesem Anschluss einsetzt irgendwie eine IP-Konfiguration erhalten haben muss, sonst könnte die Fritzbox ja keine Verbindung zum SIP-Server herstellen.

    Als ich vorort die Fritzbox-Konfiguration anschaute staunte ich dann auch nicht schlecht als ich sah, dass die Fritzbox keine Internetverbindung im Online-Monitor anzeigte, die DG-Telefonnummer unter "Eigene Rufnummer" aber ganz offensichtlich tatsächlich registriert war. Und tatsächlich konnte mit dem Anschluss problemlos telefoniert werden. Die Anrufe gingen problemlos rein und raus :?::!:

    Dann habe ich als nächstes meinen Laptop per LAN-Schnittstelle an die Fritzbox angeschlossen. Die Fritzbox teilte dem Laptop problemlos eine IPv4-Adresse aus ihrem privaten Subnetz mit. Ziele im Internet konnte ich jedoch nicht erreichen. tracert ergab, dass alle ICMP-Pakete bis zur Fritzbox kommen, aber von dort aus nicht weiter kamen. Spaßeshalber habe ich auch versucht die IP-Adresse des DG-Sipserver zu tracern, auch diese kam entweder nur bis zur Fritzbox, oder sämtliche Router auf DG-Seite antworten nicht auf ICMPv4-Traceroute (zumindest der erste Router auf DG-Seite antwortet eigentlich immer). Seeehr seltsam. Die Fritzbox konnte mit dem SIP-Server kommunizieren, an ihr angeschlossene Geräte jedoch nicht. So als wenn das NAT der Fritzbox nicht funktionieren würde, habe ich persönlich noch nie erlebt und ich habe schon sehr viele Fritzboxen gehabt, gesehen und konfiguriert. Trotzdem ging ich bei diesem Fehlerbild erstmal davon aus, dass die Fritte im Eimer ist, oder zumindest die Firmware.


    Um dies zu bestätigen, habe ich dann die LAN-Schnittstelle meines Windows 10 Laptops direkt an den NT gehängt. An einem korrekt funktionierenden DG-Anschluss, der auf dem Modus mit kundeneigenenem Router eingestellt ist, erhält der Computer (bzw. der DHCP(v6)-Client des Windows 10-Systems) eine IPv4-Adresse und eine /128 IPv6-Adresse. Doch siehe da, der Computer richtete sich selbst auf eine APIPA-Adresse ein (aus dem Bereich 169.254.0.0./16), als wenn der DHCP-Server nicht oder nicht korrekt reagiert.

    Nun gut, dann habe ich eben mit Wireshark mal nachgeguckt was da eigentlich abgeht:
    LAN-Schnittstelle eines Windows 10-Systems am NT:


    Interessant, also der DHCP-Server bietet nach 5 Versuchen tatsächlich ein Offer an. Dann muss der DHCP-Client zweimal requesten um wieder eine Reaktion vom DHCP-Server zu erhalten, doch dieser Antwortet mit einem DHCP NAK, er zieht das Angebot also zurück, warum auch immer. Das ganze wiederholt sich bis der DHCP-Client aufgibt.


    Zwischenfazit:
    - Die Fritzbox zeigt keine IP-Konfiguration im Online-Monitor an

    - Die Fritzbox selbst kann jedoch mit dem SIP-Server kommunizieren,

    - ICMPv4 Traceroutes von an der Box angeschlossenen Clients kommen nur bis zur Fritzbox

    - das DHCP Request des Windows 10 Systems wird vom DHCP Server abgewiesen.


    Nun wollte ich herausfinde, warum um alles in der Welt die Kommunikation zwischen Fritzbox und SIP-Server funktionierte. Zum Glück können Fritzboxen den IP-Verkehr auf den Schnittstellen mitschneiden.

    Dies ist der DHCP-Prozess zwischen Fritzbox und DG DHCP-Server:


    Und siehe da, der DHCP-Prozess läuft zumindest durch und die Fritzbox erhält eine Adresse (100.92.29.106), auch wenn sie dies im Online-Monitor nicht zugeben mag. Und mit dieser findet die Kommunikation mit dem SIP-Server statt.




    Wie ihr seht, ein ziehmlich seltsames Fehlerbild was da sowohl die Fritzbox als auch der DG-DHCP-Server abgeben. Ich vermute derzeit, dass das DHCP Offer des DG-DHCP-Server nicht ganz sauber ist und die Fritzbox dadurch so aus dem Takt bringt, dass sie das beschriebene Fehlerbild zeigt. Aber dafür kenne ich mich leider nicht gut genug mit den DHCP Flags aus. Ist zufällig ein DHCP-Experte hier :D ? Ich lasse gerne die Paketaufzeichnungen vollständig zukommen. Auf IPv6-Ebene passiert übrings seitens DG garnichts. Das Windows 10 System und die Fritzbox senden zwar ein Router Solicitation, erhalten aber kein Router Advertisment.
    ...Wie gerne ich doch mal ein Blick in die Routing Table und die NAT Table der Fritzbox werfen würde, aber da kommt man ja nicht dran.

    Der DG-Kundenservice ist in diesem Fall leider auch kein kompetenter Ansprechpartner, auch wenn ich dem zu verstehen gegeben habe, das ich da etwas mehr Fachwissen habe als der Ottonormal-Supportfall :( . Die sehen leider das die Telefonie ja funktioniert und beharren darauf, dass das Problem auf Nutzerseite liegen muss. Diese (doch seehr fachliche) Paketaufzeichnung die ich auf dem Windows 10 System gemacht habe, habe ich natürlich auch an den DG-Kundenservice geschickt. Die Paketaufzeichnung von der Fritzbox in der zumindest die DHCP-Aushandlung mit einem DHCP ACK quittiert wird, habe ich mal lieber nicht mitgeschickt, sonst behaupten die erstrecht das ihrerseits alles in Ordnung ist. Ich bekomme auch so schon nur die Standard-Tipps für den Ottonormal-Nutzer wie NT neustarten, Fritte zurücksetzen etc. Solche Basics mache selbstverständlich schon bevor ich DG mit einem Problem konfrontiere. Die Fritzbox ist exakt so konfiguriert, wie in den Konfigurationsanleitungen von Deutsche Glasfaser beschrieben.

    Wenn jemand das hier beschriebene Fehlerbild schonmal gesehen hat oder weiß wie man vom DG-Support mit einem solchen Fehlerbild ernst genommen wird, dem wäre ich sehr seeehr seeeeeeeeehr dankbar :).


    Vielen Dank :)

  • dkweb

    Hat den Titel des Themas von „Deutsche Glasfaser: Mysteriöse DHCP“ zu „Deutsche Glasfaser: Seltsame DHCP-Antworten und Fritzbox-Verhalten“ geändert.
  • Die Fritzbox kann eine separate Internetverbindung für VoIP aufbauen. Das ist wahrscheinlich angeschaltet, sollte es aber nicht. Der Schalter befindet sich unter "Telefonie", "Eigene Rufnummern", "Anschlusseinstellungen". Wenn der Server dann von dem Anschluss regelmäßig mehrere Verbindungen sieht, wird vielleicht eine "nur ein Router pro Anschluss, bitte" Regel aktiviert, um zu verhindern, dass jemand den Anschluss einfach über einen Switch vervielfältigt. Kontrolliere auch, ob bei den Internetzugangsdaten oder bei den Telefonie Anschlusseinstellungen ein VLAN eingetragen ist.

  • Moin,


    zum VOIP Problem kann ich nichts mehr hinzufügen, allerdings kann ich etwas zum Verhalten des DHCP Servers sagen:


    Ich hatte ebenfalls mit dem DHCP und DHCPv6 Server der DG zu kämpfen. Mir ist bis heute Unklar in welchem China-Shop die sich die Konfiguration gekauft haben ;).


    Wie alfalfa bereits andeutete, regelt die Deutsche Glasfaser die "maximal ein Gerät Policy" über DHCP statt direkt auf Layer2. Die Leases gelten bei der DG immer für eine Stunde. Möchtest du also das Gerät tauschen (hier Notebook), so musst du den Router abklemmen, eine Stunde warten bis der DHCP Lease bei der DG raus ist und kannst dann dein Notebook anschließen, sonst hat der DHCP Server das von dir beschriebene Verhalten. Statt sich an zuverlässig den 4-Way Handshake zu halten und konsequent ein NAK zu schicken, wenn ein Gerät nicht erlaubt ist, werden einige DHCP Discoveries ignoriert oder auf den DHCP Request vom Client nach dem Offer kommt einfach gar keine Antwort mehr (Deswegen auch die Eingangsbemerkung, das du erstmal einen DHCP-Server finden musst der sich so verhält).


    Gleichzeitig verwerfen die auch sämtliche Standards bezüglich IPv6 Router Advertisments. Normalerweise reagiert ein Router auf Router Solications. Die DG ignoriert diese allerdings vollständig und sendet stattdessen konsequent und immer mitten im DHCPv6 Handshake ein Router Advertisment. Es funktioniert, ja, aber ist definitiv nicht im Sinne des Erfinders. Ich hatte auch schon den Fall, das plötzlich kein DHCPv6_IA mehr geschickt wurde und nur noch DHCPv6_PD. Auch hier Frage ich mich, was die für Software nutzen, das das überhaupt möglich ist.


    Das typische Supportspiel: "Trennen Sie den Router mal für eine Stunde vom Netz kann daher bei der DG teilweise echt Wunder verbringen."

  • alfalfa
    Wow, vielen Dank für diesen Hinweis! Genau das war das Problem :)
    Unter "Telefonie/Eigene Rufnummern/Anschlusseinstellungen" war der Haken bei "Für Internettelefonie eine seperate Verbindung nutzen (PVC)" aktiviert. Das erklärt natürlich alles :) . Interessant ist jedoch die Tatsache, dass diese Konfiguration fast 1 Jahr lang problemlos funktionierte. Wenige Stunden bevor diese Anschlussstörung bei meinem Freund losging, viel in unserem und einigen benachbarten Ausbaugebieten der Internetzugang vollständig aus für einige Stunden. Nach diesem Ausfall erhielt mein eigener Anschluss ein neues DHCP_PD-Präfix und der Router eine neue DHCP_IA-Adresse, nachdem sich diese seit Monaten nicht mehr verändert hatten und das obwohl ich dazwischen sogar (innerhalb des selben Ausbaugebietes) umgezogen bin. Der DHCP-Server hat die DHCP/DHCPv6-Client-ID meines Routers einfach wiedererkannt, nehme ich an. Sieht so aus, als hätte DG irgendwas an seiner Konfiguration verändert und erst seitdem weist der DHCP-Server Mehrfachverbindungen ab.


    Waishon

    Ähnlich wie du schilderst, hat es tatsächlich mehrere Stunden gedauert, bis der DHCP-Server das DHCP-Request der Fritzbox nach der Änderung der Telefonieeinstellungen wieder akzeptierte.

    Seitens dem DG-Kundenservice finde ich es trotzdem absolut unterste Schublade mit diesen Standard-Antworten abgespeißt zu werden, wenn man als Kunde schon solch detalierte technische Informationen wie diese Traffic-Aufzeichnungen liefern kann. Man sollte ja meinen, die Technik sollte erkennen was es bedeutet, wenn deren DHCP-Server ein deratiges Verhalten zeigt und DHCP-NAK ausgibt. Diese überaus nützliche Information, dass da aus Sicht von DG mehr als 1 Gerät versucht Adressen zu beziehen, hätte ich ganz gerne von DG gehört und nicht erst in einem von DG unabhänigen Forum :/.

  • dkweb

    Hat den Titel des Themas von „Deutsche Glasfaser: Seltsame DHCP-Antworten und Fritzbox-Verhalten“ zu „[Gelöst] Deutsche Glasfaser: Seltsame DHCP-Antworten und Fritzbox-Verhalten“ geändert.
  • dkweb

    Ja das ist das Hauptärgernis an der Deutschen Glasfaser. Du kannst den 1st Level Support Simulator als Privatkunde schlicht nicht durchspielen. Die sind optimiert daran die Kunden hinzuhalten und sämtliche Probleme auf z.B. AVM oder deinen eigenen Router zu schieben. Selbst im NOC erreicht man keinen, selbst wenn man z.B. Peerings machen will.


    Wir hatten in unserem Ausbaugebiet das Problem, das die zugeteilten IPv6 Adressen nicht geroutet wurden im Backbone. Man wollte das Problem auf AVM schieben, bis wir unsere lokale Presse eingeschaltet haben, die das Problem (da es viele Kunden betraf) an die DG geschickt haben. Und oh Wunder: Es gab einen Konfigurationsfehler auf deren Seite und das Problem war innerhalb einer Woche behoben.


    Priorität der DG ist eindeutig gute PR und Marketing für die Investoren zu haben und das man ja auch noch so ein lästiges Backbone mit Internet für Kunden betreiben muss ist halt Beiwerk ;) Meines Wissens ist das Backbone auch outsourced an eine Niederländische Firma (kann man mit bisschen Recherche rausfinden wer das ist). Das vereinfacht nicht gerade die Problemlösung bei solchen Fehlern.


    Ich glaube das diese "1 Gerät Policy" sehr neu ist und erst Stück für Stück in alle Gebiete ausgerollt wird. In unserem Ausbaugebiet wurde direkt mit dieser Technik gestartet. Ich kenne andere Regionen, da kann/konnte man fröhlich alle paar Sekunden ein anderes Gerät einstecken ohne Probleme.

  • beharren darauf, dass das Problem auf Nutzerseite liegen muss [...] Standard-Tipps für den Ottonormal-Nutzer wie [...] Fritte zurücksetzen [...] Solche Basics mache selbstverständlich schon bevor ich DG mit einem Problem konfrontiere. Die Fritzbox ist exakt so konfiguriert, wie in den Konfigurationsanleitungen von Deutsche Glasfaser beschrieben.

    Zur Ehrenrettung des Supports: Das Problem lag auf Nutzerseite, der Standard-Tipp "Fritte zurücksetzen" hätte das Problem gelöst, wurde aber offensichtlich nicht schon vorher probiert, und die Fritzbox war nicht exakt so konfiguriert wie in der Anleitung beschrieben. :whistling: Die haben's halt auch nicht leicht.

  • alfalfa Glaube auch das das in 99,5% der Fälle auf den Router des Kunden zurück zu führen ist bzw. es allgemein ein Nutzerproblem ist. Problematisch sehe ich das nur, wenn es augenscheinlich für die restlichen 0,05%, wie bei uns, wo es ein Backbone Problem war, schlicht keine Eskalationsstufen existieren bzw. diese ausschließlich über die PR Abteilung erreicht werden können.

  • Das sehe ich auch so. Die DG ist sich zu oft zu sicher, dass der Fehler beim Kunden liegt. Dafür macht die DG zu oft eigene Fehler und dokumentiert die Eigenheiten ihrer Anschlüsse zu schlecht. Das beste Beispiel dafür war das VLAN-Durcheinander. Aber leicht ist es sicher nicht, im Support zu entscheiden, ob der Kunde nur besonders stur ist oder wirklich ein Problem hat, das er nicht selber lösen kann, weil es nicht auf seiner Seite liegt.


    Die DG könnte sich wahrscheinlich eine Menge Supportaufwand sparen, wenn die Anschlusskonfiguration robuster wäre. Andere ISPs schaffen es doch auch, dass man nicht stundenlang warten muss, bevor man einen anderen Router anschließen kann. Es würde außerdem sicher helfen, wenn die Unterscheidung zwischen DG-Routern und Kundenroutern nicht mehr bestünde. Macht das irgendein anderer Provider? Mit weniger unnötigem Supportaufwand würden die echten Probleme dann vielleicht auch nicht mehr so leicht unter den Tisch fallen.

  • Der Vertrieb empfiehlt meines empfinden nach auch viel zu leichtfertig, dass die Möglichkeit besteht einen eigenen Router zu benutzen um die Kosten für ein Mietgerät einzusparen. Neben der Tatsache das einige Gerätesparten wie der Telekom Speedport garnicht eingesetzt werden können, weil diese nur PPPoE-Einwahl können, haben auch andere beliebte Router wie die Fritzboxen durchaus das potentiall durch Fehlkonfigurationen Probleme zu verursachen, die der nicht Tech-Affine Kunde nicht so einfach selber gelöst bekommt.


    Die DG eigenen Router kosten zwar unter Umständen Miete, haben aber eben den angenehmen Vorteil, dass diese Plug-and-Play mäßig nur mit dem NT verbunden werden müssen und los gehts.

    Nachdem das DG-Netz hier an den Start ging, war ich einigen Haushalten zu Gast, in denen das DSL-Kabel einfach nur vom Splitter in den NT umgesteckt wurde und die Leute sich wunderten, dass nichts funktionierte...

  • dkweb Nach einer Woche Erfahrung mit dem durch seine Firmware beschnittenen "Basic Router" F@st 5366se kann ich jedem technisch ansatzweise affinen Benutzer dringend zum eigenen (oder für 5€ mietbaren 7590) Router raten.


    Damit hast Du allerdings Recht: Plug&Play für nicht so versierte Menschen ist nur mit den Mietgeräten gegeben.


    Auszugsweise:

    Systemlog wenig detailliert

    Kein alternativer DNS einstellbar (oder azev dafür zu ungeschickt)

    Kein DNS über TLS

    Dann und wann kein IPv6 - reboot oder besser Reset hilft zuverlässig.

  • Unter "Telefonie/Eigene Rufnummern/Anschlusseinstellungen" war der Haken bei "Für Internettelefonie eine seperate Verbindung nutzen (PVC)" aktiviert. Das erklärt natürlich alles :) . Interessant ist jedoch die Tatsache, dass diese Konfiguration fast 1 Jahr lang problemlos funktionierte.

    Interessanter finde ich die Tatsache das dieser Haken den Reset auf Werkseinstellungen überlebt hat. ;) Gibt es dafür auch eine Erklärung?

  • Interessanter finde ich die Tatsache das dieser Haken den Reset auf Werkseinstellungen überlebt hat. ;)

    Wenn ich das wäre, aber ohne die Erfahrung, die ich mit deren Anschlüssen inzwischen habe, hätte ich den Router zurückgesetzt, und ausprobiert, ob's dann geht. Das wäre erfolglos geblieben, weil mir niemand etwas von der nötigen Wartezeit gesagt hat. Vielleicht hätte ich noch bemerkt, dass sogar die Telefonie nicht mehr geht, die ja dann den selben verweigerten Internetzugang benutzen würde wie der Rest. Nach dem Test hätte ich das Backup wieder eingespielt. Die Anschlusskonfiguration der DG ist echt nicht robust genug für hektisches Ausprobieren.

  • alfalfa Als Privatpersonen kann man da ja noch warten. Wie soll das denn Laufen, wenn Dienstleister X zum Kunden muss um schnell den Router zu tauschen oder ähnliches. Anschließen, konfigurieren, dem Kunden sagen, dass er eine Stunde warten muss und dann hoffen, das der Kunde nicht anruft und alles nach einer Stunde geht? Wenn man Pech hat, darf man dann nach einer Stunde wieder kommen, weil die unrobuste DG Konfig noch einen anderen Fehler hat.


    Mir graußt es da jetzt schon :D

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden