<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFCC" text="#000000">
You should monitor the disks, not the log?<br>
<br>
Any system that uses disk space on that particular host needs free
space. The systems I have seen warn when less than 10% free disk
space is remaining, that is the point you should act on - free up
disk space or add new disks. This information is not available in
dhcp-logs but a well designed monitoring system will tell you.<br>
<br>
Once you see the message from dhcp, the disaster is at the door,
knocking.<br>
<br>
<br>
<div class="moz-cite-prefix">On 28/05/13 6:25, Louis Lau wrote:<br>
</div>
<blockquote
cite="mid:E7484DFA00E47E4585B888C5A8D03DDE92B18ED5@nhk-exchange.nhk.nec.com.hk"
type="cite">
<pre wrap="">
Yes agree. This can be monitored by monitoring system with some docuentation. Currently we may use HPOV or other monitoring script to monitor the DHCP log. But the output must match exactly or otherwise too many alarm will be triggered.
We noted that there are subscription service of ISC DHCP, would this cover the documentation for the monitoring part?
And also we want to know are there any application level fault the failover mechanism could handle. We have currently just know that if node down or communication down, the failover will kick in. not sure about what other condition would kick in the failover.
Louis Lau
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:dhcp-users-bounces+louis_lau=nechk.nec.com.hk@lists.isc.org">dhcp-users-bounces+louis_lau=nechk.nec.com.hk@lists.isc.org</a> [<a class="moz-txt-link-freetext" href="mailto:dhcp-users-bounces+louis_lau=nechk.nec.com.hk@lists.isc.org">mailto:dhcp-users-bounces+louis_lau=nechk.nec.com.hk@lists.isc.org</a>] On Behalf Of Glenn Satchell
Sent: Tuesday, May 28, 2013 12:02 PM
To: Users of ISC DHCP
Subject: Re: DHCP failover - disk full, can not commit to lease file
DHCP is not a monitoring system. Why not use your existing, dedicated monitoring system to detect the failure modes you care about, and get that to trigger failover. This could be simple - turn off the dhcp service, or put it in partner-down mode.
There are many possible scenarios where this would be appropriate, but is this something the dhcp server needs to be able to handle? Is this the best use of available dhcp developer time?
regards,
-glenn
On Tue, May 28, 2013 9:27 am, Doug Barton wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I could make a pretty good argument that "My disk is full and I cannot
write leases" would be something that should trigger failover.
Doug
On 05/27/2013 03:56 PM, Steven Carr wrote:
</pre>
<blockquote type="cite">
<pre wrap="">No, your disk is full (and you risk more issues than just DHCP
problems), DHCPD needs to be able to write the lease information to
disk, without that that it will not function. The DHCP failover
protocol does not take into account the resources on the local system
when assigning DHCP leases, it assumes your resources are adequate
enough for the job.
On 27 May 2013 19:53, Louis Lau <a class="moz-txt-link-rfc2396E" href="mailto:Louis_Lau@nechk.nec.com.hk"><Louis_Lau@nechk.nec.com.hk></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Dear all,
I have two DHCP servers configured as failover peer and the router
relay the DHCP/Bootp request to both server. When the system works
normaly, a DHCP discover from client will be broadcast to both
server and the observed behavour is that both server will offer an
DHCP OFFER to the same client, The primary DHCP server shall reply
an IP-A managed by the Primary, and the Secondary shall reply an
IP-B that is managed by the secondary. Assume the client select IP-A
and send an DHCP Request for IP-A to both server.
However recently, primary server disk is full, and in the log there
are a lot of
ommit_leases: unable to commit: No space left on device
We observed that the DHCP does not failover to the secondary in this
case, and the primary will still response to DHCPDISCOVER and
provide a DHCP Offer. And in this case, we observed that most
client does not try the DHCP offer from secondary but most of them
choose the IP assigned from the Primary DHCP server.
Is this behaviour normal?
Are there any configuration that can make the server fail to
secondary DHCP server for similar case or let the client try the
other DHCP OFFER when the first DHCP IP does not have a ACK?
Thanks for your help on this matter.
Louis Lau
</pre>
</blockquote>
</blockquote>
<pre wrap="">
_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
</pre>
</blockquote>
<pre wrap="">
_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
_______________________________________________
dhcp-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Best regards
Sten Carlsen
No improvements come from shouting:
"MALE BOVINE MANURE!!!"
</pre>
</body>
</html>