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!
