The map is assembled from what your routers see of each other. This is what it draws, what it cannot draw, and what to check when a site comes up empty.
The map is not a picture you draw. It is assembled from what your routers already know about each other: each device's own neighbour table, /ip/neighbor, which RouterOS fills from MNDP and, where you have enabled them, LLDP and CDP.
A device is read during a scan when all three of these hold: it is enabled, it is online at the time of the scan, and it is assigned to the site you are looking at. The map is per site — there is no fleet-wide view, and picking a site is the first thing the page asks you to do.
A line is drawn when at least one of the two ends lists the other. Both ends listing each other is the normal case, but one is enough — a switch whose neighbour table is empty still appears connected if the router on the far side sees it.
Neighbours are matched to devices you manage in this order: the MAC address of any of the device's interfaces, then the address you manage it on, then its RouterOS identity. Matching on any interface MAC matters more than it sounds — plenty of switches announce themselves from their bridge or management interface, not from the port the cable is in.
Two kinds of node. A managed node is a device in the manager: it carries the name you gave it, its model, its address, and — while it is online — CPU, memory and uptime, with a status dot that updates live as polls come in, without the map being redrawn under you. Clicking it opens the device page.
An unmanaged node is something one of your devices discovered that the manager does not have: a switch nobody added yet, an IP phone, a printer, a neighbour's router on a shared segment. It is drawn dashed. Its address comes from what it advertised, and when it advertised none, from the ARP tables of the site's devices — which is why a plain host behind a switch often still shows an IP. That entry lives on whichever device routes for that subnet, not on the switch the host hangs off, so the whole site is searched for it.
Links carry what the ports report. The label is the negotiated speed; a bonded pair is collapsed into one line labelled with the bond rather than drawn as two; wireless links are drawn differently from wired ones. Hovering a link lists the ports at both ends, in the form ether5 (core) ↔ ether1 (sw-1).
Where a neighbour is learned on a bridge, the manager tries to put the line on the physical port using the bridge host table, so a bridged switch does not collapse into a single bridge-to-bridge line. When it cannot resolve the port, the line stays on the bridge.
One line you will not see: if A and C can both see each other through B, and B has them on different ports, the A–C line is dropped as indirect. Without that, a management VLAN — where every device sees every other one — draws a mesh that tells you nothing.
Opening a site shows the last result immediately and starts a new scan if the result is older than a minute, or if there is none yet. A scan reads every online device in the site, so it takes as long as the slowest device answers — seconds for a handful, longer for a large site. Only one scan per site runs at a time, however many people have the page open.
A result that found no links is retried sooner, after fifteen seconds, on the assumption that the devices may have still been coming online. It is not retried on every request: a site whose devices genuinely have no neighbours would then re-read every device in it for as long as the page stayed open.
Refresh forces a scan regardless of age. It needs the operator or admin role; anyone signed in can look at the map, and scoped users see only the sites they have access to.
Before 1.79.2, a site with no links between its devices never left "Scanning site topology…", because the page waited for links to appear and the server started a fresh scan on every poll. If you are on an older build, that is what you are seeing.
When a scan finishes without finding a link, the devices are still drawn — unconnected — with a panel beside them listing the reasons a site ends up empty. Working through them in order:
/ip/neighbor/discovery-settings print shows discover-interface-list, and the ports it does not cover announce nothing and hear nothing. Check it on both ends — a device that sees nobody is often the one that is not listening./ip/neighbor print.A device that appears as a dashed unmanaged node next to its own name is not a missing link — it is a device the manager has not been given, or one whose MAC and address did not match anything it has. Adding it turns the dashed node into a managed one on the next scan.
The first drawing is automatic — a layered layout when there are links, a plain grid when there are none. Drag a node and its position is saved for the site, so the arrangement you build is what everyone opening that site sees. Reset discards the saved positions and lays the site out again; Fit only changes the zoom. Saving positions needs the operator or admin role.
Unmanaged toggles the discovered-but-not-managed nodes. Turning it off is a quick way to see your own fleet without the phones and printers; remember that it hides their links too.
Wireless clients are not on it, by design. The graph is built from neighbour discovery, and a laptop or a phone is not a neighbour. An access point appears — as a managed device if you added it, otherwise as a discovered node — and its uplink is drawn as a wireless link, but the stations associated with it live on the device page, under Wireless clients.
It is a discovery map, not a cabling diagram. An unmanaged switch that speaks no discovery protocol is invisible, and two devices either side of it look directly connected.
The page is desktop-only. On a phone it says so rather than rendering a canvas nobody can use.