Last few days I am struggling with creation of bonded link of combined throughput, that has as slave wifi 5G and powerline cable. According to information here, I am trying to include wifi using EoIP tunnel, but it is not working properly, especially EoIP seems doesnt work at all. I am looking for way how to bound it to wifi interface and how to make whole bonding operable. Could you check my setup and advice, what I am missing here ?
First, in your /interface eoip configurations you use local-address and remote-address which are not up on any interface on the machines. So you need to /ip address add address=192.168.2.x/30 interface=wlan2-5g (choose x to match the local-address on the machine where you’re adding that address item). That should make your /interface eoip get up.
Next, what do you expect from the bonding, redundancy or higher throughput? The property of bonding is that it only provides higher summary throughput if you have enough different addresses at both ends of the bonded link; communication between a single pair of IP addresses always takes the same physical link in each direction (unless you configure the bonding for round-robin which causes other headache already with links with much lower transport delay difference than your combination of wired and wireless one).
Thanks for hint about EoIp. After this EoIp started to work as expected.
Regarding bonding I expected higher throughput. I read more about round-robin and this really wont be useful as it is not suited for different link speeds.
Redundancy was my secondary goal, so I set bonding mode to balance-alb as this prioritizing link with more throughput (wireless in my case).
But whole bonding is not working correctly for me. When I put both slave interfaces on both ends up, then I cannot connect to any device on each end. If I change wired connection on one device to different port (not part of slave bond link interface) I am able to connect to both end, but it not desired state, as only wireless link goes through bonding.
Could you advice, what issue could be here ? I suspect some looping inside network.
It doesn’t seem like looping to me, but I am confused by your “can’t connect to anything across the link”.
So first the obvious errors - at each machine, you have attached an IP configuration to the bonding interface which is at the same time a member port of a bridge. This is wrong and causes unexpected behaviour, although I don’t think it explains your particular problem.
Second, you’ve configured link monitoring by setting arp-ip-targets=192.168.1.7 at server and arp-ip-targets=192.168.1.8 at client, but these IPs are not visible anywhere in your configuration; even those assigned to the bonding interface are 192.168.1.4 at client and 192.168.1.5 at server. So I assume the GW on your scheme is the actual DHCP server, and it assigns 192.168.1.7 and 192.168.1.8 to these two Mikrotik boxes via their DHCP clients.
Plus you have a dhcp server and dhcp client both active at the same time on the /interface bridge which is a mere nonsense.
Also the dhcp relay attached to the 2g WLAN interface makes no sense (any may cause some surprises) as the 2G WLAN interface is a member port of the bridge.
So I’d do the following cleanup steps:
remove the statically assigned IP addresses from the /interface bonding at both Mikrotiks
disable the /ip dhcp-server at both Mikrotiks
disable the /ip dhcp-relay at both Mikrotiks
assign the addresses 192.168.1.7 and 192.168.1.8 statically to the /interface bridge of both machines, disable the /ip dhcp-client on both, and exclude the two addresses from the DHCP pool on the GW device. Or use addresses outside the existing DHCP pool instead of the .7 and .8. The point is that when the bond goes down, the dhcp client at Link Slave cannot ever renew the IP address, so the LinkServer will always think it is down if monitoring link state using the IP address
When finished, and if it still doesn’t work when ether1 of both machines are interconnected by cable, I’d set link-monitoring at both /interface bonding to none. You have it on the default value mii, so the arp-ip-targets list should be ignored, but I’m not sure how link-monitoring=mii makes friends with one of the slaves being wireless, so disabling link monitoring completely is a diagnostic step to find out whether it breaks things by making false conclusion about slave link being down while it actually isn’t.
Hi,
Thanks for help how to cleanup setup.
I did everything you suggested (except arp-ip-targets, which simply cannot be defaulted when arp monitoring is off).
I also set monitoring to none, to exclude monitoring as a cause.
Also I copyied dynamic routes to static ones, to be visible. See cleaned setup below.
After all these steps my situation doesnt improve.
It behaves as follows (hope it helps) :
192.168.1.7 ↔ 192.168.1.8 No ping on bonded line (but MAC ping against found devices on this ips working)
192.168.1.8 ↔ 192.168.1.1 No ping between LinkSrv and GW (but MAC ping against found devices on this ips working)
192.168.1.7 ↔ 192.168.1.1 No ping between LinkSlave and GW (but MAC ping against found devices on this ips working)
192.168.1.8 ↔ 192.168.1.15 Ping working for client connected on LinkSrv bonded line side
192.168.1.7 ↔ 192.168.1.15 No ping between LinkSlave and client connected on LinkSrv bonded line side
192.168.1.7 → 192.168.2.1 Ping working from LinkSlave to LinkSrv wireless bond link address
192.168.1.8 → 192.168.2.2 Ping working from LinkSrv to LinkSlave wireless bond link address
No DHCP for wireless 2g clients
Could you please check if you see something that is not right ?
Thanks
