Why is windows DHCP server offering reserved IPs and then NAKing its own OFFERs ?

2017-01-13

Question

_{Friday, January 13, 2017 10:05 AM}

Hi,

I have a question regarding how windows DHCP server offers IP addresses to dhcp clients.

What we sometimes observe is that DHCP server OFFERs IP address for which inactive reservation already exists and is registered on DHCP server - and when the client REQUESTs that address DHCP server sends a NAK. Upon further DHCPDISCOVER messages from the same client, DHCP server offers the next IP address (which is also reserved), e.g.: first 10.76.170.82 is offered which is reserved, then 10.76.170.83 is offered and so on until first 'free' IP address exists.

So basicaly, DHCP server is offering reserved IP addresses and then NAKs its own offers. This seems a little bit strange - I would expect DHCP server to see the address is reserved and not offer it to clients with different MAC address.

**My question is this: **what could cause DHCP server to behave this way -- is it expected behaviour for windows DHCP server to offer IP addresses for which reservation exists or is this behaviour caused by some misconfiguration of DHCP server on our part ?

Setup info

DHCP server:

windows server 2012 r2 standard 64 bit
(2 dhcp servers in failover hot-standby mode, only one dhcp server is serving requests)
DHCP Version: 6.3

Client:

- linux machine running centos 7 dhclient.x86_64 12:4.2.5-42.el7.centos.

Relay agent:

- activated on CISCO ASA firewall.

The complete packet exchange is provided bellow.

Should you require any additional info that might help I'll be glad to provide it.

Thank you for your help!
Mario

Recorded DHCP package exchange

Here's the relevant info about server, client and relay agent:

DHCP server IP: 10.76.155.251
DHCP client mac: ae:f5:00:00:00:1a
Relay IP: 10.76.170.1

Here's the packet exchange we observe on the wire:

DHCPDISCOVER sent by the client:
===================================

Frame 33: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Cisco_99:ae:14 (f4:cf:e2:99:ae:14), Dst: Microsof_af:e7:12 (00:15:5d:af:e7:12)
Internet Protocol Version 4, Src: 10.76.170.1 (10.76.170.1), Dst: 10.76.155.251 (10.76.155.251)
User Datagram Protocol, Src Port: 67 (67), Dst Port: 67 (67)
Bootstrap Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 1
Transaction ID: 0xc07e6f09
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 10.76.170.1 (10.76.170.1)
Client MAC address: ae:f5:00:00:00:1a (ae:f5:00:00:00:1a)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
Length: 1
DHCP: Discover (1)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 192.168.10.106 (192.168.10.106)
Option: (12) Host Name
Length: 14
Host Name: myclienthost
Option: (55) Parameter Request List
Length: 13
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (2) Time Offset
Parameter Request List Item: (121) Classless Static Route
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (12) Host Name
Parameter Request List Item: (40) Network Information Service Domain
Parameter Request List Item: (41) Network Information Service Servers
Parameter Request List Item: (42) Network Time Protocol Servers
Parameter Request List Item: (26) Interface MTU
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (3) Router
Option: (255) End
Option End: 255
Padding: 00000000000000000000000000000000000000

DHCPOFFER sent by the server (server offers 10.76.170.82 for which reservation exists on server - VM using this IP does not use DHCP, it has statically assigned IP) :
=========================================================================================
Frame 34: 348 bytes on wire (2784 bits), 348 bytes captured (2784 bits) on interface 0
Ethernet II, Src: Microsof_af:e7:12 (00:15:5d:af:e7:12), Dst: Cisco_99:ae:14 (f4:cf:e2:99:ae:14)
Internet Protocol Version 4, Src: 10.76.155.251 (10.76.155.251), Dst: 10.76.170.1 (10.76.170.1)
User Datagram Protocol, Src Port: 67 (67), Dst Port: 67 (67)
Bootstrap Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xc07e6f09
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 10.76.170.82 (10.76.170.82)
Next server IP address: 10.76.155.251 (10.76.155.251)
Relay agent IP address: 10.76.170.1 (10.76.170.1)
Client MAC address: ae:f5:00:00:00:1a (ae:f5:00:00:00:1a)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Length: 1
DHCP: Offer (2)
Option: (1) Subnet Mask
Length: 4
Subnet Mask: 255.255.255.0 (255.255.255.0)
Option: (58) Renewal Time Value
Length: 4
Renewal Time Value: (1800s) 30 minutes
Option: (59) Rebinding Time Value
Length: 4
Rebinding Time Value: (3150s) 52 minutes, 30 seconds
Option: (51) IP Address Lease Time
Length: 4
IP Address Lease Time: (3600s) 1 hour
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 10.76.155.251 (10.76.155.251)
Option: (15) Domain Name
Length: 14
Domain Name: vuksinec.local
Option: (6) Domain Name Server
Length: 8
Domain Name Server: 10.76.150.100 (10.76.150.100)
Domain Name Server: 10.76.150.101 (10.76.150.101)
Option: (3) Router
Length: 4
Router: 10.76.170.1 (10.76.170.1)
Option: (255) End
Option End: 255
DHCPREQUEST sent by the client to confirm offered IP address
======================================================================
Frame 35: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Cisco_99:ae:14 (f4:cf:e2:99:ae:14), Dst: Microsof_af:e7:12 (00:15:5d:af:e7:12)
Internet Protocol Version 4, Src: 10.76.170.1 (10.76.170.1), Dst: 10.76.155.251 (10.76.155.251)
User Datagram Protocol, Src Port: 67 (67), Dst Port: 67 (67)
Bootstrap Protocol (Request)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 1
Transaction ID: 0xc07e6f09
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 10.76.170.1 (10.76.170.1)
Client MAC address: ae:f5:00:00:00:1a (ae:f5:00:00:00:1a)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Request)
Length: 1
DHCP: Request (3)
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 10.76.155.251 (10.76.155.251)
Option: (50) Requested IP Address
Length: 4
Requested IP Address: 10.76.170.82 (10.76.170.82)
Option: (12) Host Name
Length: 14
Host Name: myclienthost
Option: (55) Parameter Request List
Length: 13
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (2) Time Offset
Parameter Request List Item: (121) Classless Static Route
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (12) Host Name
Parameter Request List Item: (40) Network Information Service Domain
Parameter Request List Item: (41) Network Information Service Servers
Parameter Request List Item: (42) Network Time Protocol Servers
Parameter Request List Item: (26) Interface MTU
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (3) Router
Option: (255) End
Option End: 255
Padding: 00000000000000000000000000
DHCPNAK sent by DHCP server to client
=========================================

Frame 36: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0
Ethernet II, Src: Microsof_af:e7:12 (00:15:5d:af:e7:12), Dst: Cisco_99:ae:14 (f4:cf:e2:99:ae:14)
Internet Protocol Version 4, Src: 10.76.155.251 (10.76.155.251), Dst: 10.76.170.1 (10.76.170.1)
User Datagram Protocol, Src Port: 67 (67), Dst Port: 67 (67)
Bootstrap Protocol (NAK)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0xc07e6f09
Seconds elapsed: 0
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 10.76.170.1 (10.76.170.1)
Client MAC address: ae:f5:00:00:00:1a (ae:f5:00:00:00:1a)
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (NAK)
Length: 1
DHCP: NAK (6)
Option: (54) DHCP Server Identifier
Length: 4
DHCP Server Identifier: 10.76.155.251 (10.76.155.251)
Option: (255) End
Option End: 255
Padding: 000000000000000000000000000000000000000000000000...

All replies (7)

_{Friday, January 13, 2017 10:41 AM | 2 votes}

hi Mario,

by default Microsoft DHCP server will not offer a reserved IP address if the reservation was done correctly on the servers.

let's walk through it step by step:

couple of questions:

- do you face this issue on windows client machines or only linux machines?

- what is IP address 192.168.10.106? any idea why it was requested by the client?

- you mentioned a word "inactive reservation" what do you mean by that?

Thanks Mahmoud

_{Friday, January 13, 2017 12:35 PM}

Hi Mahmoud and thank you for your answer!

- do you face this issue on windows client machines or only linux machines?

We didn't try this with windows clients, we use DHCP only for linux VMs at the moment so I can't say how windows client behaves.

- what is IP address 192.168.10.106? any idea why it was requested by the client?

Yes, we noticed that too - it is because Linux VM image that we use to create the VM has some 'stale' dhcp configuration data left over from when image was created.

That is why client on the first boot sends 192.168.10.106 in DHCPDISCOVER request.

We plan to remove this from the image but this should not affect DCHP dicover flow if I'm not mistaken.

- you mentioned a word "inactive reservation" what do you mean by that?

On the DHCP Server UI under "scope -> Address Leases" I can se a list of client IP addresses with following columns: 'Lease Expiration', 'Type', 'UniqueID', etc.
For VMs which use DHCP to manage their IP under 'Type' it says 'DHCP'.
For VMs which don't have DHCP client activated and have a statically allocated IP address under 'Type' it says 'Reservation (inactive)'.

Also, here's the powershell dump of the DHCP server scope config (I included only mentioned IP addresses of relevant scope for brevity):

$scopes = Get-DhcpServerv4Scope

foreach ($scope in $scopes) {
    Get-DhcpServerv4Lease -ScopeId $scope.ScopeId >> dhcp_lease_dump
    Get-DhcpServerv4Reservation -ScopeId $scope.ScopeId >> dhcp_reservation_dump
} 
dhcp_lease_dump: 
================

IPAddress       ScopeId         ClientId             HostName             AddressState         LeaseExpiryTime                                                                                
                                                                                                                                   
10.76.170.54    10.76.170.0     ae-f5-00-00-00-0d    dhcp-ok-host-54       ActiveReservation                                                                                                   
10.76.170.82    10.76.170.0     00-15-5d-64-3f-10    static-ip-host-82     InactiveReservation                                                                                                 
10.76.170.83    10.76.170.0     00-15-5d-af-17-07    static-ip-host-83     InactiveReservation                                                                                                 
10.76.170.84    10.76.170.0     00-15-5d-64-41-1c    static-ip-host-84     InactiveReservation          


dhcp_reservation_dump
======================

IPAddress            ScopeId              ClientId             Name                 Type                 Description         
                                                                                  
10.76.170.84         10.76.170.0          00-15-5d-64-41-1c    static-ip-host-84    Both                 Reserved for static-ip-host-84
10.76.170.82         10.76.170.0          00-15-5d-64-3f-10    static-ip-host-82    Both                 Reserved for static-ip-host-82
10.76.170.83         10.76.170.0          00-15-5d-af-17-07    static-ip-host-83    Both                 Reserved for static-ip-host-83
10.76.170.54         10.76.170.0          ae-f5-00-00-00-0d    dhcp-ok-host-54      Both                 Reserved for dhcp-ok-host-54

As you said 'by default Microsoft DHCP server will not offer a reserved IP address if the reservation was done correctly on the servers' - I have a couple of questions:

- is there a non-default mode where dhcp server does offer reserver ip addresses - in what case does this happen?

- not sure how can I check if DHCP server is misconfigured - is there a way to maybe turn on additional logging info from which I could see there is a problem in configuration ?

Thanks again,
Mario

P.S.

I forgot to mention that hosts in 10.76.170.0/24 subnet are pingable from DHCP server, so this is one other thing that is not clear to me -- I read in documentation that DHCP server wlll ping first to check if the IP offer candidate is alive in which case it will not offer it. Both .82, .83 IPs are pingable but I am not sure how to check if DHCP server tried to ping those IPs before offering them.

_{Friday, January 13, 2017 1:53 PM | 2 votes}

hi Mario,

let's look into it from different angle:

- if the client whose MAC address is 00-15-5d-64-3f-10 always gets IP address 10.76.170.82 then it means DHCP reservation is working well when looking at the reservation result from client perspective.

- now the process by whoch the DHCP picks free IP address from his pool is actually by numbered order: 1 then 2 then 3 then 4...etc

- from my experience with DHCP .. the implemetned DHCP architecture almost changes with every windows server edition specially that i have seen differencies in protocol options and implementaitons from different vendors like cisco and unix....etc as each dhcp client service could have little differences from windows dhcp client service. so the question of why DHCP offers a reserved IP address and then negative acknowledge it could be an architecture change from previous DHCP implementation, so what i would do is to first verify the behaviour by doing following:

- test the same exact behavior on windows dhco client and see if you get same result or no. meaning to see if dhcp server still offer the reserved IP and then negative acknowledge it or not.

- if you find that the behavior is exact same then most likely this is a by desgin so please let me know so that i can take it with my resources and take it with Microsoft windows team to get an official answer on that.

Thanks

Thanks Mahmoud

_{Friday, January 13, 2017 1:54 PM | 2 votes}

hi Mario,

let's look into it from different angle:

- now the process by whoch the DHCP picks free IP address from his pool is actually by numbered order: 1 then 2 then 3 then 4...etc

- test the same exact behavior on windows dhco client and see if you get same result or no. meaning to see if dhcp server still offer the reserved IP and then negative acknowledge it or not.

Thanks

Thanks Mahmoud

_{Friday, January 20, 2017 2:46 AM | 1 vote}

Hi Mario,

Just want to confirm the current situations.

Please feel free to let us know if you need further assistance.

Best Regards

John

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Tuesday, January 31, 2017 11:54 AM}

Hi,

So here's the latest update.

We diagnosed that IPs in .170 subnet were not pingable (due to firewall setup on the ASA router).

When we allowed ICMP to go though - DHCP tries to ping the IP prior to sending OFFER and that works like expected - if pinged IP is alive DHCP server will not offer it.

After digging through all documents about how to configure windows DHCP server our conclusion is this:

- for static IP configured machines use DHCP exclusion

- for servers that lease IP from DHCP server - use reservations (since that is what we want - IP per mac address to be reserved)

I could not find any explanation in the documentation or on the webs as to why windows DHCP server would sometimes offer reserved IPs which are marked 'inactive' (inactive = reservation created manually for a server which does not use DHCP but has a statically assigned IP). Any pointers where I could find docs explaining this behaviour would be appreciated.

Thank you and regards,

Mario

_{Wednesday, February 1, 2017 9:04 AM}

Hi Mario,

>>which are marked 'inactive' (inactive = reservation created manually for a server which does not use DHCP but has a statically assigned IP).

Please check link below to understand it:

Converting an active lease to a reservation causes the lease to become inactive on Windows Server 2008https://support.microsoft.com/en-sg/help/976160/converting-an-active-lease-to-a-reservation-causes-the-lease-to-become-inactive-on-windows-server-2008

Best Regards

John

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

Share via

Why is windows DHCP server offering reserved IPs and then NAKing its own OFFERs ?

Question

All replies (7)

Additional resources