HI
My DHCP-server is a PR732 and DHCP-relay is a RB750GL. Connection between them is made through two different interfaces. RB750GL reaches PR732 via eth1 and via eth2 (it is because redundancy). RB750GL performs a DHCP-relay where DHCP-server-IP is the one at the eth1 in PR732. DHCP-server in PR732 is bounded to eth1 interface.

The problem arise when first connection (PR732.eth1 <--> RB750GL.eth1) fails. Given second connection is made through eth2 interface and DHCP server runs over eth1 interface, computers connected to RB750GL are not able to get IP. DHCP-server do not answer.

It is possibe to make some trick in order to get this up?

If ether1 is down on the DHCP server, then that IP address is probably inactive.

I suggest that you create a "loopback IP" (to use a Cisco term) on the server, and configure the relay to use the loopback IP.

In Mikrotik terms, you can create a bridge interface and attach no ports to the bridge. Then put a single IP address on the bridge interface (e.g. 10.10.10.1/32). As long as all devices know how to reach 10.10.10.1/32, then the DHCP relay should work.

I don't know whether you are using some dynamic routing protocol on your network, but given the diagram, you are routing IP and not bridging, so I would hope that you're using OSPF to manage your link states. If this is the case, just make sure that 10.10.10.1/32 appears in your OSPF routes.

ZeroByte:
I really appreciate your answer. We have already tryed to set a Loopback interface just creating a bridge without any port. But guess that, DCHP server didn´t work, i.e. it didn´t deliver any IP to DHCP client. It seems that DHCP request "must" enter through the interface where DHCP server is running on.

In the other hand, we are using OSPF as you said. And regarding eth1: it doesn't need to get down in order to make the path unavailable. Let´s suppose a router in the path just break down, or a wireless link has an outage.

Thank you very much for your interest one more time. We didn´t find any solution yet.
Kind regards

Ivan

I am also using OSPF and trying to use a Loopback interface on the DHCP server for DHCP-Relay. However, it does not work for me. If I use the nearest upstream port instead of the Loopback interface the DHCP-Relay works. Has anyone been able to use a Loopback interface on the DHCP Server for DHCP-Relay? If so, can you give me an example?

Thanks,
Bob

I figured out how to do this - it's a little bit strange but seems to work in my lab.

Step1: Create the "loop" address on a standalone bridge interface (and don't connect it to any physical ports)
/interface add name="bridge1"
/ip address add address=10.10.10.1/32 interface=bridge1

Step2: Create the IP Pool
/ip pool add name=Relay1 ranges=192.168.1.10-192.168.1.255

Step3: Create the network
/ip dhcp-server network add address=192.168.1.0/24 gateway=192.168.1.1 dns-server=8.8.8.8

So far, it's all normal, right?
Say your server has 3 interfaces that could reach the relay network: ether1, ether2, and ether3
For each relay network, you would need to add three DHCP servers, all three of which use the same remote pool, relay address, and SRC-ADDRESS set to your "loop" address from step 1.

Step4:
/ip dhcp server add Relay1-ether1 relay=192.168.1.1 address-pool=Relay1 src-address=10.10.10.1 interface=ether1
/ip dhcp server add Relay1-ether2 relay=192.168.1.1 address-pool=Relay1 src-address=10.10.10.1 interface=ether2
/ip dhcp server add Relay1-ether3 relay=192.168.1.1 address-pool=Relay1 src-address=10.10.10.1 interface=ether3

Step5:
On your relay server, set the relay address to the loop address: 10.10.10.1
/ip dhcp-relay add name=LocalRelay1 interface=Local1 dhcp-server=10.10.10.1 local-address=192.168.1.1 disabled=no

Why it doesn't work for just one DHCP server on bridge1:

If you set interface=bridge1 on the DHCP server, the process will never receive the packets. The DHCP daemon is listening for packets coming INTO the Mikrotik from bridge1 (imagine a firewall rule in-interface = bridge1) - however, the packets are not arriving on bridge1, they're arriving on ether1, ether2, or ether3 as the routing protocols determine.... so they're not being passed to the DHCP server.

Creating the three (in this example) DHCP server processes allows the Mikrotik to listen on all interfaces, but to share the single pool of addresses. If you make changes to the parameters/options on the network then it will be the same for all three.

If you make an entry static in the Mikrotik, be sure to remove the specific server from the static entry!


Another solution might be to just create a Metarouter just for running DHCP.

It would be nice for situations like this if you could specify multiple interfaces on a single DHCP server instance.
If I can think of a way to successfully ingress the packets that doesn't involve something even worse than this workaround, then I'll post it here.