Beiträge von alfalfa

    Der Server akzeptiert ganz sicher mehr als nur ein Gerät, aber halt nicht viele in kurzer Zeit. Und manchmal scheint es den Fehler zu geben, dass ein bestimmtes Gerät partout keine IPv6 Adressen bekommt. Wenn man den DUID ändert, bekommt das Gerät dann vielleicht doch Adressen.


    Die WAN-Konfiguration beim Level1-Router sieht so aus, als müsste es gehen (auch wenn ich wegen der Firewall-Geschichte aus dem anderen Thread nicht weiß, warum das überhaupt erstrebenswert ist). Der DUID-Wert ist vom Typ "Link-Layer". Nach der 0003, die diesen Typ kennzeichnet, kommt 0001 für Ethernet und dann wahrscheinlich die MAC-Adresse vom WAN-Interface. Vielleicht kann man den Wert ändern, indem man eine andere MAC-Adresse cloned (weiter unten auf der Seite). Ich würde noch "PD Enable" (Prefix Delegation) einschalten, damit die Geräte im LAN auch Adressen bekommen können. Rapid Commit kann man auch mal probieren.

    Der DUID ist der DHCP Unique Identifier. Warum der DHCPv6 Server teilweise auf Requests mit einem bestimmten DUID-Wert auch nach längerer Zeit nicht antwortet, auf Requests vom selben Gerät nach Änderung des DUID aber dann doch, weiß nur die DG. Ich finde das auch merkwürdig. Man könnte zwar sagen, dann ändere ich eben den DUID, aber das ist bei vielen Routern gar nicht vorgesehen.


    Es ist möglich, dass der Level1-Router unter "AUTO" nicht eine automatische Protokollauswahl sondern nur die "stateless address autoconfiguration" (SLAAC) versteht, also dass sich der Router mit Hilfe eines per Router Advertisement gelernten Präfixes selbst eine Adresse erzeugt und per Neighbor Discovery überprüft, dass die nicht schon verwendet wird. Die Router Advertisements am DG-Anschluss verkünden aber kein Präfix, sondern nur, dass "managed address configuration", also DHCPv6, zu verwenden ist.

    Die Signalwerte sind in Ordnung.


    Ohne die konkrete Konfiguration der Fritzbox zu kennen, würde ich darauf tippen, dass der Fritzbox die vielen Verbindungen Probleme bereiten, sofern NAT und/oder die Firewall aktiv sind. Selbst wenn nur 3 IP Adressen im Spiel sind, sind bei 500-1000 WLAN Clients doch viele tausend gleichzeitig zu trackende Verbindungen zu erwarten.


    Wenn die Fritzbox einen Tag durchhält, könnte man vorübergehend mit einer einfachen Zeitschaltuhr immer mitten in der Nacht die Fritzbox kurz stromlos machen, um den nächsten Tag wieder frisch zu beginnen. Nicht schön, aber wenn's funktioniert...


    Ein Netz dieser Größe rechtfertigt m.M.n. professionellere Hardware.

    Gerade dieses Testen mit mehreren Geräten scheint solche Probleme auch mal auszulösen. Die Anschlusskonfiguration bei der DG scheint mir nicht sehr robust zu sein. Eigentlich müsste es ja möglich sein, es auf Anbieterseite so zu konfigurieren, dass nur das letzte Gerät bedient wird, welches sich am Anschluss gemeldet hat, und alle vorherigen Adresszuweisungen damit verfallen. Das ist aber nicht so. Es werden u.U. mehrere Präfixe gleichzeitig auf einen Anschluss geroutet, wenn mehrere Router/Geräte hintereinander per DHCP angefragt haben. Vermutlich deshalb "wehrt" sich der Anschluss, wenn er zu viele Geräte sieht.


    "Immer eine native IPv4-Anbindung nutzen" auf Seite 3 der Anleitung für die Fritzbox 7390 ist die universelle Einstellung. Man kann nicht an allen DG-Anschlüssen IPv6 ohne IPv4 nutzen, weil IPv6 an älteren Anschlüssen teilweise mittels 6rd getunnelt wird, und dafür wird IPv4 benötigt. Eine reine IPv6-Konfiguration müsste möglich sein, aber wirklich getestet habe ich das nicht, und man kommt ohne IPv4 auch noch nicht zurecht.


    Das Problem, dass keine IPv6 Konfiguration zugewiesen wird, wird auch in anderen Foren immer wieder mal vorgetragen. Eine wirkliche Lösung habe ich bisher noch nicht gesehen. Der Support kümmert sich nicht wirklich um kundeneigene Router. Am ehesten kommt man noch zu einem Ergebnis, wenn man eine Fritzbox hat, weil die DG inzwischen auch selbst Fritzboxen vermietet. Sonst muss man schon genau belegen können, dass die Ursache auf der Netzbetreiberseite liegt. Die Supporter schieben die Schuld sehr schnell auf den Router des Kunden. Ich hatte das Problem auch schon und konnte es nur durch DUID-Änderung "lösen", bei ansonsten identischer Konfiguration. Die DG muss in Sachen problemlose Anschlusskonfiguration noch sehr viel lernen, besonders weil der Support praktisch keine Hilfe ist, wenn man nicht hartnäckig und gezielt mit Fachwissen nachhaken kann.

    Ich antworte mal in "deinem" Thema statt im anderen Thread:

    Zitat

    Ist es eigentlich notwendig hinter dem Medienkonverter einen Modem zu betreiben?

    Nein, der Medienkonverter hat die Funktion eines Modems an einem herkömmlichen Internetanschluss. Der Medienkonverter wird mit einem Glasfaserkabel an die Glasfasersteckdose angeschlossen und mit einem (normalen elektrischen) Netzwerkkabel an den Router -- so wie ein Modem mit einem Telefonkabel an die Telefondose angeschlossen wird und mit einem Netzwerkkabel an den Router.

    Ich sitze genau so viel oder wenig an der Quelle wie du. Ich bin DG-Kunde mit einem Anschluss, an dem ein G-010G-P werkelt.


    Den NT kann man auf Werkseinstellungen zurücksetzen. Hinter einem kleinen Loch auf der Seite mit den Anschlüssen befindet sich ein Taster. Den drückt man leicht und hält ihn etwa 10 Sekunden gedrückt, bis alle LEDs zweimal geblinkt haben. Der ONT sollte nach meinem Verständnis nicht an der Adressvergabe beteiligt sein. Die DG verlangt diesen Werksreset aber sogar selbst, bevor man einen Speedtest durchführt, wenn man Probleme mit der Geschwindigkeit meldet. Also kann der Werksreset anscheinend nicht schaden.


    Der Router muss seine Adresse und das Präfix für die Geräte im LAN per DHCPv6 abrufen. Die Router Advertisements schreiben "managed address configuration" vor. Das 331 Seiten starke Handbuch des Level1 Routers hat dazu eine halbe Seite (S.232) und wenn die Einstellung "AUTO" nicht das Richtige macht, dann geht es wohl nicht. Die anderen genannten Wahlmöglichkeiten ("static IP", "PPPoE" und "Bridge") sind jedenfalls falsch.


    Ich würde zumindest zur Fehlersuche immer einen OpenWRT-Router oder eine Fritzbox bereithalten, selbst wenn es nur 100Mbit/s-Geräte sind. Die sind so verbreitet, dass man davon ausgehen kann, dass die an einem funktionierenden Anschluss laufen.

    Das online zu findende Handbuch passt nicht zu der Firmware, mit der der NT ausgeliefert wird. Es gibt da aber auch wirklich nichts einzustellen oder zu sehen, was irgendwie wichtig wäre. Ich habe nachgeschaut.


    Wegen des DHCPv6 Servers würde ich mal einen Tag warten, wenn man vorher am Anschluss experimentiert hat.

    Der IPv6 DHCP-Server lässt sich auch im Normalfall manchmal viel Zeit. Der nimmt es auch übel, wenn er zu viele wechselnde Geräte direkt am NT sieht, und schmollt dann. Wenn ein Router auch nach längerer Wartezeit keine Adressen bekommt, kann man versuchen, das Problem an der Hotline zu erklären. Nicht damit abwimmeln lassen, dass der Router doch eine fe80-Adresse habe.


    Ohne eigene IPv6 Adressen nützt auch keine leicht merkbare IPv6 Adresse zum anpingen etwas, aber 2001:4860:4860::8888 ist einer der öffentlichen Google DNS-Server. Der antwortet auf Pings. FE80-Adressen sind link-local Adressen, die nicht geroutet werden. Die dienen nur der Kommunikation mit anderen Geräten im selben LAN. Den Google-DNS kann man damit nicht anpingen.


    Sobald der G-010G ONT glasfaserseitig eine Verbindung hat, ist er nicht von der Ethernetseite erreichbar. Das ist keine Fehlkonfiguration und kein Hinweis auf einen Defekt.

    Das Handbuch ist ziemlich abenteuerlich. Lang, ausführlich, aber mit reichlich Fehlern. Auf der Seite 237 über "Port Filtering" stehen so bedenkliche Sätze wie "Enable/Disable the WAN packet filter. Default setting is Disable." und "Enter the port range to be filtered for both Outbound and Inbound packet". Es hat den Anschein, dass die Firewallfunktionen alle symmetrisch sind, also unabhängig von der Richtung WAN2LAN und LAN2WAN gleich sperren. So kann man natürlich nichts wirklich ausfiltern, weil man sonst vom Client auch keine Verbindungen aufbauen kann. Mit IPv4 scheitern die Verbindungen wahrscheinlich nur an NAT, was kein vollständiger Schutz ist.


    Level1 hat eine Support-Email-Adresse ins Handbuch geschrieben. Vielleicht können die erklären, wie man den Router sicher konfiguriert.

    Schau mal in der Anleitung nach, ob man die Firewall evtl. erst einschalten muss. Welche Adressen auf der WAN-Seite verwendet werden, darf die Firewall nicht beeinflussen. Die Seite hast du ja im Normalfall nicht unter deiner Kontrolle. Typische SPI-Firewalls haben eine Regel, die Pakete vom WAN-Interface nur reinlässt, wenn sie zu einer bestehenden Verbindung gehören. Dafür braucht man keine Adressen zu testen.

    Vielen Dank für die Tests. Dieses Ergebnis habe ich dann doch erwartet. Für meinen Anschluss wäre der also nichts...;)


    Diese Durchläufe testen übrigens die Uploadrichtung. Für die umkehrte Richtung wäre noch ein -R anzuhängen. Das sollte aber keinen großen Unterschied machen.


    Du könntest noch die Firewall testen, indem du den Server auf der LAN-Seite und den Client auf der WAN-Seite startest. Das sollte nicht funktionieren, bis du den LAN-seitigen Server in der Firewall des Routers freischaltest. Würde ich für den ruhigen Schlaf prüfen, wenn das mein Router zum Internet hin wäre.

    Ich vermute, dass ich diese beiden Konfigurationsseiten bearbeiten muss:

    LAN-Settings

    WAN-Settings

    Im Prinzip das gleiche wie bei IPv4: Die beiden PCs brauchen jeweils eine Adresse, eine Netzmaske und ein Gateway. Der Router braucht eine WAN-Adresse, eine WAN-Netzmaske, eine LAN-Adresse und eine LAN-Netzmaske. Alles andere ist optional. Konkret:


    PC auf der WAN-Seite: fd01::3, Präfixlänge 64, Gateway fd01::2


    Router WAN-Seite: fd01::2, Präfixlänge 64

    Router LAN-Seite: fd02::1, Präfixlänge 64


    PC auf der LAN-Seite: fd02::2, Präfixlänge 64, Gateway fd02::1


    Die Schreibweise :: ist eine Abkürzung für "restliche Viererblöcke mit Nullen auffüllen". fd01::3 heißt fd01, dann nur Nullen und dahinter noch ein Block mit 3, also fd01:0000:0000:0000:0000:0000:0000:0003, was man auch als fd01:0:0:0:0:0:0:3 schreiben kann.


    Server auf dem PC auf der WAN-Seite starten, damit die Firewall im Router nicht dazwischenfunkt. Es sollte reichen, auf dem Client als Serveradresse fd01::3 anzugeben. iPerf weiß selbst, dass das eine IPv6 Adresse ist. Nach dem Test nicht vergessen, die statische IPv6 Konfiguration der PCs wieder auszuschalten.

    Danke für den Test. Die Routing Performance ist viel besser, als ich erwartet hatte.


    Wenn ein Test mit IPv6 möglich ist, wäre das Ergebnis auch noch interessant, besonders für den Einsatz an einem Deutsche Glasfaser Anschluss. Die günstigen Router erreichen ihre Routingleistung oft nur durch Hardware Offloading, das aber teilweise nur für IPv4 implementiert ist.

    Das passt so. 12 Fasern sind nicht nötig, schaden aber auch nicht. Je Verbindung werden zwei Fasern verwendet. Es gibt auch Übertragungsstandards, die nur eine Faser benötigen, aber die Technik für zwei Fasern ist günstiger. Für die Distanz ginge auch Multimode, aber Singlemode wie angegeben hat mehr Möglichkeiten, z.B. wenn über das Kabel später mal eine FTTH-Verbindung laufen soll. Die Spleißbox sollte genug Platz für so viele Steckeradapter bieten wie benötigt werden. Ein normal großer Adapter hat Platz für einen SC-Stecker oder zwei LC-Stecker. Hier ist ein Video, wie so eine Strecke konkret aufgebaut wird:


    Der zweite Router wäre nur dazu da, um per DHCP dem anderen Router und dem PC mit dem iPerf3 Server die Adresskonfiguration zu geben. Wenn man die Adresse des Server-PC und die WAN-Adresse des zu testenden Routers manuell einstellt, braucht man auch keinen DHCP Server. Man kann aber auch auf dem WAN-seitigen PC einen DHCP Server installieren und konfigurieren, anstatt die WAN-Adresse des Routers manuell zu vergeben. Wie immer gibt es viele Möglichkeiten.


    Ich wollte es nicht zu kompliziert machen. Router und PC an vorhandenen Router, zweiten PC an zu testenden Router und mit iPerf3 die Datenrate zwischen den beiden PCs testen. Nur wenn beide Router den gleichen Adressbereich für ihre LANs verwenden, muss man dann noch in die Netzkonfiguration eingreifen, um einen der Adressbereiche zu ändern. Sonst ist es einfach nur stöpseln, testen, fertig.

    Würde es nicht ausreichen, 2 PCs an WAN und LAN des zu testenden Routers anzuschließen und die IP-Adressen der PCs in unterschiedliche Teilnetze zu legen?

    Natürlich würde das auch ausreichen, aber dann muss man das Netzwerk im Router und im WAN-seitigen Computer manuell einstellen. Einfacher ist es mit einem zweiten Router. (Ein wenig Glück, dass die Router nicht den gleichen IP-Adressbereich für ihre LANs verwenden, gehört aber auch dazu.)

    Unser Glasfaseranschluss ist derzeit auf 300 MBps eingestellt, sodass ich zumindest bis dahin die Leistungsfähigkeit prüfen kann. Wenn ich das Laptop direkt an den ONT anschließe, dann kommen bis zu 36 MB/s. Ich werde berichten.

    Auf das Ergebnis bin ich sehr gespannt. Man kann mit zwei Computern und einem vorhandenen Router auch ohne Glasfaseranschluss relativ einfach die (IPv4-)Routingleistung eines neuen Routers messen. Dazu schließt man einen Computer an einen Gigabit-LAN-Port des vorhandenen Routers an, startet dort einen iPerf3 Server und gibt ggf. den Port in der Firewall des Computers für ankommende Verbindungen frei. Den zu testenden Router schließt man mit dem WAN-Port ebenfalls an einen Gigabit-LAN-Port des vorhandenen Routers an. An einen LAN-Port des zu testenden Routers schließt man den zweiten Computer an und startet von dort die iPerf3 Tests als Client. Um Einschränkungen durch andere Einflüsse auszuschließen, sollte man den zweiten Computer auch mal am vorhandenen Router anschließen und den Test so im selben LAN durchführen. Dabei sollten ungefähr 940 Mbit/s möglich sein, sonst bremst irgendwas anderes. (Ein Test mit IPv6 ist etwas komplizierter, weil dafür auf dem ersten Router Prefix-Delegation konfiguriert werden muss.)

    Der LevelOne WGR-8031 arbeitet mit einem Realtek Chipsatz. Realtek ist dafür bekannt, dass die WLAN-Treiber keine gute Qualität haben, und dass keine Bemühungen unternommen werden, Unterstützung für die Hardware in den Hauptzweig des Linux Kernels zu bekommen. Deshalb gibt es keine alternative Firmware für Realtek-Router. Die Originalfirmware arbeitet mit einem veralteten Kernel. Davon abgesehen wird der Router sehr wahrscheinlich am DG-Anschluss funktionieren. Zur Routing-Leistung ist nichts zu finden. Zur Zuverlässigkeit auch nicht.