Project

General

Profile

Actions

Feature #11957

open

XMLRPC synchronization for DHCP relay settings

Added by Guillaume LUCAS 2 months ago. Updated about 1 month ago.

Status:
Feedback
Priority:
Normal
Assignee:
Category:
XMLRPC
Target version:
Start date:
05/24/2021
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
21.09
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 #1

Updated by Viktor Gurov 2 months ago

see also #2593

Actions #2

Updated by Jim Pingle 2 months 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:

  1. 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.
  2. 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.
  3. 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 #3

Updated by Viktor Gurov 2 months 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 #4

Updated by Guillaume LUCAS 2 months 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 #5

Updated by Jim Pingle 2 months 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 #7

Updated by Jim Pingle 2 months ago

  • Status changed from New to Pull Request Review
  • Target version set to 2.6.0
  • Plus Target Version set to 21.09
Actions #8

Updated by Renato Botelho about 1 month ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Viktor Gurov

PR has been merged. Thanks!

Actions #9

Updated by Viktor Gurov about 1 month ago

  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF