CMR

官方原文约 79 分钟阅读

CMR 是面向 RouterOS 设备机群的集中监控平台。它支持在整个机群范围内执行更新、监控和告警管理。

CMR

CMR 是面向 RouterOS 设备机群的集中监控平台，支持在整个机群范围内执行更新、监控和告警管理。

信息

cmr 软件包仅在 arm、arm64 和 x86 架构的设备上受支持。CMR 客户端是 RouterOS 的一部分，因此除 smips 和 powerpc 架构的设备外，每台设备都可以作为 CMR 客户端。

概述

CMR 从机群中的一台设备管理整个 RouterOS 设备机群。一台设备运行 CMR 服务器，其他设备作为 CMR 客户端连接到它。通过服务器可以查看整个机群的状态、升级机群、接收告警、在多台设备上同时运行命令、绘制网络拓扑图，以及配置 WiFi 网络和 VLAN 端口。

CMR 的功能

设备清单 - 列出每个客户端的标识、板卡、RouterOS 版本、已安装软件包、连接状态和标签。
机群升级 - 按规则升级设备组：通道或固定版本、计划时间、设备组顺序以及失败策略。软件包来自 MikroTik 更新服务器或服务器上的某个目录。
告警 - 监视资源使用率、健康传感器、可用性、升级、接口和日志行，在条件满足时写入日志消息、运行脚本或调用 webhook。
在多台设备上执行命令 - 在选定设备上运行脚本并显示每台设备的输出，还可以重启、升级或配对设备。
仪表板 - 实时显示所选设备的摘要：连接状态、资源使用率、接口、流量和 WiFi 客户端。
网络拓扑 - 绘制网络拓扑图，设备之间的链路根据邻居和端口数据构建。拓扑图在 GUI 中显示。
应用流量 - 收集经过所选路由器（通常是网关）的应用流量统计。
WiFi 配置 - 一次性定义 WiFi 网络和射频设置，并将其应用到选定的接入点，也可按频段应用。
VLAN 配置 - 将客户端的选定端口配置为 VLAN 的 access 或 trunk 端口。

CMR 不执行的操作

CMR 不配置 IP 地址、DHCP、路由、防火墙、用户或其他设备设置。请使用 WinBox、WebFig 或 CLI 在设备上进行配置。若要在多台设备上执行一次性更改，请使用 run-script。
CMR 不编辑或接管设备的现有配置。它会在现有配置旁边创建自己的配置对象，并在发生重叠时接管，例如 WiFi 射频或网桥端口。
CMR WiFi 将配置写入每个接入点。它不协调接入点之间的漫游，也不充当中央认证服务器。

工作原理

服务器运行在安装了 cmr 软件包的设备上。客户端是 RouterOS 的一部分，因此除 smips 和 powerpc 架构的设备外，每台设备都可以作为客户端。
客户端通过邻居发现（MNDP）或 DNS 查找服务器，也可以连接到 controller-addresses 中设置的地址。对于 DNS，客户端会解析 _cmr._tcp.lan 和 _cmr._tcp.<domain>，其中 <domain> 是从 DHCP 收到的域名（选项 15，domain-name）。服务器无需充当网关，客户端可以跨路由网络连接，包括通过 NAT 或 VPN 连接。
只有双方设备都同意后，客户端才会被管理。这个过程称为配对。配对后，服务器从客户端收集状态数据，并向其发送配置，例如 WiFi 网络。
CMR 发送的配置以托管对象的形式存储在客户端上，并标记为 Y 标志。这些对象无法在客户端上更改，并且在服务器不可达时仍然有效。禁用客户端会移除这些对象。
CMR 菜单请使用 WinBox 4 或 WebFig。WinBox 3 不支持这些菜单。

CMR 最适合运行默认配置或接近默认配置的设备，例如刚开箱的设备。CMR 不会调整其对象来适应自定义的网桥、VLAN 或 WiFi 设置，因此配置了大量非标准设置的设备可能需要手动调整，之后 CMR 配置才能按预期工作。

快速开始

在将作为服务器的设备上安装 cmr 软件包，并使用 /cmr set enabled=yes 启用服务器。
在每台要管理的设备上，使用 /cmr/client set enabled=yes 启用客户端。如果客户端无法自行发现服务器，请添加 controller-addresses。
批准配对。在默认配置中，服务器会等待批准：新设备会以 P 标志列在 /cmr/device 中，直到为其运行 pair。配对章节介绍了各个选项。
为设备分配标签，例如按站点和角色分配，以便规则能够选择设备组。
为这些标签创建升级规则和告警规则。

CMR CLI Reference 详细说明了服务器上 /cmr 菜单中的每个参数和命令。CMR-Client 指南介绍了客户端侧，CMR-Client CLI Reference 详细说明了受管设备上 /cmr/client 菜单中的每个参数和命令。

CMR 服务器通过 /cmr 菜单进行配置。

启用 CMR 服务器

CMR 客户端通过 TCP 端口 54321 连接到服务器。请在服务器防火墙（input 链）中允许客户端连接到此端口，并允许此流量通过客户端与服务器之间的任何防火墙。

启用服务器：

[admin@MikroTik] > /cmr set enabled=yes

启用服务器后，该路由器将成为已连接 CMR 客户端的管理控制器。设备列表（包括服务器自身）显示在 /cmr/device 菜单中。

服务器设置

/cmr 菜单还控制客户端如何查找服务器，以及服务器从客户端收集哪些内容：

controller-addresses - 当设备无法通过邻居发现（MNDP）或 DNS 自动发现服务器时，发送给设备的服务器 IP 地址。
track-topology - 从客户端获取路由、WiFi 注册表、ARP 表、邻居、DHCP 状态和接口状态。网络拓扑布局的自动链路依赖这些数据。默认值：yes。
fetch-comments - 从客户端获取接口、端口和 WiFi 注册表条目的注释。默认值：yes。
auto-labels - 选择服务器从客户端获取哪些自动标签：version、architecture、model、board-name、identity 和 address 中的任意项，或者 all 或 none。默认值：all。
apptraffic-devices - 按标签选择要收集应用流量统计的设备。默认值：gateway，即带有 gateway 标签的设备。设置为 all 可选择所有设备。
upgrade-check-interval - 服务器检查更新服务器以获取新版本的频率。最小值为 1 分钟。默认值：10h。
packages-directory、packages-cache-type 和 packages-cache-limit - 服务器获取和存储升级软件包的位置。升级来源章节对此进行了说明。

目前，对于未设置的设置项，/cmr/get 会返回空值，而不会返回其默认值。要将设置恢复为默认值，请在其名称前加上 !，例如 /cmr set !upgrade-check-interval。

目前，更改 packages-directory、upgrade-check-interval 或 pairing-requirement 会重启服务器上的 CMR：每个客户端都会重新连接，仍然匹配的状态告警会再次执行其操作。

配对

只有双方设备都同意，配对才会建立。每台设备都有自己的 pairing-requirement 设置，该设置定义了远程设备必须执行什么操作，本设备才接受配对。由于每一侧都有自己的要求，只有双方设备的要求都得到满足后，配对才会成功。

在本地运行 pair 命令始终表示本设备批准配对，无论其配置的要求是什么。CMR 服务器支持 pairing-requirement=none、password 和 confirm；客户端支持 none 和 password：

none - 无需额外批准。此设备会自动接受配对。
password - 远程设备可以通过 pair 命令的 username 和 password 参数提供本设备上某个 RouterOS 用户的用户名和密码来批准配对。CMR 没有单独的配对密码。也可以在本地使用 pair 命令批准配对。
confirm - 在 CMR 服务器上，必须在本地运行 /cmr/device/pair 来批准配对；无法从远程侧批准。

可以将 pairing-requirement 理解为：本设备同意配对之前必须发生的事情。只有双方设备都同意后，配对才会完成。

典型配对场景

none 适用于可信环境，设备一旦发现彼此就应自动配对。例如，同一受管 LAN 上的 CMR 服务器和客户端都可以使用 none，从而无需用户交互即可完成配对。
confirm 强制在服务器上进行显式的本地批准：仅发现新客户端还不够；管理员必须在服务器上运行 pair 命令，服务器才会接受该客户端。
password 适用于需要远程批准，但物理或管理访问两台设备都不方便的情况。例如，客户端可以使用 password，允许 CMR 服务器使用客户端上某个用户的凭据远程满足客户端的要求。

两台设备上的要求相互独立。客户端会自动接受配对（none），或者在服务器提供客户端上某个用户的凭据时接受配对（password）。例如：

CMR 服务器：none，客户端：none - 双方设备都自动接受。
CMR 服务器：none，客户端：password - 当服务器提供客户端上某个用户的凭据时，客户端接受配对。
CMR 服务器：password，客户端：none - 当客户端提供服务器上某个用户的凭据时，服务器接受配对。
CMR 服务器：password，客户端：password - 除非在本地使用 pair 命令批准配对，否则每台设备都必须满足另一台设备的密码要求。
CMR 服务器：confirm，客户端：none - 客户端自动接受，但必须在服务器上运行 pair 命令。
CMR 服务器：confirm，客户端：password - 当服务器提供客户端上某个用户的凭据时，客户端接受配对，但还必须在服务器上运行 pair 命令。

每个 pair 命令都接受另一台设备的用户名和密码：在服务器上，/cmr/device/pair 接受被配对设备上的用户；在客户端上，/cmr/client/pair 接受服务器上的用户。不带凭据运行 pair 表示批准本设备这一侧，当远程侧的要求为 none 时，这会同时满足双方。配对通常可以从一个控制台完成：在服务器上，/cmr/device/pair 已经批准了服务器这一侧，因此服务器自身的 password 只会在客户端控制台输入，永远不会在服务器上输入。服务器的 password 要求仅在从客户端发起配对时才重要。confirm 是唯一强制在服务器控制台执行操作的要求；设置它后，无法仅从客户端完成配对。

使用密码配对还会自动找到设备：服务器会向每台选定设备出示 username 和 password，因此无需知道哪台设备对应哪个密码。当一个站点的设备各自带有不同的出厂密码，并且这些设备就在你面前时，请对每个包装箱运行一次 /cmr/device/pair username=admin password=<其中一个包装箱的密码>：每次运行都会配对具有该密码的设备，其他设备则保持待配对状态。使用 labels 代替 all，可将一次配对运行限制在机群的一部分。

要开始配对，请在其中一个设备上运行 pair 命令：在 CMR 服务器上运行 /cmr/device/pair，或在客户端上运行 /cmr/client/pair。也可以使用物理复位按钮执行配对：服务器上的 /cmr/push-button 或客户端上的 /cmr/client/push-button。

管理设备

/cmr/device 菜单列出由服务器管理的设备。设备一旦连接到服务器，就会出现在列表中；在配对获得批准之前，它会带有 P（待配对）标志。服务器自身显示为带有 L 标志的设备。每个条目显示设备标识、板卡、RouterOS 版本、标签和运行时间。对于当前已连接的设备，使用 where 过滤列表时，print 输出还会包含连接地址：

[admin@MikroTik] > /cmr/device/print where labels=Group2
Flags: C - CONNECTED; U - UPGRADE-AVAILABLE
Columns: IDENTITY, BOARD, VERSION, LABELS, UPTIME, ADDRESS
 #    IDENTITY  BOARD       VERSION  LABELS  UPTIME   ADDRESS
 2 CU MikroTik  RB4011iGS+  7.x      Group2  1h5m53s  192.168.1.98
 3 CU MikroTik  RB4011iGS+  7.x      Group2  1h3m8s   192.168.1.99
 9 CU MikroTik  RB4011iGS+  7.x      Group2  1h9m37s  192.168.1.100

设备的 address 是其与服务器连接时的源地址。对于位于 NAT 后面的客户端，它是转换后的地址，因此多个客户端可能显示相同的地址。

标志表示设备状态：L 表示服务器自身，P 表示配对待批准，C 表示已连接，S 表示状态过期（无连接），U 表示设备的升级通道上有不同版本可用。U 版本也可能早于已安装版本，例如设备运行测试版本，而其升级规则使用 stable 通道时。/cmr/device CLI 参考列出了每个标志和每个只读值，例如板卡、序列号、已安装软件包、告警计数以及覆盖该设备的升级规则。

设置设备属性

可以从服务器更改受管设备的以下属性：

identity - 重命名设备。新标识会应用到设备本身。
labels - 分配标签以对设备分组。标签是 CMR 中通用的选择机制：升级规则、告警规则、run-script 和其他设备命令都按标签选择设备。
port-labels - 为每个端口分配标签。请给标签加引号，例如 port-labels=ether1:"uplink"。/cmr/vlan 规则的 port-labels 会按这些标签或接口名称选择端口。
pairing-requirement - 针对单台设备覆盖服务器的配对要求。

可以使用 where 按上述任意属性过滤列表，例如 /cmr/device/print where connected 或 /cmr/device/print where labels=office。要移除设备的所有标签，请将 labels 设置为空值。

标签与设备选择

标签用于对设备分组。升级规则、告警规则、WiFi 和 VLAN 配置、布局、apptraffic-devices 设置以及设备命令都按标签选择设备。

除了你分配的标签外，每台设备还有自动标签，显示在只读值 auto-labels 中：例如其地址、架构、型号、板卡名称和标识。自动标签和你自己的标签一样用于选择设备，因此 labels=arm 会选择所有采用 arm 架构的设备，labels=Office-AP1 会选择具有该标识的设备。

labels 值是以逗号分隔的列表。普通标签之间使用 OR 组合。以 + 开头的标签也必须匹配（AND），以 - 开头的标签会排除设备（AND NOT）。all 会选择所有设备，包括 CMR 服务器。

选择器	选中的设备
`labels=office,lab`	具有 `office` 标签或 `lab` 标签的设备。
`labels=office,+ap`	同时具有 `office` 和 `ap` 标签的设备。
`labels=office,-ap`	具有 `office` 标签、但没有 `ap` 标签的设备。
`labels=office,lab,-ap`	具有 `office` 或 `lab` 标签、但没有 `ap` 标签的设备。
`labels=all,-core` 或 `labels=-core`	除具有 `core` 标签的设备之外的所有设备。

说明

+ 和 - 符号必须位于列表元素的开头。没有逗号时，labels=office+ap 是一个单独的标签名称。没有设备具有的标签也会被接受，且不会发出警告，因此在依赖某个选择之前请先检查它，例如使用升级规则的 show-devices 或告警规则的 devices 计数。 WiFi 项目还可以使用频段标签选择某个频段的射频，VLAN 规则可以按端口标签选择端口。WiFi 配置和 VLAN 配置章节对此进行了说明。

在设备上运行命令

设备菜单提供了对选定设备执行操作的命令，以及它们报告的只读值：

run-script - 在每台选定设备上运行单行 RouterOS 脚本并显示其输出。脚本以受限权限运行：需要 policy 权限的命令（例如添加用户）会失败并提示 "not enough permissions (9)"。
upgrade - 为选定设备启动升级任务，无论其升级规则的计划如何。
reboot - 重启选定设备。命令会立即返回，设备重启后服务器会记录 <device> rebooted，其中 <device> 为 identity@address。
pair - 开始与选定设备配对。
wifi-logs - 监视选定设备的 WiFi 日志。可以按 event（connected、disconnected 或 failed）、客户端 MAC 地址（address）、bssid 或时间范围（time-start 和 time-end）过滤条目。由 CAPsMAN 管理的接入点事件由 CAPsMAN 设备记录，并显示在该设备下。目前，设备选择不会限制输出：会显示所有记录 WiFi 事件的设备的条目。
apptraffic - 选定设备的应用流量监视器。
dashboard - 选定设备的实时视图。

每个命令通过 labels（或 numbers）选择设备，并按设备报告结果。例如，在具有 Group2 标签的所有设备上运行命令：

[admin@MikroTik] > /cmr/device/run-script labels=Group2 script="/system/identity/print"
Columns: DEVICE, STATUS
DEVICE                  STATUS
MikroTik@192.168.1.98   running
MikroTik@192.168.1.99   running
MikroTik@192.168.1.100  running

Columns: DEVICE, STATUS, OUTPUT
DEVICE                  STATUS   OUTPUT
MikroTik@192.168.1.98   success   name: MikroTik
MikroTik@192.168.1.99   success   name: MikroTik
MikroTik@192.168.1.100  success   name: MikroTik

该命令首先将选定设备列为 running，然后在脚本完成后显示每台设备的 STATUS 和 OUTPUT。run-script 拒绝空选择：没有 numbers 或 labels 时会失败并提示 "numbers and/or labels required"；标签未匹配任何设备时会失败并提示 "no devices selected"。这里的 labels 遵循 CMR 中各处相同的标签语法：以逗号分隔的列表中，普通标签使用 OR 组合，以 + 开头的标签也必须匹配（AND），以 - 开头的标签会排除设备（AND NOT）。例如，labels=office,+ap 选择同时具有两个标签的设备，labels=all,-core 选择除具有 core 标签之外的所有设备。没有逗号时，office+ap 会被视为一个单独的标签名称。

run-script 权限

通过 /cmr/device/run-script 发送的脚本会在每个客户端上以 read、write、test 和 reboot 权限运行，且没有用户会话。需要其他权限的命令会失败并提示 "not enough permissions (9)"，例如 /user add 需要 policy 权限，/tool sniffer 需要 sniff 权限。/system backup save、/system reset-configuration 和 /file copy 也会以相同错误失败。/export 可以正常工作：它会在输出中返回客户端的配置，因此 run-script 可以从机群收集配置导出。敏感值不可读取：/export 会省略它们，/export show-sensitive 也不会显示其值，get 会将它们显示为 *。仍然可以设置它们，例如 PPP secret 密码。

由 run-script 创建的脚本和计划任务条目会以相同的四项权限保存，显示为 policy=reboot,read,write,test。owner 是系统用户（*sys），而不是控制器用户。权限集无法在客户端上更改：尝试授予更宽权限的脚本会将其 policy 缩减为这四项权限。下表显示了在 run-script 下每项权限可以执行的操作：

权限	示例命令	结果
`read`	`:put [/system identity get name]`	成功，返回该值。
`read`	`/export`	成功，返回不含敏感值的配置。
`write`	`/file add contents=x`、`/ip service set telnet port=2323`、`/tool romon set enabled=no`	成功，配置已更改。
`write`	`/system script add`、`/system scheduler add`	成功，条目以 `policy=reboot,read,write,test` 保存。
`write`	`/ppp secret add name=test password=abc`	成功，即使缺少 `sensitive` 权限也会设置密码。
`test`	`/ping`、`/tool traceroute`	成功
`reboot`	`/system reboot`	成功，客户端重启并重新连接到服务器。
`policy`	`/user add`、`/user group add`	失败并提示 "not enough permissions (9)"。
`sniff`	`/tool sniffer quick`	失败并提示 "not enough permissions (9)"。
`sensitive`	`:put [/ppp secret get ... password]`	值显示为 `*`。

仪表板

/cmr/device/dashboard 命令打开选定设备的实时视图：连接了多少台设备、CPU、内存和磁盘使用率、接口状态以及流量吞吐量。该视图每隔几秒刷新，直到你停止它。按 m、l、a、p、w 或 s 可在主视图、告警、设备、端口、WiFi 和资源视图之间切换，按 D 导出当前视图，按 Q 退出：

[admin@MikroTik] > /cmr/device/dashboard numbers=[find where [:find $labels "Group2"]>=0]
DEVICES          TOTAL  PAIRED  ONLINE
                 3      3       3
RESOURCES                MIN  AVG  MAX
CPU        ------------  0    0    0
Memory     ===---------  33   33   34
HDD        ===========-  96   96   97
3      Ethernet
3      Enabled   =====================
3      Running   =====================
3      Wifi
3      Enabled   =====================
                              TX  RX
Total                         0   480
Uplink                        0   480
Ethernet                      0   480
Wifi                          0   0

目前，使用 labels 选择设备时，dashboard 和 wifi-logs 会返回 no such item。请改用 numbers 选择设备，如示例所示：[find where [:find $labels "Group2"]>=0] 选择具有 Group2 标签的设备，[find where identity~"Office"] 按标识选择设备。/cmr/device/dashboard CLI 参考列出了其所有参数。

WebFig GUI 中会显示相同的实时视图：

<center>![](https://manual.mikrotik.com/img/cmr_dashboard.webp)</center> <center>**该图显示 WebFig GUI 中的 CMR 仪表板。**</center>

仪表板分区

仪表板分为八个分区：

Devices - 已配对和在线设备的数量。只有当前已连接的已配对设备才算在线，因此离线的已配对设备或尚未配对的设备不会显示为在线。
Resources - 每台设备当前的 CPU、内存和磁盘使用率。
Bandwidth - 设备流量吞吐量的实时图表。绿色区域是上传带宽，红色/棕色区域是下载带宽，绘制最近几分钟的数据。摘要显示当前、平均和最大下载与上传速率。
Active Alerts - 当前触发的告警规则，以及每个告警在多少台设备上处于活动状态。
Available Updates - 升级通道上有不同 RouterOS 版本可用、且由其升级规则提供的设备。
Traffic - 来自应用流量分类器的设备应用流量表，覆盖最近一小时。每行是一个应用，包含其名称、下载量及占总量的比例（以进度条显示），以及上传量及其比例。
Access Points - 设备上运行的接入点数量。WiFi 频段选择器（2.4、5 或 6 GHz）可过滤视图，柱状图显示每个信道上运行了多少个接入点。
Stations - 连接到这些接入点的客户端站点数量。WiFi 频段选择器可像接入点一样过滤视图，柱状图显示每个信道上连接了多少个站点。

机群升级

CMR 通过 /cmr/upgrade 菜单中的升级规则管理整个机群的软件升级。升级规则通过 labels 选择其覆盖的设备，安排升级运行时间，并定义要安装的通道或版本。

升级规则

规则通过 labels 选择其覆盖的设备，这些标签与 CMR 中各处使用的标签相同。如果省略 labels，规则将覆盖所有已连接设备（labels=all）。普通列表使用 OR 组合标签，以 + 或 - 开头的列表元素分别以 AND 和 AND NOT 组合它们，例如 labels=all,-core。

例如，以下规则创建每晚将所有已连接设备升级到最新 stable 版本的升级任务：

[admin@MikroTik] > /cmr/upgrade/add name=nightly labels=all channel=stable schedule-time="00:00:00" strategy=sequential fail-policy=continue

每个参数设置规则的一个属性：

name=nightly 为规则命名。该名称会出现在规则列表中，并用于选择规则以立即运行。
labels=all 选择所有已连接设备。显式指定 all 与省略 labels 相同。
channel=stable 选择升级通道：long-term、stable、testing 或 development。要固定特定版本，请直接将版本设置为通道值，例如 channel=7.24.4。
strategy=sequential 逐台升级设备，并等待每台设备完成。另一种选择是 parallel，它会同时升级所有覆盖的设备。
fail-policy=continue 跳过失败的设备并继续处理其余设备。未设置 fail-policy 时，规则使用 stop。第三种失败策略是 continue-order。
schedule-time="00:00:00" 每天午夜触发此规则。schedule-time 是一个时间，可选带星期几，例如 14:00:00（每天 14:00）或 00:00:00@sat（每周六午夜）。多个时间用逗号分隔，例如 00:00:00@sat,00:00:00@sun。星期几使用 @ 分隔：如果使用空格，例如 "14:00 sat"，星期几会被丢弃，规则每天运行。

<center>![](https://manual.mikrotik.com/img/cmr_upgrade_rule_nightly.webp)</center> <center>**该图显示在 WinBox GUI 中配置的每晚规则。**</center>

每周规则的创建方式相同。例如，以下规则每周六 14:00 升级两个标签组，并在首次失败时停止：

[admin@MikroTik] > /cmr/upgrade/add name=weekly labels=Group1,Group2 channel=stable schedule-time="14:00:00@sat" strategy=parallel fail-policy=stop order=Group1,Group2

schedule-time="14:00:00@sat" 每周六 14:00 开始升级。星期几位于 @ 之后，可以是 sun、mon、tue、wed、thu、fri 或 sat。
order=Group1,Group2 设置标签组及其处理顺序。
fail-policy=stop 在设备失败时停止整个升级。在此示例中，Group1 中有一台设备失败会停止升级，Group2 不会被升级。

<center>![](https://manual.mikrotik.com/img/cmr_upgrade_rule_weekly.webp)</center> <center>**该图显示在 WinBox GUI 中配置的每周规则。**</center>

信息

规则的顺序决定优先级。当多条规则选择重叠的设备时（例如一条 labels=all 规则和若干具有特定标签的规则），列表中第一条匹配某台设备的规则会占用该设备。因此，放在首位的 labels=all 规则会覆盖所有设备，后面的规则在 /cmr/upgrade/show-devices 中不会显示任何设备。当每个标签组都需要自己的规则时，请将特定标签规则列在 labels=all 规则之前，并使用 show-devices 验证每台设备的分配情况。启用服务器后，规则列表中会包含一条名为 default 的动态规则（标志 D，labels=all，channel=stable）。它列在你自己的规则之后，覆盖没有其他规则占用的设备。该规则没有计划时间：它设置检查这些设备 U 标志和 available-version 时使用的通道。如果你的设备运行测试版或开发版，请创建覆盖它们的规则，以免向它们提供 stable 升级。

要更改规则的位置，请使用 move，例如 /cmr/upgrade/move [find name=weekly] 0。目前，add 的 place-before 参数会将新规则添加到列表末尾。

运行升级

创建规则后，会根据其 schedule-time 安排任务。也可以不等待计划时间而直接开始升级：

/cmr/upgrade/trigger - 立即启动所选规则的任务，提前升级其覆盖的设备，无需等待 schedule-time。
/cmr/upgrade/job/run-next - 立即运行已计划的任务。对于升级规则的任务，已计划任务仍保持计划状态，而本次运行会作为新任务添加。通过 /cmr/device/upgrade 计划的任务没有需要保留的计划，因此 run-next 会启动该任务本身。
/cmr/device/upgrade - 无论设备的规则计划如何，都升级选定设备：立即升级，或在下一个 schedule-time 时升级。未指定 channel 时，每台设备按其自己的升级通道升级，即 /cmr/device 中显示的 channel 值。

在控制台上，/cmr/device/upgrade 会显示其启动任务中的设备及其状态，直到你按 <kbd>Control</kbd>+<kbd>C</kbd> 或达到 duration 中给定的时间。停止输出不会停止任务，任务会在服务器上继续。之后可以使用 /cmr/upgrade/job/show-devices 查看。

一次只能运行一个升级任务。当另一个任务正在进行时触发第二个任务，会将新任务置于 queued 状态，直到正在运行的任务完成。使用 /cmr/upgrade/version-check 查看升级规则中配置的通道可用的最新版本。

升级来源

服务器会向 MikroTik 更新服务器查询升级规则所用每个通道的最新版本。/cmr/upgrade/version-check 显示结果，已连接设备会在 /cmr/device 菜单的只读参数 available-version 中显示最新可用版本。/cmr 菜单中的 upgrade-check-interval 设置控制检查频率。

当升级运行且所需版本在本地尚不可用时，服务器会下载软件包文件，存储它们，然后发送到设备；定期版本检查只查询哪些版本可用。/cmr 菜单中有缓存设置：packages-cache-type 选择下载的软件包存储在服务器存储上（directory，位于 packages-directory 的 cmrcache 子目录中）还是内存中（memory），packages-cache-limit 设置最大缓存大小（兆字节）。缓存已满时，服务器会驱逐较旧的条目，为新下载的软件包腾出空间。

要让服务器提供你自己的软件包，请将 .npk 文件放在服务器文件系统中的某个目录，并将 packages-directory 设置为该目录。软件包会单独解析：所需版本已存在于目录中的软件包会直接从那里提供，无需重新下载，只有缺失的软件包才会下载到缓存。

使用软件包目录可以安装更新服务器不提供的版本。将覆盖设备所需每种架构和每个已安装软件包的软件包放入目录，将其选为 packages-directory，并将版本设置为通道。例如，对于采用 arm 架构并安装了 wifi-qcom 软件包的设备：

[admin@MikroTik] > /file add name=cmr-packages type=directory

将 routeros-<version>-arm.npk 和 wifi-qcom-<version>-arm.npk 上传到 cmr-packages，例如使用 SFTP，然后选择该目录并升级设备：

[admin@MikroTik] > /cmr set packages-directory=cmr-packages/
[admin@MikroTik] > /cmr/device/upgrade labels=testgroup channel=7.24.4

packages-directory 值从现有目录中选择，并以 / 结尾。目前，更改 packages-directory 会重启服务器上的 CMR，所有客户端都会重新连接，因此请在 /cmr/device 中客户端重新显示为已连接后再启动升级任务。

如果目录在被选择后被删除，/cmr print 仍会显示它且不会发出警告，服务器会将其下载的软件包保留在 RAM 中。请以相同名称重新创建目录，例如 /file add name=cmr-packages type=directory，并将软件包放入其中。该设置不会改变，因此 CMR 不会重启。

在将一组设备升级到固定版本之前，请先升级该组中的一台设备。如果目录中缺少某个软件包，任务会让设备保持 pending 状态，并显示错误 no upgrade available，不会重启设备。

警告

设置为通道的版本即使早于已安装版本也会被安装，因此固定通道可能会降级设备。

任务状态与结果

任务列在 /cmr/upgrade/job 菜单中，表示一次升级运行。任务会经历 scheduled、queued、waiting devices、version check、processing 等状态，最后变为 done 或 cancelled。success 计数器为 upgraded/total，例如 6/7。

由 /cmr/device/upgrade 为按编号选择的设备启动的任务没有 labels，并且只有在指定版本时才显示 channel。其设备通过 /cmr/upgrade/job/show-devices 列出。

说明

success 计数器只统计任务实际升级的设备。当规则覆盖的设备已经处于目标版本（保持 pending 并带有备注 no upgrade available）或被禁用时，任务不会升级该设备。目前，当固定版本的软件包既不在 packages-directory 中也不在更新服务器上时，设备也会保持 pending 并显示错误 no upgrade available。当服务器升级自身时，其任务会以 0/1 结束为 done，并且即使升级成功，show-devices 也会让服务器保持 rebooting 状态：服务器在记录结果之前会重启。请在 /system/resource 中或通过 /cmr/device 中服务器自身条目的 version 检查已安装版本。目前，此类任务的 start-time 以 UTC 显示。

可以移除任务以取消它。使用 /cmr/upgrade/job/remove 移除任务。移除已计划或已排队的任务会将其标记为 cancelled，任务仍会保留在列表中。移除正在处理的任务会停止运行，并将剩余设备标记为 cancelled。被中断的安装仍可能在设备重启后完成。移除 cancelled 任务会将其从列表中删除。

策略与失败处理

strategy 控制覆盖设备的升级方式。可选的 order 将覆盖设备拆分为标签组，并定义各组的处理顺序。

Parallel - 同时升级所有覆盖的设备。与 order 结合时，一个标签组内的设备一起升级，各组按 order 给定的顺序依次处理。
Sequential - 逐台升级设备，并等待每台完成。与 order 结合时，order 中的各组依次处理，组内设备逐台升级。

fail-policy 控制设备失败时的行为：

continue - 跳过失败的设备，继续处理其余设备。
stop - 首次失败时停止整个升级。任务不会继续处理剩余设备，也不会继续处理 order 中的下一个标签组。这是默认值。
continue-order - 跳过失败的设备，继续处理 order 中的下一个标签组。需要 order，其中列出要逐组处理的标签。没有 order 时不接受 continue-order。失败设备所在组的处理方式取决于 strategy：
- sequential - 跳过该组剩余设备（尚未开始的设备保持 pending），任务继续处理 order 中的下一个组。
- parallel - 只放弃失败的设备。同一组中已在进行中的设备会完成，任务继续处理 order 中的下一个组。

按网络顺序升级

设备在升级过程中会重启。重启期间，通过该设备连接到服务器的设备也会失去与服务器的连接。如果交换机或网关在其后面的设备之前升级，那些设备会在任务进行中断开连接。服务器不会根据网络拓扑推导顺序：order 定义顺序。

请根据设备在网络中的位置分配标签，并在 order 中按从网络边缘到服务器的顺序列出标签。例如，接入点标记为 ap，它们连接的交换机标记为 switch，网关标记为 gw：

[admin@MikroTik] > /cmr/upgrade/add name=fleet labels=ap,switch,gw order=ap,switch,gw channel=stable strategy=sequential fail-policy=stop

order=ap,switch,gw 先升级接入点，然后升级交换机，最后升级网关。
strategy=sequential 一次升级一台设备，因此一次只有网络的一部分会重启。
fail-policy=stop 在设备失败时停止任务，此时其连接的设备尚未升级。

机群任务完成后，再使用单独的规则或 /cmr/device/upgrade 升级 CMR 服务器自身。

备注

移除升级规则不会取消其已启动或已排队的任务。请使用 /cmr/upgrade/job/remove 显式取消任务。
/cmr/upgrade/show-devices 和 /cmr/upgrade/job/show-devices 都会列出规则或任务的逐设备覆盖情况和状态。它们会显示逐设备备注，例如前几节所述的 "upgrade available" 和 "no upgrade available" 状态。
服务器会将每次设备升级的结果以 cmr 主题写入日志，例如 <device> has successfully upgraded to version <version> 或 <device> failed to upgrade from <version> to <version>, error: <reason>。当设备的升级通道为其提供新版本时，服务器会记录 <device> has new version available <version>。

告警规则

告警规则定义条件（何时触发）和操作（做什么）：写入日志消息、运行 RouterOS 脚本、发送 HTTP 请求，或组合这些操作。规则通过 labels 选择设备，并在 CMR 服务器上执行操作。请在 /cmr/alert 菜单中管理规则。

配置的条件决定规则是状态告警还是事件告警。状态告警在条件满足期间保持活动。事件告警会针对每个匹配的发生执行操作，且从不会保持活动状态。

行为	状态告警	事件告警
表示	持续存在的条件，例如 CPU 使用率过高。	已经发生的事情，例如匹配的日志消息。
评估时机	新设备数据到达或计时器运行时。	事件发生时。
操作运行	告警变为活动时运行一次；仅在告警清除并再次变为活动后才再次运行。	每个匹配的发生立即运行。
活动告警与仪表板计数	活动期间保持可见并计入。	不会显示为活动告警，也不会增加活动告警计数。
每条规则的条件	多个状态条件，以逻辑 AND 组合。	最多一个事件条件。

创建告警规则

规则至少需要一个条件和一个操作。例如，创建一个状态告警，在任意设备的 CPU 负载超过 95% 时记录警告：

[admin@MikroTik] > /cmr/alert/add name=cpu-load labels=all cpu-above=95 action.log="[device] CPU usage is above 95% ([cpu-usage]%)" action.log-topics=cmr,warning severity=high category=performance
[admin@MikroTik] > /cmr/alert/print where name=cpu-load
11  ;;; example
    name="cpu-load" labels=all cpu-above=95
    action.log="[device] CPU usage is above 95% ([cpu-usage]%)"
    .log-topics=cmr,warning severity=high category=performance devices=9
    devices-on=0 fired=0 action-failures=0

devices 值统计规则标签选中的设备数量。devices-on 值统计存在活动状态告警的设备数量，fired 统计规则已触发的次数。此示例会在设备开始匹配 CPU 条件时记录一次日志。条件持续期间，设备仍会计入 devices-on，但不会重复记录日志消息。

条件

规则通过 labels 选择其适用的设备，这些标签与 CMR 中各处使用的标签相同。/cmr/alert CLI 参考列出了每个条件和参数。

状态告警

状态条件描述持续为真或为假的状态。当新的设备数据到达时（例如仪表板统计或健康读数），或计时器运行时，CMR 会重新评估这些条件。一条规则中可以组合多个状态条件：只有当所有条件都匹配（逻辑 AND）时，告警才处于活动状态。例如，hdd-above=80 hdd-below=95 匹配从 80% 到 95%（不含）的磁盘使用率。对于二选一的情况，请创建两条规则。

告警变为活动时，操作会运行一次。随后，告警会保持可见并在仪表板中计数，直到其条件不再匹配。只有在告警清除并再次变为活动后，操作才会再次运行。例如，CPU 规则的活动告警计数为五，表示有五台设备满足 CPU 条件，而不是发生了五次 CPU 事件。

状态条件包括：

使用率阈值 - cpu-above 和 cpu-below、mem-above 和 mem-below、hdd-above 和 hdd-below 将 CPU、RAM 或磁盘使用率与百分比进行比较。
健康传感器 - health-above 和 health-below 将健康传感器与某个值进行比较。health-value 指定传感器名称，并匹配 /system/health/print 中的名称（例如 cpu-temperature）。规则仅在报告该传感器的设备上比较传感器；没有该传感器的设备会被忽略。等于 above 条件阈值的值也会触发规则；below 条件仅在值严格低于阈值时触发。
可用性 - connected 匹配设备是已连接还是已断开。disconnected-more-than 匹配断开时间超过给定时间的设备。
可用升级 - upgrade-available 在有较新的 RouterOS 版本可用于设备时匹配。

事件告警

事件条件描述单次发生。规则会针对每个匹配事件立即执行操作。事件告警从不会保持活动状态，因此不会在仪表板中显示为活动告警，也不会增加 devices-on。一条规则最多只能包含一个事件条件。

例如，匹配的日志消息可以促使 CMR 写入日志条目、运行脚本或发送 HTTP 请求。该消息不会创建之后必须清除的持久告警状态。另一条匹配消息会再次运行操作。

事件条件包括：

接口 - interface-change 在接口变为 running 或 not-running，或者被 added 或 removed 时触发。可选择按 interface-type（ethernet、wifi 或 bridge）过滤。目前，禁用或启用由 CAPsMAN 管理的 WiFi 接口不会触发 interface-type=wifi 规则。
设备升级 - upgrade-done 在设备升级完成时触发。可以选择成功升级、失败升级或两者。
升级任务 - upgrade-job-done 在多设备升级任务整体完成时触发。可以选择成功任务、失败任务或两者。
意外重启 - rebooted 在设备意外重启时触发。
未配对连接 - unpaired-device-connected 在未配对设备连接时触发。
日志行 - log-topics 和 log-regex 定义一个日志消息事件条件，匹配配置的主题和消息正则表达式。CMR 会自动指示设备转发匹配的日志消息。匹配的值可通过 [message] 和 [message-topics] 使用。

设备与系统范围

告警范围与状态/事件区分是分开的：

设备告警按受管设备应用。大多数告警具有设备范围。每台设备独立跟踪状态告警，统计信息会区分规则选中了多少台设备以及多少台设备的告警处于活动状态。设备事件（例如 upgrade-done）会为触发它们的单台设备运行操作。
系统告警与 CMR 服务器相关，而不是与单台受管设备相关。例如，upgrade-job-done 是系统事件告警：它报告整个多设备升级任务的结果，没有单台设备的上下文。

操作

规则触发时，会运行所有已设置的操作：

action.log 连同可选的 action.log-prefix 和 action.log-topics 向 CMR 日志写入消息。默认主题为 cmr,info。对于日志行条件，消息以发送日志行的设备开头，格式为 identity|board|address:，因此仅使用 [message] 作为消息文本即可，例如 action.log="[message]"。
action.script 运行指定的系统脚本，action.script-vars 为其提供触发设备的值。脚本必须允许自身以降低的权限运行（dont-require-permissions=yes），否则操作会记录 "not enough permissions"。
action.http-url、action.http-method、action.http-body 和 action.http-headers 调用 HTTP 或 HTTPS webhook。请求体中的占位符会按设备替换。调用本身不会设置 Content-Type 头，因此当接收方需要时，请通过 action.http-headers 添加（例如为 JSON 请求体添加 Content-Type: application/json）。调用失败会以 warning 写入 cmr 主题，并计入 action-failures，例如 alert "name" HTTP action failed: request failed: Connection refused。当服务器的设备模式不允许 fetch 时，webhook 仍然可用。

操作文本中的变量

操作文本支持 [variable] 展开，例如 [identity]、[severity] 和 [alert-name]。占位符会替换为来自告警及其设备或事件上下文的值。当变量名列在 action.script-vars 中时（例如 action.script-vars="device,version" 会在脚本中设置 $device 和 $version），由 action.script 触发的脚本也可以使用相同的值。可用变量取决于触发告警的内容。

设备变量可用于每个设备告警，来自触发告警的设备：

占位符	值
`[device]`	设备标识和地址（`identity@address`）。地址未知时仅使用标识，例如对于控制器自身。
`[identity]`、`[address]`、`[board]`、`[version]`	设备标识、地址、板卡和 RouterOS 版本。
`[arch]`、`[serial]`	设备架构和序列号。
`[packages]`	已安装软件包的逗号分隔列表。
`[labels]`	用户标签和自动标签的逗号分隔列表。
`[state]`	设备状态，例如配对状态或升级状态。对于已配对且没有进行中操作的设备为空。
`[available-version]`	设备可用的较新 RouterOS 版本，或 `unknown`。
`[upgrade-state]`	当前升级进度或结果，或 `unknown`。
`[cpu-usage]`、`[mem-usage]`、`[hdd-usage]`	CPU、RAM 和磁盘使用率百分比；在设备连接后报告之前为 `unknown`。
`[<sensor>]`	规则指定的健康传感器的当前读数，例如 `[cpu-temperature]`。

事件变量在规则的事件条件匹配时可用：

占位符	值
`[iface-name]`、`[iface-type]`、`[iface-change]`	接口变更条件的接口名称、类型和变更（`running`、`not-running`、`added` 或 `removed`）。
`[upgrade-version]`、`[upgrade-error]`、`[upgrade-state]`	升级完成条件报告的版本、错误和最终状态。`[upgrade-error]` 是设备未升级的原因，例如 `no upgrade available`，成功升级后为空。`[upgrade-state]` 是设备在任务中的最终状态，例如 `done`，或者对于任务未升级的设备为 `pending`。
`[message]`、`[message-topics]`	日志行条件的匹配日志行的消息和主题。
`[job-device-count]`、`[job-success-count]`	升级任务完成事件的总设备数和成功升级设备数。
`[job-start-time]`、`[job-end-time]`、`[job-run-time]`	已完成任务的开始时间和结束时间，例如 `2026.10.06-14:20:36`，以及其持续时间（秒）。

说明

升级任务完成事件是没有设备上下文的系统事件，因此上表中的设备变量对它不可用。其他事件条件会为设备触发，设备变量可与事件变量一起使用。 告警变量可用于每个告警，无论由什么触发：

占位符	值
`[alert-name]`	配置的规则名称，或根据条件生成的名称。
`[severity]`、`[category]`	规则严重性和逗号分隔的类别。
`[alert-users]`	告警适用的设备数量。
`[alert-fired-count]`	告警已触发的次数。
`[action-fail-count]`	操作执行失败的次数。

不适用于某条规则的占位符会呈现为 unknown。值不可用的占位符会呈现为 (empty)，例如控制器自身的 [address]。

规则的触发方式

新建的状态告警会立即为每台已配对且已满足其条件的设备触发。当设备断开连接时，状态告警默认会为该设备保留状态；设置 reset-on-disconnect=yes 可在断开连接时清除状态，使设备在重新连接且仍然匹配后再次触发规则。状态告警仅针对已配对设备进行评估。事件告警没有可重置的持久状态，并会在每次匹配发生时触发，包括 unpaired-device-connected 的未配对连接。

当服务器上的 CMR 重启时（例如重启后或更改 packages-directory 后），它会再次评估状态告警：仍然匹配的告警会再次变为活动状态并运行其操作。更改已启用的规则（即使只更改其注释）也会对该规则产生相同效果：其状态告警会在匹配的设备上再次变为活动状态并运行其操作。

每条规则都有 severity（critical、high、medium 或 low，默认 medium）和 category，控制器会根据规则的条件分配类别（例如 performance、availability 或 version）；类别可以更改。只读值描述规则的状态：

devices - 规则标签选中的设备数量。
devices-on - 存在活动状态告警的设备数量。事件发生不会增加此计数。
fired - 规则触发的总次数，包括事件发生。
action-failures - 操作失败的次数。

测试与检查规则

test 立即运行规则的操作，并将占位符替换为 [placeholder] 值，以验证操作是否正常。目前，每次测试运行也会计入规则的 fired 值。
show-devices 列出规则的状态告警处于活动状态的设备。事件告警从不会保持活动状态，因此 show-devices 不会为其列出设备，其 fired 值改为统计发生次数。
由 action.log 写入的消息会以规则中设置的主题出现在路由器日志中，因此可以使用 /log/print where topics~"cmr" 读取它们。

/cmr/alert CLI 参考详细描述了每个参数和只读值。

网络拓扑

/cmr/layout 菜单存储网络拓扑。拓扑由节点和链路组成：node 将设备或另一个布局映射到某个位置，link 连接两个节点。可以使用 rebuild-links 从端口数据自动生成链路，也可以使用 add-devices 批量添加设备。拓扑本身仅在 GUI 中显示。

自动链路根据 track-topology 从客户端获取的数据构建，因此使用 rebuild-links 时请保持 track-topology=yes。rebuild-links 仅在直接连接的设备之间创建链路。请将自己的其他连接添加为链路，例如通过 VPN 或非 CMR 客户端的交换机建立的连接。自动链路会显示两台设备上连接的端口及其流量计数器和 PoE 状态。节点可以表示另一个布局（target-layout），因此概览布局可以显示并链接各自包含设备的站点或建筑布局。节点名称在所有布局中必须唯一。

例如，为一个站点创建布局，添加具有 office 标签的设备，并生成它们之间的链路：

[admin@MikroTik] > /cmr/layout/add name=Office
[admin@MikroTik] > /cmr/layout/add-devices [find name=Office] labels=office
[admin@MikroTik] > /cmr/layout/rebuild-links [find name=Office]

下方截图中的拓扑存储为一个布局，每台设备对应一个节点，已连接的设备之间有一条链路：

<center>![](https://manual.mikrotik.com/img/cmr_topology_example.webp)</center> <center>**该图显示 WebFig GUI 中的示例网络拓扑。**</center>

[admin@MikroTik] > /cmr/layout/print detail
 0  name="Example" scale=110 file="Floor_0.png"
 1  name="1_floor" file=""

[admin@MikroTik] > /cmr/layout/node/print detail
 0  name="RB5009UPr" layout=Example device=RB5009UPr x=300 y=25
 1  name="CRS354" layout=Example device=CRS354@192.168.255.2 x=308 y=99
 2  name="hAP" layout=Example device=hAP@192.168.1.96 x=285 y=-113
 3  name="hAP-1" layout=Example device=hAP@192.168.2.92 x=636 y=-104
 4  name="cAP ac 1" layout=Example device=cAP ac 1@192.168.2.91 x=628 y=227
 5  name="To_Floor_1" layout=Example target-layout=1_floor x=295 y=159

[admin@MikroTik] > /cmr/layout/link/print
 #   LAYOUT   NODE1      NODE2
 0   Example  CRS354     RB5009UPr
 1   Example  RB5009UPr  hAP
 2   Example  CRS354     hAP-1
 3   Example  CRS354     cAP ac 1
 4   Example  CRS354     To_Floor_1

布局存储其名称、背景图片的 scale 以及 file 中的图片本身。节点在布局中放置一台设备（通过 device，例如 RB5009UPr 或 cAP ac 1@192.168.2.91），或放置另一个布局（通过 target-layout）；device 和 target-layout 互斥。上面的 To_Floor_1 节点会打开示例中的 1_floor 布局，因此概览布局可以显示并链接整个站点或建筑布局。

信息

在 GUI 中，右键单击拓扑图中的空白位置可创建节点：

通过选择一台设备创建设备节点，以及

通过选择另一个布局创建布局节点。

右键单击现有节点可创建到另一个节点的链路。也可以在 CLI 中使用 add、node 和 link 命令完成相同操作。链路连接布局中的两个节点。由 rebuild-links 创建的链路还会显示两台设备上连接的端口及其流量计数器和 PoE 状态：

[admin@MikroTik] > /cmr/layout/link/print detail where layout=Example
 0  layout=Example node1=CRS354 node2=RB5009UPr
     links=*ether47(poe=waiting-for-load,tx=520,rx=0)--*ether2(poe=waiting-for-
        load,tx=132.0KiB,rx=160.9KiB),ether49(,tx=913.0KiB,rx=30.8KiB)--
        ether1(poe=waiting-for-load,tx=350.7KiB,rx=67.5KiB)
 1  layout=Example node1=RB5009UPr node2=hAP
     links=*ether6(poe=powered-on,tx=0,rx=0)--*ether1(,tx=0,rx=0)

这里，CRS354 上的 ether2 连接到 RB5009UPr 上的 ether1，ether6 向 hAP 上的 ether1 提供 PoE 供电。端口名前的 * 表示两个端口之间的直接物理链路；poe=powered-on 和 poe=waiting-for-load 显示每一侧的 PoE 状态，tx/rx 显示流量计数器。仅连接两个布局的链路（例如 CRS354 与 To_Floor_1 之间的链路）不包含端口。

节点坐标相对于布局中心，因此 x=0, y=0 表示中心，允许使用负值。x 向右增大，y 向下增大，因此较小的 y 会将节点放在图中更高的位置：在上方截图中，y=-113 的节点靠近顶部，y=227 的节点位于底部。print 输出以带符号数字显示坐标，例如 y=-113。

应用流量

CMR 可以从选定设备收集应用流量统计。通过 /cmr 菜单中的 apptraffic-devices 设置按标签选择设备，默认选择具有 gateway 标签的设备；随后服务器会在选定设备上启用应用流量分类器（/tool/apptraffic）：

[admin@MikroTik] > /cmr set apptraffic-devices=gateway

分类器会看到设备路由的流量。如果接入点在网桥快速路径中桥接客户端流量，则它只能看到自己的流量，例如其 DNS 查询和管理会话。请选择路由网络流量的路由器（例如网关）来查看客户端的应用。

统计信息在 GUI 的 CMR > Traffic 下按应用或类别显示，包括最近一分钟、一小时、一天和一周的进出流量。目前，CLI 视图（/cmr/device/apptraffic 和 /tool/apptraffic/stats）仅列出检测到的应用和类别，不包含流量计数器。

分类器在采用 mmips、smips 和 powerpc 架构的设备上不可用。

WiFi 配置

/cmr/wifi 菜单定义机群的 WiFi 网络，/cmr/wifi/radio 菜单定义射频配置。项目会应用到与其 labels 匹配的设备，标签选择方式与升级规则和告警规则相同。参数延续 /interface/wifi 配置：网络项目包含连接性和 security 设置，射频项目包含 configuration 和 channel 设置。项目没有名称；labels 选择目标设备，numbers 选择要编辑的项目。

定义 WiFi 网络

为具有 Group2 标签的设备创建一个网络，广播 SSID Office，使用 WPA2 和 ccmp 加密进行认证，并将客户端流量标记为 VLAN 10：

[admin@MikroTik] > /cmr/wifi/add labels=Group2 ssid=Office vlan-id=10 security.authentication-types=wpa2-psk security.encryption=ccmp security.passphrase="office-passphrase" comment=office-wifi

网络会出现在列表中。组的设置使用点分名称。在 print 输出中，组名只写入一次，该组其余值以点开头写入：

[admin@MikroTik] > /cmr/wifi/print
0  ;;; office-wifi
   labels=Group2 ssid="Office" security.encryption=ccmp
   .authentication-types=wpa2-psk vlan-id=10

{/* 截图占位符 — 当 WinBox 截图可用时添加 ../img/cmr_wifi_network.webp：

<center>![](https://manual.mikrotik.com/img/cmr_wifi_network.webp)</center> <center>**该图显示在 WinBox GUI 中配置的 WiFi 网络。**</center>

*/}

网络参数与 /interface/wifi 网络对应：

labels - 应用该网络的设备。
ssid - 向客户端广播的网络名称。
mode - 运行模式：ap、station、station-bridge 或 station-pseudobridge。
vlan-id - 客户端流量标记的 VLAN。
security.authentication-types - 认证方法，例如 wpa2-psk、wpa3-psk 或 owe。
security.encryption - 允许的加密算法，例如 ccmp 或 gcmp。
security.passphrase - 个人认证类型的网络密码。密码短语是敏感值，不会出现在 print 输出中。REST API 会将其返回给具有 sensitive 权限的用户。

禁用网络可停止应用它而不删除它。禁用的网络会标记为 X 标志：

[admin@MikroTik] > /cmr/wifi/set 0 disabled=yes
[admin@MikroTik] > /cmr/wifi/print
Flags: X - DISABLED
 0  X ;;; office-wifi
      labels=Group2 ssid="Office" security.encryption=ccmp
      .authentication-types=wpa2-psk vlan-id=10

配置射频

/cmr/wifi/radio 菜单设置选定设备的射频参数。射频项目会应用到其选中设备的每个射频，因此请使用频段标签将信道设置限制在一个频段，例如 +5ghz。没有频段标签时，5 GHz 频率也会应用到 2.4 GHz 射频，后者会因 "no available channels" 而保持非活动状态。为具有 Group2 标签的设备的 5 GHz 射频设置监管域、射频链和信道：

[admin@MikroTik] > /cmr/wifi/radio/add labels=Group2,+5ghz configuration.country=Latvia configuration.chains=0,1 channel.band=5ghz-ax channel.frequency=5180 channel.width=20mhz comment=office-radio

[admin@MikroTik] > /cmr/wifi/radio/print
0  ;;; office-radio
   labels=Group2,+5ghz configuration.country=Latvia .chains=0,1
   channel.frequency=5180 .band=5ghz-ax .width=20mhz

configuration 和 channel 组与 /interface/wifi 的射频参数对应：configuration.country 设置监管域，configuration.chains 设置射频链，channel.band、channel.frequency 和 channel.width 设置信道选择。

/cmr/wifi 和 /cmr/wifi/radio CLI 参考列出了两个菜单的每个参数。

配置的应用方式

在每台选定设备上，WiFi 网络会作为托管条目（标志 Y）写入设备的 /interface/wifi/network 菜单，射频项目会作为托管条目写入 /interface/wifi/network/radio。托管条目会应用到项目选中的射频：

没有频段标签时，网络或射频项目会应用到选定设备的每个射频。添加频段标签可选择某个频段的射频：+2ghz、+5ghz 或 +6ghz。例如，labels=Group2,+5ghz 仅选择具有 Group2 标签的设备的 5 GHz 射频。
CMR 网络会接管其选中的射频，并替换其现有配置，包括由 CAPsMAN 管理的射频和具有本地配置的射频。没有 CMR 网络选择的射频会保留其配置，因此接入点的 2.4 GHz 射频可以继续由 CAPsMAN 管理，而其 5 GHz 射频由 CMR 配置。
射频项目仅应用到 CMR 网络也选中的射频。
在具有 WiFi 7 射频的设备上，设备会为 CMR 网络创建 MLD 接口。
托管条目无法在设备上更改。请在 CMR 服务器上更改它们。

警告

目前，移除或禁用 CMR WiFi 网络，或在设备上禁用 CMR 客户端，不会恢复射频之前的配置。射频会回退到与其匹配的本地 /interface/wifi/network 条目，当没有匹配条目时会保持禁用状态。必须在设备上重新设置其之前的 CAPsMAN 或每接口配置，因此请在将 CMR 网络应用到接入点之前导出其 WiFi 配置。

网桥与 VLAN

目前，CMR WiFi 网络无法选择网桥，因为 /cmr/wifi 没有 datapath 设置。网桥取决于网络的 vlan-id：

指定 vlan-id 时，WiFi 接口会加入托管的 cmr-bridge（与 VLAN 配置创建的网桥相同），并启用 VLAN 过滤，vlan-id 作为其 PVID。
未指定 vlan-id 时，WiFi 接口不会加入任何网桥，客户端没有网络访问权限。目前，请为每个 CMR WiFi 网络设置 vlan-id。

在设备的某个端口加入 cmr-bridge 之前，它不会连接到网络的其余部分。请使用 VLAN 配置规则将接入点的上行端口加入 cmr-bridge，使上行链路承载该网络的 VLAN。例如，对于具有 office-ap 标签的接入点上 VLAN 10 的办公网络，ether1 作为上行链路：

[admin@MikroTik] > /cmr/wifi/add labels=office-ap ssid=Office vlan-id=10 security.authentication-types=wpa2-psk,wpa3-psk security.passphrase="office-passphrase"
[admin@MikroTik] > /cmr/vlan/add labels=office-ap port-labels=ether1 vlan-ids=10 role=trunk comment=ap-uplink

上行链路另一端的交换机端口和路由器必须承载带标记的 VLAN 10。路由器提供网络的 IP 地址、DHCP 和防火墙规则；CMR 不配置这些内容。

警告

当接入点的上行链路加入 cmr-bridge 时，它会离开接入点之前的网桥，通过该网桥的管理访问会停止。trunk 端口还只接受带 VLAN 标记的帧，因此上行链路上的无标记流量会被丢弃。在将接入点的上行链路加入 cmr-bridge 之前，请规划好接入点的管理访问。

VLAN 配置

/cmr/vlan 菜单在选定的 CMR 客户端上创建网桥和 VLAN 配置。规则通过 labels 选择设备，通过 port-labels 选择端口（设备接口名称，例如 ether1，或在 /cmr/device 中分配给端口的端口标签，例如 uplink），定义 vlan-ids（逗号分隔的列表或范围，例如 10,20 或 10-20），并为每个端口分配 role：access（默认）或 trunk。

在选定设备上，规则会创建一个专用 cmr-bridge 网桥（启用 VLAN 过滤），并将选定端口移入其中：

access 端口属于单个 VLAN，即 vlan-ids 中的第一个 VLAN，并设置为该端口的 PVID。它承载无标记帧。在客户端上，当端口有链路时，该 VLAN 会作为动态无标记条目出现在网桥的 VLAN 表中。
trunk 端口承载 vlan-ids 中的每个 VLAN，使用 802.1Q 头标记，并且只接受带 VLAN 标记的帧。

一条规则可以选择多个端口；每个选定端口都以相同方式配置。trunk 端口只接受带 VLAN 标记的帧，即使 vlan-ids 中包含 VLAN 1 也是如此，因此一个端口不能同时承载无标记 VLAN 和带标记 VLAN。目前，当多条规则选择同一端口时，第一条规则生效，其他规则会被忽略且不会发出警告。

例如，为具有 office 标签的设备提供一个 VLAN 10 的 access 端口和一个承载 VLAN 10 和 20 的上行链路：

[admin@MikroTik] > /cmr/vlan/add labels=office port-labels=ether5 vlan-ids=10 role=access comment=office-access
[admin@MikroTik] > /cmr/vlan/add labels=office port-labels=ether6 vlan-ids=10,20 role=trunk comment=office-uplink

[admin@MikroTik] > /cmr/vlan/print
0  ;;; office-access
   labels=office port-labels=ether5 vlan-ids=10 role=access

1  ;;; office-uplink
   labels=office port-labels=ether6 vlan-ids=10,20 role=trunk

移除或禁用规则会撤销其配置：选定端口会恢复为之前的网桥和端口配置，当最后一条使用 cmr-bridge 的规则被移除时，cmr-bridge 会被删除。

警告

配置会将选定端口移入托管的 cmr-bridge，这会断开端口当前的流量；如果选择了管理端口或上行端口，可能会切断设备的管理访问。没有 labels 和 port-labels 的规则会应用到所有已连接设备及其所有端口，包括 CMR 控制器自身；应用此类规则会断开整个机群和控制器自身的管理访问。请保持设备和端口选择器明确。禁用或移除规则会恢复之前的配置，前提是仍可从控制器访问该设备；如果规则还配置了设备自身的上行链路（例如没有选择器的规则），则可能切断该链路，此时 cmr-bridge 会一直保留，直到重新建立与设备的 CMR 连接（例如重新启用 CMR 客户端）。