<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";
        color:black;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        color:black;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page Section1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=white lang=EN-GB link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Thanks Jane, this is very interesting. It helps. We were running
an ancient release candidate version of 3 point something on NetBSD 3.1.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I figured out why the server’s NAK was broadcast, it was because
the REQUEST had come in from the interface with no “giaddr” set,  that is to
say the REQUEST was logged as:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>DHCPREQUEST on <client IP> from <client MAC> via
e1000g0: lease <client IP> unavailable.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I fail to see how this could have happened as the client is on
192.168.22.0/24 subnet and the server is on 192.168.5.32/29. The router must have
relayed the packet, so why is giaddr missing from the incoming REQUEST? Did the
router forget to put it in there, or did the server lose it? :-)<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>On a test linux PC, I killed off the automatic network manager
and ran “dhclient” manually, repeated the experiment and did not get the
problem. That time the REQUEST was logged as:<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>DHCPREQUEST on <client IP> from <client MAC> via
<router IP>: <client IP> lease unavailable.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>In this case the NAK was seen by the client and it dropped the
dynamic IP and re-DHCPed and picked up the fixed one with no problems. This was
using the ISC “dhclient”.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I think I will repeat the experiments and try with V 3.1.0 as
well, as this problem seems to be in 4.0.0 and 4.1.0 so I assume it is in 4.0.1
as well.<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<div>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>---------------<br>
Barry Dean<br>
Networks Team<br>
http://pcwww.liv.ac.uk/~bvd/<o:p></o:p></span></p>

</div>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>

<div>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>

<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif";color:windowtext'>From:</span></b><span lang=EN-US
style='font-size:10.0pt;font-family:"Tahoma","sans-serif";color:windowtext'>
dhcp-users-bounces@lists.isc.org [mailto:dhcp-users-bounces@lists.isc.org] <b>On
Behalf Of </b>Jane Zuzek<br>
<b>Sent:</b> 20 March 2009 12:37<br>
<b>To:</b> Users of ISC DHCP<br>
<b>Subject:</b> Re: DHCPD Stopping<o:p></o:p></span></p>

</div>

</div>

<p class=MsoNormal><o:p> </o:p></p>

<p class=MsoNormal>I'm sorry I can't offer any solutions, but I'll note that we
experienced similar problems last month when we attempted to upgrade from dhcp
3.1.0 to version 4.1.0 running on Solaris 10.  We ended up reverting to
version 3.1.0 after about 2 days, so I didn't gather a lot of data.  We're
running in a single server environment, with no failover configured.<br>
<br>
We experienced two notable issues:<br>
<br>
1) Assigning a static address to a formerly-dynamic client caused DHCP services
to stop responding, as detailed by Barry.<br>
2) Many statically-defined clients on the same network as the DHCP server could
cause services to hang, simply by a DHCPREQUEST (renew lease).  We found
that these were frequently Macintosh systems, although as I said, we didn't
stay at version 4.1.0 long enough to gather a lot of data.<br>
<br>
When we encountered our problems, the dhcpd daemon would continue to run, but
simply didn't seem to be responding to requests.   At one point, when
the daemon was failing to respond to requests, I noted in the logs that it
rotated out the dhcpd.leases file as part of its normal hourly operation. 
So it was still performing <i>some</i> functions.<br>
<br>
Although I was able to write a script to run through cron to watch for DHCP
services becoming unresponsive (ie, watch for lack of updates to the dhcpd.log
file) and programmatically restart services, this didn't resolve the problem of
formerly-dynamic clients picking up newly assigned static addresses.  So
we reverted back to version 3.1.0.<br>
<br>
   Jane Zuzek<br>
<br>
Dean, Barry wrote: <o:p></o:p></p>

<pre>I am still having the occasional problem with DHCP ceasing to answer requests from clients.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>I have traced it to a reproducible situation.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Client (only seen with Linux and HP Printers at the moment) is sitting on a dynamically allocated IP from the pool and all is happy.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>We allocate a fixed IP to the MAC address by editing in a "host {}" entry into the config and restart the master and slave server in the failover pair.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Client does a DHCPREQUEST for the dynamic IP, the server issues a DHCPNAK.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>The client and server are on separate subnets with Cisco 6905E routers doing the dhcp relaying.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>The interesting thing is that I see lots of DHCPNAKs, most do not cause a problem. Looking in the logs the "safe" NAKS look like:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>DHCPNAK on <client IP> to <client MAC> via <router IP><o:p></o:p></pre><pre><o:p> </o:p></pre><pre>But the server stops serving clients as soon as it issues a NAK that is logged as:<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>DHCPNAK on <client IP> to <client MAC> via e1000g0<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>e1000g0 being the interface on the DHCP server (a Sun X4200).<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This looks like DHCPD had broadcast the NAK instead of unicasting it to the router for relaying. The upshot is that the client does not see the NAK and keeps on using the dynamic IP it has.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>This is causing us a bit of trouble at the moment as we have printers and PCs being moved all over the shop and we are losing the DHCP service several times a day.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>What makes the server broadcast the NAK on its own local subnet? How can I stop it? I looks like a client issue, but the server's way of dealing with it is a cause for concern...<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>As the leases on our dynamic pools are 8 days, it can be a while after you issue the fixed address that the server dies. If it happens over a weekend we lose services. Our wireless access points seem particularly sensitive and we have lost wireless everywhere on one occasion. <o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Any ideas, I am getting hassle over this! Any help much appreciated.<o:p></o:p></pre><pre><o:p> </o:p></pre><pre>Thanks.<o:p></o:p></pre><pre>---------------<o:p></o:p></pre><pre>Barry Dean<o:p></o:p></pre><pre>Networks Team<o:p></o:p></pre><pre>Computing Services Department<o:p></o:p></pre><pre>Tel: 0151 794 5641 (x45641), Web: <a
href="http://pcwww.liv.ac.uk/~bvd/">http://pcwww.liv.ac.uk/~bvd/</a><o:p></o:p></pre><pre>---<o:p></o:p></pre><pre>Nice boy, but about as sharp as a sack of wet mice.<o:p></o:p></pre><pre>                -- Foghorn Leghorn<o:p></o:p></pre><pre><o:p> </o:p></pre><pre><o:p> </o:p></pre><pre>_______________________________________________<o:p></o:p></pre><pre>dhcp-users mailing list<o:p></o:p></pre><pre><a
href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a><o:p></o:p></pre><pre><a
href="https://lists.isc.org/mailman/listinfo/dhcp-users">https://lists.isc.org/mailman/listinfo/dhcp-users</a><o:p></o:p></pre><pre>  <o:p></o:p></pre></div>

</div>

</body>

</html>