- Your current setup doesn’t monitor transparency of the WAN all the way to the internet, which means that in order that the routing would fail over from ISP 1 to ISP 2, the ISP 1 interface must go physically down so that routes via that interface would become inactive. When this happens, there is no active route left in the table to-ISP1, so the routing uses table main as a backup.
See this on how to use a functionality originally intended for a different purpose for a scriptless monitoring of uplink transparency.
2. The two rules matching on per-connection-classifier, whose presumable purpose is to distribute the generic LAN->WAN traffic evenly between the two WANs, have currently no effect - as they match on WAN _in-interface_s, and as each of them matches on another one, each of them just re-assigns the same connection-mark like one of those two right before them for matching connections. If their intended purpose is indeed to distribute the generic traffic, they have to match on in-interface=bridge instead.
3. [quote=“, post:37, topic:130751”]
The problem is that if I don’t disable ether4, the port forward won’t work (outside or on the .36 site).
[/quote]
Here I would assume that it’s because when updating the DDNS (the “ip cloud” functionality), RouterOS has sent the update packet via ether4, so the xxxxxxxx.sn.mynetname.net resolves to the public IP behind ether4, so the phone (or more likely the cloud server of Bria) try to register to that address.
To make RouterOS always send the DDNS update via ether5, you have to add a mangle rule to chain output before those translating connection-mark to routing-mark:
chain=prerouting protocol=udp dst-port=15252 action=mark-connection new-connection-mark=ISP1 passthrough=yes
4. [quote=“, post:36, topic:130751”]
I use Bria because it support push notification when I have an incoming call - so the app can “wake up” from sleep.
…
With ROS6 in Athens, it was working perfectly in both sites.
[/quote]
In order that push notifications about incoming calls worked, the phone app must either register via an external server operated by the app developer that receives the INVITE and sends the push notification via a link to Google/Apple infrastructure before forwarding the INVITE it the phone, or it must provide an https link with some unique identifier in it that the PBX uses, before sending the INVITE, to ask the developer’s server to send the push notification to the phone. To date I don’t know about any VoIP app using the latter approach any more. So I’d assume no matter whether the phone is connected to WiFi in Athens or in Russia, or to LTE, the registrations come from the same IP of the external server.
The reason why it worked in ROS v6 and doesn’t in v7 may be related to different treatment of routes with identical dst-address and distance in the same routing table and with different gateways. In v6, just one of such routes becomes active, and I don’t know the rules determining which one it will be; in v7, all of them are active and used in a round-robin manner (ECMP).