Now two lte interfaces are enabled and traffic is visible on the charts. But somehow it works strangely, the sites load with a delay and restart at the beginning. I can’t check the speed on the site yet https://www.speedtest.net/
LATENCY TEST ERROR
Could not connect to the test server. A firewall could be blocking the connection or the server might be having some issues. Please try again later.
Post the complete export. The excerpt you’ve shown above is weird (routes are added twice, with different table names (LTEx vs-LTEx_rout), but /routing/table/add is only shown for the “long” names), so maybe there are some extra rules that interfere with those you’ve shown.
sindy, thank you again for your cooperation!
I wanted to upload the configuration export file, but I don’t know how to attach it.
How post the complete export?
When you edit a post, there are two tabs below the editing window - Options and Attachments. Choose Attachments and press [Add files].
If that does not work (it may require a higher rank on the forum), open the exported configuration in a text editor, select all, Ctrl-C, press the [</>] button above the edit field here, and press Ctrl-V.
Apart from the routes being added twice into the additional routing tables (which is not harmful, just useless), and apart from the mangle rules in chains input and output, which only make sense if the SIM cards provide you with public IPs and thus the Chateau is accessible from the internet, I cannot see anything strange in the load distribution part.
However, only connections via lte1 get src-nated, because your action=src-nat rule matches on out-interface-list=WAN, but currently only lte1 is a member of that list. So /interface list member add list=WAN interface=lte2 should help. What probably happens is that connections directed to lte2 by the per-connection-classifier mangle rules fail due to missing NAT (either the ISP drops the request packets or at least the responses get misrouted in the local environment of the server) and the retry connections come from another port and eventually get sent via lte1.
The /ip dhcp-server network row with address=0.0.0.0/24 is useless too.
I read it and decided to reset all the settings and reinstall everything again.
As I understand it, my SIM cards provide me with internal (gray) IP addresses and I do not need to prescribe the rules of the mangle in the input and output chains, that is, the commands
ip firewall mangle add action=mark-connection chain=input in-interface=lte1 new-connection-mark=con_LTE1
ip firewall mangle add action=mark-connection chain=input in-interface=lte2 new-connection-mark=con_LTE2
ip firewall mangle add action=mark-routing chain=output connection-mark=con_LTE1 new-routing-mark=LTE1_rout
ip firewall mangle add action=mark-routing chain=output connection-mark=con_LTE2 new-routing-mark=LTE2_rout
it is not necessary to enter.
But to connect via lte2, you need to add
/interface list member add list=WAN interface=lte2
sindy
I apologize for the long answer, I tried to figure it out myself. But I haven’t found a solution yet.
That’s the problem
If you use only lte1, then ping passes to google.com .
If lte2, then ping does not pass until google.com
When the lte1 and lte2 are both active, ping does not pass.
There must be some way to configure dns, but I can’t manually make changes through winbox - these fields are not active.
The configuration file contains only the changes I made last time. If I try to add something and it doesn’t work, I roll back.
Pinging google.com from the router
lte1
[admin@MikroTik] > ping google.com
SEQ HOST SIZE TTL TIME STATUS
0 173.194.222.102 56 110 38ms465us
1 173.194.222.102 56 110 42ms117us
2 173.194.222.102 56 110 54ms348us
3 173.194.222.102 56 110 41ms777us
4 173.194.222.102 56 110 44ms964us
5 173.194.222.102 56 110 67ms225us
lte2
[code][admin@MikroTik] > ping google.com
invalid value for argument address:
invalid value of mac-address, mac address required
invalid value for argument ipv6-address
while resolving ip-address: could not get answer from dns server
both
[code] [admin@MikroTik] > ping google.com
SEQ HOST SIZE TTL TIME STATUS
0 216.58.209.174 56 48 54ms57us
1 216.58.209.174 timeout
2 216.58.209.174 timeout
3 216.58.209.174 timeout
4 192.168.0.100 84 64 153ms452us host unreachable
5 216.58.209.174 timeout
6 216.58.209.174 timeout
7 216.58.209.174 timeout
8 192.168.0.100 84 64 126ms267us host unreachable
So you have configured the same default-route-distance for both LTE interfaces (or, better to say, you haven’t changed the default value of 2 for none of them), hence when both are active, default routes via both are added with the same distance value, and the ping packets take “randomly” one of them.
If LTE2 works as such: the first packet of a ping sequence activates a src-nat handling for the whole sequence for the IP adddress of LTE A, so the packets that choose to leave via LTE B may be dropped due to their wrong source address; if they are not, the ISP B applies another src-nat on them and translates their source address to one of its public IPs, but when the response arrives, it gets un-dst-nated back to your WAN A address. And your WAN A address is assigned to someone totally unrelated within ISP B’s network.
Another possibility is that LTE2 doesn’t work at all; to find that out, disable LTE1, and try pinging 8.8.8.8 rather than google.com. If 8.8.8.8 responds but you get that error message for google.com, it means the DNS fqdn->IP number resolution doesn’t work with LTE2. When LTE1 is down, the DNS server list it has provided should be removed from the DNS dynamic configuration, but maybe something else is wrong. Check what :put [/ip dns get dynamic-servers] shows when only LTE1 is enabled, only LTE2 is enabled, and when both are enabled.
Not sure that’s entirely correct, if the distance is same, ECMP is used. For forwarded packets (e.g. LAN to internet) connection tracking will take over, so the first ping packet will go out a “random” LTE interface, but subsequent ping should go out the same LTE interface as the first packet, since connection tracking takes over. Now for internet to router, the same-distance / ECMP routes can cause trouble, so you need packet marks etc on input/output so connections go out the same route them came in.
Saw someplace in configs here that it’s 7.0.4. Don’t know specifically about Chateau LTE12, but for RB5009 (another V7-only device), MT recommend using 7.1.1. Can’t say that “fix” anything automatically, but 7.0.4 is now a pretty old version.