Services: DHCP Server: Failover peer IP
-
I seem to recall that there was a discussion about this earlier but I cant find it now.
The statement for the "Failover peer IP:" seems to be a bit contradictory/confusing.
Leave blank to disable. Enter the interface IP address of the other machine. Machines must be using CARP. Interface's advskew determines whether the DHCPd process is Primary or Secondary. Ensure one machine's advskew<20 (and the other is >20).
It says "Enter the interface IP address of the other machine." From which I infer that it wants the IP address of the interface like the LAN interface on the failover firewall. Fine and dandy.
But then it says "Machines must be using CARP". And talks about Advertising Frequency Skew which is defined on a CARP VIP. Which then makes me think that maybe this needs to be a dedicated CARP VIP for the DHCP server since there could be many CARP VIPs between the two nodes of the CARP cluster.
So now if I do create a dedicated CARP VIP for the DHCP server, then do I put that CARP VIP as the "Failover peer IP". If so then its not technically the "IP address of the other machine". If not then how do I tell the DHCP server to look at the advskew of this CARP VIP that I just created.
Up until now I was using the IP address of the LAN interface as the peer IP on each firewall and both firewalls in the cluster were happy running with peer state of normal. At some point (I don't know when, haven't been paying attention to DHCP server) this broke and now the "My State" on one firewall says "recover" with "Peer State" of unknown-state and on the other firewall says "communications-interrupted" with "Peer State" of normal.
So my questions are:
1. What am I supposed to put for the "Failover peer IP". Do I put the IP address assigned to the LAN interface of the other firewall or create a CARP VIP and use the same CARP VIP on both firewalls as the "Failover peer IP".
2. Why cant I run DHCP Server on both firewalls at the same time and have them share the same DHCP database like it was running before. So what if the client gets two DHCP offers at the same time.
-
Perhaps to understand this better, have a look at the man page to isc-dhcpd, the failover section. Specifically, it
says there, that dhcpd supports only pair-relationships (primary/secondary), there is no support for multiple
failover setups. The two servers talk their own synchronisation protocol on ports 519 and 520 between each other,
and so the only logical deduction is, that they need an invariant address of each other, not some address that is
subject to CARP. pfsense uses the CARP part to decide which of the two firewalls is supposed to be primary, and
which is secondary (dhcpd doesn't include that part in its protocol).1. What am I supposed to put for the "Failover peer IP". Do I put the IP address assigned to the LAN interface of the other firewall or create a CARP VIP and use the same CARP VIP on both firewalls as the "Failover peer IP".
The LAN IP of the other box. You also need a CARP interface on that LAN, and this determines which of the two firewalls
is running dhcpd primary, and which is running the secondary instance.2. Why cant I run DHCP Server on both firewalls at the same time and have them share the same DHCP database like it was running before. So what if the client gets two DHCP offers at the same time.
If you did that, some clients would get their offering from server-A, and others from server-B, and they could wind up with the same
IP addresses. Saves you on IP addresses, but doesn't exactly increase reliability :-)
The primary and secondary DHCP servers do work off the same database, but split it in half (at least with the configuration
generated by pfsense, which is reasonable IMHO), so the primary is handing out addresses
from one part, and the secondary from the other. There are IMHO bugs in the pfsense dhcp config file code generation at the moment,
so I suggest you have a close look at what is generated for each of your firewalls afterwards. The config file is in /var/dhcpd/etc/dhcpd.conf.Specifically check that your primary (your CARP MASTER) has a "failover peer" section with "primary" in it, and your secondary (your
CARP BACKUP) has "failover peer" "secondary". According to man dhcpd.conf, the primary must contain an "mclt" statement and
should contain a "split" statement. The secondary may not contain an "mclt" statement, and may contain a "split" statement. -
Thanks for the info. Both my firewalls are getting configured as secondary.
This commit: https://github.com/pfsense/pfsense/commit/24670866827b4e2d7a4a05baaf6d09ee377ce7cb fixes the problem.
If would be nice to let the admin decide which one of the two firewalls they want to be primary and which one to be secondary. Instead of trying to guess that from the skew on the CARP VIPs.
-
Thanks! I'll give that a try, my current fix looks much uglier :)
Regarding the comment about manual primary/secondary selection: I originally thought the CARP way was
logical, but now that you question it, I agree that it is a bit arbitrary. It does make things easier to
configure for the average setup, but by doing so couples things together that aren't technically
interdependant. So, from my point of view I second that it would be nice to have a manual "primary" and "secondary"
setting, which could be preset using CARP (but that would make the setup process more complicated to
program, I don't know how far pfsense is with ajax stuff). DHCP isn't a "typical" service that flips from primary to
secondary in a failover case. The two services are always active, and in the failover case just also assume the
duties of the peer. This is different to the way CARP or other VIP selection protocols work.Some changes to be considered for 2.2?
-
https://github.com/pfsense/pfsense/commit/24670866827b4e2d7a4a05baaf6d09ee377ce7cb fixes the problem.
This fixed a problem I was seeing were the DHCP server was not updating my dynamic DNS server. The problem was that my two DHCP servers would never enter state normal since both thought they were the secondary server.
-
Yep. That commit should show up in the 2.1-RELEASE. In the mean time the easiest way to install it to have the "System Patches" package installed and have the patch fed to it as https://github.com/pfsense/pfsense/commit/24670866827b4e2d7a4a05baaf6d09ee377ce7cb.patch as jimp pointed out in another thread.
-
Doesn't look like a fix for this problem got included in 2.1-RELEASE. Both nodes of my DHCP clusters are getting setup as Primary now and the patch no longer applies cleanly.
Not to mention this thread got dumped into General Questions when the forum was retired. I guess its time to start another thread on this. –> http://forum.pfsense.org/index.php/topic,66749.0.html
-
Doesn't look like a fix for this problem got included in 2.1-RELEASE.
The patch got reverted since it broke more than it fixed.
https://redmine.pfsense.org/projects/pfsense/repository/revisions/a3d6166bb20a3ff4d6a7ff57290c3e59ce51ded4
-
Might also want to reference my original thread
http://forum.pfsense.org/index.php/topic,66234.0.html
since the backed out patch looks remarkably like the one that was proposed there and where I raised my
concerns as to whether comparing the interface address against $vipent['subnet'] will work (I think it
won't).If possible, the two threads should probably be merged.