It means I have spent a few days working with a new feature, have some useful observations to share, and have already discovered one way to make a test office network considerably less productive. MikroTik introduced CMR with RouterOS 7.26beta1, released on October 5, 2026. This article describes that initial evaluation, rather than a long-term production assessment. Features, behavior, and interfaces may change as development continues, hopefully with feedback from users helping guide those improvements.

CMR is MikroTik’s centralized monitoring and management platform for fleets of RouterOS devices. One device operates as the controller, providing a central place to observe and manage participating clients. I initially assumed the name meant something like “Centralized Monitoring Router,” but MikroTik’s documentation does not explicitly expand the acronym. We will leave the naming department to MikroTik and focus on the practical benefit: fewer individual logins when managing a collection of devices.

CMR provides inventory, fleet upgrades, alerts, script execution, dashboards, topology views, application traffic reporting, and selected WiFi and VLAN provisioning functions. General IP addressing, DHCP, routing, firewall, and user configuration still require device configuration or an appropriate script. CMR creates its own managed configuration objects, making existing custom configurations important to evaluate before provisioning. The official CMR documentation explains the platform’s scope and limitations.

The evaluation took place in a test office using a CCR2116 with NVMe storage as the controller. The environment included multiple CRS354 switches, multiple CRS328 switches—including 24P and 24G variants—a CRS112, multiple 750G devices, and multiple 951G devices. This provided a mixed collection of switching and routing hardware for evaluating inventory, labels, and management behavior. Participating devices were upgraded to RouterOS 7.26beta1 for this test.

WiFi provisioning was not tested, even though the environment included devices with wireless capabilities. The wireless discussion therefore covers documented behavior and deployment considerations. Reading a feature description and successfully operating it across a live network are two different accomplishments, and that distinction matters.

Start with a configuration export and binary backup on each device you intend to upgrade. The export provides a readable configuration record, while the binary backup provides a separate recovery option. Copy both files off the device before making changes, because neither is much help when the only copy remains on a device you cannot reach.

/export file=before-cmr
/system backup save name=before-cmr

The development channel provides the development release available when you check, rather than permanently selecting 7.26beta1. Read the offered version and confirm that it is appropriate before installing it. Installation reboots the device, so arrange a maintenance window and recovery access before proceeding. MikroTik explains this workflow in its RouterOS upgrading and installation guide.

/system package update set channel=development
/system package update check-for-updates

# Install only after reviewing the offered version.
/system package update install

The client must be enabled before a device can participate in CMR management. Installing compatible RouterOS software does not automatically enroll the device, and discovering the controller does not complete pairing. The default client requires password-based approval, while the server normally requires confirmation. Configure the controller address when necessary, inspect the client, and complete the applicable approval steps.

# Replace this example with your controller's reachable address.
/cmr/client set enabled=yes controller-addresses=192.168.88.1
/cmr/client print

Giving a device information through DHCP does not automagically enable its CMR client. I checked, and the magic department apparently has other priorities. CMR supports neighbor and DNS discovery, with DHCP option 15 supplying the domain used for DNS discovery where applicable. Simply supplying an IP address through an arbitrary DHCP option is not equivalent; see the CMR client configuration and pairing documentation.

The separate CMR server package supports ARM, ARM64, and x86 architectures, while the client is available on supported RouterOS devices except SMIPS and PowerPC. Install the appropriate package through System → Packages, apply the changes, and allow the required reboot. Use WinBox 4 or WebFig because WinBox 3 does not support the CMR menus. For anyone still holding tightly to WinBox 3, this is a practical reason to become familiar with version 4.

/cmr set enabled=yes
/cmr print

Pay attention to controller addresses and package storage settings. The controller-addresses setting supplies addresses for clients to use; it is not a firewall rule or an interface access restriction. NVMe storage on the test controller provided a suitable location for packages, but disk and directory names vary between installations. The following example assumes the directory already exists; review the CMR controller settings reference before selecting storage parameters.

# Example only: verify the existing directory first.
/cmr set packages-directory="nvme1/cmr-packages/" packages-cache-type=directory

The centralized view reduced the need to open individual devices simply to check their condition. Connection and pairing states help distinguish discovered, approved, and actively communicating clients. Establish a labeling convention before applying rules, using meaningful device roles, locations, and upgrade groups. Labels such as switch, router, pilot, access, and core make selections easier to understand and review.

/cmr/device print detail

Port labels deserve the same attention, especially before VLAN provisioning. Identify uplinks and management-facing ports while the network is working, because doing so during an outage is considerably less enjoyable. During this evaluation, the graphical topology worked in WebFig but did not display correctly in WinBox; that is an observation from this test rather than a universal result. The device inventory reference explains properties and state flags.

Upgrade management is promising, although I had not completed a full scheduled automatic upgrade cycle when writing this first look. Rules select devices by label and define a channel or pinned version, schedule, execution order, and failure policy. Review the target carefully because a selected channel or pinned release can be earlier than the installed version. Begin with a pilot group and verify recovery before expanding the scope.

/cmr/upgrade print detail

Parallel execution can shorten a maintenance window when devices have independent paths to the controller. If an upstream device reboots while downstream devices depend on it, those devices may lose their management connection. Upgrading the farthest devices first may preserve access longer, but that is an operational strategy rather than evidence that CMR understands every dependency. Select the failure policy deliberately and review the upgrade rule reference before scheduling changes.

My initial experience with the script interface was positive, particularly the ability to inspect status and output centrally. Start with a harmless inspection command and confirm the selected devices before making configuration changes. The following command is a useful initial test when entered through the script tool. Before distributing a change, consider what happens if it runs twice, completes on only some devices, or removes management access.

/system resource print

The beta script tool does not provide a dedicated scheduling option, and execution permissions can affect which commands succeed. Alerts match conditions or events and perform actions such as logging, running a script, or making an HTTP request. Alert scripts execute on the controller, so email actions depend on its email configuration. Start with actionable conditions, verify the results, and consult the alert rule reference before expanding the alert set.

/cmr/alert print detail

Think of the topology view as a younger relative of The Dude: useful, somewhat fresher-looking, and still developing its personality. Yes, I went there, but the map was reasonably accurate in this test network. I have not yet evaluated a larger deployment or frequent topology changes. Clearer layout controls would improve troubleshooting usability, and the layout reference documents the available settings.

For application traffic reporting, the observation point matters. A routed gateway is generally more useful than an arbitrary access switch when evaluating traffic leaving a site. Traffic that never passes through the observing device cannot be evaluated there, so compare reports with the actual forwarding path. I would like more flexibility in application identification and plan to evaluate this feature further as development continues.

WiFi provisioning was not tested in this deployment, so its practical behavior remains part of a future evaluation. Before applying it to an existing installation, record the radio configuration and verify how provisioning interacts with bridges and VLANs. Test a single access point and confirm both client connectivity and management access before expanding the group. Avoid assuming that removing managed configuration will reproduce every detail of the original setup, and preserve a verified recovery plan.

VLAN provisioning caused approximately three hours of downtime at the test office. That is three hours I would have preferred to spend doing almost anything else. The rule I applied changed the relevant ports into access ports and removed the communication path back to the controller. Once that happened, the controller could no longer reach the device to undo the change.

CMR VLAN rules create a managed bridge and move selected ports into it, making selection scope particularly important. Leaving device or port selectors unspecified can affect more of the network than intended. Access ports use a PVID for untagged traffic, while trunk ports carry the configured VLANs as tagged traffic. Preserve the management path throughout the change and review the VLAN rule documentation before applying a rule.

# Inspect rules on the controller:
/cmr/vlan print detail

Recovery in this incident required local console access, disabling the client, correcting the controller rule, and then enabling the client again. Bridge settings, ports, and management connectivity still needed verification before recovery could be considered complete. This was the sequence used in this incident, rather than a universal repair procedure. The controller needs a working communication path to deliver a rule removal, which is why preserving that path matters.

# On the affected client, through local recovery access:
/cmr/client set enabled=no

# Correct the controller rule and verify connectivity first.
/cmr/client set enabled=yes

The centralized view already offers practical value for routine fleet checks. Several additional features look promising, although the upgrade and wireless workflows need more testing before I would make stronger claims. These are the main positives from this initial evaluation:

• Centralized visibility: Inventory and device state reduce the need to log in to every device for routine checks.
• Flexible upgrade controls: Labels, ordering, schedules, and failure policies provide a useful framework for staged maintenance.
• Local package storage: Correctly stocked controller storage can reduce repeated downloads and support sites with limited internet access.
• Convenient script execution: Selected devices can run common tasks with centrally visible status and output.
• No separate CMR subscription in this setup: The package makes the feature accessible without adding a recurring management subscription.
• Potential for consistent provisioning: Shared WiFi and VLAN rules could simplify suitable deployments after careful validation.
• Encouraging initial resource usage: The CCR2116 did not appear heavily loaded during this test, although this is not a fleet-sizing benchmark.

The beta has limitations worth considering before deployment. Some are missing conveniences, while others require careful planning to avoid disrupting the network. These are the main concerns and improvements I would like to see:

• Provisioning can interrupt management: An overly broad VLAN rule can remove the controller connection and require local recovery.
• Existing configurations need evaluation: Managed objects can overlap with custom bridge, VLAN, or wireless arrangements.
• A dedicated backup workflow would help: Centralized changes make convenient fleet backup and recovery preparation especially valuable.
• Initial adoption requires compatible client software: An earlier client rollout would have made enrollment easier for existing fleets.  i.e. If they would have rolled the CMR client out in v7.24, vs 7.26, it would have helped adoption. 
• The script tool lacks a dedicated scheduling option: Recurring tasks require additional planning.
• Topology presentation needs polish: Layout usability and the display differences observed between WinBox and WebFig deserve attention.
• Application reporting could be more flexible: Broader identification options would improve its usefulness, ability to add more applications.  
• Long-term behavior remains unproven in this evaluation: Scheduled upgrades, partial failures, and wireless provisioning need further testing.

CMR looks promising as a practical tool for managing a MikroTik fleet. Even without expanding into WiFi and VLAN provisioning, centralized inventory, monitoring, and upgrade management could make it worthwhile. The CCR2116’s behavior during this test was encouraging, but it does not establish controller sizing for a larger deployment. Start small, label carefully, preserve the management path, and keep recovery access available.

There is still plenty to evaluate, particularly around repeated maintenance cycles and failure recovery. The early results are encouraging enough to justify further testing. Of course, “free” does not mean an outage costs nothing, and this test has already contributed to that accounting lesson. A centrally managed mistake is still a mistake—just delivered more efficiently.

Dennis Burgess is the author of this first-look evaluation for Link Technologies Inc. This article combines his observations from a test office deployment with references to MikroTik’s documentation. The recommendations reflect that initial testing and should be revisited as CMR develops.