core icon indicating copy to clipboard operation
core copied to clipboard

dhcp/dhcrelay: Make dhcrelay carp-aware

Open AndyX90 opened this issue 7 months ago • 7 comments

This commit adds carp-awareness to the dhcrelay service.

AndyX90 avatar May 24 '25 09:05 AndyX90

Out of curiosity, your problem relates to the monitoring part of the service? For the forwarding part it feels a bit odd trying to stop a service that wouldn't receive any data anyway.

AdSchellevis avatar May 24 '25 13:05 AdSchellevis

Wouldn't a DHCP Discover broadcast be received by any running dhcrelay instance in the same broadcast domain?

Monviech avatar May 24 '25 14:05 Monviech

Totally my mistake, had relayd in my head while reading the PR, for dhcp relay there might be scenario's where you don't want to forward the discoveries indeed.

AdSchellevis avatar May 24 '25 15:05 AdSchellevis

Actually this is ready and working if you only consider the carp functionality. The case which is not covered atm is if you are on carp backup and apply service settings which calls reconfigure. Then it would also start on the backup.

AndyX90 avatar May 25 '25 07:05 AndyX90

it might be good to fix the startup on backup first, but further than that I have no objections.

AdSchellevis avatar May 25 '25 09:05 AdSchellevis

@AdSchellevis I think this is the better approach, as we don't have interfaces to depend on for a single service. It now starts only on configured interfaces which have CARP vips and are in MASTER state. Interfaces where no vips are configured are untouched and start anyway.

AndyX90 avatar May 25 '25 16:05 AndyX90

@AndyX90 maybe we better turn this into a feature request first. There are some questions which lead to design choices in the eventual solution.

If we pin the behavior to the interface combined with having a carp address configured on it, we rule out setups that listen on an interface without one but forward using a interface which maybe in backup state. For this reason other services (openvpn, wireguard) pin the status to the vhid to track. The other option is a "one toggle to rule them all" which flips behavior for the full service, but is less flexible (some plugins do this).

The tracking option is cleaner, but is obviously more work. On my end this isn't at the top of the priority list, but as design choices influence future choices, we should discuss direction before implementation in my opinion, which is why I prefer a ticket in this case.

AdSchellevis avatar May 26 '25 09:05 AdSchellevis

https://forum.opnsense.org/index.php?topic=48131

Monviech avatar Jul 25 '25 13:07 Monviech

@AndyX90 in case you want to test, this https://github.com/opnsense/core/commit/6e7e2a3225c3ad910b9bbfb04a539f25909d1e25 should offer carp vhid tracking per relay, similar to openvpn and wireguard.

AdSchellevis avatar Nov 12 '25 13:11 AdSchellevis