Einen von Linux verwalteten Netzwerk-Switch bauen
(blog.brixit.nl)- Um eine Struktur wie im Inneren von Consumer-Routern nachzubilden, bei der Linux den Switch-Chip direkt steuert, wurde eine Gigabit-Switch-PCB auf Basis des RTL8367S entworfen und an DSA/switchdev angebunden
- Der gewählte RTL8367S ist ein 7-Port-Gigabit-Switch-Chip mit integrierten PHYs an 5 Ports; statt eines dedizierten CPU-Ports wird Port 0 per Netzwerkkabel mit dem Ethernet eines Linux-Boards verbunden
- Beim Hardwarebau wurde die Stromversorgung auf 3,3 V und 1,1 V vereinfacht, und Konfigurationspfade wie Boot-Konfigurationspins, EEPROM, SPI-Flash und serielle Schnittstelle wurden experimentell untersucht
- Für die Linux-Anbindung waren ein PINE64-A64-lts-Board, angepasste Kernel-Optionen und Änderungen am Device Tree nötig; nach dem Booten erscheinen unter
eth0die Interfaceslan1bislan4wie lokale Netzwerk-Interfaces - Der Ansatz funktioniert gut mit bestehenden Tools wie Linux Bridge und
ethtool, ist auf normalen PCs, Servern oder USB-Netzwerk-Interfaces aber wegen Device-Tree- und GPIO-Einschränkungen nicht ohne Weiteres nutzbar
Verwaltete Switches und die Linux-DSA-Struktur
- Ein typischer verwalteter Switch lässt sich über ein Web-Interface konfigurieren und zeigt den Portstatus an; teurere Geräte bieten zusätzlich Schnittstellen wie Telnet oder eine serielle Konsole
- Auch der Switch im Inneren eines Consumer-Routers kann als eigener Typ verwalteter Switch betrachtet werden
- Der Router ist ein kleines Linux-Gerät mit einem Switch-Chip im Inneren
- Einer oder mehrere Ports sind intern mit der CPU verbunden, die übrigen sind als physische Ports nach außen geführt
- Mit den Linux-Subsystemen DSA und switchdev verhalten sich die an den Switch angeschlossenen Ports wie echte „lokale“ Netzwerkports
- Zwischen Router-SoC und Switch werden Verbindungen wie SGMII oder RGMII sowie ein Management-Bus wie SMI oder MDIO benötigt
- Bei gewöhnlichen Fertig-Switches sind die nötigen Chip-Verbindungen nicht nach außen geführt, weshalb sie sich auf diese Weise nur schwer steuern lassen
Bau eines Switch-Boards auf Basis des RTL8367S
- Der selbstgebaute Gigabit-Switch verwendet den Realtek-Chip RTL8367S
- Ein weit verbreiteter 5-Port-Gigabit-Switch-Chip
- Tatsächlich besitzt er eine 7-Port-Struktur: 5 Ports mit integrierten PHYs und 2 Ports für die CPU-Anbindung
- Das Datenblatt liefert nur minimale Informationen, daher wurden zusätzlich Schaltpläne von Geräten mit ähnlichen Realtek-Chips und Ethernet-Designdokumente herangezogen
- Anfangs schien es, als würden etwa 7 separate Stromversorgungsnetze benötigt, doch durch das Zusammenfassen von Netzen mit überlappenden Spannungsbereichen reichte eine Konfiguration mit nur 3,3-V- und 1,1-V-Reglern
- Da Linux switchdev nicht zwingend einen dedizierten CPU-Port für die CPU-Anbindung voraussetzt, wird in diesem Design Port 0 per Kabel mit dem Linux-Board verbunden
- Aus Sicht des switchdev-Treibers sieht es so aus, als gäbe es dazwischen keinen Ethernet-PHY
Konfiguration des Switch-Chips und PCB-Fehlversuche
- Der RTL8367S bietet mehrere Konfigurationspfade, aber allein anhand des Datenblatts war schwer zu erkennen, welche Minimalkonfiguration für den Betrieb als gewöhnlicher Dumb Switch nötig ist
- 8 beim Start eingelesene Pins werden auch mit den Port-LED-Pins geteilt
- Der i2c-Bus kann für einen EEPROM-Chip verwendet werden, teilt sich aber Pins mit dem benötigten SMI-Bus
- Über den SPI-Bus kann ein NOR-Flash angeschlossen werden, um Konfigurationsregister oder Firmware für den integrierten 8051-Kern zu speichern
- Es wurde angenommen, dass der serielle Port ohne 8051-Firmware nicht funktioniert
- Beim ersten Board wurde nach der Bestellung durch Umlöten und Ändern von Verbindungen experimentell ermittelt, unter welchen Bedingungen es funktioniert
- Ein Footprint für den Flash-Chip war vorhanden, wurde am Ende aber nicht benötigt
- Für die Konfigurationspins wurden Lötjumper vorgesehen
- LEDs wurden weggelassen, weil sie sich nur schwer sinnvoll konfigurierbar machen ließen
- Gigabit-Ethernet-Designdokumente betonen meist Impedanzkontrolle und präzises Längenmatching, aber bei realen günstigen Switches wirkte das Layout nicht so streng
- Wichtiger erschien das Skew-Matching zwischen den Netzwerkkabelpaaren
- Alle 4 Netzwerkkabelpaare insgesamt auf exakt gleiche Länge zu bringen, wurde nicht als sinnvoll betrachtet
- Schon innerhalb eines Netzwerkkabels unterscheiden sich die 4 Paare wegen unterschiedlicher Verdrillung deutlich in ihrer Länge
- In frühen Board-Revisionen funktionierte Ethernet nicht, weil die Kondensatorbeschaltung zur Referenzierung des Center-Taps des switchseitigen Transformators gegen Masse fehlerhaft war
- Beim Testen wurde eine kleine Leiterbahn durchtrennt, um den Kurzschluss nach Masse aufzuheben
- Im Testaufbau funktionierte es auch mit schwebendem Center-Tap
- Im finalen Design wurde der betreffende Kondensator ergänzt
Der fertige Switch und die Linux-Anbindung
- Das fertige Board ist ein etwas ungewöhnlich geformter Gigabit-Switch
- 4 Ports zeigen in eine Richtung
- 1 Port zeigt in die entgegengesetzte Richtung und dient zur Verbindung mit dem Linux-Board
- Die Stromversorgung erfolgt über eine 2,54-mm-Pinleiste
- Zusätzlich wurde ein USB-Type-C-Connector-Footprint ergänzt, damit sich Strom auch ohne DuPont-Kabel zuführen lässt
- Als Linux-Testboard wurde das PINE64 A64-lts gewählt
- Die Position der Anschlüsse passte ungefähr zur gewünschten Anordnung
- Weil Änderungen am Device Tree nötig waren, war eine andere Plattform als x86 wichtig
- Der Kernel wurde neu gebaut, da Switch-bezogene Module normalerweise nicht aktiviert sind
CONFIG_NET_DSA: Distributed Switch ArchitectureCONFIG_NET_DSA_TAG_RTL8_4: Port-Tagging für Realtek-Switch-ChipsCONFIG_NET_SWITCHDEV: Netzwerkswitch-TreibersystemCONFIG_NET_DSA_REALTEK,CONFIG_NET_DSA_REALTEK_SMI,CONFIG_NET_DSA_REALTEK_RTL8365MB: Treiber für den tatsächlichen Switch-Chip
- Statt ein Device-Tree-Overlay per U-Boot zu laden, wurde der Device Tree des A64-lts-Boards direkt gepatcht
- Der Treiber wird mit dem kompatiblen String
realtek,rtl8365rbgeladen - Dieser Treiber unterstützt mehrere Realtek-Switch-Chips, darunter auch den verwendeten RTL8367S
- Die CPU-Port-Definition aus dem Dokumentationsbeispiel wurde entfernt und stattdessen 5 normale Switch-Ports definiert
- Der Treiber wird mit dem kompatiblen String
port@0ist der nach hinten gerichtete Port und mit&emacdes A64-lts verbunden- Die übrigen Ports sind jeweils mit den PHYs im Switch-Chip verbunden
- Im oberen Teil des Device Tree sind 3 GPIOs definiert, die mit SDA/SCL und Reset verbunden sind
Linux-Netzwerktools und Einschränkungen
- Nach dem Booten erscheinen in Linux neben dem normalen Gerät
eth0auch die im Device Tree definierten Switch-Port-Interfaceslan1@eth0lan2@eth0lan3@eth0lan4@eth0
- Für den tatsächlichen Betrieb müssen
ip link set eth0 upund die einzelnenlan-Interfaces aktiviert werden - Die Einbindung in Standard-Linux-Netzwerktools ist naheliegend
- Werden mehrere
lan-Ports in eine Linux Bridge aufgenommen, übernimmt switchdev das Bridging dieser Ports innerhalb des Switch-Chips - Linux muss diesen Traffic nicht selbst weiterleiten
- Mit
ethtool lan3lassen sich Link-Informationen anzeigen ethtool -S lan3liefert Standard-Statusinformationen einschließlich der Pakete, die vollständig vom Switch verarbeitet wurden
- Werden mehrere
- Für den Einsatz in normalen Umgebungen gibt es jedoch große Einschränkungen
- Man muss entweder selbst einen Netzwerkswitch bauen oder einen vorhandenen Switch öffnen und die nötigen Verbindungen auffinden
- Gewöhnliche PCs oder Server verwenden keine Device-Tree-basierte Konfiguration, und vom Kernel steuerbare GPIO-Pins stehen dort meist ebenfalls nicht zur Verfügung
- USB-Netzwerk-Interfaces eignen sich dafür nur schwer, da ihnen ein Device-Tree-Node-Handle fehlt, das als Conduit-Port festgelegt werden könnte
- Manche Einschränkungen lassen sich womöglich umgehen, aber für Wege, switchdev in Umgebungen ohne ARM-Gerät oder mit speziellen USB-Geräten mit GPIO-Exposition zu laden, wäre deutlich mehr Dokumentation nötig
1 Kommentare
Meinungen auf Hacker News
Ein Paar älterer Dell-OS9-Switches ist zum Beispiel betagtes stackbares Equipment mit 48 10-Gb/s-Ports und 4 optischen 40-Gb/s-QSFP+-Ports; ein einzelner Switch kann bis zu 1,28 Tb/s verarbeiten.
Heute bekommt man sie für etwa 1.800 £ inklusive VAT, und sie halten praktisch ewig.
Solche Versuche sind gut, aber man sollte auch berücksichtigen, dass Anbieter wie Netgear 8-Port-1-Gb-Switches mit PoE auf allen Ports für rund 125 £ verkaufen.
Wenn man für die Wirtschaftlichkeit des Projekts die eigene Zeit mit 20–50 £ pro Stunde ansetzt, kann ein Fertigprodukt die richtige Wahl sein; wenn aber das Projekt selbst der Zweck ist, spielt der Preis keine Rolle.
(1) https://i.dell.com/sites/doccontent/shared-content/data-shee...
(2) https://www.etb-tech.com/dell-force10-s4820t-10gbe-switch-os...
Der ASIC-Preis lag in einem erwartbaren Bereich; genaue Zahlen kenne ich nicht, aber vermutlich ein paar Hundert Dollar.
Die Dokumentation zur Software-Schnittstelle war sehr dürftig, und weil es eine Bibliothek für alle Broadcom-Switch-ASICs war, bestand sie aus
.a-Dateien von mehreren Hundert MB voller Funktionen, die nur „auf diesem Gerät nicht unterstützt“ zurückgaben — was man erst wusste, nachdem man sie direkt aufgerufen hatte.Für einfachere Einsatzzwecke bekommt man meist OpenWRT-unterstützte Router mit Managed-Switch-Chips, und OpenWRT bietet eine gute Oberfläche, um VLANs und diverse Optionen zu konfigurieren.
Allerdings kann die Unterstützung für Funktionen wie PoE oder 10Gb/SFP+-Ports eingeschränkt sein, und ich bin mir über den aktuellen Stand nicht sicher.
Dieses Projekt wirkt aber eher wie der erste selbst gebaute Managed Switch, den ich gesehen habe, statt nach dem Prinzip „einem unmanaged Switch ein externes Gehirn verpassen“.
Ich vermute, dass die Hardwareseite eine bessere Performance liefert, weiß aber nicht, ob es Tests gab, die den tatsächlichen Unterschied zeigen.
Bei USB-Adaptern stößt man schnell an die maximale Bandbreite, weil USB in vielerlei Hinsicht ein geteilter Bus ist; außerdem müssen die Daten bis zur CPU hinein und wieder heraus.
Beim Switching in Software kommt Zeit hinzu, um jedes Paket zu verarbeiten und wieder an die richtige Stelle zu schicken, plus die Latenz der Schnittstellen selbst.
Jeder Adapter hat sein eigenes Netzwerk-PHY und eigene Hardware, was den Stromverbrauch erhöht; zusammen mit der zusätzlichen Verarbeitung steigt der Energiebedarf weiter.
Hardware-Offloading und andere Performance-Verbesserungen nutzt man ebenfalls weniger, sodass das Gesamtsystem stärker am Verschieben der Pakete beteiligt ist.
Funktional hängt es von der gewählten Hardware ab; bei manchen günstigen USB-Gigabit-Adaptern funktionierten Dinge wie VLANs nicht richtig.
Mit mehreren PCIe-Karten kann man dagegen deutlich bessere Funktionen bekommen, aber ab diesem Punkt ist es eher Routing als Switching.
Selbst wenn das Host-OS abstürzt, kann das Switching weiterlaufen; kombiniert man Watchdog und Recovery, lässt sich ein System bauen, das trotz eines kurzen Ausfalls mancher Funktionen verfügbarer ist als eine Software-Bridge.
Voraussetzung ist allerdings, dass der Switch-Chip selbst nicht ausfällt oder hängen bleibt.
Je nach Zielsetzung sind vier Interfaces eindeutig besser, wenn man den gesamten Traffic durch den Switch inspizieren will.
Wenn ein hostbasierter Switch auch viel selbst kommuniziert, liefern vier Interfaces dem Host 4 Gbps und sind einem einzelnen 1-Gbps-Link überlegen.
Gebrauchte Enterprise-Quad-1G-Karten bekommt man auf eBay für unter 15 $, und ich bevorzuge die Silicom Quad Bypass 1G
PEG4BPI-SD.Die Bypass-Funktion ist interessant und ungewöhnlich, weshalb sie günstiger ist; meistens kann man sie aber einmal wie eine „Standard-NIC“ konfigurieren und dann ohne größere Probleme anderswo einbauen.
Frühe Modelle sind schwieriger zu verwenden, weil Vendor und Subvendor der PCI-ID als Silicom erkannt werden; die
-SD-Karten haben eine Intel-Vendor-ID und Silicom als Subvendor, sodass der normale Treiber greift.Bei 4x10G-Ports gibt es mehr zu verwalten, und je nach Hostsystem reicht der Durchsatz von Software-Bridging möglicherweise nicht aus.
Quad-Port-10G-Karten sind schwer zu bekommen, aber 2x10G findet man mit etwas Geduld zu vernünftigen Preisen.
Ein Switch schaltet Pakete im ASIC und nicht in der CPU; damit hängt es von der CPU-Leistung ab und ist meist keine effiziente Nutzung der vorhandenen Rechenressourcen.
Wenn man den Aufwand für Design und Fertigung ignoriert, könnten die gesamten Hardwarekosten trotzdem unter 100 $ liegen und damit möglicherweise günstiger sein als ein Computer mit mehreren Interfaces.
Allerdings ist ein 1-Gb/s-Netzwerk inzwischen ziemlich betagt.
Allein mit Standardkomponenten lässt sich für etwas über 200 US-Dollar ein größerer und schnellerer Managed Network Switch bauen
Nimmt man zum Beispiel einen Odroid H4+ mit 2 Ports und eine M.2-Erweiterungskarte, die 4 Ethernet-Ports hinzufügt, erhält man einen 6-Port-Switch mit 2,5 Gb/s
Eine weitere Möglichkeit ist ein Mini-Computer mit N100-CPU und vier 2,5-Gb/s-Ports, den man in dieser Preisklasse bei mehreren chinesischen Anbietern kaufen kann
Ein ähnlicher Mini-Computer mit sechs 2,5-Gb/s-Ports ist etwas teurer und kann knapp über 300 US-Dollar liegen
Es schien perfekt für solche Geräte zu passen, aber ich habe das Interesse verloren, weil es nahezu unmöglich war, eine Laborumgebung dafür aufzubauen
Wenn die CPU das Switching übernimmt, ist die Last hoch, deshalb braucht man meiner Meinung nach solche Chips
88E6393Xläuft ohne Firmware im „einfachen/extern verwalteten“ ModusEr kann wie das Gerät in diesem Artikel zusammen mit Linux switchdev verwendet werden
Um zu zeigen, wie der Hardware-Switch mit dem Rest des Systems verbunden ist, wurde ein RouterBoard-Blockdiagramm als Modell verwendet, anschließend scheint aber behauptet zu werden, solche Geräte seien unmöglich oder schwer zu handhaben
Mich würde interessieren, ob hier tatsächlich schon einmal ein RouterBoard beschafft wurde
Für die meisten RouterBoards dürfte sich OpenWRT bauen lassen, und das 2011er dürfte auch auf dem Gebrauchtmarkt recht verbreitet sein
Die bessere Frage ist, ob das Ziel von Anfang an war, alles von Grund auf selbst zu bauen, oder ob die Verwendung fremder Hardware aus einem bestimmten Grund verworfen wurde
Das RB2011-Diagramm habe ich verwendet, weil ich es für einfach und gut erklärt halte
Technisch wäre das RB1100AHx4, das denselben Switch-Chip verwendet, ein besseres Beispiel, aber es ist verwirrender, weil es beide CPU-Ports zusammen nutzt und zwei 1,25-Gb/s-Links als 2,5-Gb/s-Link bezeichnet, wobei der Encoding-Overhead ignoriert wird
Der Grund für den Eigenbau war, dass die Kosten vernünftig sind und dieses Gerät in eine FOSDEM-Videoaufzeichnungsbox passen muss
Dabei müssen einige für dieses Design spezifische Probleme gelöst werden: Vier Netzwerk-Ports müssen an der Frontblende des Gehäuses herausgeführt werden und zugleich mit dem internen SBC verbunden sein
Im Gehäuse ist kaum Platz, um ohne externes Loop-Kabel für den SBC einen Passthrough bis zum Switch unterzubringen, und mit einem einfachen Switch wäre auch kein System-Monitoring möglich
Da wir ziemlich viele solcher Boxen bauen, ist das eine sinnvolle Lösung; wenn man die Entwicklungszeit ignoriert, ist es als Freiwilligenarbeit machbar
Das Problem scheint in gewissem Maß mit NAND zusammenzuhängen und unterscheidet sich, soweit ich mich erinnere, irgendwie von anderen unterstützten RouterBoards
Jemand hat eine neue Lösung für dieses Problem vorgeschlagen, sie wurde aber noch nicht übernommen: https://forum.openwrt.org/t/wiki-cleanup-for-mikrotik-rb2011... sowie weitere Threads