Fixed: Not-a-bug: Bug affecting dhcpd failover state

jason0

Hello,

I believe I found a bug.

I am running pfsense 2.4.1-release (amd64) on two fw-7541c lanner firewalls. ( not supported by the pfsense team…I know).

I have verified the config.xml files are nearly identiical (enclosed).

The bug is in the dhpd.conf files on either system. I have also enclosed both files.

Primary dhcpd.conf exerpt:
failover peer "dhcp_lan" { primary; ... split 128; mclt 600; }
failover peer "dhcp_opt2" { secondary; ... }

Secondary dhcpd.conf exerpt:
failover peer "dhcp_lan" { secondary; ... }
failover peer "dhcp_opt2" { secondary; ... }

Note that "secondary" appears in the failover description from the primary system, and also does not include split, or mclt.

With this configuration, no dhcp addresses are handed out by either server on the "dhcp_opt2" aka em4.1002.

In the dhcpd logs on either primary or backup, I see the messages (for the correct interface):

DHCPDISCOVER from xx:yy:zz:aa:bb:cc via em4.1002: peer holds all free leases
DHCPREQUEST for 10.37.56.188 from xx:yy:zz:aa:bb:cc via em4.1002: not responding (recovering)

Otherwise: carp seems to operate correctly.

The symptoms are that no ip addresses are handed out on the guestwifi, and the following appears on the dhcpd.leases status page:

Pool Status

I followed the instructions on https://doc.pfsense.org/index.php/DHCP_Failover_Troubleshooting, and no change occurs.

My work-around is I have removed "dhcp server settings" from the sync-options, removed the peer address from the primary dhcp config for the guest wifi, and disabled the guestwifi dhcp server on the secondary system.

–jason

fw1-primary-config.xml.txt
fw2-secondary-config.xml.txt
fw1-dhcpd.conf.txt
fw2-dhcpd.conf.txt

jimp

The primary/secondary stuff is keyed off the presence of a CARP VIP for the subnet and its skew and so on.

Your VIP for opt2 isn't in the correct subnet, it's 192.168.56.1 when the subnet is 10.37.56.0/24. That's broken in several ways, DHCP is only one of them.

jason0

Wow! Good eye on that one! Thanks!

jason0

So yes, what Jim said is correct: my carp ip address was in a different subnet as the network it was supposed to be on.

I am happy to be wrong!

–jason