Topology

What the map is drawn from

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, and picking a site is the first thing the page asks you to do. The one view across sites is the BGP tab.

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 the name you gave it or 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.

The tree and its root

Each site is drawn as a tree. One device sits at the top, every other device hangs off the one it is connected to, and each line runs from the parent down to the child. The ports on both ends are printed next to the line.

The top of the tree, the root, is chosen in this order:

1. A device you picked by hand, in the Root picker above the map or by double-clicking it.
2. A device with ISP links, the same ones the ISP alerts watch: an interface comment such as ISP1, or the list set on the device in the manager.
3. A device whose default route leaves the site, meaning its gateway is not one of the site's own devices. A switch points its default route at the site's router, so it does not qualify.
4. The STP root bridge, for a site that is switches only.
5. The device with the most links.

The panel beside the map says which device is the root and why. Picking a root needs the operator or admin role, and it applies to everyone who opens that site. Root: auto goes back to choosing it from the list above.

From the root the tree follows the links STP is forwarding on. A link that STP holds in standby stays on the map, drawn dotted and apart from the tree. So does a second path between two devices when STP is off, drawn dashed. Neither is lost, they are just not how the tree is reached.

To learn this, a scan also reads each device's default route and its bridge STP state, the same state the STP tab on the device page shows. On a switch with many bridge ports the STP read adds a second or two to the scan.

Reading the map

Two kinds of node. A managed node is a device in the manager. Its card shows the name you gave it, its model, its address, and while it is online, CPU and uptime, with a status dot that updates live as polls come in. The border colour says what it is: router, switch or access point. An offline device is dimmed. Click a card to see its details in the side panel, with the port it hangs from and a button to open 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. Its card has a grey border. 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.

An unmanaged card shows a name rather than a MAC address wherever one can be found. See Names for discovered devices.

A device you have named or given a type, on the map or in DHCP Leases, is drawn even when it announces nothing over discovery: a TV, a camera, a printer, a phone. It goes under the port where the site's switches and access points learn its MAC. An access point also learns everything above it on its uplink, so that sighting is ignored, and of the rest the device furthest down the tree wins. A named device that no bridge host table has seen, such as a laptop that is switched off, is not drawn. Devices nobody named stay off the map, so it does not fill up with every client on the network.

Two or more unmanaged devices of the same kind hanging off the same device fold into one card, such as 4 unmanaged or 2 phones. Click it to list them in the side panel, and click a name there to see that device. Servers that announce a platform such as Proxmox or TrueNAS fold into their own servers card.

Links carry what the ports report, and two devices are never joined by more than one line. Several cables between the same pair share one line, and its label says how many, for example 1G ×2. A bonded pair is labelled bond. Everything else is labelled with the negotiated speed. 10G and faster is drawn thicker, and a wireless link is drawn dashed and labelled Wi-Fi. Click a line to list every port pair it stands for and which of them STP holds in standby. The far end's port is named when the neighbour was identified by the MAC of that port, and left out when the neighbour announced itself from a bridge, since a bridge MAC does not say which port the cable is in.

Above the root, each of its ISP links gets an Internet card with the interface it runs on. The card turns grey and its line red while the link is down.

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.

Scanning and freshness

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, ten at a time, 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.

A re-scan never blanks the page. The last result stays on screen — links, nodes and the panel described below — and is swapped for the new one when the scan lands; the button reads Scanning… while it runs. A spinner instead of a map means this site has never been scanned at all. If a scan has not landed after about two minutes the page stops waiting, and Refresh starts it again.

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. The site picker is built from the devices you are allowed to see, so a site outside your scope is not offered and is refused if asked for directly.

A site with no links

When a scan finishes without finding a link, the devices are still drawn — unconnected — with a panel beside them naming what the scan could see: how many of the site's devices were offline and which ones, and what to check next. The panel has its own Refresh and can be dismissed; when a site has no devices at all it fills the canvas instead of sitting beside them. The full set of reasons a site ends up empty, in the order worth working through:

• Devices offline. An offline device is not read and contributes nothing, and the panel names them.
• Discovery not reaching the port. In RouterOS 7, discovery is governed by an interface list: /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.
• Nothing to discover. Neighbour discovery does not cross a router. If a site holds a single device, or devices in different physical locations, an empty map is the correct answer.
• The account cannot read the table. The RouterOS user the manager connects with needs to be able to run /ip/neighbor print.

A device that appears as a grey 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.

Layout, positions and folding

The first drawing is automatic. The tree is laid out from the root down, each branch as wide as what hangs below it, and devices with no link at all sit in a grid underneath. Drag a card and its position is saved for the site, so the arrangement you build is what everyone opening that site sees. A line can be dragged too: it bends, so it can go around a card or another line, and it keeps that bend. Double-click a bent line, or use Straighten in its panel, to put it back. Reset layout discards the saved positions and bends and lays the site out again. Fit only changes the view and moves no card. Saving positions needs the operator or admin role.

The ▾ badge on a card folds the branch below it, and then reads how many devices it hides. Expand all and Collapse all do the same for the whole map. What you fold is remembered in your browser, per site, and does not change the map for anyone else. So does Lines, which switches between curved lines and right angles.

Links drawn by hand

Discovery cannot see every cable. A pair of point-to-point radios usually passes no LLDP, so the two sites either side of it look unconnected, and sometimes a scan draws a link that is not there. Edit links fixes both. It needs the operator or admin role.

With it on, each card shows a dot at the top and the bottom. Drag from a dot to another card to draw a link. You are asked for the port at each end, picked from the ports the scan read on the device, or left as not known, and for a note, for example why discovery does not see it.

Click a link and its ends turn into yellow handles. Drag one to another card to move that end. A link the scan found is never changed: moving it hides it and puts a link drawn by hand in its place, and removing that link brings the found one back. Hide this link takes a wrong one off the map without drawing anything instead.

A link drawn by hand is dashed in amber and labelled by hand. If a later scan finds the same link, with ports that do not contradict yours, the two show as one. The panel says for each link whether the scan found it, it was drawn by hand, or both, and who drew it and when.

Under the panel there are always three lists: Hidden, with whether the scan still finds each one and a Restore button; Drawn by hand; and Not on the map now, for a link drawn to a discovered device the last scan did not find. Every change goes to the Activity log.

Verified links

A link the scan found can be marked as the way it should be. Turn on Edit links, click the link and choose Mark as verified. The mark keeps both ends and their ports as the scan found them, and the link gets a verified tag. It needs the operator or admin role.

Every scan after that checks each mark. When the scan no longer finds the link, or finds another device on one of its ports, the map draws a red dotted line between the two cards, labelled not found or other neighbour, and the line above the map says how many verified links are not as marked. The side panel lists every mark with its state, the ones not as marked first, and on a phone they are listed under the tree.

A link with an end that is offline is not judged, since that device's neighbour table could not be read. Nor is a site that has not been scanned yet.

Remove the mark in the panel takes it off. Marking and removing go to the Activity log.

The map shows a mismatch only to someone who opens it. To be told without looking, subscribe a webhook to Verified Link Mismatch and Verified Link Restored. While one does, every site with a verified link is scanned every 15 minutes. A mismatch is sent after two scans in a row, so a neighbour that missed one announcement does not wake anyone, and only once. When the link is back, the webhooks that were told hear that too. See Webhooks.

Port comments

The map knows what each port leads to, and Port comments writes that into the port's comment on the router, so it shows in WinBox and in an export. Click a managed device and choose Port comments. It needs the operator or admin role and is not offered for a device managed over SNMP.

Nothing is written before you see it. The dialog lists every port the map says leads somewhere, what it leads to, its comment now and what would be written, with a tick per port. Write writes only the ticked ones, one at a time, and the change goes to the Activity log.

The manager writes mikr: followed by the name, and on its own only into a comment that is empty or already starts with mikr: . A comment you wrote yourself is listed as written by hand, kept. To replace it, press Override on that row: the port gets a tick, and the new text is marked as replacing the comment written by hand. Nothing is overridden on a port you did not pick. If the comment on the router has changed since you opened the dialog, that port is skipped and the dialog says so. The Activity log records the comment that was replaced. (v1.105.0+)

A port is left alone, with the reason shown, when it leads to more than one device (a Wi-Fi port with several clients), to a device known only by its MAC, or when the device does not have that port. When a comment is read back as a name for a discovered device, the mikr: part is dropped.

Names for discovered devices

A device the manager does not have is known to it by its MAC address. The map looks for a better name, and uses the first of these it finds:

• the comment on a static DHCP lease for that MAC, on any device in the site;
• the name the device announces over neighbour discovery;
• the host name it asked DHCP for;
• the comment on the port it is connected to, but only when nothing else is seen on that port, since a port comment often describes the port and not what is plugged into it.

When none of these exists, the card shows the MAC address.

You can also name a device yourself. Click its card, then Name and type. The name you give always wins over one found automatically, and stays even when the lease or the comment changes later. The type sets the icon: router, switch, access point, server, camera, phone, printer, computer or other device. Cameras, phones, printers and computers get their own icon in the unmanaged colour, and the legend under the map lists them. On a phone, tap the device's name in the list.

Names are kept per site and apply to everyone who opens it. The DHCP Leases tab of every device in that site shows them in a Name column, and can set them too. Giving a name needs the operator or admin role. To go back to the automatic name, open the dialog again and choose Back to automatic. Every change goes to the Activity log.

Putting a device on the map

To put a device that announces nothing on the map, such as a printer, a camera or a virtual machine, name it from the Not on the map list. (v1.105.0+)

With nothing selected, the side panel lists every MAC address the last scan saw on a port of the site's devices that is not on the map and has no name. Each row shows the device and port it was seen on, whether that port is Wi-Fi, and the IP address, DHCP host name or static lease comment where one is known. Wired devices come first. Virtual machines on Proxmox, QEMU/KVM, VMware, Hyper-V and VirtualBox are marked as such. Phones and laptops on Wi-Fi often use a random MAC address that changes, so a name given to one does not last; those are folded away behind Show N with a random MAC. A filter appears when the list is long. On a phone the list is under the tree.

Name on a row opens the same dialog as on the map, and once saved the device goes on the map under that port. It needs the operator or admin role.

Below it, Named lists every name given on the site: its type, its MAC address, whether it is on the map or was not seen by the last scan, and who named it and when, with Edit and Remove. Removing the name of a device that is on the map only because of it takes it off the map.

A device behind another

A virtual machine is seen on the same switch port as the server it runs on, so on its own it is drawn beside the server, under the port. When you name a device from the map, the dialog has a Behind field listing the other unmanaged devices on the map, those on the same port first. Pick the server and the virtual machine is drawn under it. While the server is not on the map, it goes back under the port. (v1.105.0+)

BGP sessions

BGP sessions often run between sites, so they have a tab of their own: BGP, next to Map at the top of the Topology page. It draws every BGP session in the fleet as one graph, across sites. The tab is offered only when a router you can see runs BGP. (v1.105.0+)

The manager reads BGP every 5 minutes on the routers that run it, and the tab draws from the last read, so opening it does not contact any device. A router appears after its first read. The line above the graph counts routers and sessions, and how many sessions are established, down and disabled. A router whose last read is older than 15 minutes is outlined in amber, and that line counts it as not read.

Reading the graph

Each router is a card with its site, AS number and router ID. Routers sit in two rows: Transit on top and Sites below. A router without a row set sits in Sites. Sites are placed under the transit routers they peer with.

A session between two routers in the manager is drawn once. Its two halves are matched by the addresses at both ends, not by peer names, which each side picks on its own. A session that is down on one side is still drawn to the router that holds the address. If the same pair of addresses is used on more than one site, such as the same private range twice, those sessions are not joined on a guess.

The number at each end of a line is how many prefixes that router receives on the session. An established session is drawn green, one that is down red and dashed, and a disabled one grey and dotted.

A peer that is not a router in the manager, or is one outside your site access, is drawn as an outside peer by its address, above a transit router or below a site router. A router you cannot see is never named on the graph.

Details and rows

Click a router to see its site, address, AS, router ID, how many of its sessions are eBGP and iBGP and how many are established, how long ago it was read, and its neighbours with their AS, prefixes and uptime. Open device goes to its device page. Click a line to see both ends with their address, AS and prefixes received.

The Row picker in a router's details puts it in Transit or Sites. The row applies to everyone and needs the operator or admin role; the change goes to the Activity log.

On a phone the whole graph is fitted to the screen as an overview, and tapping a router or a line opens its details below.

Arranging and hiding

Drag the background to pan and use the mouse wheel to zoom. Fit brings the whole graph into view, which is also how the tab opens. Operators and administrators can drag a router to a new place; the position is saved on the server and comes back for everyone. Reset layout puts every router you can see back where the manager would draw it. A viewer can pan and zoom but not move cards. (v1.106.0+)

Hide from graph in the details of a router or an outside peer takes the card and its lines off the graph for everyone, and the outside peers of a hidden router go with it. The line above the graph counts how many cards are hidden, and the panel on the right lists them with a Show button that brings each one back. Hiding and showing need the operator or admin role and go to the Activity log. (v1.106.0+)

What the map does not show

Clients you have not named are not on it, by design. The graph is built from neighbour discovery, and a laptop or a phone is not a neighbour. It appears only once you name it, as described in Reading the map, and the Not on the map list shows what can be named. Every station associated with an access point is listed on the device page, under Wi-Fi.

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. Where you know better, draw or move the link by hand.

A link that leaves the site is not drawn at all. If a neighbour turns out to be a device you manage in a different site, it is recognised as that device rather than treated as a stranger — and because the map only ever draws one site, it then has nowhere to go. No line, and no dashed node standing in for it. The same is what keeps the map inside your access: a device in a site you cannot see never reaches the drawing.

Only links learned on a real port are drawn. A neighbour seen over a VLAN is followed back to the port underneath it, and one seen on a bridge is resolved to a port where the bridge host table allows; a neighbour learned on anything else — a tunnel, for instance — is left out rather than drawn as a cable that does not exist.

On a phone there is no canvas. The page shows the same tree as an indented list instead: each device with the port and speed of its uplink, branches that fold, and the links outside the tree listed underneath. Arranging cards and picking the root are done on a larger screen.