[RB5009] IPv4 PPPoE Download Slow — CPU0 Maxed, IPv6 Fine, Full Speed Only After Factory Reset

RouterOS General
1

Hi all,
I’ve run into a strange issue with my MikroTik RB5009UG+S+IN when using it on a 2Gbps/1Gbps GPON connection via PPPoE over VLAN. Hopefully others can confirm if they’ve seen this behavior.

Setup:
ISP: Telekom Malaysia GPON with 2Gbps down / 1Gbps up
IPv4: via PPPoE (VLAN interface)
IPv6: via DHCPv6-PD
RouterOS: 7.20beta2 and 7.19.1
FastTrack enabled on firewall

What Works:
When I factory reset the RB5009, configure PPPoE over VLAN manually (via Quick Set), and test — I get:
IPv4 Speed: 1.9–2Gbps down / 1Gbps up
IPv6 Speed: Full 2Gbps/1Gbps
CPU Load: evenly spread across cores

Problem:
After restoring my full .backup, I get:
IPv4 download: 500–940Mbps (inconsistent)
IPv4 upload: full 1Gbps
IPv6: still full speed (2Gbps)
CPU0 stuck at 99–100%, all other cores idle during test

Troubleshooting Tried:
Verified not ISP-related (tested with ISP’s own ONR/router = full speed IPv4/IPv6)
Restored .backup, then stripped down config to basic:
:right_arrow: Removed Containers, BGP, SD-WAN tunnel
:right_arrow: Set firewall to default (with FastTrack)
:right_arrow: Removed port forwards, queues
:right_arrow: Rebooted — same issue: CPU0 maxed, IPv4 slow
Only fix: factory reset, manually reconfigure, do not restore backup

Has anyone else experienced this behavior or similar devices under PPPoE?

2

These full backups should only be used when restoring the same RoS version. You shouldn’t make a backup at (say) 7.19.1 and restore on a 7.20beta.

3

Says who?

A .backup file is basically an archive of all of the binary config files (.dat / .idx) that RouterOS stores in the underlying filesystem at /flash/rw/store. When you upgrade from one version of ROS to another, those files are checked by the new version of ROS after it boots up, and any data schemas that have changed in the newer version are updated within the data files.

Restoring from a .backup taken with an older version of ROS is conceptually no different than updating a device to a newer version of ROS that (by definition) has config files on the disk that were necessarily made by an older version.

To drive the point home, RouterOS v7 /system/backup/load command has an option, force-v6-to-v7-configuration-upgrade=yes, that you use when you want it to migrate certain things from a v6 config that require more extensive translation and adaptation than usual (such as route filters), otherwise it skips them. So loading a backup taken from RouterOS v6 onto a v7 device is even explicitly supported. If you can restore a v6 backup to a v7 router, then naturally you can restore a v7.19.1 backup to a v7.20 router.

Version differences are rarely the problem (unless there is a bug). Where backup files can be problematic is when you want to load one on a device that is a different model than the one the backup was originally taken on (because the physical interface arrangement is going to be different). But not one that is from a different version.

.rsc exports have slightly different limitations in this regard, since it’s possible for user-facing ROS command syntax to change, for parameter names to change or be re-arranged, etc. So an export made on one version might not cleanly import onto a different version, simply because of those kinds of differences. But whenever that’s a problem, it typically results in the import bombing out, due to command/syntax error.

In any case, @Anime4000 didn’t even say they were restoring full .backups across different versions. So that’s an assumption. All that they said was that they tested this on both 7.19.1 and the latest 7.20beta. For all we know, they could have taken a backup on 7.19.1 and then restored it to the same router running the same version, ran into the problem, so then they tried upgrading to 7.20beta, wiping config, re-config’ing from scratch, taking backup, immediately restoring it, and found that the same problem seems to be triggered even on the latest beta version when taking the same steps.

4

to clarify this, I backup within same 7.20beta2

I want 7.20beta2 because it fix ISP using PPPoE over VRRP & VXLAN that cause MTU to 1480 in disappointment: http://forum.mikrotik.com/t/pppoe-compatibility-issues-with-vbras-nfv/182546/1

I did try restore .backup and stripped down config to basic, as similar to factory reset > quick set
Download speed on IPv4 still crap and CPU 0 pegged at 100% :rofl:

5

Mikrotik themselves.

https://help.mikrotik.com/docs/spaces/ROS/pages/40992852/Backup

We recommend restoring the backup on the same version of RouterOS.

And hundreds of users having issues suddenly solving it after following the advice not to restore over different versions.

But your choice, you are free to continue doing it.

6

Can you maybe post your config export? When you run Tools → Profile, which router process uses CPU resource the most?

7

Touche.

That said, it is clearly a “recommendation”, not a hard fact. Such a “recommendation” also flies in the face of the existence of the “force-v6-to-v7-configuration-upgrade” option. Also, if you understand how upgrades work under-the-covers, then it is clear that restoring a backup on 7.20 that was made on 7.19.1 is absolutely no different from upgrading to 7.20 from 7.19.1. The exact same code paths are traversed.


What “it” are we talking about, in “solving it”?

In any case, it has now been clearly established that OP was not even doing this to begin with, so this is largely irrelevant to this discussion anyway.

8

You brought it up, in length :laughing:

9

Says Mikrotik themselves. But go ahead, You really know better than the maker. Go on, make my day.

10

I wonder there are way to read .backup and edit?

but I do this method seem fixed it.

  1. I dump into .rsc file
  2. factory reset
  3. use quick set (defconf remain)
  4. configure basic stuff like IPv6, Cloud, DoH, disable fasttrack (need use queue), etc
  5. test speed, 2G/1G as expected
  6. reboot
  7. test speed, 2G/1G as expected
  8. backup (just in case)

now edit .rsc file, remove what already exist (sanitize), re arrange line who take precedence, for example: add address list first before add filter/nat that use address list.
hard part like Wireguard, BGP, Routing, Port Forward, etc will be restore via SSH (paste all line)
then I reboot

verify all SD-WAN IPIP/IPIPv6 tunnel works, BGP, Route etc…

Then do speedtest again, this time, no weird speed drop, achieve 2Gbps download and 1Gbps upload on both IPv4/6 with Queue Tree active and fasttrack disabled:
Screenshot 2025-06-10 014633.png
This make me wonder, what inside of .backup file? Contain hidden internal states?