CCRs und das V6.49-Problem
Wer einen auf der Tile-Architektur basierten CCR von Mirktoik einsetzt und auf ROS Version 6.49 updatet, kann es erleben, dass das Gerät nur mit langer Verzögerung (8 bis 12 Minuten!) neustartet und sich im Betrieb unvorhersehbar verhält!
Der Router läuft hier in einen Timeout, der abhängig davon ist, wie viele Simple-Queues angelegt sind (keine = schnellerer Shutdown / mehr = je länger dauert der Shutdown-Prozess). Das Problem tritt ab dem zweiten Neustart (i. d. R. bei einem Update die Firmware / des Bootloaders) mit V6.49 auf. Was ursprünglich auf ein Firmware-Problem hindeutete, aber auch mit einer gedowngradeten Firmware (6.48.4) und ROS (6.49) besteht das Problem. Warum der zweite Reboot ursächlich ist, bleibt unklar…
Auf dem LCD wird während dieser Zeit „rebooting“ angezeigt:
Über die Console sieht man, dass das Problem mit einem Dienst in Zusammenhang steht „Stopping services“:
In diesem Zustand bleibt der Router, bis irgendwann der Timeout erreicht wird.
Auch im Regelbetrieb verhält sich der Router dann nicht mehr vorhersehbar, so können z. B. angelegte Interfaces u. U. nicht gelöscht werden „Timeout (13)“ oder das Gerät „friert“ 10 Minuten ein -> scheinbar läuft hier auch irgendwas in einen Timeout.
Momentan (Stand 06.11.2021) ist die einzige Möglichkeit das Problem zu beheben, auf eine ROS Version 6.48.5 oder älter zu downgraden (ROS und Firmware!).
Nach einer längeren Diskussion mit dem Support, konnte bei Mikrotik der Fehler reproduziert werden. Was dahingehend interessant ist, dass scheinbar nicht alle CCRs davon betroffen sind – möglicherweise nur bestimmte Hardware-Revisionen..?
We have managed to reproduce the issue locally in our labs and look forward to fixing it on upcoming RouterOS versions, unfortunately, I cannot provide an ETA now. Meanwhile please use 6.48.x. – Mikrotik
Auch hier die Empfehlung auf eine ROS 6.48.x-Version zu downgraden bzw. mit Tile-CCRs gar keinen Versuch auf die 6.49 zu wagen (zumindest bei Produktivsystemen). Geräte ohne Tile-CPUs sind davon nicht betroffen.
Update vom 11.11.:
Mikrotik hat mir eine Vorabversion mit der Versionsnummer „6.99“ zugesendet, mit der Bitte zu testen ob der Fehler behoben wurde.
In dieser Version war der oben beschriebene Fehler tatsächlich verschwunden. Somit darf man auf eine baldige Veröffentlichung von 6.49.1 hoffen!
Update vom 17.11.:
Wie vermutet, mit ROS 6.49.1 ist der Fehler beseitigt worden!
Im offiziellen Change-Log findet sich dazu aber nichts.
System- und Netzwerkadministrator
Informationstechnik – Netzwerktechnik – Consulting
MCSA+M | MCSE | MTCNA