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