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
>>      *           (
>>       1) DUT(SU)(DHCP Server)----Ethernet0-----Win XP PC (DHCP Client)
>>       2) Windows 2003 Server ( ----Eth----WIN XP (DHCP
>> Client)*
>>    *
>>    *
>>    *4) Enable the DHCP Server on DUT
>>    5) Make WinXP PC as Client and get the ip address (say
>>    6) Disconnect the DHCP Client PC and connect to windows 2003 Server i.e
>> another
>>    DHCP Server configured on subnet.
>>    7) DHCP Client sends the DHCP request message with the old ip address,
>>    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
>>    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 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
>>               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