Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My Windows 2003 server standard DHCP server takes 30-45 seconds to give out an IP to XP clients. I've never seen one this slow before. The server is not overwhelmed.

We are on 100 Mbps switches.

Any ideas or suggestions?

share|improve this question

Launch NetworkMonitor or Wireshark and observe the traffic between the client and server. It's likely a network related problem. You could also use Windows Server's Perfmon to watch DHCP statistics in the various stages of the DORA process. Also, check to see if there's another DHCP server on the network, although the symptoms don't sound like what I would expect.

If you want to try blindly twiddling options, you could try restarting the DHCP service to see if that clears things up. You could also rebuild the DHCP database. I'd recommend observing the network traffic and DHCP statistics first.

Is the indexing service or an antivirus client scanning the DHCP directory? If so, that's bad.

share|improve this answer
I would suggest running the capture on the server itself. Look at the time deltas of the incoming and outgoing DHCP packets. If the delay is seen in the capture on the server between the incoming and outgoing packets then it's a server problem and you can focus your investigation there. If the delay is not seen in the capture on the server then it's a network problem. – joeqwerty Jan 13 '10 at 18:09
Great point. Are you stalking me? =) – Wesley Jan 13 '10 at 18:41

Does it take that long just to release/renew on the client or is it only at initial bootup? If it is only taking that long when the client first powers up/connects to the network it might be due to spanning tree protocol operation on the switch. By default STP spends about 15 seconds in each Learning and Listening states before forwarding frames. So the 30 seconds you are seeing may be the client is transmitting discover packets but not seeing an offer until STP has entered the forwarding state and forwards along the next DHCP discover.

share|improve this answer

Had the same problem with a Linux server and a Dell Powerconnect 6224 switch. As Thomas G mentioned above, the problem was related to STP. I solved it by setting the switch ports to "portfast" (but NOT for uplink ports connected to other switches).

This is how to do it on that particular switch. If you have a different switch, it may still give clues to find the setting.

In the 6224 switch CLI, to enable portfast on switch 1, ports 1 to 19:

interface range ethernet 1/g1-1/g19
spanning-tree portfast


In the web configuration, go to Switching -> Spanning Tree -> STP Port Settings and check "Fast Link" for the ports.

You then need to copy the running config. to the saved config. so that it will be used at the next reboot.

share|improve this answer

Packet never lie

You can capture all the data under XP client and analyse them. From which you may find answer.

You can find how much times Broadcast\Discover\Request packets the XP client sending and how long time DHCP server response them.

In a word,in packets world you can find more info than application operation and your sense.

share|improve this answer
packets may not lie but they also may not explain why a server takes X seconds to generate them... – Antitribu Jan 13 '10 at 17:12

protected by sysadmin1138 Aug 1 '11 at 11:44

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?