Hello dear all.. the Mikrtotik lovers

I've been using Mikrotik and RouterOS for quite some years now.
I've always load-balanced 2 lines (ISPs) up to 5 lines together using almost same configurations, same script, both in RouterOS v6 and v7.

Recently, I did setup a router with 2 (PPPoE), but the traffic keeps going to one line, ignoring the route-mark.
Here is basic configurations export:

Help is more than appreciated..!!

You have only posted the part of the configuration you assume to be related. However, in most cases, the issue you cannot find is typically caused by some part of the configuration you don't expect to be related but it actually is.

But even in this restricted configuration, I can see two mistakes:

• on the two /ip route rows you did post, the gateway set to interface name (which is perfectly OK since the interfaces are L3 ones) and check-gateway is set to ping, which would be allright too if the gateway was set to an IP address but it is wrong in this case where the gateway is an interface. Since RouterOS developers did not anticipate such a misconfiguration, the check-gateway result is "fail" and the routes are not eligible. As a consequence, the traffic falls back to routing table main, in which one of the routes probably has a higher priority (lower value of distance) so it gets all the traffic.
• you assign the connection-mark valuses based on in-interface, but from the point of view of the firewall, the WAN interfaces are pppoe-out1 and pppoe-out2, not the Ethernet ports they are attached to.

I wondered how its been used for many years with such a misconfiguration............
Which leads one to conclude we dont have a complete picture as well.

/export file=anynameyouwish ( minus router serial number, any public WANIP information, keys etc. )

You have only posted the part of the configuration you assume to be related. However, in most cases, the issue you cannot find is typically caused by some part of the configuration you don't expect to be related but it actually is.

Well, indeed.. that was all about it. I removed very other basic stuff like, router identity... etc!

But even in this restricted configuration, I can see two mistakes:

• on the two /ip route rows you did post, the gateway set to interface name (which is perfectly OK since the interfaces are L3 ones) and check-gateway is set to ping, which would be allright too if the gateway was set to an IP address but it is wrong in this case where the gateway is an interface. Since RouterOS developers did not anticipate such a misconfiguration, the check-gateway result is "fail" and the routes are not eligible. As a consequence, the traffic falls back to routing table main, in which one of the routes probably has a higher priority (lower value of distance) so it gets all the traffic.
• you assign the connection-mark valuses based on in-interface, but from the point of view of the firewall, the WAN interfaces are pppoe-out1 and pppoe-out2, not the Ethernet ports they are attached to.

Thanks a ton! really thank you!
Point one, that was really the mistake.. I little-bit altered the configuration from balancing 2 lines coming from regular IP routers, to PPPoE lines.
Hence this piece of glitch was not dropped. Well, mistakes happen
Once I removed the check part, all went as expected.
By the way.. what's the right way to check in case of PPPoE or Interface gateway?!

Regarding the other point, it was a typo I made during post touch-up for easier readability.. but it was set right in the router.

I repeat my gratitude..

I wondered how its been used for many years with such a misconfiguration............
Which leads one to conclude we dont have a complete picture as well.

/export file=anynameyouwish ( minus router serial number, any public WANIP information, keys etc. )

Yes, it's the complete picture, sindy figured it out for me.
Thanks for wondering any way

what's the right way to check in case of PPPoE or Interface gateway?!

It depends on the particular situation.

Like all the other PPP-based tunneling protocols, PPPoE is a stateful tunnel that uses keepalive messages to verify availability of the remote endpoint if no payload traffic is present, so if the connection to your ISP fails for whatever reason (disconnected Ethernet cable at your end, DSL/optical line broken due to ground works in the street, power outage at the ISP, ...), the pppoe-client interface becomes inactive so any routes that use it become ineligible too. So if all your uplink connections are provided by the same RAS at the same ISP, there is no point in checking anything else, because the path from your router to the RAS is monitored by PPPoE itself and the path from that RAS to internet is common for both your uplinks.

If your uplinks are provided by different ISPs operating their own hardware (in many countries, ISPs that are competitors on sales level actually share the infrastructure), or if you've got e.g. an LTE or satellite backup connection for critical traffic, it makes sense to verify the transparency of the path from the ISP to the internet, where "internet" is represented by some addresses that are known to be highly available, often called "canary" addresses (canaries are very sensitive to carbon monoxide so miners used them as biologic gas detectors before electronic ones got invented). You can use netwatch and scripts or the "recursive next hop search" approach to monitor those canary addresses and disable the default routes via affected uplinks. There are tons of topics about both these approaches here on the forum.

what's the right way to check in case of PPPoE or Interface gateway?!

canaries are very sensitive to carbon monoxide so miners used them as biologic gas detectors before electronic ones got invented

Lovely one.. about the canaries..

Thanks a lot sandy, precious information..