Logs

A log is only worth something if it still exists at the moment you need it. That is exactly where RouterOS falls short by default: everything sits in memory, and memory empties on a reboot. The very reboot you wanted to investigate.

What is in there by default

RouterOS writes the topics info, error, warning and critical to the action memory: a ring buffer of a few hundred lines. You read it with:

/log print

Filtering is more practical. A few you will need often:

/log print where topics~"dhcp"
/log print where message~"login"
/log print follow

The last one stays open and shows new lines as they arrive. Useful while reproducing something: switch it on, pull the cable, watch what appears.

With /system logging print you see which topics go to which action, and with /system logging action print how those actions are set up.

Why it is gone after a reboot

The memory action is RAM. On a reboot, a power cut or a watchdog reset the contents are gone. That is not a bug: flash on a router is not built for thousands of small writes a day.

The consequence is that you miss precisely what you are looking for. A router that restarted during the night shows you a log in the morning that begins at boot. To learn why, the log has to go somewhere else. In any case, check how long the device has been up:

/system resource print

An uptime of forty minutes while you did nothing already tells you half the story.

What the tool makes of it

Under System sits the Logging field with three choices.

Default (memory)

The script leaves RouterOS logging alone. Fine for a device you watch anyway.

Also to flash disk (info/warning/error)

The script creates a disk action with five files of a thousand lines and sends info,!firewall, warning and error there. That is five thousand lines of history that survives a reboot.

Also to a syslog server

The script creates a syslog action pointing at the address and port you fill in (514 by default, facility local0) and sends info,!firewall, warning, error and critical there.

The Syslog server field takes an IP address, not a hostname. That is also the right choice: a router that has just booted and has no DNS yet should still be able to log.

In all three cases you see a block of /system logging action in the script followed by a few /system logging lines. The two belong together: the action says where to, the rule says what.

Note the !firewall in those topics. Firewall messages are so numerous that they would push everything else out, so they are excluded by default. If you do want them, there is a separate switch, log firewall drops, which sends the firewall topic to your syslog server, or to memory if you have no server.

What is worth logging

The answer depends on where it goes. To a syslog server you can be generous: that machine has a disk and a search function. To the router's flash you cannot, because every line is a write.

Almost always useful:

• system, info: reboots, configuration changes, who logged in when.
• error and critical: the short list you look at first.
• interface: ports going up and down. See Cables and power, because a flapping port is usually a cable.
• dhcp: which device got which address. Rarely needed, and then indispensable.

What fills a disk:

• firewall on a router facing the internet. A public address collects thousands of scan attempts a day. Only log this temporarily, and only to a syslog server.
• debug on any topic at all. Switch it on for the duration of the problem and off again afterwards.
• wireless or wifi on a busy access point. Every client that associates and leaves again is a line.

Services and tools holds the neighbours of this subject: SNMP and NetFlow give you numbers instead of lines, graphing draws the trend, and send e-mail lets you be warned. For real monitoring, Netwatch or a monitoring system is the right instrument; a log is for afterwards.

Reading a log when something broke

Work backwards. The line you land on is usually a consequence, not the cause.

1. Find the moment. Is the clock right? Without NTP, RouterOS writes times from 1970 or from the last time it knew. The tool enables NTP by default; check with /system clock print.
2. See whether the device rebooted. If there is a run of boot lines, your investigation starts there and not at what happened after.
3. Filter on the part you suspect, for example /log print where topics~"pppoe" for a connection that dropped.
4. Look for repetition. One link down is a cable that came loose. Forty in an hour is a cable that is broken.

If there is nothing useful in it, that is an answer too: the device did not see it happen. Then the problem sits before it or behind it, not in it.

Getting the log off the box

A syslog server does not have to be a project. A small Linux machine with rsyslog, a NAS that offers it, or a container on the router itself will do. What you gain is that the logs of all your devices sit in one place, with timestamps you can put side by side. A site with a router, two switches and three access points cannot be investigated by typing /log print six times.

If you send to a server outside your own network, remember that syslog over UDP is unencrypted and that all sorts of things are in it: usernames, addresses, which devices exist. Keep it inside your own network or send it through a tunnel.

Read on: System and time for the field itself, Services and tools for SNMP, NetFlow and e-mail, and When something goes wrong for the problems you need the log for.