Neuerungen in MikroTik RouterOS 6.41

Ende letzten Jahres hat MikroTik die neue Version 6.41 seines RouterOS-Betriebssystems veröffentlicht, die mit zahlreichen Neuerungen aufwartet und ggf. die Anpassung bisheriger Skripte erfordert.

Das Changelog des Herstellers liest sich dabei durchaus interessant. Auf Basis meiner vorherigen Blogbeiträge fasse ich das Wichtigste kurz zusammen. Die Darstellung ist dabei jedoch keineswegs vollständig, sondern gibt nur das wieder, was ich in ersten kurzen Tests festgestellt habe.

Eine detaillierte Beschreibung der neuen Funktionen und eine Aktualisierung meines Tutorials folgen demnächst.

Hardware-Bridge statt Master-Port

Die wichtigste Änderung, die Administratoren auch zu einer Anpassung ihrer Skripte zwingt, ist die Aufgabe des Master-Port zugunsten einer Hardware-Bridge. Bis einschließlich RouterOS 6.40 wurde eine Software-Bridge stets über die CPU geleitet und war dementsprechend langsamer als die hardwarebeschleunigte Variante direkt über den Switch-Chip.

Um beispielsweise am großen Switch alle Ports miteinander zu verbinden wurde daher auf das Konstrukt des Master-Port zurückgegriffen: ether2-ether24 waren Slaves zum Master ether1. Beim Verbinden von WLAN und kabelgebundenen Anschlüssen kam die Software-Bridge zum Einsatz.

RouterOS 6.41 ändert dieses Konzept nun. Der Master-Port wird zugunsten einer – unter bestimmten Voraussetzungen hardwarebeschleunigten – Bridge gestrichen. Das MikroTik-Wiki enthält hilfreiche Hinweise zum Thema samt Konfigurationsbeispielen.

In meinen Tests klappte die Umstellung beim Update vollautomatisch. Gerade bei komplexeren Setups empfehle ich jedoch dringend, nicht nur ein Backup der Konfiguration anzufertigen, sondern die Änderungen beispielsweise unter Linux mittels des Befehls diff nachzuvollziehen und zu überprüfen.

Interface-Listen für bestimmte Funktionen

Beim Update auf RouterOS 6.41 wird zudem eine weitere Änderung durchgeführt: Anstatt wie bisher einzelne Interfaces u.a. für den Zugriff auf WinBox anzugeben (siehe Teil 3 meines Tutorials), arbeitet das System nun mit Interface-Listen. Aus einem

/tool mac-server mac-winbox add interface=ether2

wird beispielsweise ein

/interface list add name=mac-winbox
/interface list member add interface=ether2 list=mac-winbox
/tool mac-server mac-winbox set allowed-interface-list=mac-winbox

Änderungen bei Neighbour Discovery

Ähnlich verhält es sich auch beim Neighbour Discovery, das ich ebenfalls kurz in Teil 3 meines Tutorials behandelt habe. Aus dem bisherigen Ausschließen von Interfaces mittels

/ip neighbor discovery set ether1 discover=no

wird nun ein augenscheinlich explizites Aktivieren der Interfaces (samt Umbennung des Pfads in discovery-settings), beispielsweise mittels

/interface list add exclude=dynamic name=discover
/interface list member add interface=wlan1 list=discover
/interface list member add interface=ether2 list=discover
/interface list member add interface=ether3 list=discover
/interface list member add interface=ether4 list=discover
/interface list member add interface=ether5 list=discover
/interface list member add interface=bridge1 list=discover
/interface list member add interface=br-cap list=discover
/ip neighbor discovery-settings set discover-interface-list=discover

DHCP-Server

Streng genommen schon seit RouterOS 6.40 hat der DHCP-Server eine Verbesserung erfahren, die insbesondere Nutzern von Amazon Fire OS zugute kommt – der Basis für deren smarte Lautsprecher, Tablets und Streaming-Geräte. In früheren Versionen schlug die Verlängerung der Lease-Zeit fehl, sodass die Verbindung zwischendurch kurz abbrach. Echo-Geräte waren in meinen Tests bis zu einer Minute offline, der Fire TV hat den Dienst bis zu einem Neustart gar ganz quittiert, wogegen die Fire-Tablets nur kurzzeitige Aussetzer von 1-2 Sekunden hatten. Der Workaround mit einer sehr hohen Lease-Zeit ist nun nicht mehr nötig, die Verlängerung klappt problemlos.

Details zum Problem gibt’s im MikroTik-Forum.

DHCPv6-Client

Augenscheinlich gab es auch Verbesserungen beim DHCPv6-Client. In früheren Versionen hatte ich an meinem Kabelanschluss das Problem, dass mitunter kurz nach dem Reboot des Modems noch kein DHCPv6 zur Verfügung stand und der RouterOS-Client bei v6 im Gegensatz zu v4 keinen neuen Versuch unternommen hat. In jüngster Zeit tritt das Problem bei mir nicht mehr auf – ob aber ggf. Updates am Modem dafür verantwortlich sind vermag ich nicht zu sagen.

Details zu diesem Problem gibt’s ebenfalls im MikroTik-Forum.

RouterBOOT-Versionierung

Der Bootloader RouterBOOT wird seit RouterOS 6.41 nicht mehr in einer eigenen Versionierung wie beispielsweise 3.41 geführt, sondern trägt stets die Versionsnummer der Betriebssystemversion, mit der er ausgeliefert wurde, also z.B. 6.41.2. Dieser Änderung stehe ich noch etwas ambivalent gegenüber – im Moment ist mir noch nicht klar, ob die Versionsnummer automatisch angehoben wird oder nur dann, wenn es Änderungen gibt. Das offizielle Changelog im Wiki schweigt sich dazu bislang aus.

Zusammenfassung und Ausblick

Ich setze RouterOS 6.41 mittlerweile auf meinen Systemen produktiv und ohne Probleme ein. Die Änderungen machen durchaus Sinn, erfordern aber ggf. eine Anpassung der Skripte. Im Falle der Interface-Listen lassen sich diese aber beispielsweise auch für die Firewall heranziehen, sodass die Gesamtkonfiguration wieder einfacher wird.

Wer lieber auf Nummer sicher gehen will, für den hat MikroTik im Bugfix-Zweig erst jüngst die Version 6.40.6 veröffentlicht, die keine weitergehenden Änderungen erfordert.

Auf weitere Neuerungen darf man jedoch gespannt sein, findet doch im April die MikroTik-Konferenz in Berlin statt.