Feature #12055
closed
Option to disable XMLRPC Sync for Loopback Virtual IPs
Added by Chris Myles almost 3 years ago.
Updated over 1 year ago.
Category:
Virtual IP Addresses
Description
According to this pfSense doc, Loopback IPs are synchronized via XMLRPC because they are only ever active on the local machine and therefore cannot conflict with each other on multiple nods. However, this is not actually true. If you add a loopback IP into routing as a /32 network, it is capable of receiving traffic from any host on the network just like any other address is. I use this model to configure management interfaces for my firewalls so it would be helpful to have an option to disable XMLRPC sync for specific virtual IPs so that they don't conflict.
Files
- Status changed from New to Feedback
While it is capable of receiving traffic from another host, nothing could ARP for it, so it can't "conflict" as other VIP types could (IP alias on a regular interface, CARP, or proxy ARP). It could be a source of traffic but if that's the problem you can just not choose it as a source on the secondary for whatever daemon you're using it with.
Can you describe in more detail the problem scenario and exactly what sort of conflict you are seeing?
The problem is that when you configure a loopback address, it's considered a directly connected network and will be advertised by dynamic routing protocols. This makes it a simple yet scalable solution for device management, but it also results in a conflict as both the primary and standby devices will advertise routes for it which makes it impossible to target an individual device. I'm seeking a way to make loopback addresses unique to a particular device in the same way a physical interface address is.
My current workaround has been to disable Virtual IP sync but that also means that CARP addresses are not synced which causes issues when selecting a CARP address in an interface selection dropdown. At the moment I'm using static routing within my network but I'm planning on deploying OSPF which will distribute the loopback address as a /32 route.
Use the features built into the dynamic routing protocols to prevent those addresses from being advertised. That's the purpose of things like route-maps and distribute lists in the OSPF settings near the advertise options.
They should be advertised though as the loopbacks serve as the primary management addresses for their corresponding node. The point I'm getting at is that there are scenarios in which loopback addresses should be able to accept traffic from outside of the device, at which point the address must obviously be unique on the network since every IP accessible on a network must be unique to avoid routing conflicts. According to the pfSense documentation I linked, non-loopback IP aliases are not synced between nodes for this exact reason. I'm just asking for that functionality to be extended to loopback addresses through the use of a "disable XMLRPC sync" option.
Then set FRR differently on each node so it only advertises the addresses you want from each node. FRR does not support XMLRPC so there is no problem doing that.
I get what you're after but I don't think it's the right or proper solution for addressing the root cause here.
That seems unnecessarily complex and counter-intuitive. If I go that route then I have a routable IP address on two devices at once and I'm relying on routing config to blacklist the advertisement of the IP that doesn't belong to the device.
It would make more sense to me to either add an option to block XMLRPC sync, or modify XMLRPC sync to not sync routable IP aliases regardless of the interface they live on (i.e. a 127.x address on loopback would sync, but an RFC1918 address would not).
Changing the sync default behavior would be a POLA violation as it would break users who rely on that behavior now.
For how the vast majority of users implement things, it works as-is and there are plenty of users relying on that already.
We could maybe add an option on VIPs to not sync a specific VIP, but like with rules you get into a problem where that lets you have an entry on the primary which differs but it does not protect items on the secondary which will be clobbered by the sync. It's nowhere near as simple as just adding a checkbox.
You have several valid ways to implement the design you have chosen. That you do not like them does not make them less valid.
- Status changed from Feedback to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
