DHCPD failover
-
Hi everyone,
I'm using "2.2-BETA (amd64) built on Fri Sep 19 10:13:16 CDT 2014" NanoBSD, two firewalls in a CARP setup. Config sync is enabled, and it's syncing DHCPD settings as well. For DHCPD failover, I've entered the other firewalls IP address in the field "Failover peer IP". This have been done on both nodes. But I have observed that if I save the DHCPD settings on the primary, it overwrites the "Failover peer IP" on the backup firewall, making it blank. fw1 has the IP address of fw2 for failover peer IP, and fw2 has the IP address of fw1.
If I remember correctly, in pfSense 2.1.* it didn't sync that particulary setting, and was working pretty well.
In addition to the above, when I now view the page "DHCP Leases", the column "My state" says partner-down, and "Peer state" says recover-wait. On the backup node, it's the reverse (when the Failover peer IP has a value). Maybe it's related to the problem above?
Anyone other than me also experience this?
Edit: I just noticed this: https://redmine.pfsense.org/issues/3853. But this was 10 days ago, and it appears to still not be working.
-
I can't replicate any problems with this on current snapshots. The failover IP synchronizes properly and the DHCP pool status shows normal/normal on both.
Ensure you have a CARP VIP defined on the interface and that it's configured for proper master/backup status.
-
Ok, thanks for your reply jimp. I will try to figure it out :)
-
I went through the code for "guess_interface_from_ip($ipaddress)" in interfaces.inc, and may have discovered an issue.
In my setup, the command "/usr/bin/netstat -rnWf inet" doesn't return the entire interface name, it is shortened, like seen below. Actual interface names are for instance em0_vlan1013, em0_vlan1014, em0_vlan1020. This could explain why the fix for 3853 does not work for me.[2.2-BETA][root@fwp01m.tvi.lan]/root: /usr/bin/netstat -rnWf inet Routing tables Internet: Destination Gateway Flags Use Mtu Netif Expire default 84.212.128.1 UGS 20296843 1500 em0_vlan4 10.10.10.0/24 link#16 U 0 1500 em0_vlan11 10.10.10.1 link#16 UHS 0 16384 lo0 10.10.10.1/32 link#16 U 0 1500 em0_vlan11 10.10.10.2 link#16 UHS 0 16384 lo0 public-ip/18 link#6 U 363383 1500 em0_vlan4 public-ip link#6 UHS 0 16384 lo0 127.0.0.1 link#4 UH 9 16384 lo0 172.16.0.0/25 link#21 U 0 1500 em0_vlan11 172.16.0.36 link#21 UHS 0 16384 lo0 172.30.1.0/27 link#7 U 161978532 1500 em0_vlan10 172.30.1.1 link#7 UHS 0 16384 lo0 172.30.1.14 link#7 UHS 0 16384 lo0 172.30.1.32/27 link#8 U 1985150 1500 em0_vlan10 172.30.1.33 link#8 UHS 0 16384 lo0 172.30.1.47 link#8 UHS 0 16384 lo0 172.30.1.64/27 link#9 U 170416797 1500 em0_vlan10 172.30.1.65 link#9 UHS 7 16384 lo0 172.30.1.92 link#9 UHS 2 16384 lo0 172.30.1.96/27 link#17 U 0 1500 em0_vlan10 172.30.1.97 link#17 UHS 0 16384 lo0 172.30.1.98 link#17 UHS 0 16384 lo0 172.30.1.128/27 link#10 U 23912 1500 em0_vlan10 172.30.1.129 link#10 UHS 0 16384 lo0 172.30.1.136 link#10 UHS 0 16384 lo0 172.30.1.160/27 link#11 U 0 1500 em0_vlan10 172.30.1.161 link#11 UHS 0 16384 lo0 172.30.1.167 link#11 UHS 0 16384 lo0 172.30.1.192/27 link#12 U 31869078 1500 em0_vlan10 172.30.1.193 link#12 UHS 0 16384 lo0 172.30.1.197 link#12 UHS 0 16384 lo0 172.30.1.224/27 link#13 U 0 1500 em0_vlan10 172.30.1.225 link#13 UHS 0 16384 lo0 172.30.2.0/27 link#14 U 0 1500 em0_vlan10 172.30.2.1 link#14 UHS 0 16384 lo0 172.30.2.48/28 link#18 U 846084 1500 em0_vlan10 172.30.2.49 link#18 UHS 0 16384 lo0 172.30.2.50 link#18 UHS 0 16384 lo0 172.30.2.132/30 link#15 U 10556 1500 em0_vlan10 -
most things don't parse netstat in that way anymore, but that circumstance is an issue.
https://redmine.pfsense.org/issues/4000
