Project

General

Profile

Actions

Feature #9141

open

FRR xmlrpc

Added by Chris Macmahon over 6 years ago. Updated 14 days ago.

Status:
New
Priority:
Very Low
Assignee:
Category:
FRR
Target version:
-
Start date:
11/21/2018
Due date:
% Done:

0%

Estimated time:
Plus Target Version:

Description

FRR seems to be missing the option to sync the config viar XLMRPC.


Related issues

Has duplicate Feature #11798: HA Sync for FRR configDuplicate04/11/2021

Actions
Actions #1

Updated by Jim Pingle over 6 years ago

  • Priority changed from Normal to Very Low

There is no sync in Quagga or OpenBGPD either.

AFAIR it was done deliberately since in nearly all cases it would be an error to run an identical configuration on two routers running a routing protocol. You'd want separate feeds/connections to neighbors and to work out the failover using priorities/cost/etc in the routing protocols.

It can monitor a CARP VIP for status to stop/start but that's a bit of a kludge.

Might get around to it eventually but it might cause more problems than it fixes.

Actions #2

Updated by Viktor Gurov about 3 years ago

Actions #3

Updated by Mike Moore over 1 year ago

To understand the set up then.

nodeA and nodeB will have sepearate routing neighbors probably exchanging the same route. Selecting nodeA as primary for routing purposes would include as metioned cost/local-pref or whatever it is for the protocol.

Downstream nodeA and nodeB will be in HA with the LAN assuming no dynamic neighbors needed.

If so makes sense just added complexity

Actions #4

Updated by Adrian Dascalu over 1 year ago

In simple setups like mine I believe having the same BGP configuration on both Primary and Secondary members is what is required. The FRR Global configuration already has provision to monitor CARP status of a selected IP (vhid) and run the daemon only on primary.

Actions #5

Updated by Adrian Dascalu about 1 year ago

No progress here obviously, just wanted to add that in the mean time I'm using a workaround: every time i change something on the primary GUI I transfer the raw FRR running config onto the standby cluster (as saved config).

Actions #6

Updated by Mike Moore 8 months ago

Just following up to see if there is any progress.
In theory there isn’t really a good reason to not have the configs sync’s.
The more I thought about it the more nonsensical it is to not have this ability to sync FRR configs. If I am in a HA setup with the same feeds coming in, only one firewall would have the FRR daemon running. This works similarly to PanOs and JUNOS in that the secondary node in standby does not form a routing relationship.

The config sync here should happen. No good reason to not do it

Actions #7

Updated by Mike Moore 6 months ago

Any updates?

Actions #8

Updated by Julien Bennet 2 months ago

also interested on this,

is implementing this feature consists in changing which keys should be merged/copied in xmlrpc.php , and setting them in rc.filter_synchronize ?

Our actual workaround is to backup main pfsense, alter configuration.xml with a script to create secondary config.xml , and restore secondary config on secondary pfsense. Which is a pain if you are working on areas that are not XMLRPC sync'ed

Agreed. No good reason not to sync.

Actions #9

Updated by Mike Moore 2 months ago

Jim - Any hope we can get it implemented? There is a high degree of interest in making our pfsense deployments highly available with the use of FRR.

Actions #10

Updated by Mike Moore about 2 months ago

Any updates on getting config sync moving along?

Actions #11

Updated by Mike Moore 14 days ago

Looking to see if there is an update available? Any hope in getting config sync possible with FRR?

Actions #12

Updated by Julien Bennet 14 days ago

Hello, no updates on my side, I think that unless we come up with a pull request, there's no chance to have a fix on this.
Anyway I don't think I can submit a patch unless someone qualified points me in the right direction.

Actions

Also available in: Atom PDF