Fred Wright wrote:
> On Thu, 24 Jun 2004, Adam Nellemann wrote:
>>I'm not quite following the other discussion in this thread. What is
>>the need for a lease/mapping that survives a reboot (or more
>>correctly, a crash)? And isn't this what the static mappings are for
>>(they should certainly survive any kind of crash, altough the lease
>>would still have to be renewed I guess, but again I don't see the harm
> It insures that existing access isn't killed by the loss of the lease.
> Without persistent mappings, the reincarnated server may reassign an
> address to a different client, resulting in two clients with the same
Ah, I can see how that could be a problem (a rather big one actually),
I just assumed that the DHCP server, when comming up again, would
start some kind of "discovery" (for want of better a word?) Whereby
all DHCP clients would get a new lease, or some similar way of
resolving this particular issue (which could hardly have gone
unnoticed when the DHCP protocol was standardised?)
But of course, that might be exactly what was hinted at when there was
talk about how a DHCP (according to the RFC) ought to behave (ie. it
should try to maintain persistent mappings).
A possible solution (I'm shooting from the hip here):
What if m0n0wall were to treat ALL DHCP leases as (semi-)static, in
that once a given host (MAC) was assigned an IP from the dynamic pool,
m0n0wall would create a (semi-permanent) static mapping for it, and
save this to the CF. Then, whenever that host requests an IP, the same
one would be used (regardless of any crashes in the meantime). In case
no more dynamic IPs (that haven't previously been made
"semi-permanent") are available, the oldest, unused, of these
semi-static mappings could be erased. In addition (if at all
necessary) m0n0wall might once in a while (say once a day) "prune" any
semi-static mappings that have not been in use for the period (or some
other reasonable interval).
While not entirely eliminating occasional CF writes (ie. whenever an
unknown/new host requests an IP and, if needed, that one time each day
when "pruning" is done), it should still keep these to a bare minimum
(at least in a great many network configurations, the exception being
one where a lot of "foreign" hosts are continually connected to the
> Sure you can get around this with static mappings, but if you need to make
> all mappings static to make them reliable, then what good are dynamic
> mappings? The intent is that you should only need static mappings for
> machines that need to be accessed as servers (and hence at known IP
> addresses). Of course for maximum reliability you shouldn't use DHCP for
> servers at all, but sometimes the convenience of managing addresses
> centrally outweighs the reliability issue.
This sounds quite reasonable, personally I do things in a three-fold
manner, trying to get the best of both (all?) worlds:
- "Real" (as opposed to smaller, monolithic) servers and hosts needing
a static IP don't use DHCP at all, just plain old static IPs.
- Those "smaller, monolithic" boxen (such as my printserver and my
accesspoint) get a static DHCP mapping.
- The remainding "normal" hosts, without any need for a particular IP,
get a dynamic IP via DHCP. (Although, currently I have no boxen
falling into this category.)
I find this to be a good compromise between easy (central) managing of
IPs (in this case limited to those less important small boxen and the,
so far non-existent, "plain" hosts), and the stability gained with
static IPs for the more important servers (ie. they don't need the
DHCP server, aka. m0n0wall, to be running in order to function on the
LAN), which should of course be kept to a minimum (as they will need
manual reconfiguration in case of changes a subnet change or such).
But then again, what do I know, I'm just running my home network
(albeit a rather complex one at that). I'm sure quite different
considerations are needed for larger, cooporate, networks?