Feature #11957
closed
XMLRPC synchronization for DHCP relay settings
Added by Guillaume LUCAS over 3 years ago.
Updated about 3 years ago.
Plus Target Version:
22.01
Description
Configuration synchronization (XMLRPC) does not replicate the configuration of DHCP relay. Why?
In the same kind but with less impact (because I don't modify these settings everyday): conf sync don't replicate general/advanced configuration (general logging options, enable/disable scrub, enable/disable PF, do not display state table without a filter, etc.).
Without that, fresh HA setup requires the utmost attention. Misconfiguration can happen very quickly. Personal example: NFS works when my first XG-1541 is master, not when my secondary pfSense box is master. Why? Scrub disable on first box, enable on secondary box… I have two other personal examples.
- Subject changed from Add dhcp relay, igmpproxy and others to configuration sync to XMLRPC synchronization for DHCP relay settings
- Description updated (diff)
Each issue should be limited in scope to one specific request. I've changed this to refer only to DHCP Relay. Feel free to open a separate feature request for the other items if you wish, but limit the requests to one per issue.
In general, the reasoning behind why XMLRPC does not support synchronization for an area falls into one of the following categories:
- The area is not a good target -- meaning the configuration must or should differ between nodes, and making it identical would pose a problem. This is why things like general/advanced system settings, interfaces, or items which refer to physical interfaces (e.g. VLANs, LAGG) cannot synchronize. In some cases you may think it's safe but for most users it's dangerous or problematic. We have to think about how it would impact tens of thousands of environments, different hardware, and likely user behavior, not just one person's environment or what they might prefer. Preventing foot-shooting is just as important as making things convenient.
- The settings for the feature are not in their own isolated section of config.xml which makes synchronization tricky or non-viable without a lot more work.
- Nobody has gotten around to coding XMLRPC support for the feature.
There are exceptions to that, naturally, but those are the most likely explanations.
It's not possible to bind DHCP Relay daemon to CARP interface.
without this, how to determine which DHCP Relay node is MASTER or BACKUP?
Viktor Gurov wrote:
It's not possible to bind DHCP Relay daemon to CARP interface.
without this, how to determine which DHCP Relay node is MASTER or BACKUP?
Why do you think we need to know which node is master or backup?
I have enabled DHCP relay on my two XG-1541 at the same time and it's work fine. In DHCP standard, an DHCP client can receive more than one offer at the same time, choose one and ack it.
I would not condone running both at once for a variety of reasons. It may appear to function acceptably in your specific case but that does not mean it would act the same for everyone.
That said, it doesn't need to bind to a CARP VIP to track the status of a VIP. It could have a choice for a VIP to track and then be checked during CARP events to see if the service should be stopped or started.
- Status changed from New to Pull Request Review
- Target version set to 2.6.0
- Plus Target Version set to 21.09
- Status changed from Pull Request Review to Feedback
- Assignee set to Viktor Gurov
PR has been merged. Thanks!
- % Done changed from 0 to 100
- Status changed from Feedback to Resolved
Tested in
22.01-DEVELOPMENT (amd64)
built on Wed Oct 13 05:25:11 UTC 2021
FreeBSD 12.2-STABLE
The DHCP Relay settings sync successfully after checking DHCP relay in the High Availability Sync settings. I will mark the ticket resolved.
- Plus Target Version changed from 21.09 to 22.01
Also available in: Atom
PDF
Updated by Viktor Gurov 
Updated by 
Updated by 
Updated by 
Updated by