Please advise
There is a network
a network bridge is created by points, the point is 192.168.1.100 3 interfaces, eth1 cable, wlan1 is the radio channel, bridge1 – bridge between eth1 and wlan1. And the same scheme in the second point 192.168.1.100.101. Each interface has its own MAC address. The bridge0 interface is selected as the main interfaces of the points creating the bridge. Addresses of points are static.
The problem is that the Central router 192.168.1.1 somehow inexplicably finds MAC addresses of other interfaces (eth1 and wlan1) persistently tries to issue them IP addresses, but at it is impossible since the pool of addresses outside addresses of the bridge, but it does it very often, several times a second that very strongly loads the processor:
WDS on the bridge is enabled in dynamic bridge mode.
ARP tried to include and disable for all interfaces in a row and differently-there is no effect.
You will not prompt that it is possible to make with them that dhcp did not go mad?
Can the points forming the bridge to clean in other subnet or to create for them VLAN?
Not quite sure what to do… Did you mean to set the MAC addresses the same for all interfaces? At the moment, bridge and wlan have the same MAC address, it is specified in the screenshot above (zyxel is trying to give him the IP). but eth has a different mac.
Static IP addresses are used for the access points forming the bridge. Why do I need a DHCP client?
That’s possible. But link works in bridge mode… why the Central router tries to give IP to all mac addresses of a point-it isn’t clear to me… It seems to me that the problem in ARP when I disconnect it on all interfaces, the problem disappears, but because of it the access point from a network disappears and I cannot come on it on IP (only on MAC) and it is not convenient to me since the equipment of the admin remotely through NAT
The only thing which comes to mind is that the wireless link isn’t operating transparently so a device connected at the remote end has its MAC address replaced by one on the SXT Lite so the DHCP offer is sent to the wrong address, although I would expect none of the remote devices to be able to obtain an address if this were the case
This one blocks DHCP offers and DHCP acknowledgements traveling from ether1 towards anywhere else. See description of DHCP operations. Which means that any potential DHCP offers that DHCP server might issue can’t reach clients beyond ether1 of this RB.
My guess: it’s the WDS which screws things (I’m not sure that WDS link is truly transparent on L2). As both devices are Mikrotiks and they are already set up as bridge and bridge-station, the WDS mode shouldn’t be necessary and would be best to switch it off.
![Screenshot_2019-09-26-09-59-42-427_com.mikrotik.android.tikapp[1].png](https://data-discourse.cdn.mikrotik.com/original/3X/9/7/97f3678f0f7c1e0ec4fbd0cbff714f81c45a6798.png)