MikroTik RouterOS keeps an event log containing system messages, interface changes, authentication attempts, routing events and messages generated by services such as DHCP, VPNs and the firewall.

The main log columns are:

• Time — when the event occurred.
• Topics — the subsystem and severity, such as interface,info or system,error.
• Message — the event description.
• Prefix — an optional label configured on a logging rule.

By default, most messages are held in memory and are lost when the router restarts.

Viewing the log

Display the current log:

/log print

Display additional fields:

/log print detail

Watch new messages in real time:

/log print follow

Stop live output with Ctrl+C.

Showing link, bridge and STP events

To show messages containing link, stp or bridge:

/log print where message~"link" or message~"stp" or message~"bridge"

The same search can be written as a regular expression:

/log print where message~"link|stp|bridge"

Follow matching events in real time:

/log print follow where message~"link|stp|bridge"

Typical results include:

• Ethernet link up or down.
• SFP or SFP+ module state changes.
• Bridge ports entering or leaving a forwarding state.
• Spanning Tree Protocol topology changes.
• Bridge ports being disabled or blocked.
• Loop-related messages.

Searches using ~ are regular-expression matches and are normally case-sensitive. Include both capitalisations when necessary:

/log print where message~"link|Link|stp|STP|bridge|Bridge"

Interface-topic messages can also be selected directly:

/log print where topics~"interface"

Useful event filters

Errors, warnings and critical events

/log print where topics~"error|warning|critical"

To include common failure wording:

/log print where topics~"error|warning|critical" or message~"failed|failure|timeout"

Router restarts, shutdowns and watchdog events

/log print where message~"reboot|restarted|shutdown|watchdog|power"

Login and authentication events

/log print where message~"login|logged|authentication|user|password"

This can reveal:

• Successful administrator logins.
• Failed WinBox, SSH, WebFig or API authentication.
• User configuration changes.
• Repeated password-guessing attempts.

Configuration changes

Accounting logging records many changes made by authenticated administrators. Check whether it is already enabled:

/system logging print

Enable accounting messages in the memory log if required:

/system logging add topics=account action=memory prefix="ACCOUNT "

Display accounting entries:

/log print where topics~"account"

Avoid adding duplicate logging rules, as the same event may then appear more than once.

DHCP events

/log print where topics~"dhcp" or message~"DHCP|dhcp|lease"

DNS events

/log print where topics~"dns" or message~"DNS|dns"

DNS query logging and DNS debug logging can generate a very large volume of entries and should normally be enabled only during short diagnostic periods.

VPN, PPP and IPsec events

/log print where topics~"ppp|l2tp|pptp|ipsec" or message~"VPN|vpn|tunnel|peer"

Routing events

/log print where topics~"route|ospf|bgp|rip" or message~"route|gateway|neighbour|neighbor"

Firewall events

/log print where topics~"firewall"

Firewall traffic is only logged when the matching firewall rule has logging enabled. Use a distinctive log prefix on selected rules so that their events can be isolated:

/ip firewall filter print detail

After enabling logging on the relevant rule, search for its configured prefix:

/log print where message~"WAN-DROP"

Do not enable logging indiscriminately on busy firewall rules. Logging every accepted or dropped packet can consume CPU, fill the log rapidly and obscure important events.

Detecting loops and packet storms

RouterOS does not necessarily generate a specific log entry for every broadcast or multicast storm. The log is useful for identifying symptoms, while interface counters and traffic tools are required to confirm the traffic.

Search for loop and storm symptoms

/log print where message~"loop|storm|broadcast|multicast|topology|own address"

A particularly important bridge-loop message is similar to:

bridge port received packet with own address as source address

This normally means that traffic transmitted by the router has returned on another bridge port. Common causes include:

• Two switch ports connected together unintentionally.
• A loop through an unmanaged switch.
• Incorrectly configured bonded interfaces.
• Multiple links between switches without STP or link aggregation.
• A virtual switch bridging interfaces incorrectly.
• VLANs being bridged back into themselves.

Repeated link up/down messages may also indicate:

• A damaged cable or connector.
• A failing SFP module.
• Incorrect speed or duplex negotiation.
• Unstable power to an attached device.
• A switch port being disabled by loop or security protection.

Check interface packet counters

Display Ethernet statistics:

/interface ethernet print stats

Look for unusually rapid increases in:

• Receive broadcast packets.
• Receive multicast packets.
• Transmit broadcast packets.
• Errors, drops or overruns.
• Traffic on an interface that should normally be idle.

Run the command repeatedly to identify which port is increasing most quickly.

Monitor traffic rates

Monitor one interface continuously:

/interface monitor-traffic ether1

Monitor a bridge:

/interface monitor-traffic bridge

Replace ether1 or bridge with the relevant interface name. Very high traffic on several bridge ports at the same time can indicate a loop or broadcast storm.

Use Torch to identify active traffic

/tool torch interface=bridge

Torch can show source addresses, destination addresses, protocols and traffic rates passing through the selected interface. On busy routers it should be used briefly because traffic analysis consumes processing resources.

Check bridge and STP state

Display bridge configuration:

/interface bridge print detail

Display bridge ports and their current states:

/interface bridge port print detail

Important items include:

• The bridge protocol mode, normally rstp or mstp.
• Ports shown as disabled, discarded or non-forwarding.
• Unexpected edge-port settings.
• Hardware offload status.
• Unexpected VLAN or bridge membership.

For normal switched networks, rstp is generally preferable to disabling spanning tree. Disabling STP removes an important safeguard against physical switching loops.

Enabling additional logging

Display the active logging rules and destinations:

/system logging print

Display logging actions:

/system logging action print

For example, ensure interface events are sent to the memory log:

/system logging add topics=interface action=memory prefix="INTERFACE "

Debug logging can generate a substantial number of messages. When enabled for diagnosis, identify the logging rule first:

/system logging print

Remove the temporary rule by its rule number after testing:

/system logging remove numbers=RULE_NUMBER

Replace RULE_NUMBER with the number displayed by the previous command.

Retaining logs

The default memory log is temporary. For fault investigation over a longer period, use a remote syslog server. A basic remote action can be created as follows:

/system logging action add name=remote-syslog target=remote remote=192.0.2.10 remote-port=514

Send important severity levels to it using separate rules:

/system logging add topics=warning action=remote-syslog
/system logging add topics=error action=remote-syslog
/system logging add topics=critical action=remote-syslog

Replace 192.0.2.10 with the syslog server’s address. The server and any intervening firewall must permit the configured syslog traffic.

Logging directly to router storage is possible, but frequent writes can cause unnecessary wear on flash storage. Remote syslog is generally more suitable for long-term retention and incident analysis.