zero free leases
jw354 at cornell.edu
Mon Jul 2 18:03:17 UTC 2007
On Jul 1, 2007, at 11:02 PM, Koichi Mori wrote:
> John Wobus <jw354 at cornell.edu> wrote
> in article Re: zero free leases
> at Fri, 29 Jun 2007 13:37:18 -0400
>> DHCP failover is designed to avoid at all costs making IP address
>> allocation mistakes,
>> What these limitations prevent the failover protocol and ISC software
>> from doing is providing a service that makes full use of available IP
>> addresses even through server failures, simply by turning on failover
>> in the
>> configuration, and with no intervention or server testing on your
> Thank you for detailed explanation.
> (sorry to late reply, I am not so good at english)
> I know I have to restore the system as soon possible when the system be
> It depends on the case, unfortunately I need the much time for
> restore the system.
> The better way is DHCP configuration would be chane to with out
> So I have to get ready "failover configuration file" and "no failover
> configuration file" for trouble?
> Then they will exchange the files when the peer partner be down?
> Becase, DHCP server can not change sate FREE while peer partner be down
> when I still use failover.
> (This case is needs the time so much for repaire)
Make sure you distinguish between the Partner Down state and
the Communication Interrupted state when you discuss this issue and
work out your plans.
To plan for surviving an outage of a certain length (e.g. 8 hours)
you must assure each server has enough addresses to
give out through the outage. You need extra addresses to
do this. If someone trained in handling these situations is available,
they can verify the server is actually down and put the
other in Partner Down state, after which the need for extra
addresses is reduced. You also need to keep in mind how the
servers will come out of Partner Down.
If you have server-based tests that you trust to verify the other
down (e.g. you trust ping) you can develop your own script to do the
and put the server in Partner Down. To go this route, it's up to you
to know what
tests are suitable in your environment, to provide the confidence that
these tests are within your "risk budget". A mistake on this part could
make a bad situation far worse.
In some cases, uses of static allocations can eliminate a lot of the
headache. At many sites, doing as much static addressing as practical,
and doing dynamic addressing for what remains reduces the scope of the
problem. A lot depends on exactly what you are doing, how your site
operates, and so forth.
My take on all this is that the knowledge required to handle a DHCP
configuration safely is not really that extensive, but seems to be
what most people, including IT people, focus on every day, and
they generally don't seem to learn it fast or retain it. And folks are
always confident they've retained all the crucial information. To a
the crucial issues are exactly the same as those of any redundant,
system, particularly one that is handing out a resource. Any time you
are given responsibility for such a system, you'd do well to gain a good
understanding of how the basic issues are addressed. When I walk into
electronics store and they see in their inventory that a store across
town has the
TV model I'm looking for and they offer to sell that one to me and
deliver it to me
the same day, they'd better make sure someone at the other store hasn't
just sold the same TV to someone else. If communication between the
is down, well, they have further challenges, and some complications
would be sidestepped if they'd had more stock in each store to begin
More information about the dhcp-users