CMR: il Dude e il CAPsMAN si fondono in un controller di flotta dentro RouterOS

Da RouterOS 7.26 c’è un gestore di flotta nativo: inventario, script di massa, upgrade orchestrati e allarmi, con un server dentro un router e gli altri come client. L’abbiamo acceso su una flotta vera — CHR più un apparato reale con WiFi — e guardato a pacchetto cosa fa davvero, dove arriva e cosa firmi in cambio.

Cos’è, in una riga

CMR (Centralized Management and Repository) è il primo controller di flotta nativo di RouterOS. Se conosci i due strumenti storici di MikroTik, è facile inquadrarlo: prende il lato monitoraggio del Dude (scoperta, inventario, allarmi) e il lato provisioning centralizzato del CAPsMAN (ma esteso oltre il WiFi: VLAN, script, aggiornamenti), e aggiunge il pezzo che a entrambi mancava: eseguire comandi e upgrade su tutta la flotta in un colpo. Tutto dentro RouterOS, senza app né server esterni.

Attenzione a una cosa, perché è una delle critiche storiche a MikroTik: il CAPsMAN non era un controller vero ma un provisioner (sparava la config e ciao). CMR fa il salto sul management — inventario vivo, script, upgrade, allarmi — ma, come vedremo, sul lato radio è ancora un provisioner, non un controller RRM (Radio Resource Management: auto-canale, auto-potenza, steering — il WiFi che si auto-sintonizza) che ottimizza canali e potenze da solo. Teniamolo a mente.

L’architettura: un server, tanti client

Un apparato fa da server: gli si installa il pacchetto extra cmr. Tutti gli altri RouterOS dalla 7.26 in su fanno da client senza pacchetto aggiuntivo — il lato client è già nel sistema base. I client si collegano al server su TCP 54321, sempre in uscita (comodo dietro NAT).

Quali apparati possono fare cosa

Restano fuori le piattaforme più piccole/vecchie (smips, PowerPC): né server né client. Il client arriva anche su mmips; il server no, vuole arm/arm64/x86.

Che server mettere, per andare bene

Il server tiene l’inventario di tutta la flotta, cifra una sessione TLS per ogni client, raccoglie gli output degli script e — quando aggiorni — fa anche da cache dei pacchetti (vedi oltre). Più client e più funzioni usi, più CPU/RAM/disco vuole. In pratica:

• CPU: conta il single-thread. Per flotte serie prendi un apparato x86 (un CHR su mini-PC/VM, o un router x86) o un arm64 di fascia alta, non un arm entry-level.
• RAM: l’inventario e le sessioni crescono coi client — stai largo (≥1–2 GB sul server per flotte grandi).
• Disco: la cache dei pacchetti di upgrade occupa spazio (un set .npk per architettura) → serve storage, non la sola NAND da pochi MB.

Un CHR su una VM con qualche core e un paio di GB è il server “da laboratorio/produzione piccola” ideale: x86, risorse elastiche, niente radio da sprecare.

Come si trovano server e client (tre vie, provate a pacchetto)

Qui c’è una sorpresa gradita e un paio di miti da sfatare. Un client arriva al controller in questi modi:

E lo si legge a pacchetto. Ecco l’annuncio del controller catturato sul segmento (MNDP, UDP 5678 broadcast), decodificato campo per campo:

IP 10.0.0.1.5678 > 255.255.255.255.5678   UDP len 153    # broadcast, in chiaro

TLV  1  MAC ............. AA:BB:CC:00:11:01
TLV  5  identity ........ cmr-srv
TLV  7  version ......... 7.26beta1 2026-10-01 13:29:47
TLV  8  platform ........ MikroTik
TLV 11  software-id ..... glwRS+Ru+AG
TLV 12  board ........... (apparato)
TLV 16  interface ....... ether1
TLV 17  IPv4 ............ 10.0.0.1
TLV 15  IPv6 ............ fe80::...
TLV 18  (NUOVO 7.26) .... 0x02   <── marcatore CMR
TLV 19  (NUOVO 7.26) .... 0x79   <── marcatore CMR

I campi da 1 a 17 sono il solito MNDP (identità, versione, scheda, indirizzi). I due TLV nuovi della 7.26 — tipo 18 e 19 (i byte grezzi 0x02 e 0x79) — nell’MNDP classico non esistono: sono il cartello «qui c’è un controller CMR», ciò che permette al client di riconoscere il server sul segmento e auto-adottarsi. A conti fatti, nel pacchetto sono l’unica cosa che sembra segnalare in automatico «io sono un controller» al client. E tutto — identità e indirizzo del controller compresi — viaggia in chiaro: lo vede chiunque annusi la LAN (il canale di controllo sulla 54321 resta invece TLS).

/cmr/client set controller-addresses=cmr.tuodominio.tld
/cmr/client set controller-addresses=10.0.0.1,10.0.0.2   # lista

E RoMON? Verrebbe da pensarci — è l’overlay di management di MikroTik che attraversa i segmenti L2 dove l’MNDP si ferma. Ma no: il controllo CMR è IP/TLS e vuole raggiungibilità IP (routing/VPN), RoMON non lo trasporta. Il dettaglio in fondo, nelle FAQ.

Nota fiduciosa: che manchi la discovery via DHCP (lo “option 43/138” stile UniFi/Omada) è un vuoto di gioventù — la richiesta è già nei pacchetti del client. Confidiamo che MikroTik la attivi: sarebbe il tassello per i rami remoti.

Il pairing: il device arriva, tu lo approvi

Un client che si presenta non è automaticamente gestito: il server lo vede «in attesa di pairing» — esattamente il modello “pending → approve” dei controller commerciali. Tre modalità:

• none — approvazione automatica. Comoda in LAN fidata, ma vuol dire «chi si connette viene adottato»: da evitare su reti esposte.
• password — segreto condiviso: il device prova di essere lui.
• confirm — serve un’azione sul device: approvazione a due mani (il più sicuro).

Il legame è crittografico e per-identità: ogni nodo ha un suo local-id, e il client memorizza l’identità del controller a cui si è pairato. Conseguenza utile: un controller-canaglia con identità diversa non dirotta un client già adottato.

Controller o provisioner? La domanda che tutti fanno sul WiFi

È la verifica che interessa a chi viene da UniFi/Omada/Cambium. Abbiamo agganciato alla flotta un apparato reale con due radio e guardato cosa espone davvero il provisioning WiFi del CMR. La regola di provisioning, per intero:

/cmr/wifi/print
labels=ap   ssid=DojoWiFi   security.passphrase=***   security.authentication-types=wpa2-psk

La regola di base porta SSID + sicurezza + label. Si può provisionare anche un canale fisso (c’è una scheda Radio Configuration), e la Dashboard mostra perfino l’occupazione per frequenza — quanti AP su ciascun canale, a 2/5/6 GHz. Quindi i dati radio ci sono e sono persino visualizzati.

Quello che manca è l’azione. CMR mostra lo spettro e ti lascia fissare un canale, ma non c’è il controller “vivo” che ascolta le interferenze e sposta il canale, abbassa la potenza, fa band-steering coordinato tra AP da solo. In una parola: provisioning e monitoraggio sì, RRM no. L’auto-canale esiste a livello RouterOS, ma è una scelta una-tantum all’avvio, non un’ottimizzazione continua di flotta. L’hardware saprebbe farlo (le radio dichiarano scansione spettrale e cambio-canale al volo): manca l’orchestrazione che le guidi.

Nota fiduciosa: è beta. Il salto sul management c’è; l’RRM radio no. Confidiamo che MikroTik aggiunga l’ottimizzazione vera. E intanto — visto che i dati (scan, monitor) e il canale di comando (run-script) ci sono già — quel pezzo si può costruire sopra CMR: ne parliamo nel seguito.

Cosa ci fai davvero

Non è solo CLI: in WinBox/Webfig c’è un menu CMR dedicato con Dashboard (device online/pairati, risorse, spettro WiFi), Devices (l’inventario con i tool Pair/Script/Upgrade/Reboot), Alerts, Ports (Tx/Rx e PoE porta per porta di tutta la flotta), Topology, Traffic, VLAN Rules e WiFi. Sotto, però, tutto è anche API/REST — ed è lì che si vede cosa fa davvero.

Raggruppi per etichette

Ogni operazione seleziona i device per label, con una piccola algebra: OR (office,lab), AND (office,+ap), esclusione (office,-ap), jolly (all, all,-core).

Lanci uno script su tutto il gruppo, e ti torna l’output

È la funzione-principe. Un comando, N device, output raccolto per ciascuno:

/cmr/device/run-script labels=office \
  script=":put ([/system/identity/get name].\" up \".[/system/resource/get uptime])"

device=cmr-c2@...  status=success  output=cmr-c2 up 02h09m
device=cmr-c3@...  status=success  output=cmr-c3 up 02h09m

run-script … script="/user/set [find name=admin] password=…"
  device=cmr-c2@…   status=failed
  output=not enough permissions (9) (/user/set; line 1)

run-script … script="/tool/sniffer/start"
  device=cmr-c2@…   status=failed
  output=not enough permissions (9) (/tool/sniffer/start; line 1)

Allarmi — con log e webhook HTTP nativo

CMR arriva con allarmi di default (CPU>95%, memoria>80%, device disconnesso, aggiornamento disponibile, device non pairato che si connette, device riavviato) e ne aggiungi di tuoi. Le azioni provate sul ferro:

• Log sul controller: action.log="…" + action.log-topics=… (con placeholder [device], [cpu-usage]…).
• Webhook HTTP — nativo: action.http-url=… + action.http-method=(get/post/put/…) + action.http-body=…. Quando l’allarme scatta, CMR chiama l’URL.

Non ci sono azioni “email” o “telegram” dirette — ma non servono: il webhook le copre tutte. Un POST al webhook di Telegram/Slack/Discord, o a un tuo n8n/Node-RED, e l’allarme arriva dove vuoi. L’abbiamo fatto scattare: un device non-pairato che si connette → riga in log device NON pairato connesso; è di fatto un «qualcuno ha attaccato un apparato non gestito alla mia flotta».

Upgrade orchestrati, e la “R” di Repository

Regole di aggiornamento per gruppo, con finestra oraria e canale (stable, long-term, testing, development): c’è già una regola default su stable. E qui si capisce la R di CMR: il server fa da repository dei pacchetti — scarica i .npk dal canale scelto, li cachea (cartella cmrpkgs, con tetto configurabile) e li distribuisce ai client. Una scaricata, tanti apparati: perfetto per una flotta dietro un’unica uscita. Nota: cachea tutti i pacchetti che un device ha (routeros + gli extra come container, wireless…), per architettura — ecco perché l’upgrade è “di tutto il device”. Non si fissa una versione precisa, si segue il canale.

La “R” è solo la cache dei pacchetti: non è un repository di log né di backup (vedi FAQ).

Costruisci la tua interfaccia: API, REST, scripting, webhook

Il bello di CMR è che non ti chiude: tutti i suoi dati sono accessibili e componibili. Provato sul ferro — la REST API serve l’inventario in JSON:

GET /rest/cmr/device   →  [ {".id":"*3","identity":"cmr-c2","board":"CHR",
                              "version":"7.26beta1","connected":"true", … }, … ]
GET /rest/cmr/alert    →  [ … le tue alert in JSON … ]

Tre superfici per leggere/scrivere — API binaria, REST (JSON su HTTP/S), scripting on-box — più il webhook per spingere eventi fuori. Con questi mattoni ti fai la dashboard che vuoi, colleghi CMR al monitoraggio che già hai (Grafana/Zabbix leggono la REST), o automatizzi reazioni. Il controller nativo ti dà i dati; l’interfaccia la decidi tu.

Sicurezza (provata a pacchetto)

In più: porta fissa 54321 (non si cambia), fiducia legata all’identità del controller (il pairing), nessun cert-pinning configurabile (la fiducia è la chiave di pairing, stile TOFU all’adozione). Esposizioni da tenere a mente: (1) servizio TLS beta = superficie pre-auth non ancora battagliata; (2) adozione-canaglia se usi pairing=none su un server esposto; (3) la discovery in chiaro (metadati, non controllo). Regola: non esporre la 54321 nuda su Internet — meglio dietro VPN (i client puntano all’IP privato), o esposta solo con pairing=confirm + allow-list sugli IP sorgente. Nessuna VPN integrata nel CMR: il suo canale è un tunnel TLS di gestione, non una VPN dati.

La discovery si può falsificare — ma il default ti salva

L’MNDP non è autenticato, quindi i due byte-marcatore si possono forgiare. L’abbiamo provato: con un piccolo annunciatore MNDP su misura (marcatori CMR + un IP a scelta) un client vergine ha provato a collegarsi all’indirizzo annunciato — anche a un IP pubblico (un indirizzo di Cloudflare): sulla 54321 è partito il SYN verso quell’IP, con controller-addresses rimasto vuoto. Tradotto: chi è sullo stesso segmento L2 può spingere un client abilitato ma non ancora pairato verso un controller a sua scelta (potenziale adozione-canaglia, se quel controller accetta il pairing).

# annuncio MNDP forgiato (marcatori CMR + IP a scelta) → il client vergine tenta la 54321:
IP <client> > 10.11.12.13.54321: Flags [S]   # un IP privato a piacere
IP <client> > 1.1.1.1.54321:      Flags [S]   # …o persino un IP PUBBLICO
# controller-addresses del client: VUOTO  (l'indirizzo arriva solo dall'annuncio forgiato)

Due cose però ridimensionano il rischio — e sono anche il modo di proteggersi:

• Il client CMR è spento di fabbrica. Su un RouterOS 7.26 appena installato /cmr/client è enabled=no: un apparato che non ha mai toccato CMR non reagisce all’annuncio. Il rischio esiste solo se il client è stato acceso.
• Un device già pairato è legato all’identità del suo controller (local-id): un annuncio con identità diversa non lo dirotta.

Hardening (provato): se non usi CMR, tieni il client spento — /cmr/client set enabled=no (con il client disabilitato, zero tentativi anche sotto spoofing). Se lo usi, restringi la neighbor-discovery alle sole interfacce fidate e adotta i device con pairing=confirm, mai none.

Nota fiduciosa: la discovery non autenticata è un tratto di gioventù — confidiamo che MikroTik firmi/autentichi l’annuncio, così lo spoofing non morde più. È beta: ha tutto il tempo per sistemarlo.

Il rovescio: il raggio dell’esplosione

Tutta la comodità ha un prezzo: da un singolo nodo si colpisce l’intera flotta. labels=all è un grilletto:

/cmr/device/run-script labels=all  script=...   # gira su OGNI device
/cmr/device/upgrade    labels=all  ...           # aggiorna OGNI device
/cmr/device/reboot     labels=all                # riavvia OGNI device

Un errore di battitura o un server compromesso si propagano all’istante. La gabbia dei permessi evita il disastro “utenti/policy”, ma scrivere config + riavviare + schedulare upgrade su tutto basta a mettere giù una rete da un punto solo. Proteggi la 54321; non usare pairing=none dove chiunque può presentarsi.

«Ma se il router è già configurato?»

Domanda giusta, risposta provata. Su un client con config vera (bridge mybr, VLAN, indirizzo) l’abbiamo pairato, gestito e persino puntato con una regola CMR. Esito:

bridge mybr    → intatto   (comment="config-utente", dynamic=false)
vlan   v100    → intatta
indirizzo      → intatto
oggetti aggiunti da CMR al device: 0

Bridge, VLAN e indirizzo intatti, zero oggetti aggiunti d’ufficio. CMR non adotta e non riscrive la tua config — lavora con oggetti suoi. Un router già configurato è perfetto da gestire, monitorare, aggiornare. Il distinguo è solo sul provisioning (WiFi/VLAN): lì CMR crea i propri oggetti e non fonde i tuoi, quindi su apparati già pieni rischi doppioni. Per un provisioning pulito parti da config vicina al default. In nessun caso ti sovrascrive quello che c’è.

Nota fiduciosa: che il provisioning non adotti ancora la config esistente è un limite di gioventù — confidiamo maturi in fretta.

E se cade il controller?

Provato: con il server spento, i device continuano a funzionare — traffico, IP e config loro intatti; la config già provisionata resta. Perdi solo la regia centrale (inventario/script/alert/upgrade) finché non torna. E al ritorno i client si riconnettono da soli e restano pairati. CMR è un piano di gestione, non sta nel percorso dati: cade il controller, la rete non se ne accorge.

Ridondanza e gerarchia

HA master/slave con sincronizzazione? No, non in questa beta (redundancy non esiste; ogni server ha identità e DB di pairing propri). L’unico mattone di ridondanza: il client accetta più controller-addresses → puoi fare uno standby “a freddo” (pre-pairi i device anche a un secondo server e metti entrambi gli indirizzi). Non è failover automatico con stato condiviso.

Gerarchia di controller? Sì, come impilamento. Un nodo può essere server e client insieme: un gateway di ramo fa da server per i suoi AP locali (auto-adozione MNDP) e da client verso un CMR master. Ma il master vede quel ramo come un solo device, non i suoi AP: è una piramide di controller, non una vista unica della flotta. Per i rami remoti, inoltre, non c’è modalità relay/proxy: ogni AP deve raggiungere il CMR via IP (routing/VPN del gateway), con l’indirizzo impostato.

Nota fiduciosa: le primitive (nodo server+client, controller-addresses multipli) ci sono. Un HA vero e un relay di ramo sarebbero l’evoluzione naturale.

FAQ rapide (tutte verificate)