DHCPNAK query
kalyan Alle
kalyan.alle at gmail.com
Fri Mar 19 10:16:39 UTC 2010
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/79d02259/attachment.html>
More information about the dhcp-users
mailing list