In message <21226672.1947.1311207580967.javamail.r...@benjamin.baylink.com>, Jay Ashworth writes: > ----- Original Message ----- > > From: "Jimmy Hess" <mysi...@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: ma...@isc.org _____ NANOG mailing list NANOG@nanog.org https://mailman.nanog.org/mailman/listinfo/nanog
