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.

vidarlo
  • 6,654
  • 2
  • 18
  • 31
aaronk6
  • 416
  • 6
  • 14
  • 1
    Could you - just to rule it out - adjust MTU to 1450B on a client and test again? – vidarlo Mar 15 '23 at 20:03
  • 1
    Yes, same issue (`ip link set mtu 1450 eno1`). – aaronk6 Mar 15 '23 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 '23 at 09: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 '23 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 '23 at 09:48

1 Answers1

4

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

aaronk6
  • 416
  • 6
  • 14
R3d3
  • 56
  • 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 '23 at 12:05