Feature #11957: XMLRPC synchronization for DHCP relay settings - pfSense - pfSense bugtracker

Actions

Copy link

Feature #11957

closed

XMLRPC synchronization for DHCP relay settings

Added by Anonymous over 3 years ago. Updated about 3 years ago.

Status:

Resolved

Priority:

Normal

Assignee:

Viktor Gurov

Category:

XMLRPC

Target version:

2.6.0

Start date:

05/24/2021

Due date:

% Done:

100%

Estimated time:

Plus Target Version:

22.01

Release Notes:

Default

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.

Actions

Copy link

Updated by Viktor Gurov over 3 years ago

Updated by Jim Pingle over 3 years ago

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.

Actions

Copy link

Updated by Viktor Gurov over 3 years ago

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?

Actions

Copy link

Updated by Anonymous over 3 years ago

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.

Actions

Copy link

Updated by Jim Pingle over 3 years ago

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.

Actions

Copy link