EdgeMax Lite – eine kurze Review

Seit 14 Tagen verrichtet ein Router der Marke „EdgeMax Lite“ von Ubiquiti seinen Dienst in meinem Netzwerk. Hier eine kleine Zusammenfassung meiner Erfahrungen.

Kurzfazit: Dieser Router wurde darauf ausgelegt 1Gbit über alle drei Ethernet Interfaces zu routen. Dafür wurde auf die üblichen Dinge wie WLAN, integrierter Switch, TK-Anlage und weitere Features verzichtet. Wer hingegen einen leistungsstarken Router und nur „einen Router“ braucht, der liegt mit diesem Gerät goldrichtig.

Der EdgeMax Lite wird es als Produkt nicht leicht haben, dass wird schon bei einem einfachen Blick auf die Featureliste und Technischen Daten klar. Andere Produkte im 100€ Segment bieten für die „normale Nutzung“ wesentlich mehr zusätzliche Features. Spätestens 30 Minuten nach Inbetriebnahme dürfte der Normalnutzer entgeistert aufgeben und bereuen sich keine „Eierlegende Wollmichsau“ zum gleichen Preis gekauft zu haben. Wie ein solcher „Vergleich“ sich dann in einem Test niederschlägt, kann man bei SmallnetBuilder nachlesen. Den EdgeMax mit einer FritzBox zu vergleichen ist ungefähr so als wolle man einen Combi mit einem Sportwagen vergleichen. Das kann man machen, viel Sinn macht es aber nicht.

Ich hab mich für einen Einsatz des EdgeMax entschieden, da mein „alter“ Buffalo AG300H einige Features einfach nicht abdecken konnte. Das Killer-Feature war dabei der Routing-Durchsatzt. Ich wollte meinen Server von meinem lokalen LAN isolieren. Etwas was jeder IT-Azubi im ersten Lehrjahr lernen sollte. Mit dem Buffalo war das nicht möglich. Ein frisches OpenWRT mit geflushten Iptables brachte gerade mal 400mbits über den Router. Sobald ein paar Iptables Rules zum Einsatz kamen, sank der Durchsatz auf unter 300mbits. HD Filme die von einem NAS gestreamt werden, fangen jetzt an zu ruckeln. Das war keine Option.

Der EdgeMax gibt sich hier keine Blöße. Wie von Ubiquiti beworben legt er das Gigabit auf die Leitung. Der Einsatz von Firewall-Regeln oder QoS  hat dabei keinen Einfluss auf den Durchsatz, wenn man sich an kleinere Einschränkungen hält (erleuterung folgt gleich). Mittels IPerf konnte ich 850mbits ermitteln. Wobei mein Switch 900mbits auf die Leitung legt. Dieser Durchsatz wird erreicht, ohne dass der CPU auch nur Notiz davon nimmt (Load von 0).

Ein Blick auf die technischen Daten macht aber klar, dass dieses Ergebnis zu erwarten ist. Zum Einsatz kommt ein Cavium Octeon 500MHz Dual Core (Hardware Einheit zur Paketverarbeitung inklusive), 512MB RAM und 2GB Flashspeicher. Das ist einfach eine andere Hausnummer als meine bisherige Routerhardware. Auch so hinterlässt der EdgeMax einen anderen Eindruck als jeder SoHo Router den ich bis jetzt in die Finger bekommen habe. Er blinkt nicht wie ein Weihnachtsbaum und buhlt auch nicht um Aufmerksamkeit wie die letzten Asus und Netgear Geräte.

EdgeMaxLite
EdgeMax-Lite während der Konfiguration

Das auffälligste ist im ersten Moment der vierte RJ45 Port – die gute alte Serielle Schnittstelle ist zu Wartungszwecken raus geführt worden. Gut selbst Cisco nutzt dafür jetzt USB Ports aber egal, ob Hauptsache sie ist raus geführt. Danach bekommt man (normalerweise) als erstes die (Web) GUI zu Gesicht. Diese kann man wohlwollend mit „managementtauglich“ Beschreiben. Man kann quasi jedem Azubi Zugriff geben, viel kaputt machen kann er nicht… Selbst für das Konfigurieren der Interfaces braucht man Zugriff via Konsole. Eine Konsole kann man zwar auch über die GUI bekommen, aber dass ist dann nicht mehr Klicki-Bunti. Überhaupt die GUI noch die sichtbarste Baustelle. Das einrichten einer Firewall Rule geht noch alles andere als intuitive von der Hand.

Wenn man sich via SSH (muss aktiviert werden) oder gar Seriellen Konsole auf den Router verbindet bekommt man direkten Zugriff auf das Router OS. Zum Einsatz kommt ein von Ubiquiti geforktes Vyatta. Dies ist eine Debian basierte Router Distribution. Anders als z.B Chanonical setzt Ubiquiti aber auf die standart Debian (squeeze) Quellen.

Die zur Verfügung gestellte vbash lehnt sich in Aufbau und Bedienung an die IOS (Cisco) Devices an. Das kann man mögen, muss aber man nicht. Standardmäßig wird zudem eine eingeschränkte Quagga Routing Suite eingesetzt. Wobei ich das Gefühl nicht loswerden, dass diese nur eingeschränkt wurde, weil man noch nicht das ganze Spektrum in der Konfigurations-Schnittstelle abdecken kann.

Das Konfigurieren geht dabei gut von der Hand. Schnittstellen und Routing sind schnell und übersichtlich Konfiguriert und der Router einsatzbereit. Besonders angenehm fällt dabei die „Commit/Rollback“-Fähigkeit der Konfigurationsoberfläche auf. Änderungen müssen erst via „Commited“ freigegeben werden bevor man sie final in den VRAM raus schreiben kann. So kann man zu jedem Zeitpunkt seine Änderungen „einsehen“. Beim Commit werden die neuen Einstellungen auf „Konsistenz“ geprüft. Firewall Rules ohne Interface werden gar nicht erst gespeichert. Anschließend werden alle Änderungen wirksam gemacht: Befehle angewendet, Dienste neu gestartet usw. Erst jetzt kann der finale „Save“ ausgeführt werden. Fehlkonfigurationen bei denen man sich selber Aussperrt, werden so erschwert. Zusätzlich können mehrere Einstellungssets vorgehalten werden. Das wirkt alles ausgereift und durchdacht. Nur leider bleibt das was man konfigurieren kann, weit hinter dem zurück, was dieser Router bietet.

Für mich war bei der Einrichtung der Firewall Schluss mit der vbash. Ich weiß nicht wie viele Versuche ich gesehen habe das Iptables-Kommando vor dem Benutzer zu verstecken. Dies ist ein weiterer auf der Liste. Kurz: ich führe nur noch das Nötigste (interfaces, web-gui abschalten, logins) in der Konfiguration, danach geht es über einen zweiten Benutzer (alternativ sudo su) an das „eigentliche“ Debian.

Ab jetzt spielt der „Router“ seine Stärke aus: brachiale Performance, Platz und Debian halt. 2GB sind für den Anfang mehr als genug um ein paar zusätzliche Dienste zu installieren. Da man die kompletten Debian-Quellen im Zugriff hat, findet man eigentlich jeden Dienst, den man irgendwie im Netzwerk gebrauchen könnte. Man hat aber auch nur 2GB Speicher. Eine Erweiterung via USB oder anderen BusSystem ist nicht vorgesehen. Zum Hosten kleiner WebSites würde es reichen, ist aber nicht zu empfehlen. Begründung folgt gleich…

Bei muss der Router FreeRadius , Kerberos  zur Verfügung stellen und mehrere Clients mit einer 2 DMZ-Lans verbinden. Zu Testzwecken hab ich vier simultane (unterschiedliche Rechner) bonnie++ auf eine NFS Freigabe losgegangen. Der Durchsatz über den Router lag immer  im Bereich 750 bis 850 mbits und die CPUs langweilten sich bei einem Load von 0. Auch versuche die CPU mit normalen Radius/Kerberos anfragen zu quälen, waren nicht von Erfolg gekrönt. Das sollte für den „Heimgebrauch“ reichen. Der Durchsatz ist aber stark vom Einsatz-Szenario abhängig. Die Hardwarebeschleunigung greift nicht überall. Sobald Bridging oder VLANs in Spiel kommen, muss die CPU rann. IPv6 wird erst mit der neusten Firmware auch „beschleunigt“ (disabled by default.). Wenn die Hardwarebeschleunigung fehlt bricht der Durchsatz rapide ein. Jeh nach Szenario landet man bei 500mbits oder gar 400 mbits (Firewall, NAT, QOS, IPv6 ohne HW) und der CPU ist am Limit. Der Router war allerding noch  ansprechbar, und gut bedienbar. Ich hab es mit fünf Simultanen Floodings nicht geschafft, den Router so weg zu schießen, dass er nicht mehr bedienbar war. Ob er einem richtigen DDOS angriff stand hält würde ich mal bezweifeln.

Ein Wort zu den VLANs/Bridging Einschränkungen. Es ist möglich auf einem Interface „ungebridged“/“ungetagged“ und gleichzeitig „bridged“/“tagged“ zu arbeiten. Dabei wird der „ungebridged“/“ungetagged“ Traffic durch die Hardware beschleunigt und der Rest muss über die CPU. Man hat also, wenn man es clever anstellt, genügend Spielraum diesen „Makel“ zu umgehen. Zumal der Hersteller in Aussicht gestellt hat, dass sich dieser Umstand in Zukunft noch verbessert, sprich VLANs auch Hardware beschleunigt werden. Überhaupt sind noch viele der Eckpunkte des EdgeMax „im Fluss“. Ubiquiti erweitert mit jedem Update die Funktionalitäten, den Umfang der Hardwarebeschleunigung und behebt (natürlich) Bugs. Dabei hatte ich nie das Gefühl eine Beta im Einsatz zu haben. (Wobei man sich für selbige anmelden kann.) Die FirmwareUpdates machen immer einen sehr runden Eindruck.

Wo wir bei den Firmware Updates waren. Die kommen momentan recht zügig (zwischen 1.1.0 und 1.2.0 lagen 4 Monate). Das Firmwareupdate läuft dabei ähnlich wie bei OpenWRT. Einmal geflasht gehen alle Informationen verloren. Einzig die ConfigDatei und alles was in bestimmten Ordnern liegt wird erhalten. Größere Datenmengen oder gar Datenbanken verbieten sich da. Da nach einem Update sowieso die zusätzlichen Dienste neu installiert werden müssen, sollte man sich nur Keys, Certs und ähnliches auf dem Router vorhalten. Ein richtiger Webserver schließt sich somit fast aus. Komfortabel ist das noch nicht. Ein Mitarbeiter von Ubiquiti hat jedoch erläutert, dass in späteren Versionen auf einen RollingRelease angeboten werden könnte…

Wo wir beim letzten wichtigen Thema sind: dem Support von Ubiquiti. Der wird recht häufig gescholten. Ich hatte bis jetzt nur das „Vergnügen“ ihn in den Foren zu erleben und muss sagen, dass es wirklich ein Vergnügen ist. Es scheinen ein paar Mitarbeiter der EdgeMax Produktlinie abgestellt worden zu sein, durch die Foren zu streifen. Zu jeder wichtigeren Frage findet man immer eine, meist sogar mehrere Antworten von Ubiquiti-Mitarbeitern. Sie begründen Entscheidung, gehen auf Testergebnisse ein oder geben Hilfestellungen. Alles in allem macht es einen ungewohnt offenen Eindruck. Dies ist aber angesichts der Funktionalität und der (fehlenden) Dokumentation auch nötig. Während die meisten etablierten Router-Hersteller eine selbsterklärende GUI oder dicke (sinnfreie) Manuals anbieten, baut Ubiquiti gerade erste ihre KnowledgeBase auf. Bei vielen Fragen muss man aufs Forum zurückgreifen. In diesem Fall sehe ich das aber nicht als Nachteil. Die Suche funktioniert gut die passenden Antworten sind markiert.

Ein letztes Wort zum Thema OpenSource: Hier blick ich nicht mehr ganz durch. Laut Ubiquiti ist es möglich sich einen eigenen Kernel oder gar Image selber zu erzeugen. Bei Freebsd und OpenWRT gibt es auch Builds die wohl den Chip unterstützen. In wie weit dort die Hardware-Beschleunigung inbegriffen ist konnte ich in Ermangelung an Zeit nicht Testen. Interessant ist in jedem Fall, das für einen SDK von Cavium erst mal ein NDA unterzeichnet werden muss. Man bekommt also einen Kernel mit ClosedSource Binaries. Für Leute die nur 100% frei Software im Einsatz haben wollen, ist die Büchse aktuell erst mal nichts.

Für alle anderen, die einen „echten“ Router suchen, ist der EdgeMax genau das richtige. Klein, Unscheinbar, Leistungsstark und wenn man Linux beherrscht simpel in der Bedienung. Hatte ich den serielle Konsole schon erwähnt? Ende des Jahres sollte die 5Port POE Version des Routers im Handel verfügbar sein, dann werden meine Buffalos endgültig ausgemistet…

Bird: strange next-hop

Nach meinem Umzug auf OpenWRT kam ich in den Genuss, das bei einem Reconnect nicht jeder Dienst neu gestartet wird. Leider hatte dieses „normale“ verhalten dazu geführt, das BIRD nicht mehr alle Routen propagiert hat. Das Problem: Es tauchten unvermittelt meldungen in folgendem Format im Syslog auf:

KRT: Received route 192.168.100.128/25 with strange next-hop 192.168.100.130

Zu Meldungen dieser Art kommt es wenn eine Routing-Regel aus der Kernel-Routing Tabelle gelernt wird, die ein direkt angeschlossenes Netz über einen entfernten Gateway schleifen will. Typisch für P-T-P und P-T-MP Verbindung wie OpenVPN oder PPPD. Interessanterweise stört BIRD das nur bei neu erlernten Routen. Ist die Route beim Dienst-Start schon in der Routing-Tabelle gibt es keine Probleme. Die Meldung kann man Unterdrücken, was jedoch stört ist die Tatsache, dass die entsprechende Routing-Rule nicht an die anderen Protokolle übertragen wird. Die möglichen Lösungen:

  • Eine statische Route über das Interface definieren und via Filter verhindern, dass diese Route zurück in den Kernel geschrieben wird.
  • BIRD nach einem Reconnect neu starten.
  • Diverse Protokolle bieten es an Netzwerke zu propagieren, die sie eigentlich nicht kennen. Unter OSPF kann man z.B. ein stubnet Konfigurieren. Dies hat den Charme, dass man der Route gleich entsprechende Kosten auferlegen kann. Die Route wird nur an die OSPF-Neighbors weitergereicht nicht an irgendein ein anderes Protokoll in der BIRD Instanz.

Welche der Lösungen man wählt hängt wohl vom Einsatzgebiet ab, ich hab mich für letztere entscheiden.

Routing unter Ubuntu

Einen Text mit viel „Bla-Bla“ hatte ich heute schon, jetzt gibt es Technisches!

Will man unter Ubuntu einen „echten“ Router betreiben, also dynamisch auf die Netzwerkumgebung reagieren, stehen zwei Routing-Suites zur Verfügung: BIRD und Quagga. Beide unterstützen die wichtigsten Routing-Protokolle: BGP, RIP, OSPF

Wichtiger Hinweis vorweg: in Ubuntu 10.04 wird BIRD noch in Version 1.1.5 ausgeliefert. Die ist mal gut zwei Jahre alt und Unterstützt noch nicht alle Funktionen. Entweder akzeptiert man diese Schwächen oder nutzt das PPA des CZ.NIC Labs.

Die Quagga-Suite ist schon seit einiger Zeit am Markt. Sie bietet ein Config-Interface das einem CISCO Router gleicht. Man kann sowohl Config Files hinterlegen als auch „on the fly“ Config Befehle geben und die entsprechende Config dann raus schreiben (ganz wie bei CISCO Routern). Im Hintergrund werden bei Quagga für jedes Routing-Prokoll ein eigener Dienst gestartet und jeder dieser Dienste macht einen TELNET Port auf. Diesen kann man auf den Localhost beschränken oder so konfigurieren, dass er jede Anfrage ablehnt (kein Password angeben).

Bird befindet sich aktuell noch in der (Weiter-)Entwicklung. Zudem wirkt es auf mich schlanker. Es wird nur ein Dienst gestartet, die Config befindet sich in einer Datei und wirkt übersichtlicher. Neben diesen „Geschmacksfragen“ soll BIRD leistungsschonender sein.[1. Quelle: Vergleich BIRD/Quagga] Laut Wiki kommt er vor allem deswegen in den großen „Verteilerknoten“ zum Einsatz. [2. Quelle: Wikipedia] Dafür spricht auf jeden Fall, dass bei DD-WRT Firmwares für wenig Speicher der BIRD zum Einsatz kommt und bei viel Speicher die Quagga-Suite.

Ich habe beide Implementierungen gezwungenermaßen durch meine Routern im Einsatz. Beim Ubuntu-Router hatte ich die Wahl und mich nach einem kleinen Quagga Test für BIRD entschieden.

Wichtig: Die meisten Routing-Protokolle nutzten MultiCast-Addressen für ihre Kommunikation. Damit das funktioniert muss man eine entsprechende Route hinterlegen.

route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0

Beispiel – Konfiguration BIRD

Einfach über apt-get oder aptitude bird installieren und schon kann es losgehen.

aptitude install bird

Danach kann man die /etc/bird.conf bearbeiten.

log syslog all;
router id 10.1.0.1;

protocol kernel {
        export all;
        learn;
}

protocol device {
        scan time 60;
}

protocol ospf {
        debug { states, routes, interfaces };
        area 0 {
                interface "eth0" 10.1.0.0/16 {
                        cost 10;
                        stub;
                        check link;
                };
                interface "eth1" 10.2.0.0/16 {
                        priority 10;
                        cost 100;
                        type broadcast;
                        hello 30; retransmit 5; wait 10; dead 120;
                        authentication none;
                        check link;
                };
                interface "eth2" 10.3.0.0/16 {
                        priority 10;
                        cost 10;
                        type broadcast;
                        hello 30; retransmit 5; wait 10; dead 120;
                        authentication none;
                        check link;
                };
        };
}

Die Config dürfte selbsterklärend sein. Ein paar Hinweise zum Umgang mit BIRD:

  • Das Kernel-Protokoll wird gebraucht. Ohne die „export all;“ Regel werden keine Routen an das OS bekanntgegeben.
  • Hat man Default-Routen oder pflegt händisch welche über den „route“-Befehl nach, sollte die über das „learn“-Statement von BIRD ermittelt werden.
  • Alle lokalen Netze, die den Nachbarn mitgeteilt werden sollen, benötigen ein interface-Statement. Das stub-Statement markiert Interfaces die nur „announced“ werden sollen aber sonst keine Funktion haben.
  • Wenn man einen PPPoE-DSL-Uplink als Default-Route verwendet, sollte man das PPPoE Interface nicht als Area-Interface hinterlegen.
  • „check link“ funktioniert nur, wenn man neuerere BIRD-Versionen benutzt. BIRD 1.1.5 meckert einen Syntax-Fehler an.

 Beispiel – Konfiguration Quagga

Installation:

aptitude install quagga

Quagga ist anfangs etwas komplizierter. Anfangs muss man erst mal die benötigten Dienste unter /etc/quagga/daemons freischalten. Will man, dass diese Dienste per TelNet auch Remote konfigurierbar sind muss man noch in der /etc/quagga/debian.conf Anpassungen vornehmen.

Auf jeden Fall benötigt man den zebra-Dienst. Dieser ist das „protocol kernel“ Pendant. Zusätzlich muss man noch den Dienst für das gewünschte Protokoll aktivieren. Für den einfachen Einstieg findet man Beispiel-Konfigurationen unter /usr/share/doc/quagga/examples.

zebra.conf

hostname deadend-router

interface br0
  link-detect
interface ath1
   link-detect

in der zerba.conf werden die zu nutzenden interfaces angegeben.

ospf.conf

interface br0
  ip ospf cost 10
  ip ospf dead-interval 120
  ip ospf hello-interval 30
  ip ospf retransmit-interval 5
  ip ospf network broadcast
interface eth0
  ip ospf cost 10
  ip ospf dead-interval 120
  ip ospf hello-interval 30
  ip ospf retransmit-interval 5
  ip ospf network broadcast

router ospf
  ospf router-id 10.3.0.10
  network 10.3.0.0/16 area 0
  network 10.4.0.0/16 area 0
    redistribute kernel
    redistribute connected

In der ospf.conf wird diesen Interfaces erst Eigenschaften zugewiesen und anschließend das Protokoll zugeschaltet. Wichtig ist die Syntax. Das Einrücken dient nur zur Optik und hat kein Einfluss. Die Reihenfolge der Befehle hingegen hat Einfluss. Gewisse Befehle „öffnen“ eine SubConfig-Ebene. Ein „ip ospf cost“ ist nur gültig, wenn vorher eine interface-Direktive stand. Was bei den „interface“-Direktiven noch übersichtlich erscheint, kann bei den area-direktiven unübersichtlich werden, da diese ineinander geschachtelt sein können. Angenehm sind hingegen die redistribute -Direktiven. So muss man nur die Interfaces auflisten, auf den auch wirklich ein weiterer Router lauscht.