Lab 09-07 · Logs, supout.rif and documenting the router¶

Imagine you go to the doctor and say "I felt bad at some point, I don't remember when, and I don't know what I ate". The doctor can do very little. Now imagine you bring a diary: "Tuesday 18:00, fever 38.5; ate seafood at 14:00". Same doctor, much better diagnosis.

Routers are the same. When something breaks at three in the morning, the person fixing it (you, a colleague, MikroTik support) needs a diary of what happened, a full medical report of the router, and a router whose configuration explains itself. By default a RouterOS router keeps its diary only in RAM, and forgets everything when it reboots. In this lab you fix that.

The router's diary: topics and actions¶

A log is the list of events the router writes down: logins, DHCP leases, interfaces going up or down, errors. Each message carries one or more topics (system, dhcp, info, error...).

The analogy for this lab: the log is the router's diary. Logging rules decide which pages of the diary (topics) are written where (actions):

flowchart LR
    EV["<b>Event</b><br>topics: dhcp, info"]
    subgraph RULES["Logging rules (System → Logging)"]
        R1["info → memory"]
        R2["info → disk"]
        R3["info → remote"]
    end
    MEM["RAM<br>lost on reboot"]
    DISK["log.0.txt<br>on the router"]
    SYS["<b>logserver</b><br>192.168.88.10<br>/var/log/remote.log"]
    EV --> R1 & R2 & R3
    R1 --> MEM
    R2 --> DISK
    R3 -->|"UDP 514"| SYS

Syslog is the standard way for devices to send their log lines to a central server over the network (UDP port 514).

Why a remote server, if the disk already survives reboots? Because if the router dies, or someone breaks in and deletes its files, the copy on another machine is still there.

The scenario¶

flowchart LR
    INET["<b>internet</b><br>198.51.100.10"]
    CAP["<b>class-ap</b><br>10.0.0.1 · 198.51.100.1"]
    subgraph R1["r1 · working, but undocumented"]
        WAN["ether2 (WAN)<br>10.0.0.x by DHCP"]
        BR["<b>bridge1</b><br>192.168.88.1/24"]
    end
    PC1["<b>pc1</b><br>your laptop<br>DHCP 192.168.88.x"]
    LOG["<b>logserver</b><br>syslog server<br>192.168.88.10"]
    INET ---|"198.51.100.0/24"| CAP
    CAP ---|"10.0.0.0/24"| WAN
    WAN --- BR
    BR ---|"ether3"| PC1
    BR ---|"ether4"| LOG

Start the lab¶

Download the lab files and unzip them: 09-07-support-logging.zip. Open a terminal inside the 09-07-support-logging folder.

sudo containerlab deploy -t topology.clab.yml

Give RouterOS about two minutes to boot. You need three terminals:

ssh admin@clab-mtcna-09-07-r1                 # password: admin
docker exec -it clab-mtcna-09-07-pc1 bash
docker exec -it clab-mtcna-09-07-logserver tail -f /var/log/remote.log

The third one stays open and shows, live, every line the syslog server receives. For now it is empty.

At any moment, CLAB_EXEC="docker exec" ./check.sh tells you what is already solved.

Step 1 · Read the diary and its rules¶

WinBox: Log (left menu), and System → Logging for the rules.

/log print
/system logging print
/system logging action print

Expected: the log shows your SSH login (system,info,account user admin logged in...). The rules are the four defaults: info, error and warning go to memory, critical to echo. The actions already include disk and remote, but no rule uses them, and remote points at 0.0.0.0.

Done when you can name the four default rules.

Step 2 · Write the diary to disk¶

First tune the existing disk action: file name log, 1000 lines per file, keep 3 files. Then add rules that send info, warning and error to it.

WinBox: System → Logging → Actions, double-click disk, set the values. Then Rules → +: Topics info, Action disk. Repeat for warning and error.

/system logging action set [find name=disk] disk-file-name=log disk-lines-per-file=1000 disk-file-count=3
/system logging add topics=info action=disk
/system logging add topics=warning action=disk
/system logging add topics=error action=disk
/file print where name~"log"

Expected: a file log.0.txt appears in Files. When it reaches 1000 lines it becomes log.1.txt and a new log.0.txt starts; with 3 files the oldest one is deleted, so the disk never fills up.

Done when log.0.txt exists.

Step 3 · Send the diary to the syslog server¶

WinBox: System → Logging → Actions, double-click remote: Remote Address 192.168.88.10, Remote Port 514. Then add three rules with Action remote.

/system logging action set [find name=remote] remote=192.168.88.10 remote-port=514
/system logging add topics=info action=remote
/system logging add topics=warning action=remote
/system logging add topics=error action=remote
:log warning "Hello syslog, this is r1"

:log warning "..." writes your own line into the log, a handy way to test.

Expected in the logserver terminal:

192.168.88.1 script,warning Hello syslog, this is r1

Every new login or DHCP lease now appears there too.

Done when your test line appears on the logserver.

Step 4 · Turn on debug logging, then turn it off¶

Normal logs say what happened. Debug logs say how, packet by packet. The course: to see detailed (debug) logs, create a new rule and add the debug topic.

WinBox: System → Logging → Rules → +: Topics dhcp and debug, Action memory, Comment TEMPORARY: DHCP debugging.

/system logging add topics=dhcp,debug action=memory comment="TEMPORARY: DHCP debugging"

Here two topics are exactly what you want: messages that are dhcp AND debug. Now make pc1 ask for an address again. On pc1:

dhclient -r eth1; dhclient eth1

On r1:

/log print where topics~"debug"

Expected: many lines like dhcp,debug,packet Msg-Type = discover, Msg-Type = ack: the whole DHCP conversation, field by field.

Now remove the rule. Debug logging is noisy, fills the memory, and on a busy router costs CPU:

/system logging remove [find comment~"TEMPORARY"]

Done when you have seen the DHCP debug lines and the debug rule is gone.

Step 5 · Create the supout.rif¶

When you open a ticket with MikroTik support, they ask for this file first.

WinBox: Make Supout.rif (left menu), or:

/system sup-output name=supout
/file print where name~"supout"

Expected: created: 100% and a file supout.rif of about 500 KiB in Files. You would download it (WinBox Files, drag it to your desktop) and attach it to the ticket.

Done when supout.rif is in Files.

Step 6 · Make the router explain itself¶

Open /export and read it as if you were a stranger. add address=192.168.88.1/24 interface=bridge1: what is it for? Which port goes where? Comments answer that inside the configuration, and they travel with every export and backup.

WinBox: almost every window has a Comment button (the yellow note icon). In the CLI, add comment=:

/ip address set [find address="192.168.88.1/24"] comment="LAN gateway"
/ip dhcp-client set [find interface=ether2] comment="WAN: address from class-ap"
/ip firewall nat set [find action=masquerade] comment="LAN to Internet: hide the LAN behind the WAN address"
/interface set ether2 comment="WAN to class-ap"
/interface bridge set bridge1 comment="LAN: ether3 pc1, ether4 logserver"

Comments are shown as ;;; lines in every print:

/ip firewall nat print

Finally, a system note: a short text the router shows to everybody who logs in. Perfect for "who looks after this router and what is special about it". WinBox: System → Note.

/system note set note="r1 - MTCNA lab 09-07. WAN ether2 (DHCP from class-ap 10.0.0.1), LAN bridge1 192.168.88.0/24. Logs: disk log.N.txt + syslog 192.168.88.10. Admin: you@mtcna.lab" show-at-login=yes show-at-cli-login=yes

show-at-login shows it when someone logs in with WinBox or WebFig, show-at-cli-login when someone opens the terminal (SSH, console). Next time anyone logs in, the router introduces itself.

Done when the key items have comments and the note shows at login. Run CLAB_EXEC="docker exec" ./check.sh: it must end with RESULT: lab solved.

If something goes wrong¶

Clean up¶

sudo containerlab destroy -t topology.clab.yml --cleanup

Key takeaways¶

• By default RouterOS logs to memory only: the diary is lost on reboot.
• Logging rules send topics to actions: memory, disk, remote (syslog, UDP 514), echo; one topic per rule, several topics mean AND.
• Debug logging (e.g. topics=dhcp,debug) shows the details of one feature; switch it off when done.
• supout.rif (/system sup-output) is the full report MikroTik support asks for; the watchdog can create autosupout.rif after a crash.
• Comments and a system note make the configuration explain itself to the next person.

Quick check¶

This was the last lab of the MTCNA course. You can now build, secure, shape, tunnel, monitor and document a MikroTik network: time to book the exam.