Re: high performance open source DHCP solution?

[Mark Andrews <marka () isc org>]

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

_____
NANOG mailing list
NANOG () nanog org
https://mailman.nanog.org/mailman/listinfo/nanog