Devices

The device list is the front door to everything else. This page covers getting devices in, what each tab of a device does, and the parts that write to hardware.

Adding devices

Devices → Discover finds MikroTik hardware your managed devices can already see, over LLDP, CDP and MNDP. Each discovered device offers one button, Adopt Device, and the platform decides what that means — a factory-default unit is configured first, an already configured one is simply registered. See Adopting devices.

+ Add Device is the manual route when discovery cannot see it: address, credentials, and optionally a credential preset so the same username and password are not retyped per device.

Site chooses the site it joins: the one in view to begin with, or with a group in view, that group's first site. A fleet-wide account can pick New site… to make one on the spot, with a group (customer) for it, existing or new (#306). An install with one site shows Add it to a new site… instead. A site made this way stays if the device then can't be added; adding again with the same name finds it.

The address can be a LAN IP, a public IP, an IPv6 address, or a hostname (a local DNS name, or a router's own /ip cloud DDNS name). Pasting a full URL like https://203.0.113.5:8729/ works too — the port is pulled out into the API Port field automatically. The same goes for an address with a port sent through the API: it is used as the API port, and refused if a different port is also given.

Leave API Port blank and the manager tries API-SSL (8729) first, falling back to the plain API (8728) if the device doesn't offer it. Both are tried at once, so a device without API-SSL isn't slower to add. A port you enter, or one in the credential preset, is used as given. The plain API sends the login unencrypted on every poll, so a device that ended up on 8728 is listed on the Security page, where it can be switched over. Choosing 8728 for a public address still shows a warning.

When you enter a port, an API-SSL (encrypted) box appears under it. It is ticked for 8729 and clear for any other port. Tick it when api-ssl runs on another port: a port forwarded through NAT to reach several devices behind one address, say, or a network where 8729 is blocked (#257). The box is in Edit Device too. Before 0.46.0, any port other than 8729 was taken to be the plain API, and the device logged TLS errors. Ports outside 1–65535 are refused.

Devices without the API enabled (SSH only)

Many fleets start with the RouterOS API services (api, api-ssl) turned off. Tick The API isn't enabled on this device yet in Add Device, or put yes in the ssh_only column of a CSV import (#174).

The manager tries the API briefly first, and if it answers, the device is added normally. If it doesn't, the manager logs in over SSH instead. That reads the device's identity, model, RouterOS version and serial number (the serial still catches duplicates), and pins its SSH host key. The same login is used for SSH now and tried on the API later. A credential preset works too: its SSH login is used, or its API login when it has no SSH one.

The device is listed as SSH ONLY in the API column. Until the API is on:

• These work: bulk commands, command templates, the terminal, backups and config history. The manager checks over SSH every minute that the device is up. An outage alerts as usual, and the name, version and model stay current.
• These wait for the API: live status and graphs, clients, ports, VLANs and the other device tabs, firmware upgrades, and Change Guard. The device page shows only Overview and Config History, with a note explaining why.

To turn the API on, run a bulk command or template on these devices with Change Guard off, since Change Guard needs the API itself. For example:

/ip service enable api-ssl

You can also create a separate user for the manager at the same time. If you do, set it as the device's API login in Edit Device.

The manager tries the API every minute, or every 15 minutes after a refused login, so a wrong password doesn't fill the router's log. Once the API answers, the device becomes an ordinary one: API-SSL is preferred, its certificate is pinned, a full sync starts, and an event is logged. Check API on the device page tries straight away and says why it failed, if it did.

IPv6 addresses

Enter an IPv6 address with or without brackets: 2001:db8::1 and [2001:db8::1] both work, and [2001:db8::1]:8729 puts 8729 in the API Port field.

Reaching IPv6 devices is off by default, because it changes how Docker sets up the host's networking. Turn it on only if you have devices you can reach only over IPv6.

Before you turn it on, check the host:

• It has IPv6 itself. If curl -6 https://ipv6.google.com fails on the host, the manager can't reach IPv6 devices either.
• Docker 27 or later. Check with docker version.
• accept_ra=2 on its network interface. Docker enables IPv6 forwarding when it creates an IPv6 network, and most Linux distributions then stop accepting router advertisements. A host that gets its IPv6 address and default route automatically can lose its own IPv6 connectivity. Setting accept_ra to 2 keeps it, for example for eth0:

echo 'net.ipv6.conf.eth0.accept_ra = 2' | sudo tee /etc/sysctl.d/99-docker-ipv6.conf
sudo sysctl --system

Hosts with a static IPv6 address and gateway don't need this.

To turn it on, add this line to .env next to your compose file:

ENABLE_IPV6=true

then recreate the stack. Your data is kept, and the manager is down for about a minute:

docker compose down
docker compose up -d

With the pre-built images, add -f docker-compose.ghcr.yml to both commands.

To turn it off, remove the line and run the same two commands.

The web UI (nginx) and the backend listen on both IPv4 and IPv6 inside their containers whenever the host's kernel has IPv6, whether or not this setting is on. With it on, they accept IPv6 connections directly, including from a reverse proxy of your own. On a host booted with IPv6 disabled they listen on IPv4 only.

Use down then up rather than just up -d. Docker has to rebuild the network when this setting changes. Recent Compose versions do that on a plain up -d, but older ones can keep the old network and not apply the change. down then up works on all of them.

IPv4 devices work the same either way.

Reachable over a VPN but not over its public IP?

RouterOS's own IP → Services list restricts each service (api, api-ssl) by an "Available From" address list. It accepts the TCP connection from anywhere, then silently drops it mid-login if the source isn't on that list — which shows up here as "The device closed the connection during login," not a normal refused/timed-out error. If a device connects fine over WireGuard (or another VPN) but not from its public IP, check that field: either add the reachable range, or leave it restricted and keep using the VPN, which is the safer choice for internet-facing management anyway.

Try All runs a bulk add across every discovered device as a server-side job. It survives a closed browser tab and reports progress and failures per device.

Importing from CSV

Import CSV on the Devices page adds up to 500 devices from a spreadsheet.

1. In the import dialog, click Download template.
2. Open it in Excel or Google Sheets. It has one column per field and a few example rows.
3. Replace the example rows with your devices, one per row, and save as CSV.
4. Choose the file in the same dialog.

Column	Needed	What to put in it
ip_address	Required	The device's IP address or hostname
name	Optional	What to call it. Blank uses the address
type	Optional	router, switch, ap or other. Blank means router
preset	Login	The name of a saved credential preset
username, password	Login	The RouterOS login, if not using a preset
port	Optional	The API port. Blank tries API-SSL (8729), then 8728
api_ssl	Optional	yes when port runs api-ssl on a port other than 8729, no for the plain API on 8729
ssh_username, ssh_password	Optional	Only if SSH uses a different login. Blank uses the one above
ssh_only	Optional	yes when the API isn't enabled yet; see SSH only
tags	Optional	Existing tags. Create them under Settings → Tags first
site	Optional	The site it joins, by name. One that doesn't exist yet is made (fleet-wide accounts). Blank joins the site in view
site_group	Optional	The group (customer) a new site goes in, made if it's new. Also read as customer or client
notes	Optional	Anything you like

A group column is read as tags, as it always was; the dialog says so. The group of a site that already exists is left as it is. The dialog lists the sites an import will make.

For several tags on one device, separate them with a vertical bar: branch|lab.

Each device needs a login: a preset, or a username and password. An ssh_only row can use ssh_username and ssh_password instead. port and ssh_port can be added as extra columns if yours aren't the defaults (8728 and 22).

The file is checked before anything is sent. Each row shows as ready, skipped or a problem, with the reason. Skipped rows are:

• devices that are already managed
• the template's example rows, if they were left in (they use 192.0.2.x, an address range reserved for examples)

Columns can be separated by commas, semicolons (which Excel uses in many countries) or tabs. Unknown columns are listed and ignored.

The import runs as the same server-side job as Try All, so the tab can be closed.

Credentials are stored encrypted

API passwords are encrypted at rest with the key from ENCRYPTION_KEY. Losing that key means re-entering every device password; see Configuration.

Device credentials

Operations → Credentials holds credential presets: a RouterOS username and password (and optionally SSH login) saved once and picked when adding devices. Passwords are encrypted and never sent back to the browser.

A preset is either fleet-wide or belongs to one site:

• Fleet admins manage every preset. A site admin manages the presets of the sites they administer.
• A site's preset is only offered, and only accepted, for devices in that site. The Add Device, CSV import and Try All dialogs list fleet-wide presets and those of the site the new device joins (the selected site, or the default site when none is).
• Operator access off makes a preset usable by admins only: fleet admins for fleet-wide presets, and that site's admins for a site's preset.
• Names are unique within a site, so CSV import matches a preset name against that site's presets and the fleet-wide ones.

Before 0.30.0 presets were fleet-wide only and lived under Settings.

Edit Device offers the same presets (#259): picking one replaces the device's login, SSH login included, with the preset's. The manager logs in with it first, and nothing is saved if that fails.

Changing the login for many devices

Select devices in the device list and choose Change login… in the bar above it (#259). Pick a preset, or type a username and password (optionally an SSH login too). This changes the login the manager uses, not anything on the devices. Each device is logged in to with the new login first, and keeps its current one if that fails; the result lists every device and why any were left alone. Presets are offered only when every selected device's site can use them.

A typical use: devices added with a shared admin login, then moved to a dedicated manager user once that user exists on them.

The RouterOS login the manager uses

Give the manager a RouterOS user in the built-in full group. It reads and changes configuration over the API, takes backups, upgrades firmware and runs bulk commands, and between them those need most of RouterOS's permissions.

Change Guard in particular needs the policy permission. Before every protected change it saves a restore point with /system backup save, which RouterOS refuses without policy, and the revert it schedules runs with the permissions of the user that created it. RouterOS 7's built-in write group has every permission except policy and ftp, so with a write user the restore point fails with "not enough permissions" and:

• protected changes are applied without auto-revert, and the result says so: Applied without auto-revert protection: Could not arm auto-revert on this device (not enough permissions (9));
• changes that could cut the manager off are refused rather than applied unprotected.

A user in the read group can be monitored but not changed.

To check a device, run /user print and look at the group of the user the manager logs in as. To fix it, /user set [find name=<user>] group=full. If you'd rather use a group of your own, Change Guard needs read, write, test, api and policy (tested on RouterOS 7.24.5: saving the restore point, and a revert firing and restoring it).

If the login has to stay in the write group, set Settings → General → Change Guard → How it reverts to Targeted, no reboot (script mode): it needs no policy permission and never reboots. Changes script mode doesn't cover still need a binary restore point, so those stay unprotected for a write user.

The device list

Filter by status, type, tag, rack or location, and sort by any column. The search box matches name, address, serial and MAC. All clears the status and the AP/SW/RTR type filter; clicking the selected type again also clears it.

Two columns show how the manager reaches each device, and each has a filter:

• API: SSL for API-SSL (8729, or another port set to API-SSL), PLAIN for the unencrypted API (8728). See Encrypted management.
• Login: PW when the manager has only the password, PW+KEY when it also has a verified SSH key (SSH then uses the key), KEY for a key without a password.

The list updates by itself as polls finish; there is no need to reload.

The power icon on a device's row reboots it, after a confirmation (#292). It isn't offered for a device added over SSH only.

Columns at the end of the filter bar shows or hides columns, apart from the status dot, the name and the action buttons (#283). Drag a column header's right edge to make it wider or narrower, and double-click that edge to put it back. Reset columns restores the defaults. The choice is remembered in your browser.

Device names

A device's name follows its RouterOS identity (/system identity): rename a router on the device, or from its System tab here, and the new name shows up at the next poll.

A name you choose yourself is kept instead. That happens when you type a name in Add Device that differs from the router's identity, or rename a device in Edit Device. The name then stays put whatever the identity says, and Edit Device shows "Set manually". Click Use the router's identity there to go back to following it.

When the two differ, the device's System Information shows both: Name (in the manager) and Identity on the router. Use this name beside the identity switches to it straight away and follows it from then on (#253).

A device added without a name (from a CSV row with no name, or Try All) starts out named after its address, and switches to its identity at the first poll.

Tags appear beside the device name. They are the only grouping that crosses both sites and device types — see Bulk commands for selecting a fleet by tag.

To tag many devices at once, tick them in the list (the box in the header selects every device the current filters show), then choose Add tag… or Remove tag… in the bar that appears. Tags can also be picked when adding a device, and set per row in a CSV import. Tags themselves are created under Settings → Tags.

Status colours

Colour	Meaning
Green	Online
Amber	Degraded: online, but a power supply or fan reports a failure, or a temperature is at or over the limit
Red	Offline
Grey	Unknown, or offline when the device is marked as expected to drop out

Hardware health

The manager reads /system/health every few minutes, and on Sync. A device is degraded when:

• a power supply state (psu1-state, psu2-state, …) is anything other than ok
• fan-state is anything other than ok (a fan speed of 0 on its own is not a failure, as some models stop their fans when cool)
• any temperature reaches the limit, 85 °C by default, set under Settings → Alerting

Voltages are not judged, since normal ranges depend on the model and power source.

The device's Overview tab lists the problem. If it is deliberate, for example a dual-supply switch fed from one supply, click Ignore on this device and that reading no longer counts. Ignored readings stay listed so they aren't forgotten.

Becoming degraded, and recovering, raise the device_degraded and device_health_restored alerts, and are written to the device's event log.

Devices that go offline on purpose

On a device's Overview tab, tick Expected to go offline at times for solar or battery powered devices, or anything else that drops out normally. Such a device:

• shows grey rather than red when offline, and isn't counted as unreachable on the dashboard
• sends no offline alert when it drops out
• alerts once if it stays offline longer than its limit (24 hours by default; 0 means never), and then sends a recovery alert when it returns

Availability, uptime and reboots

Two figures sound alike and aren't (#326):

• Availability (the dashboard's Availability 30d, and the device page's 30-day card) is the share of the last 30 days the manager could reach the device.
• Uptime (on the device page) is how long since the device last booted, with the boot time under it.

A reboot that's over before the next poll never shows as an outage, so availability alone misses it. The manager also watches each device's uptime counter: when the boot time it implies moves later, the device rebooted since the last look, however quickly. Those are counted as Reboots on the device page (hover for the last one) and next to Availability 30d on the dashboard. Counting starts from the upgrade to 0.73.0.

Resetting a device's outage count

The dashboard lists a device that went offline several times in the last week as had N outages this week. Once you've dealt with the cause, or the drops were expected (an LTE link reconnecting, say), Reset count on that item counts the device's outages from now on, so the item goes away until it drops again (#85). Only the count is reset: the availability history, uptime figures and reports keep every outage. Snooze instead hides the item for 24 hours.

Device tabs

Tab	What it is for
Overview	Status, uptime, model, firmware, resource graphs, location
Ports	The switch faceplate, per-port configuration, bonds, VLAN membership
Bridges	Every bridge, its ports, VLAN filtering and spanning tree; create, rename, edit, delete
VLANs	The bridge VLAN table, and copying VLANs between switches
Radios	Wireless interfaces, SSIDs, channels, connected clients
Firewall	Filter, NAT and mangle rules, with reordering and counters
Routing	Routes, OSPF, BGP, routing tables and filters
Queues	Traffic shaping
Connections	The live connection tracking table: the total, and the first 200, 500 or 2,000 connections, filtered by protocol on the router. A busy router isn't asked for its whole table, and refreshing is on request unless you turn on auto-refresh (#300). Every column sorts, ports included (before 0.71.0, RouterOS 7.24's ports were missing)
Hardware	Health sensors, PoE, SFP module detail
LTE	Signal, carrier, bands and the data cap — see Cellular
Security	Baseline hardening checks and the posture score
Config	System settings, certificates, SSH keys, clock
Config History	Snapshots of /export, diffs, and rollback (what rollback can do)
Tools	Ping, traceroute, IP scan, Wake-on-LAN, packet capture, bandwidth test

Tabs appear only where they apply: a switch has no Radios tab, a device without a modem has no LTE tab.

Editing settings

A save changes only what you changed. The Config tab, radio settings and SSIDs send just the fields you edited, so renaming a device no longer resets its clock to the time the form was opened, and editing an SSID no longer pins a radio set to choose its channel automatically. The Config tab edits the first two NTP servers and keeps any others the device has.

Clearing a field clears it on the device. Emptying a firewall or NAT rule's address, port or comment, a queue's comment, or a WireGuard peer's endpoint removes that setting from the item. Switching a rule's source or destination between an address and an address list removes the other one. Before 0.24.39 an emptied field was left out of the save and the device kept the old value, while the page showed it gone.

On a switch port, changing flow control in one direction leaves the other direction alone.

On the Firewall tab, Address Lists entries can be turned off and on with the power button without removing them, as in WinBox. A disabled entry stays in its list, struck through, and no longer matches. Change Guard checks it like a removal, so disabling the entry that lets the manager in is caught before it is applied.

IP addresses

The Config tab's IP Addresses card lists the device's IPv4 addresses. Add one with the form below the list, remove one with the bin, or click the pencil to edit it in place: the address and prefix, the interface, the comment, and whether it's enabled (#285). Only the fields you change are sent. Dynamic addresses (from a DHCP client, say) can't be edited.

Every change runs through Change Guard. Changing, disabling or moving the address the manager connects to is predicted as a lockout and stops for confirmation, and moving it to another interface counts too, since the manager reaches it through the old one.

Bandwidth queues and FastTrack

The Queues tab, and Limit this client on a client's page, create a RouterOS simple queue. FastTracked connections skip simple queues, so on a device with an enabled FastTrack rule a queue only limits traffic that isn't FastTracked. When the device has one, the queue dialog says so (#280). To limit a target, exclude it from FastTrack (for example, an accept rule for it above the FastTrack rule) or turn FastTrack off.

Ports and the faceplate

The faceplate mirrors the physical front panel — copper staggered odd above even as the hardware is, SFP cages and QSFP breakout lanes grouped separately. Bridges and bonds aren't on the front panel, so they sit in a Virtual strip below it. A QSFP port that isn't broken out is drawn as one box.

Some models have their layout built in, so the faceplate matches the panel without any setting: CRS354-48P-4S+2Q+, CRS510-8XS-2XQ, CRS317-1G-16S+, CRS328-24P-4S+, CCR2216-1G-12XS-2XQ and CRS518-16XS-2XQ (#288). Other models use the generic layout.

Ports are identified by RouterOS's factory name, not their display name, so renaming a port to something useful does not move it into the wrong group or cost it its label or position. Where a port has been renamed, the factory name is shown beneath it.

Negotiated link rate and SFP module details — type, connector, vendor part number — are read from the device rather than guessed from the port's name, which also distinguishes an empty cage from a copper port.

A port's Comment is its interface comment, or, where that's empty, the comment on its bridge port (Bridge → Ports in WinBox), which is where many people put them (#290). Editing a port's comment here sets the interface comment. The column is hidden when no port has a comment.

Use ports per row in the faceplate header if the default does not suit your hardware; the setting is remembered. Next to it, top row says which ports are on top: 1 3 5 (most models) or 2 4 6, for models whose front panel has the even ports on top (#277). It appears when the Ethernet ports sit in two rows, and is remembered per model in your browser. A choice you make there overrides the model's built-in Ethernet layout.

Power-cycling a PoE port

On a port that supplies PoE, Power-cycle PoE turns its power off for 5 seconds and back on, which restarts the access point, camera or phone it powers (#291). It's in the selection bar when that port is selected, and as a lightning icon on the port's row in the port table. If management traffic reaches the device through that port, it asks first: the device being powered may be carrying the manager's connection.

Changing a port's VLAN

Selecting a port and setting it to access or trunk writes three things: the PVID, the bridge VLAN membership, and frame admission (frame-types and ingress-filtering).

For a trunk, tick the tagged VLANs. The native VLAN (PVID) is greyed out because it is carried untagged. The text box below the checkboxes holds the same list, for copying between switches, and accepts ranges such as 10,20,100-110. A VLAN typed there that the switch does not have yet is created on the bridge when you save.

Unticking a VLAN removes the port from it. One exception: if the switch holds several VLANs in one bridge VLAN entry (for example vlan-ids=100-110) and the port keeps some of them, that entry is left alone and the editor tells you which VLANs are still tagged. Split the entry on the VLANs tab to remove them.

This is a guarded change

Moving the port that carries management traffic is the most common way to lock a MikroTik out of itself. Every VLAN change runs through Change Guard, which predicts lockout before applying and lets the device restore itself if contact is lost.

Moving ports between bridges

Select one or more ports on the faceplate (shift-click for several) and choose Move to bridge (#258). Pick an existing bridge, New bridge… to create one (RSTP, VLAN filtering off), or No bridge to take the ports out, for a routed port with an address of its own. A bond moves as one; its member ports, and ports a service such as CAPsMAN added to a bridge by itself, can't be moved by hand.

A port's VLAN settings belong to its old bridge, so after the move its PVID is 1 and it admits all frames, and the old bridge's VLAN table no longer lists it. Set its VLANs again in the new bridge if it uses VLAN filtering.

If a port being moved into a bridge has an IP address or a DHCP client, the move stops and says so: an address on a port stops working once the port is in a bridge, which is how a router's WAN port gets cut off. You can still go ahead with Move anyway.

The Bridge column of the port table shows each port's bridge, marked HW when the switch chip forwards its traffic and CPU when the CPU does. A MikroTik switch chip hardware-switches one bridge, so ports in a second bridge are switched by the CPU: slower, and CPU load grows with traffic. MikroTik documents CRS1xx and CRS2xx as able to offload several bridges, but a CRS112 on RouterOS 7.24.5 didn't, so the move dialog warns on every model. The result reads the device's own flag after the move (and waits a little longer for it where the target bridge is already hardware switched), and the Bridge column shows the answer. To keep networks apart on a switch, VLANs on one bridge keep hardware switching; on a router, a separate bridge for a guest or IoT network is common, and usually carries little traffic.

To delete a bridge, double-click it on the faceplate and choose Delete bridge. Only a bridge with no ports, addresses, VLAN interfaces or DHCP server can be deleted.

Moving ports and deleting bridges run through Change Guard: moving the port management traffic arrives on out of its bridge is predicted as a lockout before anything is applied.

VLANs in the switch chip's table

Older switch chips, such as the Atheros 8327 in a hAP ac² and the chips in the RB951 and hEX lite, can't hardware-switch a bridge with VLAN filtering on: turning it on moves that bridge's switching to the CPU. On these chips VLANs belong in the switch chip's own table (Switch, VLAN in WinBox), with each port's VLAN mode, VLAN header and default VLAN.

On such a device the VLANs tab shows a Switch chip VLANs card with that table and the port settings (#278), and no longer suggests turning on bridge VLAN filtering or offers to add bridge VLANs. You can edit it there:

• Add switch VLAN adds an entry: a VLAN ID and its member ports. Include the CPU port (switch1-cpu) for a VLAN the router itself needs to reach, such as one with a VLAN interface on it; it's ticked to start with.
• The pencil on an entry changes its ports or turns it on or off; the bin removes it.
• Each port's VLAN mode, VLAN header and default VLAN are set in the table below, with a save button that appears once you change a value. Hover a mode or header to see what it does. secure with always-strip and a default VLAN is a typical access port; add-if-missing a typical trunk.

Every change runs through Change Guard with auto-revert required. The lockout check can't model the switch chip, so it can't tell you in advance that a change is safe; instead, if the device stops answering, it restores its previous configuration. These changes use a binary restore point, so a revert also restarts the device. Where auto-revert can't be armed (Change Guard turned off, or a login without the policy permission), the change is refused rather than run unprotected. Chips that do VLAN filtering in hardware on RouterOS 7 (CRS3xx and other Marvell switches, and the hEX's MT7621) use bridge VLAN filtering as described above and don't show the card.

Bridges

The Bridges tab lists every bridge on the device (#284): whether it's running, its spanning tree mode and priority, its comment, its ports, whether VLAN filtering is on and which VLANs have entries, and the addresses on it. Each VLAN is listed once; VLANs that RouterOS only added by itself, for a port's PVID or a wifi interface, are marked (dynamic). A port switched by the CPU rather than the switch chip has a small chip icon; hover a port for its PVID and spanning tree role.

• New bridge creates an empty one, with RSTP unless you choose otherwise. Add ports to it on the Ports tab (see Moving ports between bridges).
• Edit renames it, changes its spanning tree mode or priority (0 to 61440 in steps of 4096; the lowest wins the root election), changes its comment, or turns it off. Renaming keeps its ports, VLANs and addresses.
• turn on / turn off next to VLAN filtering works as it does from the faceplate.
• The bin deletes a bridge with no ports, addresses or VLAN entries.

Everything runs through Change Guard. Renaming the bridge the manager connects through, or changing its spanning tree, can't be simulated, so it runs with auto-revert required; turning that bridge off is predicted as a lockout and asks first.

Routing between VLANs in hardware

On a device whose switch chip supports it (Marvell 98DX: CRS3xx, CRS5xx, CCR2116, CCR2216), the VLANs tab has an L3 hardware offloading card (#254). It shows:

• whether offloading is on, and the switch chip;
• which VLAN interfaces have addresses, so which VLANs the device routes between;
• while it's on, how many hosts and routes the chip handles, and how many entries go to the CPU (that count always includes the device's own addresses);
• routed VLANs whose bridge doesn't have VLAN filtering on: only VLAN interfaces on a hardware-offloaded, VLAN-filtering bridge are routed in hardware;
• how many forward-chain firewall rules and NAT rules the device has.

Turn on / Turn off sets /interface/ethernet/switch l3-hw-offloading under Change Guard, since the chip reprograms its tables and forwarding can stop briefly. Offloaded traffic bypasses the CPU, so firewall filter and NAT rules no longer apply to traffic routed between the VLANs. When the device has forward-chain or NAT rules, turning offloading on asks you to confirm that nothing relies on them for that traffic. FastTracked connections can still be offloaded on chips that support it.

When a supported device routes between two or more VLANs with offloading off, Config Health reports Routing between VLANs runs on the CPU. There's no one-click fix: whether to trade the firewall for speed is your call.

Tools

All of these run on the device, not from the manager, so they see the network from where the device sits.

Tool	Notes
Ping	Reachability with RTT and loss
Traceroute	Hop-by-hop path
IP Scan	ARP sweep of a subnet
Wake-on-LAN	Magic packet sent from the device
Packet capture	5–60s sniff, downloaded as .pcap. Requires SSH
Bandwidth test	Between two managed devices; the target's test server is enabled and disabled for you

Terminal

The terminal opens an SSH shell on the device, for operators and admins in the device's site. The audit log records each session's start, who opened it, from which address, and when it was refused (for example by the rate limit). What is typed in the shell is not recorded. If you need a record of commands, turn on logging on the device itself (/system logging), or use bulk commands, whose commands and output are kept.

Before 0.24.49 the address recorded was the manager's own proxy, not the user's.

Syncing and polling

Devices are polled on three cadences — see Polling and scaling for the model and for switching individual collectors off.

Sync forces a full collection immediately rather than waiting for the next cycle. It honours the collector settings, so a collector you have switched off stays off.