I have two ISPs. I connect to them via two modems and they give ip from the same ip block 192.168.1.xxx. I can make mikrotik connect via two seperate dhcp clients. I can not change the ip blocks. The only setting i can change is the router ip. So i can make router ip different.

I can see that this leads to a clash in wan routing. How do i sort it out?

I have two ISPs. I connect to them via two modems and they give ip from the same ip block 192.168.1.xxx. I can make mikrotik connect via two seperate dhcp clients. I can not change the ip blocks. The only setting i can change is the router ip. So i can make router ip different.

I can see that this leads to a clash in wan routing. How do i sort it out?

First, you're supposed to bridge the modems. Establish PPPoE/WAN/DHCP from the router directly. Why are you putting yourself in a double NAT situation?

Set Modem 1 to 192.168.1.1 and Modem 2 to 2.1 in case you want a manual route to access the admin interface.

See:viewtopic.php?f=2&t=167104&p=820481#p820481 and further down (connection-marks, routing-marks etc) about

@ahmet82, assuming it is not a completely other setup than the one you deal with in your other topic, you'll have to resolve a conflict between the scriptless failover based on recursive next-hop search and the setup recommended by @bpwl where same gateway IP is used on two WANs so you have to configure the routes' gateways as ip.add.re.ss%interface: the recursive next-hop search doesn't work with any routes whose gateways are other than just IP addresses.

I assume that you cannot change the settings of the ISP-provided modem/router devices, so you cannot follow @DarkNate's suggestion - if you could configure those devices, you would be able to change their LAN IP subnet, so this topic would not exist.

Now a bit of theory.

When a route with an IP address indicated as gateway is used, RouterOS takes the IP address of the gateway, finds the smallest one of all the local subnets to which that IP address fits, and chooses the interface to which that subnet is attached as the out-interface. Next, it looks for an ARP record associated to that interface for the gateway's IP address; if no such record is found, it sends an ARP request from that interface, asking whoever has the IP address of the gateway to respond with its MAC address. And lastly, it sends the actual packet from the chosen interface to the MAC address of the gateway. The result of the ARP response is cached for tens of seconds, so the ARP request need not be sent for every packet. So if there already is a record in the "ARP table", the ARP query is not sent, and the record is used immediately.

If the same subnet is attached to two distinct interfaces, the choice of one of them cannot be affected, except by setting the ip.add.re.ss%interface notation, which we cannot use for the reasons above.

The above is the basis for a dirty trick which can be used to make RouterOS select the proper one of the two interfaces although the actual IP address of the modem/router devices is the same in both (i.e. even if you couldn't change even the routers' own addresses).

The starting point is that you have a DHCP client attached to both WANs, A and B, both with add-default-route=no. Enable both clients. Use
:put [/ip dhcp-client get [find interface=wan-A-name] gateway]
to show the IP address of the gateway provided by A, and
:put [/ip dhcp-client get [find interface=wan-B-name] gateway]
to show the one provided by B. I assume both will show the same value, 192.168.1.1, but do check that. Then, disable the dhcp-client for A, and keep the one for B enabled.

Now ping the gateway address shown for B, and then show the ARP record for it:
/ip arp print where address=192.168.1.x
It should return a single row with 0 in the leftmost column. Add a static ARP record for an alias IP address, attached to B:
/ip arp add copy-from=0 address=192.168.1.254.

Now disable also the DHCP client for B, and manually assign addresses from different halves of 192.168.1.0/24 to each of the two interfaces:
/ip address add address=192.168.1.10/25 interface=A
/ip address add address=192.168.1.210/25 interface=B

Add manually the routes for the two WANs as needed; for routes that should use A, set the 192.168.1.1 as gateway; for routes that should use B, set the 192.168.1.254.

That's all. Routes with 192.168.1.254 as gateway will match the 192.168.1.128/25 subnet attached to B, and as the ARP record for the gateway is a static one, they will use it to find the MAC address of the gateway without sending any ARP request. Routes with 192.168.1.1 as gateway will match the 192.168.1.0/25 subnet attached to A, and will use ARP to translate 192.168.1.1 into a MAC address.

I have to ask, what is the purpose of two modems from the same ISP?
If you need more throughput why not ask for a greater throughput single WAN modem, or change providers to get higher throughput.
Finally, there is no redundancy THE MAIN reason for dual WAN, so that when one provider goes down one still has 24/7 access to the net.

I suppose there are situations where there is only one provider and their max output is not enough so they sell you another.........
So the dilemma is that they use an IP in the same subnet, or mor accurately they have the same gateway??

I kinda followed the explanation Sindy, but not knowing dickus about ARP and your IP trickery its a bit greek to me, but in any case very cool.
Dont get how you change the gateway for B into something its not, boggle my mind LOL.

I have to ask, what is the purpose of two modems from the same ISP?

It's not two modems from the same ISP. It's two modems from different ISPs, but both using the same LAN subnet, which the customer cannot change on either of the two modems.

I kinda followed the explanation Sindy, but not knowing dickus about ARP and your IP trickery its a bit greek to me, but in any case very cool.
Dont get how you change the gateway for B into something its not, boggle my mind LOL.

Once I'll learn Spanish, I'll come back and explain it again. I don't know any better way to explain that in English. The two things are tightly related - without understanding the role of translation of gateway's IP address to its MAC address in the process, you cannot understand how I can assign an IP alias to the gateway for B.

Once I'll learn Spanish

Sometimes it hits me that @anav must be a Vogon. ;-)

Please, PLEASE, keep him away from the Haiku thread! No one deserves Vogon poetry.

How does MT in this case handle the reply? Does it pollute ARP cache (with 192.168.1.1 now pointing to B's MAC) or it rather notices it received request through different ether port (and ARP cache is per port?). Or does it simply ignore sender's IP address because dstMAC of ARP response packet is already known (doesn't pollute ARP cache because dstMAC is known and already in the table and everybody is happy)?

ARP cache is per interface, and RouterOS does add records based on incoming ARP requests' source IP addresses. So it does add the translation of the gateway's real IP to its MAC to the ARP table, for that interface, once it receives the ARP request from the gateway asking for Mikrotik's own MAC address via the interface, but since the index columns of the ARP table are the IP address and the interface, not the MAC address, several records with the same MAC address can coexist as long as they differ in IP address and/or interface (the proxy-arp functionality is ony possible due to this). And when Mikrotik wants to send the packet, it uses IP address and interface as search criteria in the query to the ARP table, so the presence of other record(s) with the same interface and MAC address but with a different IP address doesn't interfere.

I have to ask, what is the purpose of two modems from the same ISP?
If you need more throughput why not ask for a greater throughput single WAN modem, or change providers to get higher throughput.
Finally, there is no redundancy THE MAIN reason for dual WAN, so that when one provider goes down one still has 24/7 access to the net.

I suppose there are situations where there is only one provider and their max output is not enough so they sell you another.........
So the dilemma is that they use an IP in the same subnet, or mor accurately they have the same gateway??

I kinda followed the explanation Sindy, but not knowing dickus about ARP and your IP trickery its a bit greek to me, but in any case very cool.
Dont get how you change the gateway for B into something its not, boggle my mind LOL.

Multiple modems to the same ISP. I do that all the time ... in Europe. It has to do with capacity, speed, ISP regulation, price setting, data quota ... etc.

Actually here I was also thinking on this, to connect to those identical cable-modems via NAT : viewtopic.php?f=13&t=165975&p=822492
But I have no problem with outgoing connections and multiple NAT levels (Load-balancers configured with NAT), so LAN subnets are no issue.

Will keep this solution of @Sindy in mind, just in case I eliminate my extra non-MKT load-balancers.

And when Mikrotik wants to send the packet, it uses IP address and interface as search criteria in the query to the ARP table ...

So I'm still confused ...

You just might be MTUNA material after all...............

I'll have to trust you on that.

Don't trust me (I dare to quote 71-Hour Ahmed on that topic: "Ye gods, no! My mother is a D'reg! She would be terribly offended if I trusted her.").

Instead, trust the machine:

formatted code

[me@myTik] > ip arp print where address in 192.168.6.0/24
Flags: X - disabled, I - invalid, H - DHCP, D - dynamic, P - published, C - complete
 #    ADDRESS         MAC-ADDRESS       INTERFACE
 0  C 192.168.6.6     48:8F:5A:BC:14:20 bridge.lte.6
 1 DC 192.168.6.1     48:8F:5A:BC:14:20 bridge.lte.6

When looking at diagrams on packet flow manual page I can't find the box which includes reference to in-interface for outgoing packet (ARP reply). My suspect is connection tracking, but I may be off track.

I don't think there is anything related to ARP handling on those diagrams at all.

The problem in this particular case is that if RB would consider only IP address of sender of ARP request, then it would look for entry matching 192.168.1.1 in ARP cache. There would be two entries, one for routerA and one for routerB, each on corresponding interface. So which one would ROS choose if it wasn't already targeting a particular out-interface? Specially so as routing decission also results in selection of out interface ...

The order of steps matters here. When the routing gets a packet to handle, it first takes the packet's destination address and chooses a route for it by the best matching (longest) dst-address prefix for it. Once the route is chosen, the routing checks its gateway.
If it is an interface (like in case of "connected" subnets), it sends the packet out through that interface; if the interface is an L3 point-to-point one (PPP-like, GRE, IPIP, ...?), it just sends the packet down the pipe; if the interface is an L2 one, it looks for the MAC address using the ARP table subset for that interface first, and triggers and ARP request if the table yields no result.
If the chosen route's gateway is an IP address, it takes similar steps as above, first matching the gateway IP to the subnets attached to all the interfaces, looking for the smallest connected subnet into which the gateway IP fits, and depending on the interface type, it then either sends the original packet out through it or looks for the MAC address for the IP of the gateway. So the ARP record is not used in the search for interface up to the gateway IP.

I was already sure about it, but I had to test it anyway, usually that happens with @anav's questions. :)

It's like this: request comes from interface X => response is sent to interface X.

It makes sense, because why would ARP care about IP routes when it's below IP. Although it would also make sense to have it connected and don't add entries that can't be useful for anything. Like in this case, when IP routing won't be looking for gateway address on one interface, when it thinks it's on another. I didn't study it in detail, but some behaviour seems to be configurable in Linux, see ARP related sysctls:

/proc/sys/net/ipv4/conf/all/(arp_accept|arp_announce|arp_filter|arp_ignore|arp_notify|drop_gratuitous_arp|proxy_arp|proxy_arp_pvlan)

Geez why didnt I think to look it up in my handy Mikrotik for Dummies Handbook, you know the chapter on Everything you wanted to know about ARP but were too drunk to ask!!

why would ARP care about IP routes when it's below IP

@mkx, this is the essence of the answer I would have written if I stayed up so late like you and Sob yesterday. The IP to MAC translation is part of adaptation of the IP layer to the link layer on shared media (point-to-multipoint) interfaces, so an ARP request is only sent when an interface has already been chosen and no record in the ARP table exists for the IP in question. Same for the ARP response which bothers you, IP routing is not used because ARP is not IP. ARP is designed as a generic protocol, allowing to translate any L3 address to an L2 one.

There's another point which was driving me mad some time ago - linux always responds to ARP requests via the interface through which it has received the request, but it responds even if the ARP request contains an IP address attached to another interface. I just can't remember the scenario where this caused the headache back then.