Beiträge von Waishon

    Ich nehme an, dass man für GPON basierte Anschlüsse bei der Deutschen Glasfaser eine ONT-Installationskennung benötigt, sprich Zugangsdaten.


    Ich denke, dass die Deutsche Glasfaser diese Installationskennung aktuell noch nicht rausgibt. Die Medienberichte beziehen sich vermutlich auf AON-basierte Zugänge.


    tec79

    Teste mal VLAN360 und für Telefonie 330.

    Der Meerfarbig Speedtest-Server hat wohl TCP-BRR als Congestion Control aktiviert. Dementsprechend gibt es dort deutlich bessere Bandbreiten auf den vollen Links der Deutschen Glasfaser, während viele andere Speedtest Server den Standard TCP-Cubic Algorithmus nutzen, der etwas "Mitbenutzer" Freundlich ist, weswegen die Bandbreite geri ;).


    Mit UDP bekomme ich Abends auch fast 500Mbit/s durchgeprügelt, bevor ein signifikanter Packetloss aufritt.

    Du musst dafür die Javascript-Konsole des Browsers öffnen. Zum öffnen der Dev-Tools im Firefox oder Chrome F12 drücken (alternativ Rechtsklick -> Untersuchen) und auf den Reiter "Console" klicken. Dort kannst du den Befehl von oben einfach eingeben. Dann einfach das Formular ausfüllen und die Validierung sollte nicht mehr meckern.


    Funktioniert eigentlich die DMZ Einstellung für den Raspberry PI? Haste die mal probiert, um andere Probleme auzuschließen?


    Hinweis:

    Achja und du musst natürlich bei der Local-IP deine Public IPv6-Adresse des Raspberry PIs eintragen. Nicht die ULA (fd00:). Der Router macht natürlich kein NAT. Nicht das das schon das Problem war :D Habe ich in deinem Post aber auch gerade übersehen. (Ich habe es in meinem Beispiel nur gemacht, weil mein Basic Router nicht angeschlossen ist).

    Bitte weiter erforschen, ob das geht. Also wenn ich das richtig verstanden habe, ist "remote" das Gerät im LAN und "local" entweder das Gerät im Internet oder die WAN-Schnittstelle, was aber egal ist, weil man für "local" einen * eintragen kann. Und das soll man ohne Anleitung erraten, liebe DG und Sagem? <X:cursing:

    Siehe Edit 1. Ich vermute, dass es doch andersherum richtig ist. Zumindest deutet das Javascript darauf hin:

    "Local" = "Source" = "BR-LAN-Interface" = fd00::

    "Remote" = "Destination" = "DATA-Interface" = 2a00::


    Und für Remote, muss man entsprechend ein "*" eingeben mit der Javascript-Modifikation.


    Bracew

    Teste mal bitte mit Remote "*" und die Javascript-Modifikation, damit der DG Router das schluckt.

    Ich habe hier gerade nochmal meinen Basic Router rausgekramt und mir die GUI angeschaut. Habe den allerdings nicht angeschlossen, von daher kann ich nicht sagen, ob es klappt, aber vielleicht ist das schon die Rätsels Lösung :D


    Ich habe mir zunächst die Einstellungen bei Port-Forwarding angeschaut, wie der eine automatische Regel für "Age-Of-Empire" anlegt:

    Wir sehen, dass man als External Host offenbar ein "*" eintragen kann, wenn diese Regel für alle externen IP-Adressen gelten soll.


    Als nächstes habe ich mir mal den JSON-Request angeschaut, den das Frontend an das Backend beim Anlegen einer IPv6-Firewall Regel sendet und siehe da: Die Bezeichnung in der GUI ist völlig willkürlich und beschreibt so gar nicht, was das Feld eigentlich macht:

    Offenbar ist das Feld "Local-IP" die Source-IP und das Feld "Remote-IP" die Destination, sprich unsere ULA. Es ist also genau andersherum, wie man es erwarten würde (in diesem Beispiel habe ich es auch zunächst intuitiv falsch herum gemacht, deswegen ist die fdaa:: auch die Source-IP, obwohl das eigentlich die Destination sein muss).


    Im Feld Local-IP kann man wie beim IPv4-Portforwarding ein "*" eintragen. Schreibt man beim Port ebenfalls ein "*" rein, so wird dieses durch eine "0" ersetzt. Ich vermute, dass dies heißt "Match-Any-Source-Port". Konkret hatte alfalfa schon Recht mit seiner Vermutung, das die Regel sowohl Source als auch Destination matcht. Aber wer kommt bitte darauf, dass man da ein "*" eintragen kann, für "Match-Any" :D


    Die Regel sieht somit so aus:

    Leider konnte ich es nicht testen. Ich bin für Feedback dankbar, ob es so klappt :D


    P.S. Die Übersetzungen und Labels der Felder sind an allen Ecken und Kanten völlig falsch. Wenn man wirklich wissen will, was ein Feld macht, sollte man über das Developer Menü des Browsers in den JSON-Request schauen.


    Edit: Ich sehe gerade im JSON, das das SourceInterface und DestinationInterface ggf. vertauscht ist. Man müsste also unter RemoteIP ein "*" eintragen, da die Destination auf dem DATA-Interface ist (sprich Internet) und die Source auf dem LAN-BR-Interface, sprich Local. Die Konfiguration erlaubt die GUI allerdings nicht. Modifiziert man aber den HTTP-Json Request und sendet ihn per CURL schluckt der Router diese Einstellung ohne zu meckern. Sollte die Lösung oben also nicht gehen, schaue ich mal ob ich eine einfache Lösung finde die Validierung im Frontend auszuknipsen :D

    (Die Aktion bitte einmal ignorieren. Das war nur ein Test, ob der das überhaupt schluckt :D)


    Edit2: Um die IPv6 Validierung für die Remote-IPv6 Adresse auszuhebeln um ein "*" einzutragen kann man folgenden Befehl in die Browser Konsole eingeben:

    Code
    1. $.util.isValidIpv6 = function(str) { return true; }

    alfalfa

    Gäbe es irgendwo im Forum die Möglichkeit eine Liste zu erstellen nach dem Schema:

    PoP-Ort (bzw. Region reicht):

    CGNat-Subnetz:

    IPv4-Gateway:

    CGNAT Exit:

    IPv6-Gateway:

    Betroffen von Problemem?:


    Vielleicht sieht man dann ein Muster. Ich fange mal an:

    PoP-Ort (bzw. Region reicht): Visbek

    CGNat-Subnetz: 100.80.0.0/14

    IPv4-Gateway: 100.80.0.1

    CGNAT Exit: ve713.cgn2.int1-dus.dg-w.de (185.22.44.29)

    IPv6-Gateway: 2a00:6020:1000:30::1

    Betroffen von Problemem?: Jap, massiver Einbruch am Abend auf teilweise 3-4Mbit/s zu MyLoc, Meerfarbig, Hetzner. Alles was am DECIX und ECIX hängt

    Moin,


    heute wurde mein Deutsche Glasfaser Anschluss ebenfalls aktiviert. Ich hänge allerdings auf der Reservefaser, da die Hauptfaser offensichtlich defekt ist. Das ist allerdings eine andere Geschichte.


    Mein Anschluss wurde gegen 19:00 Uhr freigeschaltet und ich kann genau das identische Fehlerbild mit dem gleichen ONT feststellen.


    Ich habe allerdings erstmal einen Basic-Router genommen, bis die Kinderkrankheiten eines neuen Ausbaugebiets behoben sind, sodass der Support mich nicht immer versucht abzuwimmeln, weil man einen eigenen Router hat ;). Später wird der natürlich durch einen eigenen Router ausgetauscht (was ohne Änderung der Vertragslaufzeit möglich ist).


    Habt ihr inzwischen etwas herausgefunden, woran es bei euch gelegen hat?


    Edit: Das Problem hat sich in der Nacht automatisch behoben. Am nächsten Morgen war der ONT freigeschaltet.

    Ich würde folgendes machen (und so mache ich das auch öfter bei Kunden mit dem gleichen Problem):


    Die FritzBox stellst du in deinen Anschlussraum. Für Raum Nr. 4 besorgst du dir noch eine Fritzbox 4040, die du dann über die Dose in Raum Nr. 4 mit der FritzBox im Anschlussraum verbindest.


    Das hat jetzt mehrere Vorteile:

    - Du hast WLAN über die Fritzbox 4040 (die sich die WLAN Einstellungen von der "Haupt-Fritzbox" zieht) in Raum Nr 4..

    - Du hast WLAN über die Haupt-Fritzbox im Anschlusskasten (je nachdem wie weit die auseinander sind hast du die WLAN Abdeckung deutlich verbessert).

    - Die Fritzbox 4040 ist nun über Gigabit mit der Haupt-Fritzbox verbunden, sodass du selbst mit Gigabit Glasfasertarifen später in kein Problem rennst.

    - Die Haupt-Fritzbox im Anschlussraum ist nun ein Switch, wo du auch noch Geräte aus den anderen Räumen per Netzwerkkabel anschließen kannst (wie von dir gewünscht).


    Nachteil:

    - Einmalige Investition in eine Fritzbox 4040. Die kostet aktuell ca. 75€. Würdest du jetzt mit Cable Sharing Adaptern + Switch anfangen währst du auch bei ca 30€ für eine "Murks-Lösung" ;).

    - Dein Technikkasten geht eventuell. nicht mehr zu. Da hilft vielleicht viel Fluchen und Spucke oder alternativ den Technikkasten etwas umzubauen, sodass Platz für eine Fritzbox entsteht.

    Moin,


    ich nehme an du meinst DSL?


    Kurze Antwort: Nein.


    Lange Antwort:

    Theoretisch ja, praktisch eher nein.


    Bei DSL ist die mögliche Datenrate zum Großteil von der Länge der Kupferleitung abhängig. Dadurch das alle anderen Leute aus dem Dorf den Anbieter wechseln wird deine Leitung nicht länger ;). Des Weiteren ist DSL kein Shared Medium (zumindest auf TAL Seite nicht), sodass du dir die Bandbreite nicht mit den Nachbarn teilst im Gegensatz zum Coaxialkabelnetz.


    (Natürlich kann auch das Backbone deines ISPs überlastet sein, allerdings gehe ich davon erstmal nicht aus, sodass sich hier bei weniger Kunden nichts ändern würde. Solltest du beim Magenta Riesen sein, schließe ich das sowieso erstmal kategorisch aus).


    Was aber eine Rolle spielen kann, ist das sogenannte Übersprechen von im Boden parallel liegenden Leitungen. Wenn über viele dieser Leitungen parallel Daten fließen kann es zu gegenseitigen Störungen kommen. Dies wird inzwischen durch die Vectoring Technologie vermindert.


    Deine 16k Leitung kann jetzt über zwei Wege geschaltet werden:

    1. Du hast ein Full-Profile geschaltet (100/40+ bzw. 50/10+), sprich das was deine Leitung praktisch hergibst und wirst dann vom BNG der Telekom auf 16k gedrosselt. Da dies über Vectoring realisiert wirst profitierst du nicht von weniger Kunden.

    2. Du bist über ADSL2 geschaltet. Hier gibt es kein Vectoring. Mir ist allerdings nicht bekannt, das es hier bei zu vielen gleichzeitigen Nutzern zu so massiven Störungen kommt, das du das als Endnutzer in der Bandbreite praktisch merkst (verbessert mich gerne).


    Mit dem entsprechenden Equipment wirst du vermutlich bei weniger Kunden eine Verbesserung der Leitungsqualität feststellen, deswegen das "Theoretisch ja". Allerdings, behaupte ich mal, wirst du daraus keine signifikante Verbesserung deiner Leitung bekommen.


    Wenn du magst, kannst du einmal deine aktuellen Leitungsinformationen aus der Fritzbox (sofern du eine hast) schicken. Das wäre zur Einschätzung einfacher. Die findest du unter Internet -> DSL Informatin -> Reiter: DSL

    Moin,


    ja die DG wehrt sich gefühlt mit Händen und Füßen gegen eigene Router. Bei eigenen Routern wird zudem der Support gänzlich verweigert und an AVM verwiesen, selbst bei offensichtlichen Fehlern auf DG Seiten. In Kombination mit der völlig unrobusten Anschlusskonfiguration und den kaputten DHCP Servern macht der Betrieb eines eigenen Routers wenig Spaß, bzw. erfordert im Störungsfall gute Nerven ;).


    Ich sehe da aber aktuell wenig Aussicht auf Verbesserung. Wie in anderen Threads bereits mal diskutiert: Der Support ist auf die geschätzten 99,5% der "Normalen Benutzer" ausgelegt, die eine Fritzbox haben, sei es gemietet oder eine eigene. Ich war letztens Erstaunt als ich einen Supportfall bei einem gemieteten Router hatte. Innerhalb weniger Minuten war das Problem gelöst (fehlerhafte SIP Zugangsdaten), wo ich mit eigenen Router vermutlich ewig hinterher rennen musste.


    Außerdem gibt es, wie es mir scheint, den Fall "Kunde besitzt eigenen Router, der keine Fritzbox ist", in der Support Bedienungsanleitung schlicht nicht und es gibt auch meins Wissens keinen Weg um am Support-Simulator mit eigenen Router, der keine Fritzbox ist, wirklich schnell und effektiv weiter zu kommen ;).


    Ich kann mir vorstellen, das dies auch etwas am schnellen Wachstum der DG liegt. Es wird schneller gebaut, als die Infrastruktur hinterherkommt. Gleiches gilt für den Support. Vielleicht/Hoffentlich bessert sich dies noch mit der Zeit.


    Falls jemand später auf den Thread stoßen sollte: Folgende Einstellungen werden in der Regel bei der DG verwendet.

    SLAAC: Deaktiviert

    DHCPv6_IA für /64 für den Router selber, sprich das was auf dem Uplink Interface zum ONT kommt

    DHCPv6_PD mit /56 Präfixlänge anfragen (glaub selbst wenn du /64 anfragst bekommste /56).

    Router Advertisments für die Default Route gibt es zusammen mit dem DHCPv6 Advertisment (absolut nicht Standardkonform, macht die DG aber trotzdem). Folglich den Empfang von RAs aus dem Uplink Interface aktivieren

    Router Solications: Ignoriert bzw. blockiert die DG völlig weg.

    Ein großes Problem ist nach wie vor, das AVM immer noch kein IPv6 VPN bietet. Das würde viele Dinge vereinfachen. Dementsprechend funktioniert dein VPN auch nicht, sofern du den auf der Fritzbox nutzt.


    Du schreibst das du einen NAS nutzt. Viele Consumer-NAS Geräte haben eine VPN Funktion die ebenfalls IPv6 unterstützt. Diese könntest du nutzen für den Remote-Zugriff auf dein Netzwerk.


    MyFritz dagegen hat IPv6 Support und der MyFritz AAAA DNS Record löst auf deine IPv6 Adresse der Fritzbox auf.


    Warum dein Port Forwarding vermutlich nicht geht:

    Bei IPv6 gibt es auf der Fritzbox kein NAT mehr, da es genug Adressen gibt. Jedes deiner Geräte hat eine eigene globale IPv6 Adresse. Die Freigabe in der FritzBox öffnet ausschließlich die Firewall, sodass eine Kommunikation zu deinem Endgerät mit der globalen IPv6 Adresse auf dem angegebenen Port möglich wird. Die MyFritz Adresse zeigt allerdings auf deine FritzBox und nicht auf das Endgerät dahinter. Somit erreichst du auch nichts auf dem Port.


    Zum Thema Portfreigabe gab es hier bereits Diskussionen:

    IPv6 Portfreigabe funktioniert nicht


    IPv6 Ping Funktioniert nicht

    Okay, ich habe eine eigene 7590. Bei mir sind die Speeds zu Hetzner auch stabil bei 50 Mb/s über IPv4/v6. Wenn ich mein Laptop direkt an ONT anschließe komme ich zu gleichen Ergebnissen.

    Du meinst auch 50MB/s? Nicht 50Mbit/s? Sprich du bekommst deine 400Mbit/s zu Hetzner durch?


    Das ist alles total merkwürdig :D. Wir haben aktuell bei uns im Dorf fast überall nur 70Mbit/s zu Hetzner, während ein paar wenige Anschlüsse scheinbar volle Bandbreite bekommen. Keine Ahnung ob da nen Load Balancing läuft.

    Moin,


    wir haben glaube ich neue Erkenntnisse, sind aber noch am Debuggen des DG Anschlusses, deswegen als Disclaimer: Das sind ausschließlich Vermutungen und müssen noch genauer überprüft werden.


    Ich war heute bei einem Kunden um einen Deutsche Glasfaser Anschluss in Betrieb zu nehmen. Dieser nutzte eine gemietete FritzBox 7590. Ich war sichtlich erstaunt, als an diesem Anschluss beim Download der Datei speed.hetzner.de/1GB.bin die Downloadrate auf 50MB/s kletterte und stabil blieb. Ich also zurück an meinen Anschluss und einen Speedtest mit der gleichen Datei gemacht: Downloadrate 2-8MB/s und völlig instabil. Die beiden Anschlüsse sind am gleichen PoP. Ich nutze einen Kundeneigenen Router (genauer EdgeRouter 4).


    Die erste Vermutung war, das die FritzBox 7590 dort irgendeine Magic fabriziert. Also den Traffic mitgeschnitten und gesehen, das sämtlicher Traffic über VLAN 360 geht O_o. Gleichzeitig scheint es für VoIP und TR-069 nochmals ein eigenes VLAN zu geben (342 und 330). Über VLAN 0, sprich untagged, gibt es außschließlich die Möglichkeit die Provisionierungskonfiguration des Routers zu laden.


    Um die FritzBox als "Verschnellerungsmagie" auszuschließen, haben wir den DHCP-Request der Fritzbox 7590 mitgeschnitten und mit dem dhcp-test-tool (https://github.com/saravana815/dhtest) die DHCP-Anfrage der DG über das VLAN 360 (Internet) nachgebaut. Wir haben vom DHCP Server eine IP bekommen, die wir uns dann statisch auf das VLAN Interface 360 gesetzt haben.


    Das Ergebnis war, das am Laptop die volle Bandbreite des gebuchten Tarifs ankam.


    Wir haben die Vermutung, das Anschlüsse mit Kundeneigenem Router offensichtlich ein anderes DG internes Routing haben als die Anschlüsse mit einem DG Router über VLAN 360 und somit langsamer sind. Mit den Leuten mit denen ich bisher gesprochen habe, die ein Bandbreitenproblem haben nutzen alle einen eigenen Router. Diese These wäre auch noch zu verifizieren.


    Die jetzt noch offene Frage ist: Könnte man einen Basic Router bestellen und dann den eigenen Router über VLAN 360 betreiben. Wir werden das mal testen ;)

    Hat die Bundesnetzagentur denn auch eine API, die man ansprechen kann? Es macht doch wenig Sinn, nur eine punktuelle Messung zu machen. Da können die Ursachen doch sonstwo liegen. Aber aus den kontinuierlichen Messungen sieht man sehr schön den Einbruch der Bandbreite am Abend.


    Kennt jemand die Server-ID des von der DG verwendeten Ookla-Servers? Dann könnte ich als Vergleich auch mal gegen den die Speedtests laufen lassen. Aber einen Server durch QoS so zu priorisieren, dass er volle Bandbreite hat, ist ja kein Kunststück. Da finde ich Werte gegen unterschiedliche Server aussagekräftiger.


    Ddas mit der Presse ist eine gute Idee. :)

    Die Breitbandmessung ist nunmal, meines Wissens nach, das einzige womit die BNetzA arbeiten, kann, weil die Sicherstellen können, das der Speedtest Server nicht das Problem war zu dieser Zeit. Das ist wichtig, wenn die BNetzA die DG zur Stellungnahme auffordern will, da es mit Speedtest.net Servern schlicht nicht rechtssicher ist und die DG das sofort auf die Speedtest.net Gegenstellen schieben wird.


    Deswegen machst du mit dem Tool ja auch 20 Messungen. Die muss man leider manuell machen, aber das kann man ja mal an einem Wochenende machen, indem man jede Stunde auf den Knopf drückt. Am Ende fällt eine PDF raus mit weitaus mehr Informationen, als dein Speedtest.net liefern kann. Unter anderem die Traceroute von Server -> Client. Die PDF kannst du der BNetzA schicken.


    Die DG betreibt keinen öffentlichen Speedtest.net Server, sondern hat sich den Custom Speedtest.net bei Ookla eingekauft zum selber hosten. Der Speedtest auf der DG Seite ist nur ein IFrame, den kannst du seperat öffnen.


    Ich bezweifel, das die DG QoS zum eigenen Speedtest Server macht. Erfahrungsgemäß sind die Engpässe tatsächlich in den Transits/Peerings bzw. in deren Core Routern. Der Speedtest Server steht davor.

    Es gibt von der Bundesnetzagentur die Breitbandmessung. Das Windows Tool nimmt 20 Messungen auf und erstellt im Anschluss ein genaues Protokoll inklusive Traceroutes und der gemessenen Datenrate pro Messung. Das kannst du dann bei der BNetzA einreichen. Ob das was bringt, kann ich nicht sagen. Wenn das aber viele machen ändert sich vielleicht etwas.


    Ich nehme an, der Speedtest auf der DG Seite zeigt immer die volle Bandbreite an? Der 1st Level Support verweist dich nämlich immer ausschließlich auf diesen Speedtest, da dieser immer die volle Bandbreite liefert. Ich nehme an, das die Peering und Transit Kapazitäten in deren Backbone einfach überlastet sind.


    Erfahrungsgemäß handelt die DG nur, wenn es schlechte Presse gibt, denn die ist denen hoch und heilig, sprich wenn Heise oder Golem schlecht über die DG berichten.

    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

    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.