0

I have a weird issue with my MikroTik RouterBOARD hEX - RB750Gr3 (running Router OS 7.8).

Certain TCP connections are extremely slow, for example this 93 KB file takes ages to download from the clients in the router’s LAN:

curl https://gewerbeauskunft.bremen.de/navigaweb/res/themes/System_09.12.06/js/jquery-1.11.3.min.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95957    0 95957    0     0   1998      0 --:--:--  0:00:48 --:--:--  1279

Took 48 seconds!

This is reproducible and also happens on other clients on the same LAN.

However, fetching the file on the router itself is fast:

[admin@MikroTik] > /tool/fetch url="https://gewerbeauskunft.bremen.de/navigaweb/res/themes/System_09.12.06/js/jquery-1.11.3.min.js"
      status: finished
  downloaded: 93KiB-z pause]
       total: 0KiB
    duration: 1s

So I wanted to see what’s going on and started a packet capture on the router:

[admin@MikroTik] /tool/sniffer> set filter-dst-ip-address="141.91.174.108"
[admin@MikroTik] /tool/sniffer> start

Then ran the curl command from above again on one of my clients:

curl https://gewerbeauskunft.bremen.de/navigaweb/res/themes/System_09.12.06/js/jquery-1.11.3.min.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 95957    0 95957    0     0   444k      0 --:--:-- --:--:-- --:--:--  457k

To my surprise, it finished instantly. After stopping the packet capture, it’s slow again. I’ve reproduced this many times to ensure it’s not a coincidence.

What’s going on here? 🤯

Not sure if related, but it might be worth noting that the internet connection is established through a PPPoE tunnel with an MTU of 1492. However, MSS clamping is enabled and seems to be working fine. I can see the MMS value being reduced from 1460 to 1452:

1   0.000000    192.168.88.218  141.91.174.108  TCP 78  56741 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1863267890 TSecr=0 SACK_PERM
2   0.000029    192.168.88.218  141.91.174.108  TCP 78  [TCP Retransmission] [TCP Port numbers reused] 56741 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1863267890 TSecr=0 SACK_PERM
3   0.000154    79.213.184.215  141.91.174.108  TCP 78  56741 → 443 [SYN] Seq=0 Win=65535 Len=0 MSS=1452 WS=64 TSval=1863267890 TSecr=0 SACK_PERM

I have also tested with a client with MTU set to 1450, and the same issue is still present.

Improve this question
5
  • 1
    Could you - just to rule it out - adjust MTU to 1450B on a client and test again?
    – vidarlo
    Mar 15 at 20:03
  • 1
    Yes, same issue (ip link set mtu 1450 eno1).
    – aaronk6
    Mar 15 at 20:06
  • It's probably a routing problem. There is probably somewhere a "dead end". When you start the packet capture, a working route will be established after some time, meaning, when trying to send additional data, the routers at least know this working route and use it, instead of finding new routes or using old routes (which might not work). Check all your static routes. Btw. using static routes is often a bad way to do things, because they are often overlooked.
    – paladin
    Mar 16 at 9:00
  • Hmm, I don’t have any static routes and my config is pretty barebones (except that I have two Wireguard interfaces, but the issue also occurs when they’re disabled).
    – aaronk6
    Mar 16 at 14:41
  • Using ChatGPT’s help (with the new GPT-4 model), I found out this this is caused by Fasttrack. Disabling Fasttrack actually fixes the issue reliably. So it makes sense that doing a packet capture also fixes it, too, as it presumably also deactivates Fasttrack.
    – aaronk6
    Mar 18 at 9:48

1 Answer 1

Reset to default
4

Maybe caused by MikroTik’s Fasttrack feature. Try to disable any Fasttrack rules in /ip/firewall.

Improve this answer
1
  • Yes, it’s indeed caused by Fasttrack. I found out a week ago and added this as a comment to my original post above which you may have missed. Anyway, I’m going to accept your answer since this is probably the best solution for now.
    – aaronk6
    Mar 23 at 12:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .