Hi, everyone,

i just host CHR on GCP, i don't know what the problem with my CHR, my home connection is dedicated 100M Down & 100M Up, i use wireguard for VPN to my CHR and the result is below my expectation, it really take long time to load any website (30-90 seconds to open website and picture sometimes won't load), when i open youtube, it take time to load the site, but when the video start playing the connection is normal (i test play some 4k videos and connection reach to 90mbps for stream the video), but when i try to speedtest result always show below 2M sometimes 0.3M, but no problem with upload speed.

i tried to reset factory / fresh install the CHR but the problem still there.

some said it's because missmatch MTU, that make sense because at the first time i can't connect to mikrotik server license (handshake error), and then mikrotik team tell me to change MSS after change mss to 1000 and it works,

does anyone here host CHR on GCP and facing the same problem like this? or i just got the bad luck?
should I move to AWS or another cloud services?

english is not my first language, but I hope you got my point
thank you

Right.

Interestingly, I was just tracking down the same issue.

I could track it to having packets reaching RouterOS that are bigger than the MTU. As far as I can see, this is probably caused by GSO. I think it is GSO because (1) this is a documented behavior of Linux with GSO and (2) it does *not* happen with UDP, which is why all my connections going in *and* out of the router via wireguard work nicely. Things start to fail if a part of the connection is not wireguard-based.

I don't have a fix apart from using wireguard for all connections (not nice). I did not find a way to disable GSO, neither on the Google Cloud side, nor on the Mikrotik side.

If you do not mind me asking, how did you contact the mikrotik team ? I'd very much like to talk to them about it ...

Regards,
Sylvain

I'm having the exact same issue, unfortunately I've already tried changing MTU, MSS, another VM Instance in Google Cloud, the CHR changed to P-Unlimited, site to site vpn, road warrior, and nothing help to fix the slow download speed.

check Your license status on:

System -> License

Hi,

I have the same problem, its not license or MTU or MSS issue

It's a mystery!

Hi

November 2023 - still have the same issue
My download speed at region Warsaw is 500 kbps max. (300 avg)

Upload is working fine.

GCP Issue stale from July.
https://issuetracker.google.com/issues/291524051?pli=1

Hi,

Same issue ....

Regards,

Same issue here. The default MTU 1500 would prevent me from downloading anything at all. Setting it to 1360 allows me to download.. albeit very slowly

The same issue persists. With the default MTU set to 1500, changing it to 1460 results in the following: UDP performance is normal, TCP outbound (sending) is normal, but TCP inbound (receiving) is very slow, only a few Mbps. chr 7.14.3

Hi,

Many people have already reported this issue, and as we can see, the thread keeps growing.

The slow download speed on CHR hosted on GCP is a serious problem affecting a core function of the device - stable network traffic.

Can MikroTik finally comment on the cause?
This is very important for many of us, especially since the problem seems to have been identified for quite some time now.
We are hoping for an official response or some guidance towards a solution.

20250301, The problem is still happening, Neither Mikrotik nor Google Cloud solved the problem, Can anyone submit a new ticket to Mikrotik?

You cansubmit a ticket yourself. What's the problem?

20250301, The problem is still happening, Neither Mikrotik nor Google Cloud solved the problem, Can anyone submit a new ticket to Mikrotik?

@bugtik, if you need help in this user forum, you’ll have to provide more details about your GCE setup, including networking (GCP/VPC), mode, IP settings, firewall rules, etc. Also, export your ROS configuration and post it here. Plus, you need to be more specific about what and how the download is performed. Fwiw, we’ve set up plenty of CHR instances in GCE over the years and haven’t run into this issue before.

If you’re sure it’s a bug, you can report it to MikroTik support: https://mikrotik.com/support.

I have exactly the same issue.
GCE - empty new project, us-central1-c zone, e2-micro instance type, default rules for firewall, default VPC with mtu 1460.
CHR - configured as in https://wiki.mikrotik.com/Manual:CHR_GCE.
Upgrades from 6.42 to 6.49 and 7.12 were fast. Upgrade from 7.12 to 7.18 was impossible before lowering interface MTU to 1460. After that it was extremely slow with download speed lower than 100kbps. Changing MTU to even lower values didn't help. The only additional configuration change was a password for admin user.
The same happens if I test it with fetch. Following command also gives me download speed equal to 10KiB per second (80 kbps).
/tool fetch url="https://download.mikrotik.com/routeros/ ... .1.vhd.zip"

# 2025-03-05 12:20:35 by RouterOS 7.18.1
# system id = <>
#
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no mtu=1460
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/port
set 0 name=serial0
set 1 name=serial1
set 2 name=serial2
set 3 name=serial3
/ip dhcp-client
add interface=ether1
/system identity
set name=testchr
/system note
set show-at-login=no

To start with, e2-micro is an entry-level VPS type with a shared vCPU, which means it only gets a fraction of a physical CPU core. When the vCPU is shared with other workloads, it can easily get maxed out and cause CHR’s throughput to drop to almost zero.

Second, the VPC firewall should be turned off.

Third, always run speed tests using external tools like iperf3 instead of CHR’s built-in tools like tool fetch, especially on an e2-micro, since its shared vCPU can easily get overloaded.

You should always use an MTU of 1460 with e2-micro, but make sure it's set in the VPC first for it to actually take effect in CHR since this instance type doesn’t support SR-IOV. FYI, Google Cloud allows an MTU of 1500 in most cases, but not with e2-micro because it runs on Google’s internal SDN (Andromeda), which trims off 40 bytes.

Sadly it is something with ROS7. Exactly the same instance, the same VPC, but RouterOS 6 gives high download speed for the same actions.
[admin@MikroTik] > /tool fetch url="https://download.mikrotik.com/routeros/ ... .1.vhd.zip"
status: finished
downloaded: 40597KiB
total: 40597KiB
duration: 5s

I have switched instance type to e2-standard-4 (4 vCPUs, 16 GB Memory) - download speed is exactly the same as e2-micro.

Okay, with the same config as v6? Then it might be 7.18.1. Have you tried 7.15.3 or 7.16.2? Btw, just wondering, are you using some kind of default ROS firewall config while testing? What endpoints are you using while testing?

EDIT:
Just tried iPerf in a lab instance with v7.15 to a local Win11 and got almost full throttle.

Okay, with the same config as v6? Then it might be 7.18.1. Have you tried 7.15.3 or 7.16.2? Btw, just wondering, are you using some kind of default ROS firewall config while testing? What endpoints are you using while testing?

Exactly the same default CHR config. No ROS firewall at all (I've posted full config before). I've tried 7.12 and it was the same. Not sure about the endpoints - where can I check it?

Okay, with the same config as v6? Then it might be 7.18.1. Have you tried 7.15.3 or 7.16.2? Btw, just wondering, are you using some kind of default ROS firewall config while testing? What endpoints are you using while testing?

Exactly the same default CHR config. No ROS firewall at all (I've posted full config before). I've tried 7.12 and it was the same. Not sure about the endpoints - where can I check it?

By endpoints, I meant how you ran the tests, like whether you ran them between two different CHRs on the same GC, between a CHR and a local workstation, CHR and an PC on the North Pole using Starlink, using different zones/regions on both ends or something like that.

Could you try 7.15.3 and 7.16.2 as well? If both work, then there’s something wrong with 7.18.1 and it should be reported to MikroTik. Otherwise, it might be an issue with the GC configuration or something along the way in how the tests were done.

Exactly the same default CHR config. No ROS firewall at all (I've posted full config before). I've tried 7.12 and it was the same. Not sure about the endpoints - where can I check it?

By endpoints, I meant how you ran the tests, like whether you ran them between two different CHRs on the same GC, between a CHR and a local workstation, CHR and an PC on the North Pole using Starlink, using different zones/regions on both ends or something like that.

Could you try 7.15.3 and 7.16.2 as well? If both work, then there’s something wrong with 7.18.1 and it should be reported to MikroTik. Otherwise, it might be an issue with the GC configuration or something along the way in how the tests were done.

I'm testing it with GCP CHR instance and Mikrotik's download site. But any other direction works the same way.
I know that btest is also not the best way to test, but if I do it between CHR in USA and CHR in Europe - it shows UDP both send/receive 100mbps, TCP send from USA(GCP) is also 100mbps, but TCP receive is 1.2mbps at max.
7.16.2 and 7.15.3 give the same results.
6.49.18 on the same node at the same USA region to the same European CHR node gives TCP receive 84.7 Mbps as 10s average (and every other result is 90+ Mbps).
License is P1 on all nodes.

Thanks for testing! Since 7.16.2 and 7.15.3 give the same results as 7.18.1, it doesn’t seem to be a version-specific issue. But the fact that 6.49.18 performs so much better with the exact same settings is really weird.

It might be worth checking if there have been any changes to the default TCP settings between these versions. Have you tried adjusting TCP window sizes or disabling FastTrack to see if that makes a difference?

Anyway, I’ll take a closer look and see if I can spot anything specific in a couple of customer instances when I get the chance.

It might be worth checking if there have been any changes to the default TCP settings between these versions. Have you tried adjusting TCP window sizes or disabling FastTrack to see if that makes a difference?

That is a new empty CHR installation, its firewall rules list is empty, so there is no FastTrack at all. I haven't tried to adjust tcp window size, but trying to set MSS to a lower value via a mangle rule results in even worse speeds.