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