Mikrotik has a problem with route distances, what did I do wrong?

Question

Computer networks

Good afternoon.
What we have: a Mikrotik router (OS 6.36.3) and two incoming channels: Provider j on the ether2 port and provider M on the ether3 port. It is necessary that in the event of a failure of the channel of one provider, automatic switching to the channel of the second provider occurs. I planned to do it like this: 2 routes with destination 0.0.0.0/0, gateways of each provider and different distances.

With these settings, it is possible to ping 8.8.8.8 through both interfaces.
The essence of the problem: the distance of the first rule is less (channel route j), but the packets start at least through the interface of the M channel. If I change the mask of the second rule from 0.0.0.0/1 to 0.0.0.0/0 and change the distance value to 10 and try to ping the address 8.8.8.8, then the following messages are received from the provider:
ARP, Request who-has 19x.x.x7.7 tell 19x.x.x7.1, length 28
ARP, Request who-has 8.8.8.8 tell 19x.x.x7.2, length 46
ARP, Request who-has 19x.x.x7.7 tell 19x.x.x7.1, length 28
ARP, Request who-has 8.8.8.8 tell 19x.x.x7.2, length 46
Mikrotik address on provider port M - 19x.x.x7 .2/28, gateway 19x.x.x7.1.
What could be the problem?

Answer 1

your task is solved in a completely different way, catch the solution https://www.vasilevkirill.com/MikroTik/1/

Answer 2

Route selection priority is given first to the larger mask, and then to the admin. distances. Therefore, your channel M with a mask / 1 was more priority, despite the smaller distance.

Answer 3

The essence of the problem was in Incomprehensible ARP requests when specifying the destination of the route 0.0.0.0/0 and the availability of the provider's gateway (the gateway was pinged). It seemed that instead of transmitting packets through the gateway specified in the route rule, Mikrotik began to work like the entire external Internet was connected to it locally in one broadcast domain. At the same time, the rule with a smaller distance in the Ip Route table was simply ignored.
The problem "passed" after installing OS version 6.23 and setting up Ip Route rules again.