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.![:)]( "Smile")
Unfortunately I do not have any examples available at the moment so I hope this makes sense without it.
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.
Unfortunately I do not have any examples available at the moment so I hope this makes sense without it.
Statistics: Posted by norpan — Thu Dec 28, 2023 4:26 pm