In message <21226672.1947.1311207580967.JavaMail.root@benjamin.baylink.com>, Jay Ashworth writes:
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
Of course, committing to a RAMDISK tricks the DHCP server software. The danger is that if your DHCP server suffers an untimely reboot, you will have no transactionally safe record of the leases issued, when the replacement comes up, or the DHCP server completes its reboot cycle.
As a result, you can generate conflicting IP address assignments, unless you: (a) Have an extremely short max lease duration (which can increase DHCP server load), or (b) Have a policy of pinging before assigning an IP, which limits DHCP server performance and is not fool proof.
I think a lot of this depends on the target audience of your server.
It sounds like he's in a commercial WAN environment, which of course is what those rules were written for. But I can't tell you how many service calls I have to take because of address conflicts on home LANs behind consumer routers... which don't generally cache the assignments at all, IME.
What I hate is my cable provider re-numbering without winding down the lease time first. Waking up in the morning to a lease that say its still got 18+ hours to go and no net shouldn't happen. If the DHCP server has said the address is good for 24 hours it should be good for 24 hours. I know first level support will say to reboot, which forces a renew which fails, but one shouldn't have to reboot for a renumber event. Run the old and new spaces in parallel for 24 hours. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org