I’ve been successfully using the DHCP relay on RouterOS for years over an IPIP tunnel between sites. During this time the DHCP server was a Windows server and it has worked without issue.
I am decommissioning that server and want to move that functionality to the core Mikrotik router. To do this I set up a DHCP server on the router and assigned it to an internal interface since I couldn’t assign it to the IPIP interface. However, it’s not working.
Packet capture on the router with the DHCP server show that the requests are coming in, but the DHCP server is not responding. I assume this has to do with the listener not being on the ingress interface for the requests. The packets also show that the source of the relay requests are the IPIP interface of the relay router.
I know relay requests work through the tunnel since it worked with the windows server.
@CZFan, can you be more specific regarding which line in the manual is the solution? The issue is that neither a dhcp-relay nor a dhcp-server currently seem to be able to listen on an IPIP tunnel interface in particular.
My use case was wilder than this - initially I wanted a DHCP server to listen on an L2TP server interface in order to be able to push a routing table using DHCP option 121 or 249 (the Microsoft way of doing the same) and found out that it is impossble to link a DHCP server or relay directly to an L2TP server static binding or to make it a member port of a bridge on which the DHCP server or relay would be listening. So I tried to redirect the DHCP packets from the client to an IPIP tunnel as a workaround of that, only to find out that it suffers from the same issue.
However, I’ve stopped digging further as soon as I’ve found that Android devices do not send a DHCPINFORM request after establishing an L2TP connection, so even if the solution above would start working, it would only be useful for Windows devices.
DHCP only works on a “broadcast” type interface, like ethernet. You cannot run DHCP on an IPIP interface.
However, you can run a DHCP server on one router, a DHCP relay on another (connected to ethernet), and forward the DHCP request from relay to server over an IPIP tunnel.
In this case you don’t attach the DHCP server to the IPIP tunnel, it is only referenced by the IP of the DHCP server in the DHCP relay, where you can set the remote end address
of the IPIP tunnel.
I have not done DHCP relay in a very, very long time, last time was back in year 2000 and then used Cisco / Microsoft DHCP, I rather config a DHCP server locally then people not affected when tunnel, etc goes down, but assume it could work with something like this. @petchi and @sindy, if I am wrong, please be so kind and chip in
On router 1:
Create another DHCP server, ip pool and network details for subnet 10.200.5.0/x, specify relay option to 10.200.5.1 and attach to ether2.
On router 2:
/ip dhcp-relay add name=Local1-Relay interface=bridgevlan20 dhcp-server=10.0.0.1(remote end address of IP Tunnel) local-address=10.200.5.1 disabled=no
Yes that is correct. The catch is that you MUST have a local ethernet interface for the DHCP server to function, even when you do not desire to use it locally at all.
That is even so for ISC DHCP on Linux. You cannot have a DHCP server that is ONLY a server for relays.
But you can use some dummy interface probably even a bridge with no member ports, with an ADMIN MAC on it (dummy value).
So it looks like your proposed change from my configuration is to set the DHCP-Relay to target the remote end of the tunnel as the DHCP server. Did I miss some other change? In any case, that solution didn’t work. Thanks for the suggestion though.
I’ve gone ahead and switched to an EOIP tunnel and placed the DHCP server directly on the interface and it’s working now. Hopefully this won’t impact the speed of the link significantly.
It is not clear from your original post whether you use the tunnel also for other than DHCP relay traffic. I suppose you do, so of course there is a difference, the EoIP header has 42 bytes while the IPIP header has at least 20, which, as a minimum, means smaller usable MTU on the complete path when you use EoIP. So the question is what means “significantly”.
If the performance impact is unacceptable, you can configure both tunnels in parallel and choose the IP addresses at the ends of the EoIP tunnel in such a way that only DHCP relay requests and DHCP server responses would use the EoIP tunnel, so you wouldn’t even need policy routing to separate the traffic (i.e. you dedicate a small private subnet to the DHCP relay - DHCP server communication).
For the curious ones, the reason why I could not do the same in the scenario I’ve mentioned earlier is that unlike IPIP tunnels, EoIP tunnels use a tunnel identifier which must be unique per device and is common for both directions, so a local EoIP tunnel within a single device cannot be configured.
