CMR در MikroTik چیست؟ آشنایی با مدیریت و مانیتورینگ متمرکز RouterOS

MikroTik در RouterOS 7.26 قابلیت جدیدی با نام CMR معرفی کرده است که می‌تواند نحوه مدیریت تعداد زیادی Router، Switch و Access Point مبتنی بر RouterOS را تغییر دهد.

تا پیش از این، مدیر شبکه برای مدیریت چندین تجهیز MikroTik معمولاً از ترکیبی از ابزارها استفاده می‌کرد:

  • WinBox برای Configuration هر دستگاه
  • CAPsMAN برای مدیریت Access Pointها
  • SNMP و ابزارهایی مانند Zabbix یا LibreNMS برای Monitoring
  • Script و Scheduler برای Automation
  • The Dude برای بعضی سناریوهای Monitoring و Topology
  • روش‌های دستی برای Upgrade گروهی RouterOS

CMR تلاش می‌کند بخشی از این نیازها را در یک پلتفرم مرکزی داخل اکوسیستم RouterOS جمع کند.

معماری کلی آن بسیار ساده است:

 CMR Server
 │
 ┌────────────────┼────────────────┐
 │ │ │
 Headquarters Branch 1 Branch 2
 RouterOS RouterOS RouterOS
 │ │ │
 Switches cAP / hAP Router
 APs Switches APs

یکی از دستگاه‌های RouterOS نقش CMR Server را برعهده می‌گیرد و تجهیزات دیگر به‌عنوان CMR Client به آن متصل می‌شوند.

پس از Pair شدن تجهیزات، Administrator می‌تواند وضعیت کل Fleet را از یک نقطه مشاهده کرده، Alert دریافت کند، Upgrade انجام دهد، روی چند Device فرمان اجرا کند و در بعضی بخش‌ها مانند Wi-Fi و VLAN Configuration مرکزی ایجاد کند.

نکته مهم: CMR در RouterOS 7.26beta1 به‌عنوان نسخه اولیه یا Initial Implementation معرفی شده است. در زمان نگارش این مقاله هنوز این قابلیت در شاخه Development قرار دارد و MikroTik نیز اعلام کرده که بخش‌هایی از آن در حال تکمیل و تغییر هستند. برای استفاده در شبکه Production ابتدا آن را در Lab آزمایش کنید.

CMR در MikroTik چیست؟

CMR یک پلتفرم مدیریت و Monitoring مرکزی برای مجموعه‌ای از تجهیزات RouterOS است.

هدف آن این است که به‌جای ورود جداگانه به هر Router، Switch یا Access Point، بتوانیم بخش مهمی از عملیات مدیریت Fleet را از یک Controller انجام دهیم.

برای مثال تصور کنید یک مجموعه دارای:

1 × Headquarters

15 × Branch Offices

15 × Routers

25 × Switches

40 × Access Points

باشد.

در مدیریت سنتی، بررسی Version، CPU، RAM، Uptime، Upgrade و وضعیت هر دستگاه می‌تواند زمان زیادی بگیرد.

با CMR معماری به این شکل تغییر می‌کند:

 CMR
 │
 ┌────────────┼────────────┐
 │ │ │
 HQ Branch Branch
 │ 01 02
 │ │ │
 RouterOS RouterOS RouterOS
 Switch Switch Switch
 AP AP AP

CMR می‌تواند Inventory، Monitoring، Upgrade، Alert و بعضی Configurationهای مرکزی را برای این تجهیزات مدیریت کند.

CMR از چه نسخه‌ای به RouterOS اضافه شده است؟

اولین پیاده‌سازی CMR در:

RouterOS 7.26beta1

معرفی شده است.

در Changelog این نسخه MikroTik آن را یک:

Centralised platform for RouterOS devices

برای:

  • Updates
  • Monitoring
  • Alerts
  • و سایر قابلیت‌های مدیریتی

معرفی کرده است.

در زمان انتشار این مقاله RouterOS 7.26 هنوز Development/Beta است. بنابراین پیشنهاد نمی‌شود صرفاً برای استفاده از CMR تمام Routerهای یک شبکه Production را بدون Lab Test به این نسخه ارتقا دهید.

معماری CMR Server و CMR Client

CMR از معماری Controller/Client استفاده می‌کند.

CMR Server
 │
 ├── CMR Client 1
 ├── CMR Client 2
 ├── CMR Client 3
 ├── CMR Client 4
 └── CMR Client N

Server روی یک دستگاه RouterOS دارای Package مخصوص:

cmr

اجرا می‌شود.

Client اما بخشی از RouterOS اصلی است و نیاز به نصب Package جداگانه ندارد.

ارتباط Client و Server روی:

TCP 54321

انجام می‌شود.

Server لازم نیست Gateway شبکه باشد.

Clientها می‌توانند حتی از طریق:

  • Routed Network
  • Site-to-Site VPN
  • NAT
  • شبکه شعب

به CMR Server متصل شوند.

برای شبکه سازمانی چندشعبه‌ای طراحی منطقی می‌تواند چنین باشد:

 Data Center
 │
 CMR Server
 │
 WireGuard VPN
 ┌──────────┼──────────┐
 │ │ │
 Branch 1 Branch 2 Branch 3
 │ │ │
 RouterOS RouterOS RouterOS

از نظر امنیتی بهتر است TCP/54321 را مستقیماً برای تمام اینترنت باز نکنید. در شبکه‌های چندشعبه‌ای استفاده از Private Routing یا VPN میان CMR Server و Clientها انتخاب مناسب‌تری است.

چه تجهیزاتی از CMR پشتیبانی می‌کنند؟

برای CMR Server و Client محدودیت Architecture وجود دارد.

CMR Server

Package سرور CMR در نسخه فعلی فقط روی Architectureهای زیر پشتیبانی می‌شود:

  • ARM
  • ARM64
  • x86

CMR Client

Client در RouterOS اصلی قرار دارد، اما روی Architectureهای زیر پشتیبانی نمی‌شود:

  • mipsel
  • smips
  • powerpc

بنابراین قبل از طراحی CMR برای Fleet قدیمی MikroTik باید Architecture تمام تجهیزات بررسی شود.

برای مشاهده Architecture:

/system/resource/print

یا:

/system/routerboard/print

قابل استفاده است.

CMR چه قابلیت‌هایی دارد؟

CMR در نسخه اولیه مجموعه قابل توجهی از قابلیت‌ها را ارائه می‌کند.

قابلیتکاربرد
Device Inventoryمشاهده مدل، Version، Package، Identity و وضعیت تجهیزات
Fleet UpgradeUpgrade گروهی RouterOS براساس Rule و Schedule
AlertsAlert براساس CPU، RAM، Health، Interface، Log و Upgrade
Dashboardنمایش وضعیت کلی Fleet
Run Scriptاجرای Command روی چند Device
Topologyنمایش نقشه و لینک میان تجهیزات
Application Trafficمشاهده آمار Application Traffic
Wi-Fi Provisioningایجاد SSID، Security و Radio Policy مرکزی
VLAN Provisioningتنظیم Access و Trunk Port به‌صورت مرکزی

CMR چه کارهایی انجام نمی‌دهد؟

این بخش بسیار مهم است، زیرا CMR هنوز یک سیستم Full Configuration Management برای RouterOS نیست.

CMR در نسخه فعلی به‌صورت مرکزی این موارد را Configuration نمی‌کند:

  • IP Address
  • DHCP Server
  • Routing
  • Firewall
  • RouterOS Users
  • سایر Configurationهای عمومی Router

برای این تنظیمات همچنان باید از:

  • WinBox
  • WebFig
  • CLI
  • Automation/Script

استفاده کرد.

برای تغییر یک‌باره روی چند Device نیز می‌توان از قابلیت:

run-script

استفاده کرد.

بنابراین CMR فعلی را نباید مشابه یک Configuration Management Platform کامل در نظر گرفت.

راه‌اندازی CMR Server

روی Deviceای که قرار است Controller باشد ابتدا Package:

cmr

باید نصب شده باشد.

سپس Server را فعال می‌کنیم:

/cmr
set enabled=yes

بعد از فعال‌شدن CMR، خود Controller نیز در Device List نمایش داده می‌شود.

برای مشاهده Deviceها:

/cmr/device/print

Firewall CMR Server

CMR Client باید بتواند به Server روی:

TCP/54321

متصل شود.

مثلاً اگر شبکه مدیریت شعب:

10.100.0.0/16

باشد:

/ip/firewall/filter
add chain=input \
 src-address=10.100.0.0/16 \
 protocol=tcp \
 dst-port=54321 \
 action=accept \
 comment="Allow CMR clients"

این Rule باید براساس ساختار واقعی شبکه نوشته شود. بازکردن TCP/54321 برای تمام Internet صرفاً برای سهولت اتصال Clientها توصیه نمی‌شود.

فعال‌کردن CMR Client

روی RouterOS Device تحت مدیریت:

/cmr/client
set enabled=yes \
 controller-addresses=10.100.0.1 \
 pairing-requirement=password

controller-addresses الزاماً ضروری نیست؛ Client می‌تواند Server را با Mechanismهایی مانند Neighbor Discovery یا DHCP پیدا کند.

اما در شبکه‌های Routed، شعب یا VPN بهتر است Controller Address به‌صورت مشخص تنظیم شود.

ساختار:

Branch Router
 │
CMR Client
 │
 └──────── TCP/54321 ────────→ CMR Server

Pairing در CMR چگونه کار می‌کند؟

صرف اتصال Client به Server به معنی اجازه مدیریت آن نیست.

دو Device باید فرآیند:

Pairing

را تکمیل کنند.

CMR سه مدل اصلی روی Server دارد:

none

Device بدون Approval اضافه پذیرفته می‌شود.

password

برای تأیید Pairing از Username و Password یک User RouterOS استفاده می‌شود.

confirm

Administrator باید Pairing را روی CMR Server به‌صورت محلی تأیید کند.

Clientهای Pending در:

/cmr/device/print

با Flag:

P

مشخص می‌شوند.

سپس می‌توان Device را Pair کرد.

از نظر امنیتی در شبکه سازمانی استفاده از Approval یا Password نسبت به Auto Pairing عمومی گزینه محافظه‌کارانه‌تری است.

Labels؛ یکی از مهم‌ترین مفاهیم CMR

CMR برای انتخاب گروهی تجهیزات از Label استفاده می‌کند.

مثلاً:

branch
router
switch
access-point
tehran
warehouse
gateway

ممکن است به Deviceها اختصاص داده شوند.

مثلاً:

Branch-01
labels:
branch,router

Branch-02
labels:
branch,router

Warehouse-AP
labels:
warehouse,access-point

سپس می‌توان Upgrade، Alert یا Script را فقط روی:

labels=branch

اجرا کرد.

CMR علاوه بر Labelهای دستی، Auto Labelهایی مانند:

  • Architecture
  • Model
  • Board Name
  • Identity
  • Version
  • Address

نیز دریافت می‌کند.

AND و NOT در Label Selection

CMR قابلیت انتخاب پیشرفته نیز دارد.

labels=office,+ap

یعنی:

office
AND
ap

و:

labels=all,-core

یعنی:

تمام تجهیزات
به جز
core

این ساختار در شبکه‌های بزرگ بسیار کاربردی است.

Dashboard مرکزی CMR

یکی از جذاب‌ترین قابلیت‌های CMR، Dashboard مرکزی آن است.

Dashboard اطلاعاتی مانند:

  • تعداد Deviceهای Online
  • CPU Usage
  • Memory Usage
  • Disk Usage
  • Interface Status
  • Bandwidth
  • Active Alerts
  • Available Updates
  • Application Traffic
  • Access Pointها
  • Wi-Fi Clientها

را نمایش می‌دهد.

ساختار مدیریتی تقریباً:

 CMR Dashboard

 Devices CPU Memory Storage
 ● ● ● ●

 Bandwidth Alerts Updates
 ● ● ●

 Application Traffic
 ●

 Wi-Fi APs / Clients
 ●

است.

Dashboard هم از طریق CLI و هم GUI قابل مشاهده است.

برای رابط گرافیکی فعلی باید از:

  • WinBox 4
  • WebFig

استفاده شود.

WinBox 3 از منوهای CMR پشتیبانی نمی‌کند.

Fleet Upgrade؛ آپدیت مرکزی تعداد زیادی MikroTik

یکی از مهم‌ترین قابلیت‌های CMR برای شبکه‌های سازمانی، مدیریت Upgrade تجهیزات است.

به‌جای ورود به تک‌تک Routerها می‌توان Rule تعریف کرد:

Branch Routers
 ↓
Stable Channel
 ↓
Saturday 03:00
 ↓
Sequential Upgrade

برای مثال:

/cmr/upgrade/add \
 name=branch-weekly \
 labels=branch \
 channel=stable \
 schedule-time="03:00:00@sat" \
 strategy=sequential \
 fail-policy=continue

CMR می‌تواند Deviceها را:

  • Sequential
  • Parallel

Upgrade کند.

Sequential

Router 1
 ↓
Router 2
 ↓
Router 3
 ↓
Router 4

برای Infrastructure حساس انتخاب محافظه‌کارانه‌تری است.

Parallel

Router 1 ─┐
Router 2 ─┼→ Upgrade simultaneously
Router 3 ─┤
Router 4 ─┘

سریع‌تر است، ولی Failure هم‌زمان چند Device Risk بیشتری ایجاد می‌کند.

Failure Policy

CMR سه رفتار اصلی برای Failure دارد:

  • continue — Device خراب را رد کن و ادامه بده
  • stop — با اولین Failure کل Job را متوقف کن
  • continue-order — به Group بعدی برو

این قابلیت اجازه می‌دهد Deployment Strategy مانند:

Test Group
 ↓
Branch Group A
 ↓
Branch Group B
 ↓
Core Devices

طراحی شود.

Pin کردن RouterOS Version

علاوه بر Channelهایی مانند:

  • long-term
  • stable
  • testing
  • development

می‌توان Version مشخصی را تعیین کرد.

مثلاً:

channel=7.24.4

در CMR یک Version ثابت حتی اگر از Version فعلی دستگاه قدیمی‌تر باشد می‌تواند باعث Downgrade شود. بنابراین Pin کردن Version باید با دقت انجام شود.

Package Cache مرکزی

CMR Server می‌تواند Packageهای RouterOS را Download و Cache کرده و سپس به Clientها ارائه کند.

این قابلیت برای شبکه‌ای با:

50 Routers
+
20 Access Points
+
15 Switches

مفید است، زیرا لازم نیست هر Device مستقلاً Packageها را Download کند.

حتی می‌توان فایل‌های:

.npk

را در Directory محلی Server قرار داد و Version موردنظر را از همان منبع توزیع کرد.

Alert Management در CMR

CMR می‌تواند وضعیت تجهیزات را مانیتور کرده و براساس Condition مشخص Alert ایجاد کند.

برای مثال:

  • CPU بیش از 95٪
  • RAM بیش از مقدار تعیین‌شده
  • Storage پر شده
  • Temperature بالا
  • Device قطع شده
  • Interface Down شده
  • Upgrade آماده است
  • Router Restart غیرمنتظره داشته است
  • Log خاصی ایجاد شده است

مثلاً:

/cmr/alert/add \
 name=cpu-load \
 labels=all \
 cpu-above=95 \
 action.log="[device] CPU usage is above 95% ([cpu-usage]%)" \
 severity=high

اگر CPU یکی از Deviceها از 95٪ عبور کند، Alert فعال می‌شود.

State Alert و Event Alert

CMR میان دو نوع Alert تفاوت قائل می‌شود.

State Alert

برای یک وضعیت ادامه‌دار:

CPU > 90%

Temperature > 70°C

Device Offline > 5m

تا وقتی Condition برقرار است Alert نیز Active می‌ماند.

Event Alert

برای اتفاق مشخص:

Unexpected Reboot

Interface Down

Upgrade Completed

Specific Log Message

است.

ارسال Alert با Webhook

یکی از قابلیت‌های کاربردی CMR امکان اجرای HTTP/HTTPS Request هنگام Alert است.

در نتیجه می‌توان CMR را با سیستم‌های دیگر Integrate کرد:

CMR Alert
 ↓
Webhook
 ↓
Monitoring / Automation Platform
 ↓
Telegram / Ticket / Notification

CMR همچنین می‌تواند هنگام Alert:

  • Log بنویسد
  • RouterOS Script اجرا کند
  • HTTP/HTTPS Webhook فراخوانی کند

یا چند Action را هم‌زمان انجام دهد.

اجرای Command روی چند Router به‌صورت هم‌زمان

یکی دیگر از قابلیت‌های مهم CMR:

run-script

است.

برای مثال اگر بخواهیم Resource تمام Routerهای شعب را بررسی کنیم:

/cmr/device/run-script \
 labels=branch \
 script="/system/resource/print"

CMR Script را روی تمام Deviceهای Match شده اجرا کرده و Output هر Device را جداگانه نمایش می‌دهد.

این قابلیت برای عملیات‌هایی مانند:

  • Audit
  • جمع‌آوری اطلاعات
  • بررسی Configuration
  • تغییر یک‌باره تعداد زیادی Device
  • Troubleshooting

بسیار کاربردی است.

Scriptهای CMR با Permission محدود اجرا می‌شوند و بعضی عملیات نیازمند Policyهای بالاتر ممکن است Fail شوند؛ بنابراین run-script را معادل دسترسی نامحدود Administrator در نظر نگیرید.

Network Topology در CMR

CMR می‌تواند براساس اطلاعات Neighbor و Port یک Network Map ایجاد کند.

مثلاً:

 RB5009
 │
 CRS354
 ┌─────┼─────┐
 │ │ │
 cAP ax hAP Switch
 │
 Clients

Topology می‌تواند اطلاعاتی مانند:

  • Device
  • Connected Port
  • TX/RX Traffic
  • PoE Status

را نیز روی Linkها نمایش دهد.

برای ساخت Layout:

/cmr/layout/add name=Office

/cmr/layout/add-devices \
 [find name=Office] \
 labels=office

/cmr/layout/rebuild-links \
 [find name=Office]

خود نقشه به‌صورت گرافیکی در GUI نمایش داده می‌شود.

حتی می‌توان Layoutهای جدا برای:

  • ساختمان
  • طبقه
  • شعبه
  • Campus

ساخت و آن‌ها را به یک Layout بالادستی متصل کرد.

Application Traffic در CMR

CMR قابلیت مشاهده Application Traffic را نیز دارد.

برای مثال می‌توان Gatewayها را با Label:

gateway

مشخص کرد:

/cmr
set apptraffic-devices=gateway

سپس CMR Application Traffic Classifier را روی آن Routerها فعال می‌کند.

در GUI می‌توان Traffic را به تفکیک:

  • Application
  • Category
  • Upload
  • Download

در بازه‌های:

  • Minute
  • Hour
  • Day
  • Week

مشاهده کرد.

Application Traffic بهتر است روی Routerی مانیتور شود که Traffic کاربران را Route می‌کند. یک Access Point که Traffic را با Bridge Fast Path عبور می‌دهد الزاماً Applicationهای Clientها را نمی‌بیند.

Application Traffic Classifier نیز در نسخه فعلی روی معماری‌های:

  • mmips
  • mipsel
  • smips
  • powerpc

در دسترس نیست.

Wi-Fi Provisioning در CMR

CMR قابلیت تعریف Wi-Fi Network مرکزی نیز دارد.

برای مثال می‌توان یک SSID:

Office

را برای تمام APهای دارای Label مشخص ایجاد کرد:

/cmr/wifi/add \
 labels=office-ap \
 ssid=Office \
 vlan-id=10 \
 security.authentication-types=wpa2-psk,wpa3-psk \
 security.passphrase="StrongPassword"

همچنین Radio Parameters مانند:

  • Country
  • Frequency
  • Channel Width
  • Band
  • Chains
  • Tx Power

را می‌توان به‌صورت مرکزی تنظیم کرد.

Band Label در CMR Wi-Fi

CMR اجازه می‌دهد Configuration فقط روی یک Band اعمال شود.

مثلاً:

labels=office-ap,+5ghz

یعنی:

office-ap
AND
5 GHz Radio

این موضوع اهمیت زیادی دارد؛ زیرا اگر Frequency مختص 5GHz بدون Band Selector به تمام Radioها اعمال شود، Radio 2.4GHz نیز آن Configuration را دریافت کرده و ممکن است با خطای:

no available channels

غیرفعال بماند.

CMR جایگزین CAPsMAN است؟

در نسخه فعلی پاسخ دقیق این است:

نه به‌صورت کامل.

CMR می‌تواند Configuration شبکه Wi-Fi و Radio را روی Access Pointها بنویسد، اما معماری آن با CAPsMAN متفاوت است.

طبق مستند فعلی، CMR:

  • Configuration را مستقیماً روی AP می‌نویسد.
  • Central Authentication Server نیست.
  • Roaming میان APها را هماهنگ نمی‌کند.

همچنین اگر یک CMR Wi-Fi Network روی Radioای اعمال شود که قبلاً CAPsMAN آن را مدیریت می‌کرد، CMR می‌تواند کنترل آن Radio را در اختیار بگیرد.

قبل از اعمال CMR Wi-Fi روی AP موجود، Configuration Wireless آن را Export کنید. حذف CMR Network در نسخه فعلی الزاماً Configuration قبلی CAPsMAN یا Local Radio را به‌طور خودکار Restore نمی‌کند.

برای آشنایی با CAPsMAN جدید می‌توانید مقاله راه‌اندازی CAPsMAN در RouterOS 7 را مطالعه کنید.

Managed Object در CMR چیست؟

Configurationهایی که CMR روی Client ایجاد می‌کند با Flag:

Y

مشخص می‌شوند.

این Objectها:

  • توسط CMR مدیریت می‌شوند.
  • روی Client مستقیماً قابل ویرایش نیستند.
  • در صورت قطع ارتباط Server همچنان فعال می‌مانند.

بنابراین قطع موقت ارتباط با Controller باعث از بین رفتن فوری Configuration اعمال‌شده نمی‌شود.

VLAN Provisioning با CMR

CMR می‌تواند Portهای RouterOS Client را به‌صورت مرکزی به Access یا Trunk تبدیل کند.

مثلاً:

/cmr/vlan/add \
 labels=office \
 port-labels=ether5 \
 vlan-ids=10 \
 role=access \
 comment=office-access

و برای Trunk:

/cmr/vlan/add \
 labels=office \
 port-labels=ether6 \
 vlan-ids=10,20 \
 role=trunk \
 comment=office-uplink

CMR در Client یک Bridge مدیریت‌شده با نام:

cmr-bridge

ایجاد می‌کند و VLAN Filtering را روی آن فعال می‌کند.

Access Port

Client
 │
Untagged
 │
ether5
 │
VLAN 10

Trunk Port

VLAN 10 ─┐
VLAN 20 ─┼→ ether6 → Tagged Trunk
VLAN 30 ─┘

VLAN Provisioning یکی از بخش‌هایی است که در نسخه فعلی CMR باید با احتیاط بسیار زیاد استفاده شود. CMR Port انتخاب‌شده را از Bridge قبلی خارج و به cmr-bridge منتقل می‌کند. اگر Uplink یا Management Port اشتباه انتخاب شود، امکان قطع دسترسی مدیریتی Device وجود دارد.

خطر Rule بدون Selector

یکی از مهم‌ترین هشدارهای مستند رسمی MikroTik مربوط به VLAN Provisioning است.

اگر Rule بدون:

labels

و

port-labels

ایجاد شود، Rule می‌تواند روی تمام Deviceهای متصل و تمام Portهای آن‌ها، حتی خود CMR Controller، اعمال شود.

در بدترین حالت:

Bad VLAN Rule
 ↓
All Devices
 ↓
All Ports
 ↓
cmr-bridge
 ↓
Management Lost

بنابراین Selectorهای Device و Port باید همیشه صریح و محدود باشند.

CMR با The Dude چه تفاوتی دارد؟

CMR و Dude هدف کاملاً یکسانی ندارند.

قابلیتCMRDude
RouterOS Fleet Managementتمرکز اصلیمحدودتر
Fleet Upgradeداردتمرکز اصلی نیست
Alertدارددارد
Topologyدارددارد
Wi-Fi Provisioningداردخیر
VLAN Provisioningداردخیر

ضمن اینکه The Dude در مستندات جدید MikroTik در وضعیت Legacy قرار گرفته است، در حالی که CMR قابلیت جدید و در حال توسعه RouterOS محسوب می‌شود.

با این حال هنوز زود است که CMR را جایگزین مستقیم تمام قابلیت‌های Dude، Zabbix، LibreNMS یا سایر NMSها بدانیم.

CMR برای چه شبکه‌هایی جذاب است؟

شبکه چندشعبه‌ای

Head Office
 │
CMR Server
 │
VPN
 │
├── Branch 1
├── Branch 2
├── Branch 3
├── Branch 4
└── Branch N

می‌توان وضعیت Routerهای تمام شعب را از مرکز مشاهده کرد.

ISP یا Managed Service Provider

برای مجموعه‌ای از تجهیزات RouterOS امکان:

  • Inventory
  • Version Control
  • Upgrade
  • Alert
  • Remote Command

فراهم می‌شود.

مدارس و مراکز آموزشی

برای چند ساختمان یا Campus:

Core
 │
CMR
 │
├── Building A
├── Building B
├── Laboratory
├── Administration
└── Dormitory

CMR می‌تواند Monitoring و Management مرکزی تجهیزات MikroTik را ساده‌تر کند.

برای طراحی شبکه آموزشی مقاله راهکار جامع MikroTik برای مدارس نیز مرتبط است.

هتل، فروشگاه زنجیره‌ای و انبار

هر Site می‌تواند تجهیزات خودش را داشته باشد و CMR Server وضعیت همه را در مرکز نگهداری کند.

محدودیت‌ها و نکات مهم نسخه فعلی CMR

CMR قابلیت بسیار امیدوارکننده‌ای است، اما نسخه فعلی چند محدودیت جدی دارد.

هنوز Initial Implementation است

خود MikroTik این نسخه را Work in Progress معرفی کرده است.

RouterOS 7.26 هنوز Development است

بنابراین مهاجرت Fleet Production فقط برای CMR در این مرحله تصمیم محافظه‌کارانه‌ای نیست.

CMR Full Configuration Manager نیست

Firewall، Routing، DHCP، IP Address و User Management هنوز باید خارج از CMR مدیریت شوند.

روی Configuration سفارشی باید احتیاط کرد

مستند رسمی اعلام می‌کند CMR با Deviceهایی که Configuration پیش‌فرض یا نزدیک به Default دارند بهتر کار می‌کند.

شبکه‌ای با:

  • Bridgeهای پیچیده
  • VLANهای سفارشی
  • Wi-Fi Configuration قدیمی
  • CAPsMAN فعال
  • Management VLAN خاص

ممکن است قبل از Provisioning نیازمند تغییر دستی باشد.

Wi-Fi Configuration قبلی ممکن است Restore نشود

قبل از CMR Wi-Fi Provisioning حتماً Export تهیه کنید.

VLAN Provisioning می‌تواند Management را قطع کند

خصوصاً اگر Uplink وارد cmr-bridge شود و Management VLAN از قبل طراحی نشده باشد.

WinBox 3 پشتیبانی نمی‌شود

برای GUI باید از WinBox 4 یا WebFig استفاده شود.

آیا اکنون CMR را در Production استفاده کنیم؟

برای تاریخ فعلی، پیشنهاد منطقی این است:

Production Fleet
 │
 ✕
Immediate Migration


Lab
 ↓
CMR Server
 ↓
2–3 Test Devices
 ↓
Monitoring
 ↓
Upgrade Test
 ↓
Alert Test
 ↓
WiFi / VLAN Test
 ↓
Wait for maturity

CMR ارزش بررسی بسیار بالایی دارد، اما تا زمانی که نسخه Stable و تجربه عملی بیشتری منتشر نشده است، بهتر است ابتدا برای:

  • Lab
  • Test Routerها
  • محیط Pilot
  • شبکه غیرحساس

استفاده شود.

چک‌لیست آزمایش CMR

  1. RouterOS 7.26 یا نسخه پشتیبانی‌شده بررسی شده است.
  2. Development بودن Version در نظر گرفته شده است.
  3. Architecture سرور CMR پشتیبانی می‌شود.
  4. Architecture Clientها بررسی شده است.
  5. Package مربوط به CMR روی Server نصب شده است.
  6. TCP/54321 فقط از Networkهای موردنیاز مجاز است.
  7. CMR Server فعال شده است.
  8. Clientها فعال شده‌اند.
  9. Controller Address مشخص شده است.
  10. Pairing Requirement مناسب انتخاب شده است.
  11. Deviceها Pair شده‌اند.
  12. Labels براساس Site و Role تعریف شده‌اند.
  13. Dashboard بررسی شده است.
  14. Alert CPU/RAM آزمایش شده است.
  15. Webhook آزمایش شده است.
  16. Run Script ابتدا روی Test Device آزمایش شده است.
  17. Upgrade Rule ابتدا روی Pilot Group اجرا شده است.
  18. Sequential Upgrade برای تجهیزات حساس بررسی شده است.
  19. Package Cache بررسی شده است.
  20. Topology ساخته شده است.
  21. Application Traffic فقط روی Routerهای مناسب فعال شده است.
  22. Wi-Fi Configuration قبل از Provisioning Export شده است.
  23. VLAN Rule بدون Selector ایجاد نشده است.
  24. Management Connectivity قبل از VLAN Provisioning بررسی شده است.
  25. Backup و Export تمام تجهیزات Pilot تهیه شده است.

سؤالات متداول درباره CMR در MikroTik

CMR در MikroTik چیست؟

CMR یک پلتفرم مرکزی برای Monitoring و مدیریت مجموعه‌ای از Deviceهای RouterOS است که قابلیت‌هایی مانند Inventory، Dashboard، Alert، Upgrade گروهی، Topology، Application Traffic و Provisioning Wi-Fi و VLAN ارائه می‌کند.

CMR از چه نسخه‌ای اضافه شده است؟

اولین پیاده‌سازی CMR در RouterOS 7.26beta1 معرفی شده است.

آیا RouterOS 7.26 اکنون Stable است؟

در زمان نگارش این مقاله نسخه‌ای که CMR را معرفی کرده در شاخه Development قرار دارد و CMR نیز Initial Implementation محسوب می‌شود.

CMR Server به Package جدا نیاز دارد؟

بله. Server از Package مخصوص cmr استفاده می‌کند.

CMR Client به Package جدا نیاز دارد؟

خیر. Client Functionality بخشی از RouterOS اصلی است، البته بعضی Architectureهای قدیمی پشتیبانی نمی‌شوند.

CMR از چه Portی استفاده می‌کند؟

Client برای اتصال به Server از TCP Port 54321 استفاده می‌کند.

آیا CMR Server باید Gateway باشد؟

خیر. CMR Server الزاماً Gateway شبکه نیست.

آیا CMR از پشت NAT کار می‌کند؟

بله. Client اتصال را به Server برقرار می‌کند و امکان اتصال از Routed Network، NAT یا VPN وجود دارد.

آیا برای شعب بهتر است CMR را روی اینترنت باز کنیم؟

در شبکه سازمانی بهتر است ارتباط Client و Server از مسیر Private Routing یا VPN برقرار شود و TCP/54321 بدون ضرورت برای تمام اینترنت باز نباشد.

CMR می‌تواند تمام Routerها را هم‌زمان Upgrade کند؟

بله. Upgrade می‌تواند Parallel یا Sequential باشد و براساس Label، Schedule و Failure Policy کنترل شود.

می‌توان RouterOS Version خاصی را نصب کرد؟

بله. CMR امکان Pin کردن Version را دارد، اما Version پایین‌تر نیز ممکن است باعث Downgrade شود.

CMR می‌تواند RouterOS Packageها را Cache کند؟

بله. Server می‌تواند Packageها را در RAM یا Directory محلی Cache کرده و میان Clientها توزیع کند.

CMR Alert چه مواردی را مانیتور می‌کند؟

CPU، RAM، Storage، Health Sensor، Availability، Interface Changes، Upgrade، Reboot و Log Messages از جمله موارد قابل استفاده برای Alert هستند.

آیا CMR می‌تواند Webhook ارسال کند؟

بله. Alertها می‌توانند HTTP یا HTTPS Request اجرا کنند.

آیا می‌توان یک Command را روی چند Router اجرا کرد؟

بله. با run-script می‌توان Script یا Command را روی Deviceهای انتخاب‌شده اجرا کرد و نتیجه هر Device را جداگانه مشاهده کرد.

آیا CMR Network Map دارد؟

بله. CMR می‌تواند Topology ایجاد کند و Linkهای مستقیم تجهیزات را براساس Neighbor و Port Data شناسایی کند.

آیا CMR جایگزین Zabbix یا LibreNMS است؟

در نسخه فعلی بهتر است چنین برداشتی نداشته باشیم. CMR قابلیت‌های Monitoring قابل توجهی دارد اما هنوز یک پلتفرم تازه و در حال توسعه است.

آیا CMR جای CAPsMAN را می‌گیرد؟

نه به‌صورت کامل. CMR می‌تواند Wi-Fi Configuration را روی APها Provision کند، اما Roaming را هماهنگ نمی‌کند و Central Authentication Server نیست.

آیا CMR می‌تواند AP تحت CAPsMAN را کنترل کند؟

اگر CMR Wi-Fi Network روی Radio مربوطه اعمال شود، CMR Configuration می‌تواند Configuration قبلی CAPsMAN آن Radio را کنار بزند.

آیا Configuration قبلی بعد از حذف CMR Wi-Fi برمی‌گردد؟

در نسخه فعلی الزاماً خیر. به همین دلیل قبل از اعمال CMR Wi-Fi باید Export تهیه شود.

CMR می‌تواند Firewall را مرکزی مدیریت کند؟

در نسخه فعلی خیر. Firewall جزو Configurationهایی است که باید مستقیماً روی Device یا با Automation و run-script مدیریت شود.

CMR DHCP و IP Address را مدیریت می‌کند؟

در نسخه فعلی خیر.

CMR VLAN Provisioning چگونه کار می‌کند؟

CMR یک cmr-bridge با VLAN Filtering ایجاد کرده و Portهای انتخاب‌شده را به‌صورت Access یا Trunk به آن منتقل می‌کند.

VLAN Provisioning خطر دارد؟

بله. انتخاب اشتباه Uplink یا Management Port می‌تواند دسترسی به Device را قطع کند.

CMR با Configurationهای کاملاً سفارشی سازگار است؟

مستند رسمی اعلام می‌کند CMR با Configuration پیش‌فرض یا نزدیک به Default بهترین عملکرد را دارد و Setupهای سفارشی ممکن است نیازمند Adjustment دستی باشند.

برای مدیریت CMR از WinBox 3 می‌توان استفاده کرد؟

خیر. برای GUI باید WinBox 4 یا WebFig استفاده شود.

آیا اکنون زمان مهاجرت تمام تجهیزات به CMR است؟

با توجه به Initial Implementation بودن CMR و Development بودن نسخه معرفی‌کننده آن، بهتر است ابتدا Deployment آزمایشی و Pilot انجام شود و سپس بر اساس پایداری نسخه‌های بعدی درباره Production تصمیم‌گیری شود.

جمع‌بندی؛ CMR یکی از مهم‌ترین تغییرات مدیریتی RouterOS است

CMR را می‌توان در نسخه فعلی با این ساختار خلاصه کرد:

RouterOS Fleet
 ↓
CMR Server
 ↓
──────────────────────────
│ Inventory │
│ Dashboard │
│ Monitoring │
│ Alerts │
│ Fleet Upgrade │
│ Run Script │
│ Network Topology │
│ Application Traffic │
│ Wi-Fi Provisioning │
│ VLAN Provisioning │
──────────────────────────

مهم‌ترین ارزش CMR برای شبکه‌هایی ظاهر می‌شود که تعداد زیادی تجهیز MikroTik دارند و مدیریت تک‌به‌تک آن‌ها دیگر عملی نیست.

Upgrade مرکزی، Label-based Management، Dashboard، Alert، Topology و اجرای Command گروهی می‌تواند بخش بزرگی از عملیات روزمره Administrator را ساده‌تر کند.

با این حال باید وضعیت فعلی قابلیت را جدی گرفت. CMR هنوز Initial Implementation است، Full Configuration Manager نیست و بخش‌هایی مانند Wi-Fi و به‌خصوص VLAN Provisioning می‌توانند روی Configuration موجود Device تأثیر مستقیم بگذارند.

CMR در شرایط فعلی بیشتر یک قابلیت بسیار امیدوارکننده برای Lab و Pilot است تا دلیلی برای مهاجرت فوری تمام شبکه Production به RouterOS 7.26 Development.

طراحی مدیریت متمرکز زیرساخت MikroTik

اگر مجموعه شما دارای چندین Router، Switch، Access Point یا شعبه است، انتخاب معماری مناسب برای Monitoring، Upgrade، VPN، CAPsMAN و در آینده CMR باید براساس تعداد تجهیزات و ساختار واقعی شبکه انجام شود.

برای طراحی زیرساخت، بررسی سازگاری تجهیزات با RouterOS جدید و استعلام قیمت و موجودی تجهیزات MikroTik می‌توانید با تیم فنی و فروش بیستون در ارتباط باشید.