7 min read
Ubiquiti, MikroTik and Cambium under one monitoring layer — for small and mid-sized operators
Three vendors, three consoles, three alert channels — and no answer to the only question that matters during an incident. How to build one operational view without giving up the vendor controllers.
6 min read
A small or mid-sized operator's network is almost never single-vendor. The core and the edge are usually MikroTik, the intercity and last-mile wireless links are Ubiquiti, and the access layer is increasingly Cambium. Each arrives with its own management system: UISP, MikroTik's own network map and WinBox, cnMaestro.
The problem is not that these systems are bad — each is the best thing available for its own hardware. The problem is that an incident does not respect vendor boundaries. A subscriber reports "the internet is down", and the operator on shift has three separate consoles, three separate logins, and nowhere a single screen that says whether the fault is in the core, on a wireless hop, or on the subscriber's own device.
What each vendor console does well
UISP (Ubiquiti). For airMAX/airFiber links and UISP-series devices this is the natural home for provisioning, firmware and configuration. It exposes signal, CCQ and airtime at a level of detail SNMP will not give you, and it plans wireless links with its own tooling.
MikroTik — the map and RouterOS. MikroTik's own mapping tool builds a network diagram quickly, reads SNMP from other vendors too, and costs nothing. RouterOS itself exposes everything needed — interface statistics, PPPoE sessions, queues, firewall counters.
cnMaestro (Cambium). For ePMP/PMP and cnPilot — radio parameters, sector load, subscriber-module state, bulk firmware upgrades. On Cambium hardware there is effectively no alternative.
Where each one stops
All of these are built to manage one vendor's fleet, not to operate a network. Three concrete gaps follow from that:
- History is short. A vendor controller will show you yesterday's incident; a trend from three months ago, rarely. Capacity planning lives on exactly that trend.
- There is no correlation. CCQ drops on a wireless hop and, in the same minute, an interface saturates in the core. That is one incident — but it appears as two unrelated facts in two different consoles.
- Alerting cannot be governed. Three systems write to three channels, each defines severity its own way, and no single escalation rule exists anywhere.
The approach: keep the controllers, add one layer above them
We leave the vendor consoles where they are irreplaceable and put a single vendor-neutral layer above them, with three jobs: state, history and alerting.
| Layer | What it does | Tooling |
|---|---|---|
| Discovery and inventory | Every device in one list, whatever the badge | LibreNMS / Zabbix, SNMP |
| State and history | Interfaces, CPU/memory, optical levels, PPPoE sessions | Prometheus / RRD, Grafana |
| Traffic visibility | Where traffic comes from and where it goes | NetFlow / IPFIX / sFlow |
| Synthetic checks | Latency and loss to the destinations that matter | ICMP/TCP probes |
| Alerting | One severity scheme, dedup and escalation | Alertmanager, Telegram / PagerDuty |
SNMP is the key: all three vendors support it. MikroTik exposes a full MIB, Ubiquiti exposes interface and wireless statistics, Cambium exposes radio and subscriber state. Where SNMP does not reach — cnMaestro's aggregated metrics, for instance — we use the vendor API instead.
What to actually measure on a wireless access network
Plain up/down is close to useless on wireless: the link is "alive" and still not working. The working minimum is below — and every one of these lands directly on the map, next to the node, so an engineer does not have to open a separate dashboard:
| Metric | What it answers |
|---|---|
| Wireless clients | How many subscribers are on the sector right now; a drop means the node or the sector, not the subscriber |
| Transmit CCQ | The link's real quality as a percentage — 99 and 33 on the same map are two different stories |
| Noise floor | The RF floor in dBm; a rise is interference, not "the internet broke" |
| airMAX Quality / Capacity | How efficiently the link uses the air, and how much headroom is left |
| Distance | The link's actual length in metres — the explanation behind the budget and the modulation |
| RadioFreq | The operating frequency; a frequency-plan collision shows up here |
| Rx / Tx | Current load on each link, in both directions |
| Uptime | Time since the last reboot — "it restarted by itself" ends here |
| Battery voltage | The tower's power node is on the same map: a sagging voltage warns minutes before the outage |
On top of that, what is measured per node rather than per link:
- PPPoE/DHCP session counts — a sharp drop says "the node is gone" faster than a ping timeout does.
- Optical levels (GPON/EPON and trunks) — degradation is gradual and visible in time, provided you kept the history.
- Temperature and the power feed — together with battery voltage, this explains the share of night-time outages that otherwise stays "unexplained".
- Uplink saturation — "the network is slow" is frequently this, and not the radio at all.
Alerting that means something
In a multi-vendor network alert noise doubles: one fault produces three notifications in three systems. So an alert rule here always answers three questions:
- Who is affected — one subscriber, a sector, or a node? Severity follows from that, not from the device type.
- What should be done — a notification without a runbook is not a notification, it is noise.
- Who gets it — an escalation matrix by severity, not "everyone in one group".
And one more: when a parent node fails, its children's alerts must be suppressed. That is why the topology map is not decoration — it gives the alerting engine the dependency hierarchy.
Where to start
In practice this is four steps, and none of them requires switching off what you already run:
- Inventory and discovery — every device into one system over SNMP. This is also where you find out how many devices were never recorded anywhere.
- Topology and dependencies — which node depends on which. It is the only way to bring alert noise down.
- History and dashboards — uplinks and core first, then sectors, then the subscriber level.
- Alerting and escalation — severity, dedup, runbooks, one channel.
After that the vendor consoles stay exactly where they belong: an engineer opens them to fix something, not to find out what happened.