Posts Tagged ‘FTTH’

Dienstag, 11. Oktober 2016

Turris Omnia: Erste Erfahrungen

Am Freitag, 7. Oktober 2016, wurde mir mein über Indiegogo ge-crowdfundeter Turris Omnia-Router ins Büro geliefert.

Am Sonntag-Abend ging ich mit dem Gerät online. Zeit für ein erstes Fazit:

Fiber7 SFP funktioniert (noch) nicht

Der Router wird mit einem SFP-Slot ausgeliefert. Optimal, dachte ich mir, so kann ich meinen Gerätedschungel lichten und den im Januar gekauften Fiber Media Converter TP-LINK MC220L auf’s Altenteil schicken.

Zu früh gefreut! Wie von mir im offiziellen Forum beschrieben und von Michael Stapelberg bestätigt funktioniert der flexOptix BIDI LX SFP Transceiver aktuell nicht im Router.

Zuerst ging ich (fälschlicherweise) davon aus, dass das Problem bei Turris zu suchen ist, doch ein Tweet von Fiber7 von heute Dienstag, 11. Oktober 2016, legt nahe, dass auf Seite ISP resp. auf Seiten des SFP-Herstellers noch etwas geändert werden muss:

Performance

Eigentlich hätte ich erwartet, dass der neue Router näher an die Schallgrenze (d.h. 1 GBit/s Down- und Upstream) herankommt. Doch mein stündlich laufendes Script, welches die Geschwindigkeit zu Init7s Ookla Geschwindigkeitsserver (Ookla Server ID 3026) misst, sagt etwas anderes aus:

ookla-init7-asus-rt-ac66u-turris-omnia
image-6997

Links sieht man die Werte, die ich mit einem Asus RT-AC66U (Merlin-Firmware und mit deaktivierter Firewall) erzielt habe; rechts (nach dem Unterbruch) die Werte von Turris Omnia (mit aktivierter Firewall).

Beim Client handelt es sich um einen Intel NUC DC3217IYE, welcher mit einem Cat 5e-Kabel über einen 16-Port TP-LINK TL-SG1016D über ein 20m Cat 6 STP-Flachband-Kabel auf einen ZyXEL GS1100-8HP PoE Switch via ein Cat 5e-Kabel am Turris angeschlossen ist.

Ich gehe davon aus, dass die Performance höher wäre, wenn ich einen nicht so schmalbrüstigen Client verwenden würde. Und ja, die Firewall des Turris könnte ich ja eigentlich der Performance wegen auch deaktivieren. Doch mich reizt es, die Crowd-Firewall eingeschaltet zu belassen, um mich und mein Netzwerk besser vor Gefahren aus dem Internet zu schützen.

Doch das spielt hier keine Rolle, weil im Setup einzig der Router selber ausgewechselt wurde, der Rest blieb gleich.

Michael hingegen kommt der Schallmauer gefährlich nahe — 927 MBit/s:

Führe ich speedtest-cli (ein Python-Script) direkt auf dem Turris Omnia aus, erhalte ich folgende Werte:

# ./speedtest-cli --simple --server 3026
Ping: 4.704 ms
Download: 684.35 Mbit/s
Upload: 208.04 Mbit/s

CPU-Auslastung

Dank der Aufzeichnung der Vitalparameter des Routers mittels Cacti musste ich soeben feststellen, dass die beiden CPUs des Gerätes seit heute Mitternacht (sprich seit meinem zweiten, fehlgeschlagenen Test mit dem SFP-Transceiver) 100% beträgt. Auf beiden Cores:

turris-omnia-cpu-0-usage
image-6998

turris-omnia-cpu-1-usage
image-6999

Ein Login auf dem Router und htop zeigen, welche Prozesse die Last verursachen:

turris-omnia-socat-cpu-usage
image-7000

Die Prozesse habe ich direkt in htop mittels F9 und SIGKILL abgeschossen (ein Neustart von socat im LuCI-Interface unter System > Software hat nichts gebracht). Jetzt ist die CPU-Auslastung im einstelligen Prozentbereich und die Load Average bereits bei 0.40.

LEDs

Natürlich dürfen frei konfigurierbare LED-Farben nicht den Ausschlag geben, ein Produkt zu kaufen. Dennoch möchte ich dies nicht mehr missen. Nun sehe ich nämlich von der Eingangstüre unserer Wohnung aus, ob der Router läuft (grünes LED für Power) und ob er mit dem Internet verbunden ist (rotes LED für WAN). Hinzu kommen weiss blinkende LEDs, die mir zeigen, dass im LAN Pakete herumgeschickt werden.

turris-omnia-leds
image-7001

IPv6

Das Ding würde auch IPv6 unterstützen, doch mental, fähigkeitstechnisch und auf Grund meiner leicht komplexeren Netzwerk-Infrastruktur im LAN sehe ich mich derzeit nicht imstande, diesen Schritt bereits zu wagen. Gut zu wissen, dass Turris auf jeden Fall bereit wäre:

Usability

Verwirrend (und unschön) ist es, dass der Router über zwei Web-Oberflächen verfügt: Einerseits das von Turris Omnia selbst entwickelte Foris, welches einen Wizard, aber kaum Einstellungsmöglichkeiten bietet, andererseits das OpenWRT-LuCI-Interface, über welches man jedes hinterste Bit des Routers konfigurieren kann (oder so).

Das letztere Interface kannte ich so bereits von meinem TP-LINK TL-MR3020 Travel-Router, der mich auf Reisen überall hin begleitet. Ganz interessant ist hier der Paket-Manager des Turris, obwohl ich abgesehen von snmpd und ethtool noch kein Paket installiert habe. Die Bedienbarkeit dieses Interfaces ist aber nicht so simpel gehalten wie bei einem Consumer-Router und benötigt deshalb eine gewisse Einarbeitungszeit.

Nachtrag: Unboxing-Photos

Turris vom Flickr-Benutzer Doommeer

Tags: , , , , , , , , , , , , , , , , , ,
Labels: IT

3 Kommentare | neuen Kommentar verfassen

Sonntag, 20. März 2016

Ookla Speedtest für Fiber7 respektive Init7 konfigurieren

Damit der Ookla Speedtest bei mir sauber funktioniert, habe ich mir ein Benutzerkonto angelegt und folgende Einstellungen gemacht:

Ookla Speedtest Fiber7 Settings
image-6587

Von grösster Wichtigkeit ist es, folgenden Server als Standardserver auszuwählen:

Winterthur [CH] - Init 7

(Gemäss dem HTML-Quellcode handelt es sich um den Server mit der Ookla-ID 3026)

Nur so testet man die theoretisch verfügbare Geschwindigkeit zwischen dem eigenen Router, der Telefonzentrale, in welche das Fiber- respektive das Kupferkabel führt, und dem ISP-internen Netzwerk.

Auf der Test-Oberfläche ist dann der Button „BEGIN TEST. YOUR PREFERRED SERVER“ zu wählen:

Ookla Speedtest Begin Test Preferred Server
image-6588

Nachtrag

Noch einfacher geht es für uns Linux-Geeks von der Kommandozeile. Ein findiger Zeitgenosse scheint das Ookla Speedtest-Protokoll reverse engineered und seine Erkenntnisse in einem Python-Script zusammengefasst zu haben.

Nachdem man das Script heruntergeladen und ausführbar gemacht hat, misst man die Geschwindigkeit zum Init7/Fiber7-Speedtest-Server folgendermassen:

$ ./speedtest-cli --server 3026
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Init7 (Switzerland) Ltd. (85.195.234.162)...
Hosted by Init 7 (Winterthur) [117.24 km]: 3.615 ms
Testing download speed........................................
Download: 584.35 Mbit/s
Testing upload speed..................................................
Upload: 498.04 Mbit/s

Tags: , , , , , , , , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 20. März 2016

Gigabit FTTH mit Asus RT-AC66U? Hände weg von DD-WRT!

Ende Januar 2016 wurde unsere Wohnung mit Fiber to the Home (FTTH) von Fiber7 (einer Tochter von Init7) erschlossen. Das konkurrenzlos günstige Angebot umfasst eine symmetrische 1 Gbit/s-Anbindung für weniger als 65 CHF pro Monat.

Die Verbindung zum Internet stelle ich mit einem Asus RT-AC66U und dem optischen Wandler TP-Link MC220L her. Auf dem Asus RT-AC66U lief bis letzte Woche DD-WRT mit dem Release r26332 vom 22. Februar 2015.

Von Powerline zu Ethernet-Kabel

Da ich mich beim Besuch der Elektriker von BKW ISP AG dazu entschied, den OTO im Wohnzimmer installieren zu lassen (die Alternative wäre das Büro gewesen), stellte sich mir das Problem, dass ich bis vor kurzem die maximale ISP-Geschwindigkeit nicht testen konnte: In der Stube betreibe ich einige Multimedia-Geräte wie den TV, den Apple TV sowie einen UniFi AP-PRO. Nur der UniFi WLAN-Access Point verfügt über einen Gigabit-Ethernet-Port — doch mit dem Access Point lässt sich die maximale Performance des Internetanschlusses nur schlecht testen.

Ein Geschwindigkeitstest mit der von Fiber7 empfohlenen Apple TV-App Ookla Speedtest zeigte Durchsätze von annähernd 100 MBit/s — sowohl für den Up- wie auch Downstream. Durchaus realistisch, wenn man bedenkt, dass der Apple TV nur mit einer Fast Ethernet-Schnittstelle ausgestattet ist.

Erst als ich von Digitec das lange vergriffene Wirewin Netzwerkkabel (25m, Weiss, STP, Kat. 6, Flachband) Kabel geliefert bekam, konnte ich das Büro direkt mit einem Cat 6-Netzwerkkabel erschliessen. Ich schaffte es, das Kabel der Fussleiste entlang und unter zwei Türleisten hindurch zu verlegen und so die zwei Gigabit-Switches TP-LINK SG1016D (Büro) und ZyXEL GS1100-8HP (Stube, mit PoE) miteinander zu verbinden.

In der Zwischenzeit verwendete ich ein Powerline-Produkt namens Devolo dLAN 500 duo+, um Stube und Büro über die Stromverkabelung zu verbinden. Der Frevel an der Sache: Ganze 50 MBit/s brachte ich so über die Leitung.

Erster Speedtest

Nun also waren der Mac mini und der iMac mit Gigabit-Ethernet an den Internet-Router angebunden. Voller Spannung startete ich den ersten von Init7 gehosteten Ookla Speedtest vom Mac mini aus — und erhielt mehrmals in der Folge folgende Messwerte zu Gesicht:

Ookla Speedtest Fiber7 DD-WRT
image-6583

Was zum Teufel? Verkauft mir Fiber7 vielleicht nur ein Zehntel des angepriesenen Durchsatzes?

Netzwerkkabel testen

Um das Problem einzugrenzen, teste ich als erstes das soeben verlegte Netzwerkkabel: Auf dem Mac mini startete ich iperf im Server-Modus:

$ iperf -s

Dann ging ich ins Wohnzimmer und verband einen Toshiba-Laptop mit integriertem Gigabit-Port an den Switch im TV-Schrank und lud mir iperf in der Version 2.0.5-3 auf den Rechner. Ich öffnete eine Kommandozeile und führte folgenden Befehl aus:

$ iperf -c 10.1.2.3

Der Mac mini zeigte darauf folgende Durchsätze an:

------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 128 KByte (default)
------------------------------------------------------------
[ 4] local 10.1.2.3 port 5001 connected with 10.1.2.4 port 56432
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 721 MBytes 604 Mbits/sec
...

Am Ethernet-Kabel von der Stube ins Büro konnte es also definitiv nicht liegen.

Direkt am Router

Ich schloss den Laptop per Kabel direkt an den Router an und führte den Oookla-Geschwindigkeitstest erneut durch: Auch hier wieder der „mickrige“ Durchsatz in der Grössenordnung von Fast Ethernet (100 Mbit/s). Lag das Problem allenfalls am Geschwindigkeitstest, bspw. am Server von Fiber7?

Ookla Geschwindigkeitstest testen

Ich machte mich auf die Suche nach einem im Internet verfügbaren iperf-Server und wurde auf der iperf-Web-Site fündig: Public iPerf3 servers. Ich wählte debit.k-net.fr, installierte auch noch iperf 3 und führte dann den Test aus:

$ iperf -c debit.k-net.fr

Auch bei dieser Aktion kam ich nicht nur annähernd in die Nähe der erwarteten 1 Gbit/s. Somit war für mich bewiesen, dass das Problem zwischen Router und dem ISP liegen musste. Doch wo genau?

DD-WRT

Langsam aber sicher wuchs in mir das Misstrauen gegenüber der Frickelware DD-WRT. Was, wenn die Open Source-Firmware die Performance des Routers einbrechen liess?

Ich informierte mich im Netz über die offizielle Firmware des Routers und durfte erfreut feststellen, dass das letzte Update kürzlich, am 28. Januar 2016, veröffentlicht worden war. Nach einer kurzen Recherche stiess ich auch auf die vom User „Merlin“ modifizierte Version der Firmware. Ich entschied mich, den Firmware-Wechsel zu wagen und zog Asuswrt-Merlin in der Version RT-AC66U_380.57_0 dem offiziellen Firmware von Asus vor.

Frühlingsputz: DHCP und VPN

Bevor ich aber das Vorhaben startete, entschied ich mich angesichts eines im April bevorstehenden Routerwechsels zwei Funktionalitäten vom Router weg auf einen Linux-Server zu verlagern: Den DHCP-Server sowie ein OpenVPN Site-to-Site-VPN zu meinem Elternhaus. Wie ich erst zu dem Zeitpunkt realisierte, gehört solche Funktionalität nicht auf einen Consumer-Router, sondern auf einen schicken, kleinen Linux-Server (Intel NUC), welcher ein „anständiges“ Linux, ausreichend Speicherplatz und Subversion-Anbindung möglich macht.

Asuswrt-Merlin

Wie in einem Artikel auf DD-WRT beschrieben, setzte ich den Router über das DD-WRT auf die Werkseinstellungen zurück. Anschliessend lud ich über das Web-Interface die Firmware (.trx) auf den Router und wartete den Transfer sowie die Installation ab. Der Router kam problemlos hoch und erschien nun mit der neuen, standardmässigen Oberfläche.

Nach einem erneuten NVRAM-Reset funktionierte auch die Konfiguration: Das NVRAM voller DD-WRT-Variablen wurde beim Rücksetzen nämlich irgendwie nicht gelöscht und überschritt plötzlich das maximal mögliche Volumen von 65 KB, weshalb die Routeroberfläche subtile Fehlfunktionen und Fehlermeldungen aufwies.

1 GBit/s!

Nachdem ich die Konfiguration des Routers abgeschlossen hatte, führte ich voller Spannung den nächsten Speedtest durch. Hatte sich der Aufwand, der mich fast das gesamte Wochenende gekostet hatte, gelohnt?

Ookla Speedtest Fiber7 Asuswrt-Merlin
image-6584

Beruhigt lehnte ich mich in den Bürosessel zurück und feierte innerlich der Beginn des nächsten Breitbandzeitalters.

Tags: , , , , , , , ,
Labels: IT

4 Kommentare | neuen Kommentar verfassen

Mittwoch, 2. März 2016

Bedeutung der LEDs eines TP-LINK MC220L

Seit Ende Januar 2016 ist unsere Wohnung mit 1 GBit/s FTTH von Fiber7 gesegnet. Ich betreibe dazu einen Asus RT-AC66U-Router mit DD-WRT an einem TP-LINK MC220L. Vereinfacht gesagt wandelt das TP-LINK-Gerät die Lichtsignale vom OTO herkommend in elektrische Ethernet-Signale um.

Bei der Aufschaltung unseres Anschlusses musste ich zwei Dinge beachten:

Einerseits spricht der TP-LINK MC220L ausschliesslich mit Gigabit-Ethernet-Anschlüssen. Zu Testzwecken wollte ich einen uralten Apple AirPort Express an den Wandler anschliessen, doch auf Grund des 100 MBit/s-Ethernet-Ports des AirPorts war kein Uplink zu finden. Zum Glück erfuhr ich recht schnell von diesem „Feature“.

Andererseits erstellte ich mir aus dem Online verfügbaren PDF-Handbuch des Wandlers folgenden Screenshot, um die LEDs zu deuten:

TP-LINK MC220L LEDs
image-6565

Die Verbindung funktioniert (bei mir), wenn die LEDs PWR, LINK FX sowie LINK TP ständig leuchten und die LED TP RX entweder ebenfalls ständig leuchtet oder zumindest blinkt.

Tags: , , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen