DHCPNACK - Client seems to be requesting 0.0.0.0?

Before I begin, I didn't set up any of the network in our system. I would have configured things very differently.

That being said, we have several VLANs, and two Win2008 DHCP servers assigning from different pools on each subnet. The DHCP servers are on a different subnet from most of the clients. The router forwards the DHCP requests to the servers' subnet/VLAN. I suppose the requests are acknowledged by whichever server sees them first.

Anyhow, while I realize that this setup is not ideal, it's been working fine until today, when clients on one VLAN began not getting IP addresses.

On one PC, the system log shows a DHCP error timestamped every second. The message is:

The IP address lease 0.0.0.0 for the Network Card with network address 001EC9... has been denied by the DHCP server 10.1.1.10 (The DHCP Server sent a DHCPNACK message).

The message seems to alternate between the two servers' addresses.

I do not see anything DHCP-related in the event logs on the servers. The workstation's MAC does not appear in the leases on either server. My current workaround has been to assign a static address to any PC that's not getting an address. I've rebooted both servers this morning. In at least one case, a PC had a valid IP address, then lost it after coming back from sleep mode.

The servers run DHCP for 20 VLANs and only one is having this issue. No configurations have changed. I'm stumped.
LSDITAsked:
Who is Participating?
 
Dusan_BajicCommented:
Well you you have something incorrectly on L2 level, your PC shouldn't be able to see both of them in any case.
0
 
John MeggersNetwork ArchitectCommented:
My first question is whether any hosts on that segment are getting an IP address.  I suspect the error message you're getting is not really telling you the PC is requesting 0.0.0.0, but that it's not getting an address, so it can only identify itself as 0.0.0.0.

The architecture you're describing is not unusual, and there's nothing wrong with it, as long as the requests are properly forwarded to the DHCP servers. If no PCs on that segment are getting addresses, I would take a look at the switch or router that segment is connected to and make sure it's still set up to forward DHCP requests. It sounds like you're confident of the DHCP server, so my guess is something has changed on the network side.  In the Cisco world, DHCP relary is done with the "ip helper-address x.x.x.x" command.  Make sure those DHCP relays are being sent out, use Wireshark on a laptop to sniff traffic if necessary, or debug on the router or switch.  Make sure there's still a VLAN interface with an assigned address, that's how the DHCP server will know what pool to hand out an address from, and make sure the router has reachability to the DHCP servers.

I'll see if there's anything else I can think of....
0
 
Rick_O_ShayCommented:
Make sure the servers don't think all of the addresses are leased and there are still some left in the pool. I would think there would be events to that effect on the servers if they were out of address though.

Check for an unauthorized DHCP server on that VLAN that may be causing a problem.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
LSDITAuthor Commented:
I guess what I didn't mention about the network architecture is that we have some VLANs with fewer than five PCs.

First off, I knew that the DHCP requests were being forwarded to the servers, because in the event log errors, it lists the servers' IP addresses. If the requests were timing out or not finding a server, that wouldn't have happened. But I did double-check to verify that the VLAN interface's ip helper-address config hadn't gotten changed somehow.

No PCs on that segment seem to be getting IPs. During my testing, to rule out topology issues, I took a new laptop, connected it to a port on the switch at my desk, set it to VLAN 31 (the vlan in question) and same problem. No IP, and event log errors every second. Changing the switchport to any other VLAN works fine.

The lease pools are not exhausted, that was one of the first things I checked.

I'm not certain that there's not a rogue DHCP server, but the last time I had an issue with that, it was just that clients would sometimes get a 192.168 address instead of a 10.1 address, which obviously wouldn't work. In that case, someone had connected a home router to the network, which I remotely disabled. (Thankfully, someone who would do that is also not savvy enough to change default passwords.)

I guess my next experiment will involve wireshark. I'm not real sure what I'm looking for though.
0
 
LSDITAuthor Commented:
Ok, Wireshark.

Looks like the server gets a 348-DHCP Discover from 10.1.31.1 and replies with a 348-DHCP Offer. But then it immediately gets another 348 from 10.1.35.1 followed by another 344. Then come two back-to-back 373-DHCP requests from 31 and 35, respectively.

No idea where this 35 is coming from. And I never see an ACK or a NACK.
0
 
LSDITAuthor Commented:
Ok, now I'm seeing another transaction, this one has NAK packets.

The following is from one transaction:

Source		Dest		Protocol	Length	Info
------------------------------------------------------------------------
10.1.31.1	255.255.255.255	DHCP		342	DHCP Discover
10.1.1.10	10.1.31.1	DHCP		344	DHCP Offer
10.1.35.1	255.255.255.255	DHCP		342	DHCP Discover
10.1.1.10	10.1.35.1	DHCP		344	DHCP Offer
10.1.31.1	255.255.255.255	DHCP		372	DHCP Request
10.1.1.10	10.1.31.1	DHCP		342	DHCP NAK
10.1.35.1	255.255.255.255	DHCP		372	DHCP Request
10.1.1.10	10.1.35.1	DHCP		342	DHCP NAK

Open in new window

0
 
Dusan_BajicCommented:
run wireshark on client. check the MAC addresses in log to verify that your PC and router on that VLAN are the only two devices exchanging DHCP messages.
0
 
LSDITAuthor Commented:
No, the replies on the 31 and 35 VLANs are coming from different MACs. I'm trying to figure out what switches those are.
0
 
LSDITAuthor Commented:
Oh... They correspond to the virtual interfaces on the main layer-3 switch, vlan31 and vlan35.
0
 
LSDITAuthor Commented:
Yes, I realize that. Also, when running wireshark on the client while on vlan 35, I received a packet that was broadcast to vlan 31.

What would happen if someone connected a cable between a vlan31 port and a vlan 35 port. Could it cause behavior like this?
0
 
Dusan_BajicCommented:
Yes, it could.
0
 
LSDITAuthor Commented:
Got it! That was it!

There was an old cable hanging from the ceiling near a network jack that was patched and set to vlan 35. I think the old cable ran back to an old switch on what is now vlan 31. Some joker plugged it in and has had me racking my brain for two days.

Thanks everyone for the help!
0
 
LSDITAuthor Commented:
Thanks! Got me pointed in the right direction!
0
 
Darr247Commented:
For future use, you might want to install the portable version of wireshark on a USB stick, then you can run it from any windows machine without having to install/uninstall it... just plug the stick in a USB port and use Start->Run... it takes slightly longer to start, but in my opinion it's still better than installing and uninstalling programs unnecessarily on windows machines (or worse yet, installing it and leaving it there for users to play with). The portable version only comes in 32-bit, but about the only thing I've noticed being slightly faster with the 64-bit version is changing view filters on capture files.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.