Force DHCP expiry
alexm at ndtel.com
Wed Apr 6 17:44:54 UTC 2011
On Apr 5, 2011, at 9:18 AM, Marc Perea wrote:
> Hi Alex,
> we were using option agent.circuit-id, not remote-id, but on
> previous versions to 4.2.0 we had the same problem because dhcpd
> utilizes the mac-address as the primary key in the leases file (or
> the client-id if supplied), which ties up what should be a static IP
> for the duration of the lease. I'm guessing that's the same problem
> for you since you really don't care what MAC is attached to any
> given circuit, since your equipment is trusted to always send option
> 82 and you're attempting to tell dhcpd to use that as its decision
> logic selector. Prior to 4.2.0 our only choice was to script an
> omapi session that would login, select the lease by IP, and then set
> the ends time to 0, and update. I attempted to use the lease state
> instead, but it didn't work for me - could be operator error though.
> Nonetheless, we then tied our provisioning and troubleshooting
> system which knows who a customer is based on a variety of search
> criteria and allowed it to call the script, enabling anyone (help
> desk, NOC, etc.) with access to clear a lease. Not ideal, but not a
> very cumbersome workaround at all.
> 4.2.0 was a game changer for us, though. I don't know how many
> classes you are using (how many customers), but we were in the tens
> of thousands, and dhcpd was taking literally minutes to load since
> all of those classes needed to be initialized and changes can only
> be seen on a kick to dhcpd. Scaling of the 1 class per customer
> configuration is not pretty. ISC was our hero (and still is) for
> implementing host matching based on option agent in 4.2.0. We still
> do 1 host per customer, and each customer is defined as a particular
> circuit-id, so we still need to kick dhcpd to see changes, but dhcpd
> now starts lightning fast again:
> # time /usr/sbin/dhcpd -cf /dhcp/dhcpd.conf -lf /dhcp/dhcpd.leases
> real 0m0.590s
> user 0m0.542s
> sys 0m0.045s
> I don't know what your requirements are for lease retention - we
> have none since we ensure that a customer always gets the same IP -
> because using such a host entry circumvents your lease file writing.
> As static host entries, these customers do not perform a lease
> lifecycle in dhcpd - no problem for us, but something you may want
> to be aware of. This fact also improves performance by a large
> margin. In the past, after an outage scenario (perhaps in the core)
> dhcpd would be hammered with the same tens of thousands of DISCOVERS
> simultaneously and would groan and take hours to completely service
> the entire customer base, extending the outage substantially - now
> due to less writing to disk it's only a few minutes, even if every
> customer is DISCOVER-ing.
> I can't speak highly enough of the option agent host matching;
> thanks ISC!
> dhcp-users mailing list
> dhcp-users at lists.isc.org
I like the idea; however, I don't think that it would work in our
case, as we need to make a decision based on both agent.remote-id and
agent.circuit-id. Unless we can use an identifier that includes all
of that information (is there a valid option that is called
"agent.information"?), as I understand it, the host-identifier option
will only let us select on one or the other.
On another note, it looks like you're just down the road from me...
Nice to meetcha! And thanks for the reply!
More information about the dhcp-users