DHCPNAK query
kalyan Alle
kalyan.alle at gmail.com
Fri Mar 19 10:51:23 UTC 2010
My conf file is as follows
max-lease-time 86400 ;
subnet 192.168.128.0 netmask 255.255.255.0 {
range 192.168.128.150 192.168.128.160;
option routers 192.168.128.1
default-lease-time 3600;
}
is there any mistake in the conf file.
On Fri, Mar 19, 2010 at 4:16 PM, kalyan Alle <kalyan.alle at gmail.com> wrote:
> 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/b7ef0844/attachment.html>
More information about the dhcp-users
mailing list