high performance open source DHCP solution?
Walter Keen
walter.keen at rainierconnect.net
Wed Jul 20 22:37:44 UTC 2011
We've recently setup ISC DHCPd with failover for lease information, and
LDAP as a configuration source (mostly because of our need for
dynamically adding dhcp reservations for cable modems, etc) -- we don't
have any performance issues thus far, but I'd imagine in a failover
environment, it might be safe to consider a ramdisk for leases.
Obvoiusly breaks RFC2131, but...
Walter Keen
Network Engineer
Rainier Connect
(P) 360-832-4024
(C) 253-302-0194
On 07/20/2011 03:28 PM, Jimmy Hess wrote:
> On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton<ncolton at allophone.net> wrote:
>> We were seeing similar issues with low leases, moved the dhcpd.leases file
>> to a ramdisk and went from ~200 leases per second to something like 8,000
>> leases per second.
> Yes, blame RFC2131's requirement that a DHCP server is to ensure that any
> lease is committed to persistent storage, strictly before a DHCP
> server is allowed to
> send the response to the request; a fully compliant DHCP server with
> sufficient traffic
> is bound by the disk I/O rate of underlying storage backing its database.
>
> I do not recommend use of a RAMDISK; it's safer to bend the rule than break it
> entirely; a safer way is probably to use a storage system on a battery-backed
> NVRAM cache that you configure to ignore SYNC() and lie to the DHCP server
> application, allowing the storage system to aggregate the I/O.
>
>
> 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.
>
> --
> -JH
>
> _____
> NANOG mailing list
> NANOG at nanog.org
> https://mailman.nanog.org/mailman/listinfo/nanog
More information about the NANOG
mailing list