<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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle20
{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'>Just ran my experiments against version 3.1.2 of DHCPD.<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 see the same symptoms, except the server keeps going.<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'>What it looks like is the client sends a uni-cast DHCPREQUEST to
the server it got its dynamic IP from. The server wants to NAK it as it has a
new fixed IP ready for it. The server can’t be sure it can uni-cast the
response as the IP it is asking for could be from a different subnet (it’s not
in this case, but could be), so broadcasts it. It’s no use though as the NAK
does not reach the client. The difference between versions comes down to:<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'>v 4.0.0<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> One uni-cast REQUEST hits the server, one
broadcast NAK is sent – Server stops. Chaos ensues. Boss comes in to office!<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'>v 3.1.2<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> 8 uni-cast REQUESTS hit the server, 8 broadcast
NAKs are sent – Server still responds.<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'>Then (with v 3.1.2 only as v 4.0.0 has stopped by now!), the
client sends a BROADCAST DHCPREQUEST for the dynamic IP, this is picked up by
the router and relayed, the server now has a relay to direct the NAK at, which
reaches the client, which immediately drops that IP and goes for a DISCOVER and
gets sent its fixed address.<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'>Can we have v 4.* behave like V 3.1.2 please? then boss will not
keep coming in to my office asking “have you fixed it yet!” </span><span
style='font-size:11.0pt;font-family:Wingdings;color:#1F497D'>J</span><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'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I don’t want to have to “downgrade” to v 3.1.2, but may have to.
If I do, anyone got any horror stories of the leases file getting wrecked?
Seemed to work on my test server (7 leases), but nervous about letting it loose
on my production server (25,000 “lease” entries on 2 pairs of servers when I
just checked!).<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>Dean, Barry<br>
<b>Sent:</b> 20 March 2009 13:02<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><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>
</div>
</body>
</html>