Skip to content

Network services

DHCP, DNS, NTP, WireGuard, logging, NetFlow and discovery, viewed across the fleet rather than one device at a time. Network Services → Overview is a table of which devices run what: search it, sort by any service, and click a row to open the device.

The Overview and the NetFlow fleet view show what was last read from each device and when, refreshing anything older than ten minutes in the background; Refresh reads every device again. On a large fleet the page fills in over a few seconds rather than contacting every device at once (see Scaling).

Everything here writes to the device. Changes go through Change Guard where they could affect reachability.

DHCP

Servers, address pools and leases, per device. A lease list shows the first 100; Show all lists the rest.

  • IPv4 Static Leases lists a device's reservations: add one with Static, remove one with its delete button. Dynamic leases are on the Clients page, which knows far more about each client.
  • Pools and servers can be created, edited and removed.
  • A static IPv6 binding is matched by the client's DUID, not its MAC address, and assigns a prefix. Before 0.24.51 the form asked for a MAC address, which RouterOS refused.

A DHCP server bound to an interface that later changes VLAN is a common way to hand out addresses on the wrong segment; the lease list is the quickest way to notice.

DHCP pool usage, at the top of the page (and on Wireless → Overview), shows how full every IPv4 address pool across the fleet is, read on each slow poll (#156): yellow from 80%, red from 95%. A pool that runs out is a quiet failure, since clients connect but get no address, so a nearly full pool is also listed on the dashboard. Widen the range or shorten the lease time.

DNS

The resolver configuration on each device, plus static entries.

  • Static DNS entries are managed per device, including regexp entries. The record types are RouterOS's own: A, AAAA, CNAME, MX (with a preference), NS, TXT, SRV (with port, priority and weight) and FWD (forward that name to another DNS server). RouterOS has no static PTR record. Before 0.24.51 MX, NS and SRV targets went into the wrong field and the record wasn't created.
  • Flush cache clears the resolver cache on a device, which is worth doing after changing an upstream server or a static entry.
  • Upstream DNS servers are edited one entry at a time (#207): type an address and press Enter, or paste a list; × removes one. Only IP addresses are accepted. A device's own DNS servers, under its Config tab, work the same way.

NTP

Client and server configuration. Worth more attention than it usually gets: a device with the wrong clock produces logs that cannot be correlated, certificates that appear invalid — see Alerting — and scheduled work that fires at the wrong time.

NTP servers are edited one entry at a time, like the DNS servers; addresses and host names (pool.ntp.org) are both accepted.

Configuration templates can push the same NTP servers to many devices at once.

On RouterOS 6 the NTP server comes with the optional ntp package, so a stock device shows the client only. Its client takes up to two IP addresses plus any number of names, and its mode follows from the servers: unicast when some are set, broadcast when none are. Before 0.24.51 saving NTP settings on such a device failed with an error 500.

WireGuard

Interfaces and peers per device: create, edit, enable, disable and remove. Peer public keys and allowed addresses are shown so a tunnel can be checked against the far end without leaving the platform.

Every device in the site that has WireGuard gets its own card. Devices without it are listed underneath; Show / add interface opens a card for one so an interface can be added.

A peer's persistent keepalive is in seconds; leave it empty to turn keepalive off.

Routing

Network Services → Routing lists every BGP peer and OSPF neighbour across the fleet, or the selected site (#279): the device, the peer's address, AS or router ID, whether it's up, how long for, and when it last changed. Down peers are listed first. They're read with each device's slow poll, so a change shows up within that interval. Configure BGP and OSPF on a device's Routing tab, and turn on the Routing peer down alert (Alerting) to be told when a session drops.

  • BGP: one row per configured connection (a peer on RouterOS 6). It's up when its session is established; a connection with no session is idle, one still trying is connecting, and a disabled one is disabled. Adding a BGP connection on a device's Routing tab asks for the name, remote address, remote AS, role and local AS. On RouterOS 7.20 and later a connection belongs to a BGP instance, which carries the local AS: the device's instance is used (you choose when it has several), and on a device with none, one called default is created with the local AS you enter. On 7.0 to 7.19 the local AS goes on the connection itself, and on RouterOS 6 a peer is added. Before 0.59.1 adding a connection failed on 7.20 and later with missing =instance=.

  • OSPF: one row per neighbour. RouterOS forgets a neighbour once it stops hearing it, so the manager keeps the last row and marks it down. A neighbour gone for a week is dropped from the list. 2-Way counts as up: on a LAN, two routers that are neither DR nor BDR stop there by design.

Logging (syslog)

Where each device sends its logs — remote actions and the rules that select which topics go to them. Rules can be toggled without deleting them.

On current RouterOS 7, a remote action with a facility and severity is sent in syslog format (remote-log-format=syslog), and BSD syslog picks the BSD timestamp style over ISO 8601. Older RouterOS takes the same settings in its own form. The built-in actions (memory, disk, echo, remote) can be edited but not renamed or changed to another kind. Before 0.24.51 adding an action failed on every device.

This is separate from the events the platform collects itself. The platform reads /log/print on its own cadence regardless of whether you forward logs anywhere.

NetFlow

Configuration of the exporters on each device, and the collector built into the platform. See Traffic analytics for what is done with the data.

Discovery and SNMP

Neighbour discovery protocol settings (LLDP, CDP, MNDP) per device, and SNMP configuration.

Discovery is what populates the topology map and finds devices to adopt. Turning it off on a device makes that device invisible to its neighbours — and this platform.

The LLDP section covers every online device in the current site: routers, switches, wireless APs and anything else running RouterOS. Use the tabs to narrow it to one type. Enable and Disable only touch the devices listed.

The API is GET /api/network-services/lldp and PUT /api/network-services/lldp with {"enabled": true, "device_types": ["wireless_ap"]}. Leave out device_types to target every type. The older /api/routers/lldp and /api/switches/lldp still work.

Applying SNMP settings

The SNMP section covers every online device in the current site: routers, switches, wireless APs and anything else running RouterOS (it used to cover routers and switches only). Use the tabs to narrow the list to one type.

Choose where a change goes with Choose devices (one or several, with Select all), then Apply to selected, or use Apply to all. Nothing is pushed automatically, and Apply asks you to confirm the exact changes and the devices they go to first.

The form shows what the chosen devices have now, or, with none chosen, what every listed device has. A setting they don't all share shows as differs (the slider sits in the middle) instead of a made-up default.

Only what you change is sent. The form remembers which fields you edited and highlights them; everything else is left as it is on each device, so setting a trap destination doesn't also rewrite each device's community or turn SNMP on or off. Reset discards your edits. A community name a device doesn't have is added next to its existing ones; nothing is renamed or removed. Before 0.24.37 the form was filled in from one device and every field was sent, so Apply copied that device's community, version and on/off state to the whole fleet, renaming each device's first community.

For SNMPv3, leaving the privacy password blank keeps the current one and keeps the user encrypted. It used to drop the user to authentication only.

The API is GET /api/network-services/snmp (every device type) and PUT /api/network-services/snmp, which needs device_ids: a list of device ids, or "all" (optionally with device_types). Only the settings in the body are changed, for example {"device_ids": [8, 12], "trap_target": "10.0.0.5"}. The older /api/routers/snmp and /api/switches/snmp still work.

SNMP contact and location per device

Contact, location and trap target can use variables, filled in per device:

Variable Value
{identity} RouterOS identity (/system identity). {$systemidentity} also works
{name} Device name in the manager
{ip} Management address
{model}, {serial} From the device
{site} Site name
{location} The device's location, or its site's address if it has none

For example, contact {identity}@example.com or location {site} / {location}. An unknown variable is rejected before anything is written.

The form remembers the last contact, location and trap destination you applied, variables and all, and shows them when you come back (the table shows each device's filled-in value). A remembered value isn't sent unless you change it or press Send it under the field, which is how you apply the same template to devices added later.

A blank field keeps each device's current value. Before 0.24.26 a blank field overwrote it with nothing.