The Device Page

The top of the page

Five metric cards run across the top — CPU, RAM, temperature, voltage and uptime — with temperature and voltage hidden on boards that report no such sensor. Below them a strip carries the host, board name, architecture, serial number, software ID (system ID on a CHR), connection method, RouterOS version, the device-mode the board is running in, and Last Check, the time of the last poll, whether that poll succeeded or failed. The serial number and the software ID appear once the device has reported them, and a CHR has no serial number.

Beside the device's name sit the actions you use most: Check for Updates (and Update when one is available), Test Connection and Edit. Duplicate, Reboot and Delete are in the ⋯ menu next to them, with Delete last and set apart. Which of them you see depends on your role. (v1.107.0+)

While a device is not answering, Last Seen appears beside Last Check and carries the date as well as the time. The two answer different questions: Last Check is when the manager last tried, which on a router that has been down for a week is still a minute ago, and Last Seen is when a poll last came back with something — which is what tells you how long the outage has run. On a device that is answering they are the same instant, so only Last Check is shown.

Device-mode is RouterOS's own protection setting, and it decides which features the router will permit at all — a home-mode board will not run a bandwidth test or a sniffer however you ask it. Hovering the value also shows which RouterOS versions the board is willing to install, which is worth checking when an upgrade is refused for no apparent reason. Changing device-mode has to be confirmed at the device itself with a button press or a power cycle, so the manager reads it and never writes it.

Banners appear here when they apply, and all of them are worth reading rather than dismissing:

• Flagged by RouterOS. The router examined its own configuration at startup, found signs of unauthorized access, and switched the offending settings off. While flagged it refuses bandwidth tests, the traffic generator and the sniffer, and refuses to create or enable any scheduler, SOCKS, PPTP, L2TP, IPsec, proxy or SMB entry. MikroTik's own advice is to treat the device as compromised: audit the whole configuration for scripts, users and settings you do not recognise, then change every password. Clearing the flag is done on the device and needs a button press or a power cycle, so the manager reports it and cannot clear it for you. The device also carries a flagged badge on its card, and heads the issues report.
• No write permission. The RouterOS account this device is managed with belongs to a group without the write policy. Monitoring and every read tab keep working; commands, upgrades, service toggles and backups will be refused by the router itself, whatever your role in the manager is.
• REST connection method. RouterOS accumulates REST sessions that never clean themselves up, so routine monitoring uses SSH even on REST devices. The banner is a reminder that the SSH service needs to be reachable on that router.

A third note appears where routine polling has been moved to SNMP: SSH or REST is then opened only when you open a detail tab or run an action.

The Services strip shows which of the RouterOS IP services are enabled, and an administrator can toggle one from here. If NVD advisories match the running version, a Security Advisories card sits above the interfaces — the Security page explains where those come from.

Interfaces and traffic

The Interfaces card lists the ports with their state, addresses and, on PoE boards, the per-port power draw. Clicking an interface opens the traffic card beneath it.

The card is read-only until you turn on Edit mode, which opens the VLAN editor: VLANs and a role per port, written to the device behind a preview, a backup and a rollback the device performs on its own if you do not confirm. It has a page of its own.

That card has two clocks. Live polls the device every two seconds for as long as somebody is watching, and stops when the last viewer closes the card or leaves the page — nothing is sampled at that rate in the background. The 1h, 6h, 24h and 7d ranges read stored history instead, sampled once a minute and kept for seven days by default. Anything beyond that window has been pruned, which is why the 7d range is the longest one offered.

The chart shows RX and TX with the peak and current scale beside them, and hovering reads off a single point.

SFP optics

When the selected interface carries an SFP module, a Traffic/Optical switch appears on the same card. The optical view charts three things from the module's own diagnostics — receive and transmit power in dBm, module temperature, and supply voltage — over 6 hours, 24 hours, 7 days or 30 days.

These samples come from the five-minute metric tier, not the traffic tier, so they are kept for ninety days by default rather than seven. A slowly falling receive level over a month is exactly the shape this view exists to make visible.

SFP and SFP+ ports report themselves as ordinary ethernet in RouterOS, so the switch appears based on whether a module is actually present, not on the port's type.

The PoE budget

On boards with PoE-out, a budget card sits above the interfaces: total draw, the ceiling, the percentage between them, and how many ports are actually powered. A port configured for PoE but feeding nothing reads zero watts and counts as unpowered — a forced-on port with nothing plugged in is not a load.

Where the draw figure comes from depends on the board. If it reports its own consumption meter, that wins, because it counts losses the per-port readings miss; otherwise the ports are summed. The card says which of the two you are looking at.

The ceiling names where it comes from rather than presenting a bare number:

Switches with several PSE blocks get a bar per block as well as the total: a 450 W switch with a 150 W ceiling per group of eight ports can be within budget overall and over it on one block.

Two things the watt figure alone cannot tell you are called out separately. A board powered from a low-voltage rail passes that voltage through to its PoE-out ports, so the constraint is not headroom but which powered devices will start at all. And where the voltage the board reports does not match the supply selected on the form, the card says so — that is the swapped-brick case the picker cannot catch on its own.

A model nobody has run on real hardware yet carries an "unverified" badge. It means the figures come from the datasheet alone, not that they are wrong.

ISP links

A router whose provider links are marked gets an ISP links card: each link's number and provider, its interface, whether it is up, down since when, or administratively disabled, and the address on it. It appears only when the device has at least one link, and it updates as the device is polled.

The manager does not guess which interface is a WAN. The address on one is private as often as not, behind the provider's own router or on a mobile network, and with two providers running BGP both can be active at the same time. You say which is which, in one of two ways:

• A comment on the interface, on the router itself: ISP1, isp-2, ISP3 LTE. Capitals do not matter, and the text after the number becomes the provider's name. It travels with the router's configuration, so a backup or a replacement unit keeps it.
• A list on the device form, under ISP links → Set here, for a router whose comments you cannot change. It replaces the comments completely, so it can also leave a link out.

The number only tells links apart. It is not a priority and has nothing to do with routes. If two interfaces carry the same number in their comments, the card says so and that number is not watched until one comment is changed.

What gets reported is described with the ISP link events. Each change is also written to the activity log. A router that polls only over SNMP does not show ISP links yet.

Metric history

Below the traffic card, a chart card draws history from five-minute samples, kept for ninety days by default. What it can draw is whatever the board reports — every sensor in its health table, from temperature and voltage to fan speed in RPM — plus CPU load and memory usage, which are derived from the poll and therefore available on every model and every transport.

The card appears only once something has actually been sampled, and it is deliberately not tied to the device being online. "What was the CPU doing before it stopped answering" is the question you ask about a router that is already down.

Points are placed at the time they were taken, and the line breaks wherever sampling stopped for longer than two intervals, with the number of gaps stated above the chart. A stretch with no samples therefore reads as missing rather than as a slow, steady line across it. The same is true of the interface traffic chart, the optical chart and the small sparklines beside each interface.

The tab card

One card near the bottom carries the interactive tabs. Command, History, DHCP Leases and Wi-Fi are always there for a device the manager can talk to; Logs appears when the syslog receiver is enabled; IPsec, WireGuard, IPv6 Neighbors, LTE, STP, Bridge and Routing are added only when the device reports the corresponding feature; and Firewall is added for every device that is online and enabled, because every RouterOS device has a firewall, even one with no rules in it (v1.92.0+).

Tabs load when you open them and not before, and the ones that read live state from the router then refresh every thirty seconds while they stay open. Switching away stops that polling — the page does not keep six tabs' worth of queries running against a router. Command, History, STP and Bridge are read once rather than polled.

Every role gets the card (v1.99.0+). A viewer sees all the tabs but none of the actions in them: there is no Command tab, which runs a single command against this one device and prints the output beneath, and buttons such as Add Static Lease, the Wi-Fi password Change or Mark all read are not shown. Before 1.99.0 the whole card was for operators and administrators.

The History tab lists this device's command runs, including the ones started from the Commands page.

DHCP leases and the pool bar

The DHCP tab lists the leases with their addresses, MACs, host names and expiry. Adding a lease, or converting a dynamic one to static, is an administrator action.

For a device in a site, a Name column shows the name given to each MAC in that site, the same name the topology map shows for it. Operators and administrators can set it with the Name button on the row (v1.103.0+). The Wi-Fi, Bridge and IPv6 Neighbors tabs have the same column and button, and the Wi-Fi and bridge searches find a device by its name too (v1.104.0+). The bridge's own port addresses, the local entries, get no button. On a phone the device page shows no names yet. See Names for discovered devices.

Above the table, each DHCP server gets a utilisation bar against the address pool bound to it: green, amber above 75 per cent, red above 90. What is counted is pool addresses taken, not lease rows. Those are different numbers, and the difference is the whole point: static leases normally sit outside the pool entirely, and two rows can name one address. A count of rows would read as full while addresses in the pool were still free.

Where there is no pool to measure against — a server handing out static leases only, or an IPv6 pool — there is no bar, only a lease count. A capacity the manager cannot work out is shown as no capacity rather than as a guess.

Wi-Fi

The Wi-Fi tab has two parts: the connected clients, refreshed with the tab, and above them the security profiles with their SSIDs. Each client shows its signal, band and TX/RX rate; a Wi-Fi 7 client connected over several bands lists every band and the radios it uses. On the modern wifi package the rates need an account allowed to run scripts, and stay empty on a read-only one (v1.96.0+).

Passwords in that table are write-only. The current passphrase is never read from the device and never displayed — an administrator can set a new one, and that is all. Profiles using EAP rather than a pre-shared key are shown as such, with nothing to change here.

Changing a password covers the modern /interface wifi stack. Legacy wireless and CAPsMAN profiles are not listed.

Bridge hosts and multicast groups

On a device with a bridge, the Bridge tab shows two tables (v1.101.0+). The host table says which MAC address the bridge has learned on which port, with its type: local, static or dynamic, plus external or invalid where RouterOS marks an entry so. The VLAN column appears only when a bridge has VLAN filtering on, and the Bridge column only when the device has more than one. The search box matches a MAC with or without separators, so d0ea11 finds D0:EA:11:…, as well as a port or a VLAN.

The multicast table lists the groups learned by IGMP/MLD snooping, one row per group with every port that has joined it, which answers "who is subscribed to 239.1.1.1" at a glance. Static entries show their configured ports and their comment. When snooping is off on every bridge, RouterOS keeps no multicast table, and the tab says so instead of showing an empty one.

A busy switch can hold thousands of host entries, so the tables are read when you open the tab and never by the background poll. On a phone they are under More…, with the host list cut at 200 entries.

Tunnels and IPv6

The IPsec tab lists peers with their policies. Each selector's status comes from that policy's own phase-2 state rather than from matching addresses against the peer, and selectors are grouped by name — which is what makes a multi-selector peer readable instead of a flat list.

The WireGuard tab lists peers with their interface, endpoint, last handshake and transfer counters, and the comment each peer carries. RouterOS 7.15 added a name of its own to a peer; where peers have one, a Name column appears beside the interface (v1.84.0+). Adding a peer is an administrator action.

The IPv6 Neighbors tab is the device's neighbour discovery table with each entry's state — reachable, stale or failed. IPv6 routes are not separate; they live in the Routing Table card, under its IPv6 switch.

LTE and SMS

On a device with an LTE interface, the LTE tab shows the modem and the radio: RSRP, RSRQ, SINR and RSSI, the cell and eNB identifiers, sector, LAC, session state, IMEI and modem firmware, with a button to start a modem firmware upgrade.

If an OpenCelliD key is configured in Settings, the tab also resolves the serving cell to approximate coordinates and links out to a map. That lookup is asynchronous and never blocks the rest of the tab: signal figures appear immediately whether or not the lookup succeeds.

Two more panels live under the same tab. Monthly data usage accumulates transfer against the limit set on the device form, and fires a webhook as the limit approaches and again when it is crossed. The SMS inbox lists messages received by the modem, with a badge showing whether reception is switched on at the RouterOS end and on which port.

Routing and BGP history

The Routing tab appears when the device has BGP connections or OSPF neighbours. BGP peers are listed with their remote address, remote AS, state, uptime and prefix count; OSPF neighbours with their address, router ID, state, adjacency, priority and area.

Clicking a peer row charts it. The BGP history card underneath draws that peer's prefix count and session state over 6 hours, 24 hours, 7 days or 30 days, from five-minute samples kept for ninety days by default. The table refreshes every thirty seconds; the chart, being a five-minute tier, refreshes every five.

The strip under the line is the session state over time: green up, red down, grey for a peer an operator disabled, and blank where there are no samples at all. It is drawn to scale, so an hour of downtime is an hour wide and time nobody measured stays empty rather than being filled in by the samples on either side. The summary above the chart states down and disabled time as durations, and says plainly when part of the range has no samples — it will not claim "no downtime" about a stretch it cannot see.

Each sample also records how long the session had been up. Two samples five minutes apart can both say "up" with a full outage between them; a session uptime that went backwards is the only trace such a reset leaves, and it is what the BGP Session Down webhook fires on as well as on a peer that is simply down. One case is deliberately quiet: rebooting a router resets every session on it, so a fallen uptime there says nothing about the peer. The device's own uptime settles it, and a restart silences the peers on that device rather than reporting one flap each.

The inventory is keyed on the BGP connection, not the session, and that distinction matters. RouterOS lists only sessions that exist — a peer that goes down disappears from that table altogether. A history keyed on sessions would therefore lose a peer at the very moment it matters, and draw the outage as a flat line with no gap in it. Connections are configuration and never vanish, so a down peer records as down. The connection name is also the name RouterOS writes in its own log, so the chart and the device's log agree with each other.

Firewall rules

The Firewall tab reads the router's IPv4 firewall and changes nothing on it (v1.92.0+). A switch across the top picks the table — Filter, NAT, Mangle or Raw — and only the table you pick is read, so looking at the filter rules does not also query the other three.

Rules are listed in the order the router applies them, numbered as WinBox numbers them, and a heading row marks each change of chain. The columns cannot be sorted, on purpose: in a rule list the order is the meaning, and a table sorted by hits would show you rules in an order the router never uses. To narrow the list, pick a chain, hide disabled or dynamic rules, hide rules that have matched nothing, or type part of a comment, address, port or list name into the filter box.

Each rule shows its action, with the action's target beneath it — the address list an entry goes to, the address and port a NAT rule translates to, the mark a mangle rule sets. The conditions follow as short tags, a negated one highlighted, and any packet where there are none. Logging is noted only when the rule actually logs. Packets and bytes are the router's own counters for that rule, and the thin bar under the packet count compares the rule with the busiest rule in the same chain.

When FastTrack is switched on, a note above the Filter, Mangle and Raw tables says so. Fast-tracked connections skip the rest of the firewall, as well as connection tracking, simple queues, IPsec and a few other features, so the rules after the FastTrack rule, and their counters, see only part of the traffic. A rule with few hits on a router that fast-tracks is not necessarily a rule that does little. The dynamic rule RouterOS adds to show FastTrack's own counters is listed like any other and can be hidden with the dynamic rules.

If the router refuses the counter read for the account the manager uses, the rules are still listed and the counters are left blank, with a note saying they are unavailable.

When a tab is not there

Tabs are added from a capability probe run when the page opens, against a device that is online and enabled. That gives three ordinary reasons for an absent tab:

• The device is offline or disabled. No probe runs, so no conditional tabs are added. The metric history card still works, because it reads stored samples rather than the device.
• The feature is genuinely not configured. No WireGuard interface means no WireGuard tab. This is the common case, and the fix is on the router.
• The device is SNMP-only. SNMP has no command channel, so Command, DHCP, Wi-Fi, Firewall and every tunnel tab are absent; History remains, and Logs with it when the syslog receiver is enabled.

A tab that is present but empty is a different problem — that one is covered on the Troubleshooting page.