Ya i have kept authoritative; at the top of the conf file. Still iam facing the same issue.<br>Plz let mw know if i have to do something else .<br><br>-kalyan<br><br><div class="gmail_quote">On Fri, Mar 19, 2010 at 3:46 PM, kalyan Alle <span dir="ltr"><<a href="mailto:kalyan.alle@gmail.com">kalyan.alle@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I did not try it. <br>I will try putting authoritative at the beginning of the conf file.<br>
<br>thanks glenn.....<div><div></div><div class="h5"><br><br><br><div class="gmail_quote">On Fri, Mar 19, 2010 at 3:40 PM, Glenn Satchell <span dir="ltr"><<a href="mailto:glenn.satchell@uniq.com.au" target="_blank">glenn.satchell@uniq.com.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Have you included the authoritative statement? by default ISC dhcpd is not authoritative. See dhcpd.conf man page, following on from the earlier section already posted:<br>
...<div><br>
If the server knows nothing about the address,<br>
it will remain silent, unless the address is incorrect for<br>
the network segment to which the client has been attached<br>
and the server is authoritative for that network segment, in<br>
which case the server will send a DHCPNAK even though it<br>
doesn't know about the address.<br></div>
...<br>
The authoritative statement<br>
<br>
authoritative;<br>
<br>
not authoritative;<br>
<br>
The DHCP server will normally assume that the configura-<br>
tion information about a given network segment is not<br>
known to be correct and is not authoritative. This is so<br>
that if a naive user installs a DHCP server not fully<br>
understanding how to configure it, it does not send spuri-<br>
ous DHCPNAK messages to clients that have obtained<br>
addresses from a legitimate DHCP server on the network.<br>
<br>
Network administrators setting up authoritative DHCP<br>
servers for their networks should always write authorita-<br>
tive; at the top of their configuration file to indicate<br>
that the DHCP server should send DHCPNAK messages to mis-<br>
configured clients. If this is not done, clients will be<br>
unable to get a correct IP address after changing subnets<br>
until their old lease has expired, which could take quite<br>
a long time.<br>
<br>
regards,<br><font color="#888888">
-glenn</font><div><br>
<br>
On 03/19/10 21:00, kalyan Alle wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div>
The DHCPNAK is sent by the windows DHCP server configured but my device<br>
with ISC dhcp-4.1.0 is unable to send the DHCPNAK.<br>
Plz suggest if this is the expected behaviour or not.<br>
<br>
-kalyan<br>
<br>
On Fri, Mar 19, 2010 at 3:20 PM, kalyan Alle <<a href="mailto:kalyan.alle@gmail.com" target="_blank">kalyan.alle@gmail.com</a><br></div><div>
<mailto:<a href="mailto:kalyan.alle@gmail.com" target="_blank">kalyan.alle@gmail.com</a>>> wrote:<br>
<br>
I have got the issue with the setup as below<br>
<br>
* (169.254.128.132)<br>
1) DUT(SU)(DHCP Server)----Ethernet0-----Win XP PC (DHCP Client)<br>
<br>
2) Windows 2003 Server (192.168.9.2) ----Eth----WIN XP (DHCP Client)*<br>
<br>
*<br>
*<br>
<br>
*4) Enable the DHCP Server on DUT<br>
5) Make WinXP PC as Client and get the ip address (say 169.254.128.10)<br>
6) Disconnect the DHCP Client PC and connect to windows 2003 Server i.e another<br>
<br>
DHCP Server configured on 192.168.9.0 subnet.<br>
7) DHCP Client sends the DHCP request message with the old ip address, DHCP<br>
server ( windows 2003 server) responds with DHCPNAK message and after receiving<br>
DHCPNAK the client restarts the allocation procedure with DHCPDISCOVER message.<br>
<br>
<br>
8) Clients gets ip address from Win server as 192.168.9.100.<br>
9) Disconnect the DHCP Client and reconnect to Mumbai SU/DUT.<br>
10)Again DHCP client sends the DHCP request message to the DHCP server with<br>
assigned ip address which is in 192.168.9.0 subnet to DUT DHCP server.<br>
<br>
<br>
The DUT DHCP server is silent and doesn't send any DHCPNAK message.<br>
<br>
Can any one comment or let me know the solution for this scenario.<br>
<br>
thanks<br>
kalyan*<br>
<br>
<br>
<br>
<br>
<br>
On Fri, Mar 19, 2010 at 12:40 PM, kalyan Alle <<a href="mailto:kalyan.alle@gmail.com" target="_blank">kalyan.alle@gmail.com</a><br></div><div>
<mailto:<a href="mailto:kalyan.alle@gmail.com" target="_blank">kalyan.alle@gmail.com</a>>> wrote:<br>
<br>
Thank you guys for letting me know this is not a bug. It works<br>
as designed.<br>
<br>
<br>
-kalyan<br>
<br>
On Fri, Mar 19, 2010 at 4:50 AM, David W. Hankins<br></div><div><div></div><div>
<<a href="mailto:dhankins@isc.org" target="_blank">dhankins@isc.org</a> <mailto:<a href="mailto:dhankins@isc.org" target="_blank">dhankins@isc.org</a>>> wrote:<br>
<br>
On Thu, Mar 18, 2010 at 08:49:29AM -0700, Friesen, Don<br>
SSBC:EX wrote:<br>
> Note that the NAK will not reach a remote client, the<br>
remote client<br>
> will continue to use the leased address until the lease<br>
expires and it<br>
> is forced to REBIND. Since the address it has is a valid<br>
routable<br>
<br>
REBINDING (or "t2") is scheduled before lease expiration.<br>
Basically<br>
it is the client giving up on the server-identifier'd<br>
server, and<br>
asking for any server to extend its lease before it expires.<br>
<br>
It's true that the server's current strategy for NAK'ing<br>
RENEWING<br>
clients is to send the DHCPNAK to the source interface at<br>
the all ones<br>
limited broadcast, hoping it's a locally attached client<br>
(the server<br>
cannot currently tell). Remote clients won't get that, will<br>
reach<br>
REBINDING, so get picked up by a relay agent which we can<br>
unicast our<br>
DHCPNAK to, and the client gets it by broadcast there.<br>
<br>
<br>
We don't answer RENEWING clients by unicast instead because<br>
I haven't<br>
had the gumption to advance the issue at IETF DHC WG.<br>
<br>
>From RFC 2131 section 4.1 ("Constructing and sending DHCP<br>
messages");<br>
<br>
If 'giaddr' is zero and 'ciaddr' is zero, and the<br>
broadcast bit is<br>
set, then the server broadcasts DHCPOFFER and DHCPACK<br>
messages to<br>
0xffffffff. If the broadcast bit is not set and 'giaddr'<br>
is zero and<br>
'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK<br>
messages to the client's hardware address and 'yiaddr'<br>
address. In<br>
all cases, when 'giaddr' is zero, the server broadcasts<br>
any DHCPNAK<br>
messages to 0xffffffff.<br>
<br>
"In all cases,"...not normative, but very clear.<br>
<br>
The only normative language at all about this is in section 3.2<br>
("Client-server interaction - reusing a previously allocated<br>
network<br>
address");<br>
<br>
If 'giaddr' is 0x0 in the DHCPREQUEST message, the<br>
client is on<br>
the same subnet as the server. The server MUST<br>
broadcast the DHCPNAK message to the 0xffffffff<br>
broadcast address<br>
because the client may not have a correct network<br>
address or subnet<br>
mask, and the client may not be answering ARP requests.<br>
<br>
Although that section is specific to basically the INIT-REBOOT<br>
scenario when a client is reconnecting and broadcasting their<br>
DHCPREQUESTs.<br>
<br>
It's pretty clear the framers of 2131 intended DHCPNAK only<br>
for the<br>
purpose of moving an un-configured client into a valid<br>
address, and<br>
not for ACL/configuration/administrative purposes. Despite<br>
that it's<br>
very useful for same. I say it's very clear because the RFC<br>
says as<br>
much, pretty plainly;<br>
<br>
DHCPNAK - Server to client indicating client's<br>
notion of network<br>
address is incorrect (e.g., client has<br>
moved to new<br>
subnet) or client's lease as expired<br>
<br>
The gist of this system is that once you give a client a<br>
valid lease,<br>
you're making a promise the client can keep that lease for<br>
as long as<br>
you've indicated. In fact, although a proper client will<br>
renew and<br>
then rebind before expiration, it can be said to be valid<br>
behaviour if<br>
a client never contacted the server again and just waited<br>
out the<br>
lease expiration. It would be dumb, but permissible for<br>
that client<br>
to use the lease the whole time until it expires.<br>
<br>
So when migrating systems between address ranges, for<br>
example, it's<br>
best to lower the lease-time sufficiently in advance of<br>
migration to<br>
give the clients a smaller window to migrate.<br>
<br>
Note that in 4.0.0, Christof Chen gave us a neat little<br>
patch that<br>
gives clients an iteratively smaller lease-time the closer they<br>
approach a "cut-over window", after which it refuses to give<br>
the lease<br>
to any client from that range. The client will expire out,<br>
DISCOVER,<br>
get an OFFER from another range, and move on. See the<br>
'allow/deny<br>
after [time];' configuration information in 'man dhcpd.conf'.<br>
<br>
<br>
Still, it would be useful and quicker if the DHCP protocol<br>
allowed<br>
NAK's on renewals. Handy when you're in a tight spot and<br>
forgot to<br>
lower the lease time in advance, or had no warning of the event.<br>
<br>
So it's on my list. It's a very long list tho. Right now<br>
I'm trying<br>
to get DHCPINFORM clarified so we can finally source lease<br>
information<br>
when replying to Windows boxes doing DHCPINFORM's for WPAD -<br>
and give<br>
them the right nameservers scoped with their pool, rather than<br>
switching nameservers to some global config and breaking them.<br>
<br>
--<br>
David W. Hankins BIND 10 needs more DHCP voices.<br>
Software Engineer There just aren't enough in<br>
our heads.<br>
Internet Systems Consortium, Inc. <a href="http://bind10.isc.org/" target="_blank">http://bind10.isc.org/</a><br>
<br>
</div></div></blockquote><div><div></div><div>
_______________________________________________<br>
dhcp-users mailing list<br>
<a href="mailto:dhcp-users@lists.isc.org" target="_blank">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>