My cellular link is at less than 100Mbps provided by a Mikrotik RBLDFR LTE, so I use the router's POE 10 port.
This is essentially what I suggested in my first reply: keep using the 2011 for now, but segregate the slow equipment from the fast, taking advantage of the router's internal design rather than fighting it.
Upgrading to a better router should help measurably, but in these supply-constrained times, you might be better off running on the 2011 for some months until a better unit becomes available.
Realize that with the 2011, there's a single 1G link between the 100M side of the network and the 1G side, and it runs through the CPU. You need to budget for this during failover: if you have firewall rules and queues and such that take up 90% of the CPU while running on the primary ISP, the system may fail entirely when you switch over to the backup network because there isn't enough CPU power left to shuttle traffic from the 1G side over to the 100M side.
That's a "maybe." Reducing speeds from 1G to 100M will drop CPU usage, so it might end up okay.
Point is, test; don't guess and pray!
I do not use BONDING but simply two prioritized routes (Fiber 1 / Cellular 2).
That appears to be
the solution from the docs I pointed you to.
Its failover behavior depends on the fact that the host you ping is diagnostic of link failure. If the local gateway stays up through that condition, it won't fail over at all, because it fools the router into thinking everything is fine. You might want to adjust the check-gateway target to point at something on the other side of the link that reliably pings only when the link is up, such as an intermediary router inside your ISP's network.
You can use "/tool/traceroute" to find potential candidates.
Beware changing it to a host that both sides of the network can ping. (Anti-example: 8.8.8.8.) That's diagnostic of nothing. Each link has to ping a host that's only available through that link if it's to fail over reliably.
6 to 9 for the DMZ.
DMZ design is old-school thinking associated with weak firewall technologies. (e.g. Low-spec ISP-provided modem/router combos.) With RouterOS, you have a modern platform with a strong firewall. Given those resources, exposing whole hosts to the Internet is lazy and reckless.
Port-forwarding is better for exposing single services hosted within a protected LAN.
If you must expose whole hosts naked to the Internet, rent some cloud service somewhere. I run dozens of public services on my $5/month VPS, for example. That way, if the VPS is ever compromised, it doesn't compromise your private LAN.
add name=Bridge-Gb
add name=Bridge-Mb
I wouldn't name the bridges after their speeds. Speeds change. Name them after their function: bridge-pri and bridge-sec, for example, being primary and secondary. Or, bridge-main and bridge-backup, or anything else, so long as it refers to permanent functional differences.
/interface ethernet
set [ find default-name=ether1 ] name=ETH01-Fiber rx-flow-control=auto \
tx-flow-control=auto
I don't rename the low-level Ethernet interfaces like this. I leave them at their default names, but then use "comment" lines up at the bridge level to mark which interface is which. Human names should be high-level things, not pushed so far down into the config.
This is a matter of taste. I won't be offended if you disagree. Consider it, then decide.
/interface list
add include=all name=WAN-ISP
I think you need to drop the "include=all" bit. That's something you normally do for the LAN in a configuration like this. Consider this alternative:
/interface list
add name=WAN-ISP include=ether1,ether10
add name=LAN include=all exclude=WAN-ISP
/ip pool
add name=dhcp_pool0 ranges=10.0.0.1-10.0.0.253
You've reserved only one static IP in each range. I normally reserve more. Indeed, I don't see how you can't get away with less than 2 reserved static IPs in this configuration. (We'll come back to that later.) A common scheme is to start the DHCP range at .10 and go to .254, leaving all single-digit final-octet IPs as static. If you want to put all static services way up at the top of the range, then I'd reserve at least .250-254.
If you ignore my advice above and continue with your DMZ plans, you need static IPs for those hosts if routing rules are to work properly. If you take my advice and switch to port-forwarding, you
still need static IPs for them.
The only exception I'd put on this advice is if you create
static leases for certain hosts, so they always get the same IP.
/ip route
add disabled=no distance=1 dst-address=192.168.10.254/24 gateway=192.168.10.254 \
pref-src=0.0.0.0 routing-table=main scope=30 suppress-hw-offload=no \
target-scope=10 vrf-interface=ETH01-Fiber
add disabled=no distance=1 dst-address=192.168.20.254/24 gateway=192.168.20.254 \
pref-src=0.0.0.0 routing-table=main scope=30 suppress-hw-offload=no \
target-scope=10 vrf-interface=ETH10-Cellular
I see no reason at all to define two more subnets here. I believe it will work, but it's pointlessly overcomplicated.
It's simpler if the fiber and cellular router/modem combos have their local interface in the 10.0.x.0/24 side of the network they serve. So, if ether1 continues as 10.0.0.254, the fiber modem can be 10.0.0.253. Now you don't need explicit routes to get packets to the gateway: you just set 10.0.0.253 as the gateway for that subnet, and let RouterOS create a dynamic route for it automatically.
Same with the celluar side: gateway 10.0.10.253.