Showing results for 
Search instead for 
Did you mean: 

DHCP Problems

Level 1
Level 1

Lately we've been experiencing some issues with DHCP on our network. Clients (Windows 10) will connect, either via Wireless or Ethernet, then might need to wait around for 5-10min before receiving a DHCP address from the server. However, at other times they'll receive the lease immediately. If you configure the address manually, things obviously work fine.

Wireless clients are just bridged to the LAN, and so are communicating with the same server as Ethernet clients, via the same routes. The DHCP server is a virtual machine on another subnet at another physical location, the path to which traverses a few Cisco FTD Firewalls. All of them have been configured with Fastpathing for DHCP traffic, but it has not made a difference to DHCP performance. QoS is configured on both the server's LAN and the clients' various LAN's. STP is not the culprit either, as the link is up, and wireless clients are also affected.

I performed some packet captures on the DHCP server and a couple of test clients, and found that the clients are indeed receiving their DHCP offers. No suspicious looking error logs, and once the client does pick up the DHCP address, it is the one contained in those DHCP offers. I found that upon running the "netsh winsock reset" command on the clients then rebooting, they pick up the address right after booting. Upon another reboot, or running "ipconfig /renew," it again takes 5-10min to get that same lease back. Disabling AV had no effect on things.

I have confirmed that routing is fine, ACL's are not blocking anything, and that pings from the troubled LANs to the server are not dropping and have excellent ping times of 1-5ms.


Any ideas what this could be? Narrowing it down is killing me. We have recently been making a lot of changes on the network, from switches to firewalls to AV products, etc, so it's hard to say any one change is what started it. 

1 Accepted Solution
14 Replies 14


  Seems to me like some security feature on the client side. Do you run anything like counter strike  or DLPs or any similar protection system?

We use CrowdStrike on all clients. No logs showing up in the control center that indicate anything happening, but that wouldn't be the first time I've seen unlogged activity cause problems. I did try disabling all detections on one test machine, but it didn't make a difference.

are you config any dot1x, the dot1x must pass before SW send/receive DHCP packet.

No Dot1x at the moment.

so are you config FTD as dhcp relay ? can you disable arp proxy in NAT may be the client send ARP for new ip but the FTD reply and this make client not accept IP.

The Core Switch is the DHCP relay. The FTD just rejects broadcast traffic. ARP Proxy is disabled for the relevant NAT statements, though.

OK, from Core SW to DHCP server try ping 
ping <dhcp server> source <SVI-ip dhcp helper>
may be there is some asymmetric routing block the traffic we will see with ping if we get 100% success if not then some DHCP unicast message is drop.

Just did so, repeated the ping 800 times. Here's the results:


Success rate is 99 percent (799/800), round-trip min/avg/max = 1/2/6 ms


One ping out of 800 dropped. QoS is configured on both the source and destination LAN though, so I'm not surprised by that.

OK, Core Sw is one or there two with HSRP ?

Just the one. A C9407. The rest of the network is made up of C9300's.

Looks promising! Just ran the "no ip redirects" command on the SVI as directed, and am testing now.

Being that it was an intermittent issue, it might take me a bit to confirm whether or not that fixed it.

Looks like that resolved the issue! All yesterday evening, and still as of this morning, DHCP takes only a second or two everywhere I've tested.

Thank you very much! That one was driving me nuts.

You are so so welcome