Hardware/Router/RB5009UPr: Unterschied zwischen den Versionen
(Hinweis: experimentelle Hardware, noch nicht für reguläre Verwendung empfohlen.) |
|||
| Zeile 23: | Zeile 23: | ||
== Allgemeines zum Gerät == | == Allgemeines zum Gerät == | ||
Vorweg: Das RB5009 ist nicht billig und aus diesem Grund sicher nicht für alle Knoten ideal. Größere Knoten (>4 Antennen, mehrere 60GHz Strecken | '''ACHTUNG''': experimentelle Hardware, noch nicht für reguläre Verwendung empfohlen. | ||
Vorweg: Das RB5009 ist nicht billig und aus diesem Grund sicher nicht für alle Knoten ideal. Größere Knoten (>4 Antennen, mehrere 60GHz Strecken) könnten evtl. diese Hardware gebrauchen. Da derzeit mit OpenWrt PoE noch nicht funktioniert, ist die Hardware generell gerade nur als "Entwicklungshardware" zu betrachten! Mit RouterOS gibt es kein "known working" Setup mit RouterOS für Einsatz bei FunkFeuer mit dem OLSR-Routingprotokoll. | |||
Das RB5009UPr ist ein extrem leistungsstarker, kompakter Router mit 7 1GBit/s RJ45 Ports, einem 2.5GBit/s RJ45 Port und einem 10GBit/s SFP+ Slot. | Das RB5009UPr ist ein extrem leistungsstarker, kompakter Router mit 7 1GBit/s RJ45 Ports, einem 2.5GBit/s RJ45 Port und einem 10GBit/s SFP+ Slot. | ||
| Zeile 37: | Zeile 39: | ||
* PoE Output geht mit OpenWrt noch nicht (fehlende Software für Mikrotik PoE v4 SPI Protokoll) | * PoE Output geht mit OpenWrt noch nicht (fehlende Software für Mikrotik PoE v4 SPI Protokoll) | ||
* Es gibt keine Anleitung bzw. erprobtes Setup mit diesem Router bei FunkFeuer | |||
=== Recovery === | === Recovery === | ||
| Zeile 51: | Zeile 54: | ||
* https://www.getic.com/product/mikrotik-rb5009upr-s-in | * https://www.getic.com/product/mikrotik-rb5009upr-s-in | ||
* https://nasstore.eu/product/mikrotik-rb5009uprsin | * https://nasstore.eu/product/mikrotik-rb5009uprsin | ||
Version vom 23. Juni 2026, 22:36 Uhr
Allgemeines zum Gerät
ACHTUNG: experimentelle Hardware, noch nicht für reguläre Verwendung empfohlen.
Vorweg: Das RB5009 ist nicht billig und aus diesem Grund sicher nicht für alle Knoten ideal. Größere Knoten (>4 Antennen, mehrere 60GHz Strecken) könnten evtl. diese Hardware gebrauchen. Da derzeit mit OpenWrt PoE noch nicht funktioniert, ist die Hardware generell gerade nur als "Entwicklungshardware" zu betrachten! Mit RouterOS gibt es kein "known working" Setup mit RouterOS für Einsatz bei FunkFeuer mit dem OLSR-Routingprotokoll.
Das RB5009UPr ist ein extrem leistungsstarker, kompakter Router mit 7 1GBit/s RJ45 Ports, einem 2.5GBit/s RJ45 Port und einem 10GBit/s SFP+ Slot. Alle RJ45 Ports können sowohl als PoE Input als auch Output genutzt werden mit sowohl passivem PoE als auch aktivem (af) PoE. Die PoE Ausgangsspannung ist immer die höchste Eingangsspannung! Das Board kann gleichzeitig über Schraubklemme, Hohlstecker und PoE mit Strom versorgt werden (24-57V), wobei immer die höchste Eingangsspannung "gewinnt".
Mit RouterOS sollte es mit den Containern möglich sein, OLSR lauffähig zu bekommen, dies wurde aber noch nicht getestet. Mit OpenWrt funktioniert das Board problemlos, nur PoE konfiguration ist (noch) nicht möglich (es wird aktiv daran gearbeitet). Da derzeit noch RouterBoot gepatcht werden muss, damit OpenWrt darauf gebootet werden kann, gibt es noch keine offiziellen OpenWrt Snapshot builds für dieses Board (solltest du es trotzdem probieren wollen, melde dich bei mir - jakob).
Known Issues
- PoE Output geht mit OpenWrt noch nicht (fehlende Software für Mikrotik PoE v4 SPI Protokoll)
- Es gibt keine Anleitung bzw. erprobtes Setup mit diesem Router bei FunkFeuer
Recovery
Sollte irgendetwas schiefgehen, kann immer (außer man hat beide Kopien von RouterBoot gekillt. Respekt dazu wenn du das geschafft hast. Melde dich bei mir und ich helfe dir beim Recovery :P) mit dem Mikrotik Netinstall auf RouterOS zurückgeflasht werden.
Performance
Getestet mit IPerf3 über das SFP+ Interface gehen 5GBit/s von Router CPU zu PC (mit aktiver Firewall). Limit ist hier, dass IPerf3 nur einen CPU Kern des Routers nutzt. NAT und Routing performance gehen 10GBit/s half-duplex problemlos (half-duplex deshalb, weil die CPU "nur" mit 1x10GBit/s full-duplex an den Switch angebunden ist) und die CPU ist weit entfernt von Volllast. Wichtig ist nur, dass Firewall Regeln so gesetzt sind, dass alle Streams mit Kernel Fastpathing bearbeitet werden können!