Lab 09-03 · The toolbox: traceroute, profile, traffic monitor, torch, bandwidth test¶
MTCNA
Module 9 · RouterOS tools. Official course slides 355–360: Tools → Traceroute and its LAB "trace the route to a website in your country and to www.mikrotik.com, observe the difference", Tools → Profile, the interface Traffic tab, and Tools → Torch. The course mentions the bandwidth test among the RouterOS tools; it is added here because it belongs in the same toolbox.
"The Internet doesn't work." You will hear this sentence hundreds of times in your career. It is the network version of "it hurts" at the doctor's. A good doctor does not guess: she takes your temperature, listens to your chest, maybe orders an X-ray. Each instrument answers one question.
RouterOS has a toolbox like that. In this lab the router comes with a planted fault. You will use the tools to find it, fix it, and then use the rest of the toolbox to look inside the traffic.
What you will learn
- Use traceroute to see every router on the way and find where the path breaks
- Read Tools → Profile to see what is using the router's CPU
- Watch live traffic with the interface traffic monitor
- Use Torch to see who is talking to whom, on which port, and how fast
- Measure a link with the bandwidth test, and understand why the virtual lab is capped at about 1 Mbps
- Avoid the trap of "DNS works, so the Internet works"
The doctor's bag¶
The analogy for this lab: the router is the patient, you are the doctor, and each tool is one instrument from the bag.
| Tool | Doctor's instrument | Question it answers | Menu |
|---|---|---|---|
| Ping | Pulse | Is it alive? How far? | Tools → Ping |
| Traceroute | X-ray of the path | Which routers are on the way, and where does it stop? | Tools → Traceroute |
| Profile | Blood test | What is the CPU busy with? | Tools → Profile |
| Traffic monitor | Heart-rate monitor | How much is flowing through this port right now? | Interfaces → port → Traffic |
| Torch | Microscope | Which conversations make up that traffic? | Tools → Torch |
| Bandwidth test | Treadmill stress test | How much can this link carry at most? | Tools → Bandwidth Test |
Traceroute: counting the steps¶
Traceroute shows the list of routers (hops) a packet crosses to reach a destination, with the time to each one.
Every IP packet carries a counter called TTL (Time To Live). Each router on the way subtracts 1. When it reaches 0, the router throws the packet away and sends back an ICMP time exceeded message, signed with its own address. Traceroute plays with that on purpose:
flowchart LR
PC["<b>pc1</b>"]
R1["<b>r1</b><br>hop 1"]
CAP["<b>class-ap</b><br>hop 2"]
S["<b>internet</b><br>hop 3"]
PC -->|"TTL=1"| R1
R1 -.->|"time exceeded: I am 192.168.88.1"| PC
PC -->|"TTL=2"| CAP
CAP -.->|"time exceeded: I am 10.0.0.1"| PC
PC -->|"TTL=3"| S
S -.->|"reply: you arrived"| PCTTL=1 dies at the first router, which reveals itself; TTL=2 dies at the second; and so on until the
destination answers. The probes can be ICMP or UDP packets (the course mentions both): RouterOS uses ICMP
by default, the Linux traceroute command uses UDP.
A * is not always a problem
A hop shown as * did not answer in time. Many routers limit how many ICMP messages they send per second,
or do not send them at all. If the next hops answer, the path is fine; only a line of * up to the end
means the path is broken there.
The scenario¶
flowchart LR
INET["<b>internet</b><br>198.51.100.10<br>web :80, /big.bin 50 MB<br>40 ms away"]
CAP["<b>class-ap</b><br>10.0.0.1 · 198.51.100.1<br>bandwidth-test server"]
subgraph R1["r1 · your router (with a planted fault)"]
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"]
INET ---|"198.51.100.0/24"| CAP
CAP ---|"10.0.0.0/24"| WAN
WAN --- BR
BR ---|"ether3"| PC1| Node | Role | Address |
|---|---|---|
internet |
"The Internet": web server, file big.bin (50 MB) to download, 40 ms away |
198.51.100.10 |
class-ap |
Class gateway: DHCP, DNS (www.mikrotik.com → 198.51.100.10), NAT, bandwidth-test server |
10.0.0.1/24 |
r1 |
Your router. Something is wrong with it | WAN by DHCP, LAN 192.168.88.1/24 |
pc1 |
Your laptop | DHCP from r1 |
Why ether2 and not ether1?
On a real hAP the Internet port is ether1. In the virtual lab ether1 is reserved for the lab itself (containerlab uses it to manage the router), so the Internet port is ether2 and the LAN ports start at ether3. Never touch ether1 in these labs.
Start the lab¶
Download the lab files and unzip them: 09-03-toolbox.zip. Open a terminal inside the 09-03-toolbox folder.
Give RouterOS about two minutes to boot. Then open the router and the laptop:
At any moment, CLAB_EXEC="docker exec" ./check.sh tells you what is already solved.
Step 1 · The patient's complaint¶
The user (you, on pc1) says "the Internet doesn't work". Confirm it:
Expected: From 192.168.88.1 icmp_seq=... Destination Net Unreachable. Interesting: somebody did answer,
and it was your own router, saying "I don't know how to get there".
On r1, try the same from the router itself, and also resolve the name:
Expected: the name is resolved (198.51.100.10 is not shown, but no DNS error either) and every packet says
no route to host.
DNS works, so the Internet works? No.
DNS answered because the DNS server (10.0.0.1) is on a network r1 is directly connected to. Reaching
the DNS server does not mean the router can reach anything beyond it.
Check yourself
- Which device sent the "Destination Net Unreachable" message, and what does that tell you?
Done when you have the symptom written down: "r1 answers, but says it has no way to the Internet".
Step 2 · X-ray the path with traceroute¶
On pc1:
Expected: only one line, 1 192.168.88.1 0.2 ms !N. The !N means network unreachable: the path stops
at hop 1, your own router.
Now look at what r1 knows about the world. WinBox: IP → Routes.
Expected: only DAc routes (connected networks: 10.0.0.0/24, 192.168.88.0/24, and the lab's ether1).
No 0.0.0.0/0, no default route: the router knows its neighbours and nothing else. Like a postman who
knows his own street but has no idea where to send letters for other cities.
Who should have created that default route? The DHCP client on the WAN, from the gateway class-ap gives it. WinBox: IP → DHCP Client.
Look for add-default-route=no. There is the fault.
Check yourself
- Explain in one sentence why traceroute stopped at hop 1 and not at hop 2.
Done when you have found add-default-route=no.
Step 3 · Fix it and X-ray again¶
WinBox: IP → DHCP Client, double-click the ether2 client, Add Default Route yes. OK.
Expected: a new line DAd 0.0.0.0/0 10.0.0.1 (d = added by DHCP). Now trace again, from pc1:
And from r1 to the name (the course's LAB):
Press Q to stop if it keeps refreshing. r1 sees two hops (10.0.0.1, 198.51.100.10): it does not count itself.
The real Internet is longer
In the classroom, a traceroute to a website in Spain usually shows around 8–12 hops, and one to www.mikrotik.com (Latvia) a few more, with a big jump in time when the path leaves the country. Our lab Internet has only one router, so you see the idea on a small scale. Try both on your home network.
Check yourself
- Which hop added most of the time, and why (remember the 40 ms)?
- Why does pc1 see 3 hops and r1 only 2?
Done when pc1's traceroute reaches 198.51.100.10 in three hops.
Step 4 · Profile: what is the CPU doing?¶
WinBox: Tools → Profile, Start.
Expected: a short list of processes with a percentage, such as networking, ethernet, management,
total. The router is almost idle; most of the CPU is idle (the course: unused CPU resources).
You will run Profile again in Step 6, when the router is busy.
Done when you know where to look when someone says "the router is slow".
Step 5 · Traffic monitor and Torch: who is using the line?¶
Give the router something to carry. On pc1, download the big file (it takes a few minutes; leave it running):
On r1, the traffic monitor shows how much flows through a port, live. WinBox: Interfaces → ether2 → Traffic tab.
Expected: about 1 Mbps of rx-bits-per-second on ether2 (coming in from the Internet). Press Q to
stop.
The monitor tells you how much. Torch tells you who. WinBox: Tools → Torch, Interface ether2,
tick Src. Address, Dst. Address, Port, Start.
Expected: one line, 198.51.100.10 80 (http) → 10.0.0.x, around 1 Mbps. Stop with Q and run Torch on
the LAN side:
Now the line shows 192.168.88.x, your laptop's real address.
Why two different addresses?
On ether2 the router has already done masquerade (NAT): the laptop's packets leave with r1's WAN address. To find which laptop is downloading, run Torch on the LAN interface. Torch on the WAN only tells you "it is someone behind me".
Check yourself
- A classmate's YouTube is eating the whole line. On which interface would you run Torch to find their laptop's address, and why?
Done when you have seen the download in Torch on both interfaces. Stop the curl with Ctrl+C.
Step 6 · Bandwidth test: how much can the link carry?¶
The bandwidth test sends as much traffic as it can between two MikroTik devices and measures it. One side runs the bandwidth-test server (enabled by default, port 2000), the other is the client. class-ap is the server; r1 is the client.
WinBox: Tools → Bandwidth Test: Test To 10.0.0.1, Protocol tcp, Direction receive, User admin,
Password admin, Start.
/tool bandwidth-test address=10.0.0.1 user=admin password=admin protocol=tcp direction=receive duration=10s
While it runs, open a second SSH session to r1 and run /tool profile duration=5s again.
Expected: rx-total-average around 1 Mbps, and in Profile a new process called btest using some CPU.
At 1 Mbps it is small; at hundreds of Mbps the bandwidth test itself can eat most of a small router's CPU,
which is why it is better to test through routers than to them.
Why only 1 Mbps?
The virtual routers are CHR (Cloud Hosted Router) with the free licence, which limits every interface to 1 Mbit/s of upload. class-ap sends at most 1 Mbps, so that is all r1 can receive. On a real hAP ax² the same test shows hundreds of Mbps. This is also why the 50 MB download takes minutes.
Do not test the line you are testing through
The bandwidth test fills the link on purpose. Running it across a production Internet line, or to a public MikroTik server, saturates it for everybody. In real life you test between two of your own devices, at a quiet time.
Check yourself
- Write the
rx-total-averageyou got and the biggest CPU user in Profile during the test. - Why do you think the bandwidth-test server asks for a user and password?
Done when the test ends with status: done testing. Run CLAB_EXEC="docker exec" ./check.sh: it must end
with RESULT: lab solved.
If something goes wrong¶
| Symptom | Likely cause | Fix |
|---|---|---|
pc1 traceroute shows !N at hop 1 |
r1 has no default route | Step 3: add-default-route=yes on the ether2 DHCP client |
A hop shows * but later hops answer |
ICMP rate limiting on that hop | Not a fault; repeat the traceroute |
| pc1 has no address | DHCP client on pc1 not finished | dhclient eth1 on pc1 |
| Torch shows nothing | No traffic at that moment, or wrong interface | Start the curl again; try ether2 and bridge1 |
Bandwidth test: authentication failed |
Wrong user or password for class-ap | user=admin password=admin |
/tool traceroute keeps refreshing |
It is interactive | Press Q, or add count=3 |
Clean up¶
Key takeaways¶
- Traceroute uses the TTL counter to make every router on the path reveal itself; the last line that answers shows where a path breaks.
- A router without a default route knows only its connected networks; DNS can still work if the DNS server is directly connected.
- Profile shows what uses the CPU; the traffic monitor shows how much flows through a port.
- Torch shows the individual conversations; on the WAN you see the address after NAT, on the LAN the real one.
- The bandwidth test measures a link between two MikroTik devices; the free CHR licence caps each port at about 1 Mbps.
Quick check¶
1. How does traceroute discover each router on the path?
- It sends packets with TTL 1, 2, 3... and each router that drops one sends back a time exceeded message
- It asks each router for its routing table
- It reads the route from the DNS server
- It sends one packet that collects the addresses of all routers
Each router subtracts 1 from the TTL. When it reaches 0 the router drops the packet and answers with ICMP time exceeded, revealing its address. Increasing the TTL one by one reveals the whole path.
2. pc1's traceroute shows only 1 192.168.88.1 !N. What is the most likely problem?
- The router 192.168.88.1 has no route towards the destination
- The destination server is switched off
- pc1's network cable is unplugged
- The DNS server is down
!N is network unreachable, sent by hop 1 itself: the first router does not know where to send the
packet. In the lab, r1 had no default route.
3. r1 can resolve www.mikrotik.com but cannot ping it. How is that possible?
- The DNS server is on a directly connected network, but there is no route beyond it
- DNS and ping use the same path, so it is impossible
- Ping is disabled on every router by default
- The name was resolved from the router's own hosts file only
Connected networks need no route. The DNS server 10.0.0.1 is on ether2's own network, so it answers. The
server 198.51.100.10 is beyond it and needs a default route.
4. You run Torch on ether2 (WAN) during a download and see the destination 10.0.0.200, not the laptop's 192.168.88.x. Why?
- On the WAN the packets have already been masqueraded to r1's WAN address
- Torch always shows the router's own address
- The laptop changed its address during the download
- Torch cannot see LAN addresses at all
Masquerade replaces the laptop's address with r1's WAN address on the way out. To see which laptop it is, run Torch on the LAN interface.
5. Which tool answers 'what is the router's CPU busy with right now?'
- Tools → Profile
- Tools → Torch
- Tools → Traceroute
- Interfaces → Traffic
Profile lists RouterOS processes and the share of CPU each uses. Torch and the traffic monitor look at traffic, not at the CPU.
6. In the lab, the bandwidth test between r1 and class-ap gives about 1 Mbps. Pick the two true statements.
- The free CHR licence limits each interface to about 1 Mbit/s
- The same test between two real hAP ax² routers would give a much higher number
- The cable between r1 and class-ap is broken
- The bandwidth test always reports 1 Mbps on purpose
The virtual routers are CHR with the free licence, capped at 1 Mbit/s per interface. Real hardware has no such cap, so the result is limited by the hardware and the cables.
Next: the traffic monitor shows now. To see what happened last night, last week or last month, the router can draw graphs.