After updating my home firewall cluster (two ALIX boards) to the i386
snapshot two days ago, I proceeded to try the great new sync feature of
dhcpd. Before, each of the cluster node was running its independent
instance of dhcpd, each dishing out from non-overlapping IP address
ranges, independent of a cluster node being in Master or in Backup state
(currently the cluster is active-passive).
Both nodes have in /etc/rc.conf.local :
dhcpd_flags="-Y vlan20 -y vlan20 vr0" # sync using multicast to
224.0.1.240
and in /etc/pf.conf :
# pfsync
pass log quick on vlan20 proto pfsync keep state (no-sync)
# spmd and dhcpd use multicasts to 224.0.1.240 for their sync
pass log quick on vlan20 proto igmp keep state (no-sync)
While testing dhcpd sync and devising a pf rule for it, looking at
'tcpdump -i vlan20' triggered the following remarks and questions:
a) It might be helpful to document in the SYNCHRONISATION section of
dhcpd(8) that 'proto icmp' is being used. This facilitates the life of
those who must devise an additional pf rule. Symmetrically, the same
would apply to spamd(8).
pfsync(4) states for example: "The protocol is IP protocol 240, PF-
SYNC, and the multicast group used is 224.0.0.240."
b) When dhcpd starts and no /var/db/dhcpd.leases exists, then dhcpd
create an empty lease file. Well, not exactly empty, but there are just
two comment lines in it, which is fine.
However, when a /var/db/dhcpd.leases still holds leases from a previous
session, the starting dhcpd does not clear thoses leases (e.g. leases
are persistent also in my case where an rsny restores the state prior to
reboot to ramdisk from CompactFlash). Nor does it apparently get a bulk
update from the dhcpd instances running on other nodes (which are
supposedly in sync, regardless if in active Master or in passive Backup
state).
pfsync has such a mechanism. Is something similar already in dhcpd's
sync (and spamd's sync), and did I simply miss it? Or is it on the to
do list? I guess it would be at least a nice to have to assert coherent
dhcpd (and spamd) state among the nodes, although dhclient (unlike pf)
can cope also while offered "incoherent" leases...
c) My setup uses the same VLAN for both the multicasts of dhcpd and
spamd (and pfsync as well). Besides potentially different shared keys in
/var/db/dhcpd.key and in /etc/mail/spamd.key, if authentication is used
at all, there is no obvious discriminator to tell the difference between
a dhcpd sync and a spamd sync frame.
Rapid inspection of /usr/src/usr.sbin/dhcpd.(h|c) and
/usr/src/libexec/spamd.(h|c) reveals that apparently the only
differences are
#define DHCPD_SYNC_VERSION 1 in dhcpd.h
#define SPAM_SYNC_VERSION 2 in spamd.h
For situations like mine where both dhcpd and spamd sync over the same
interface, would it be safer/necessary to either add an additional
application protocol flag, or to use different multicast addresses?
I would like to thank the developers for this nice new feature which
simplifies the configuration of the dhcp.conf file on my nodes and makes
them symmetric like most other configuration files in the cluster.
Rolf
