On the point of lease renewals and 2 DHCP servers on the same physical segment...
This is *not* a design flaw of DHCP!! DHCP has no requirement to allow for 2 different DHCP servers serving different functions - serving the same function, certainly, ie providing redundancy - this is in fact a very common configuration on larger networks. Usually with a local DHCP server and a redundant, centralised, remote DHCP server backing it up. It is very easy to configure - all the same scope options except each has only a part of the complete subnet range, not overlapping. This way they collaborate perfectly well, and do not conflict. If one fails, the other can take over seemlessly - just the router needs its DHCPHelper option set so clients can reach the remote DHCP server.
The fly in the ointment here is that both DHCP servers are not serving the same function, LMCE uses DHCP for much more than assigning IP addresses, so this type of configuration doesn't work for us. This isn't a reflection on the design of DHCP!!! It is fine, we are just trying to use it for something very specific which it wasn't designed for.
Also - yes, you can add/extend the DHCP schema however you want, it is already Very large and I would be surprised if you couldn't find a scope option to suit by default, to pass out any info you wanted.
With Lowspirits config, no there is nothing to prevent the real router providing the leases - and it is probably true that it was just luck that nas's, etc were served by the core. As for MDs, they are looking for PXE scope options, so probably ignore the real router's offers because they don't contain them. Both DHCP servers will respond with an offer, it is then up to the client which it chooses. The only way around this would be a packet filter on the real router (tried this on mine, didn't work!) or an ACL on the switch ports (probably requires a layer 3 switch in most cases!)
But once the devices have been "lucky" the first time, the reason this continues has nothing to do with the lease expiration times or the half lease renewal requests. DHCP clients remember their server they received after the first broadcast, and when requesting renewal of a lease direct it straight to that server, not broadcast. So as long as that server stays responsive, they will always get their renewals from it not the real router, and the IP address will remain the same.
On that note - the core also remembers where a device was in its DHCP config file. And will allow a lease to be renewed at the same IP address EVEN IF that IP address is not in the configured subnet scope! This caused me a lot of pain trying to work out why my Windows PC share media was no longer available. Briefly I turned on my router DHCP server and it got an IP address from it, outside the core's DHCP range. I then turned it off again and got my PC to renew again. As it couldn't find the router DHCP server any more it went back to broadcasting and the core responded. But it seems that the PC didn't only broadcast for a new lease, it requested a renewal of the existing IP address. Even though this was outside the core's scope, because it was in the config file it allowed it to keep that address!! No amount of releasing and renewing or rebooting would stop this because even then, the core's DHCP server still remembered this IP and kept giving it out.
Because it is outside the correct range, the core just didn't seem to want to "see" that share and its media any more. I had to manually remove the entry from DHCP3 server's conf file and release/renew - then it got a valid IP in the range and presto the media was back.
I am turning on and off my router's DHCP server regularly as I test my core in VM, so if anybody else is doing this, beware of stray leases screwing up things like this. Because I can't run the VM all the time, I can't switch over permanently to LMCE as DHCP, but once I set up a proper physical core, that's what I will be doing!
What is missing from the design of the standard DHCP protocol is precisely what is a problem for LMCE when there is an existing DHCP server on a LAN into which LMCE is installed. The existing DHCPd must be turned off, or the LMCE DHCPd must be turned off, because there can be only a single DHCP
option set served to a single LAN segment. For redundancy DHCP does have failover directives as a rudimentary interserver protocol, but work on fuller
DHCP interserver operations has not been completed. That is indeed a design flaw, that various people have done some work to correct for over 10 years, though it's not been fixed yet. Largely because failover support has met the needs of the most demanding networks so far. But the recent emergence of UPnP over LANs shows where the current DHCP design is missing that important functionality. But in the meantime if we want LMCE to work with a single NIC, we need to make LMCE work in that environment without DHCP itself supporting that setup.
Starting to use LMCE with a single-NIC machine is going to continue to be a popular option, increasingly so as more people want to try it out without supporting other devices than a simple hybrid, then switch later when they see it's other benefits. And also in general as an appliance. So I'm exploring it, and posting my results.
If other people's own personal preferences don't include that configuration, they're welcome to ignore the efforts, and spend their valuable time doing something else instead that does interest them.
