DHCP Relay in VRF

RouterOS General
1

Hello everyone!

We are having trouble migrating our services from ROSv6 to ROSv7 because we are unable to get the DHCP relay service to work within VRF.

Although this limitation existed in ROSv6, there was a workaround through mange firewall rules (http://forum.mikrotik.com/t/dhcp-relay-in-mpls-vrf/52570/1). However, we couldn’t get it to work on ROSv7. We suspect that changes to the VRF implementation in ROSv7 will prevent the workaround with mangle rules from working.

Has anyone been able to get the DHCP relay to work on VRF in ROSv7?

2

I have done more tests and I have found that using the following mangle rule:

/ip firewall mangle
add action=mark-routing chain=output dst-address=10.10.10.10 dst-port=67 new-routing-mark=VRF1 protocol=udp

DHCPDISCOVER messages are sent to the DHCP server. Also, the DHCPOFFER messages sent by the DHCP server arrive at the DHCP Relay, however they do not seem to be processed and sent to the DHCP Client. I suspect that this is where the difference in behavior in ROSV7 and ROSv7 lies.
Below the relevant configuration:

/ip dhcp-relay
add dhcp-server=10.10.10.10 disabled=no interface=ether2.10 local-address=192.168.1.1 name=dhcp-relay
/ip vrf
add interfaces=ether2.10 name=VRF1
/ip firewall mangle
add action=mark-routing chain=output dst-address=10.10.10.10 dst-port=67 new-routing-mark=VRF1 protocol=udp

The network topology:
Network Topology.png

3

I’m updating the thread in case anyone else is interested in this topic. Support told me that DHCP relay inside VRF is in the “To Do” list. However, they couldn’t give me an ETA.

4

I have discovered the same thing recently.

My conclusion is that since the vrf’s in v7 are totally separated and the response from the DHCP-server (DHCPOFFER) will have a dst-address of an IP-address belonging to the main-table, the old workaround does not behave as in v6.
The dst-address in DHCPOFFER will in your case be looked up only in VRF1 and be routed away if a matching route is found.

I have tried with mangle-rules, nat-rules and route-leaking to work around this but neither worked.
The only idea of a workaround I have so far is if you create a new loopback interface, add it to VRF1 and set the IP-address (/32) of the dst-address in the DHCPOFFER to the loopback.
I have not tested this with dhcp-relay but I made a similar test with ping and it worked. It’s an ugly workaround I know but i might just make dhcp-relay work on a vrf again until dhcp-relay is vrf-aware. :slight_smile:

Unfortunately I do not have any examples available at the moment so I hope this makes sense without it.

5

I searched with no result - Maybe I look in the wrong direction :neutral_face:
Anybody found an “easy” way to add working dhcp relay to vrf-interfaces?

KR

6

https://help.mikrotik.com/docs/display/ROS/DHCP#DHCP-DHCPRelaywithVRF(introducedin7.15)

7

The Mikrotik development team introduced DHCP Relay support in RouterOS 7.15, which is awesome.
However, there remains an important limitation in the implementation of this feature. The DHCP Relay uses the IP address of the egress interface as the source IP address in the packets it generates. This IP address has no significance within the VRF and causes problems in certain cases (for example DHCP servers behind a firewall). Support has told us that they will evaluate adding the functionality of being able to modify this source IP address (similar to what many other manufacturers allow).
Currently, in order to get around this limitation we are using src-nat rules, which forces us to use connection tracking.

8

Finally Mikrotik introduced the functionality of being able to modify this source IP address using the

local-address-as-src-ip

parameter in ROS 7.17.

Thank you Mikrotik for implementing this feature.