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.
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.
Sadly, that issue still exists in 7.19. Were you able to check your customer instances? Are they working fine or do the have the same issue with slow download speed?
Hello everyone! If anyone is still interested, the following worked for me:
Machine type e2-micro → advanced configurations → vCPUs to core ratio set to 1 vCPU per core (default is 2). ROS v7.19.4.
The underlying issue appears related to MTU on deployed RouterOS instance interfaces in GCP. AWS and Azure do not suffer from this issue.
We deploy VPCs and increase the GCP default MTU for a VPC from 1460 to 1500. We interconnect VPCs in different clouds with IPSec (NAT-T) and L2TP. RouterOS interfaces are showing an active MTU of 1500 when deployed.
Prior to 7.20.1 we got fragmentation over our tunnels if we tried to move a packet larger than 1368bytes in GCP. This fits perfectly with IPSec + ESP + NAT-T + L2TP overhead, implying the real MTU in GCP for RouterOS interfaces is 1460, not 1500 as expected.
The lower than expected MTU causes OSPF to never form adjacency with peers, if the database frames require fragmentation. Also ingress TCP traffic e.g. RouterOS updates was dead slow.