If there’s one thing every network admin learns the hard way, it’s that DHCP problems rarely announce themselves politely. One minute everything is fine, and the next users are wandering the office asking why Wi-Fi suddenly stopped working. That’s why proactive DHCP troubleshooting matters. Instead of waiting for a full-blown outage, keeping an eye on your DHCP logs can reveal warning signs long before devices start losing addresses and chaos begins. In this example, I will refer to Ubiquiti EdgeRouters, since I'm working with them quite a bit lately. One of the best places to start is the trusty command sudo cat /var/log/dhcpmasq.log
FYI. the same methodology and tips will apply to any DHCP server.
Inside that log, lives a running conversation between your devices and the DHCP server. Under normal conditions, you’ll see the classic DHCP process known as DORA — Discover, Offer, Request, and Acknowledge. A client broadcasts a Discover message looking for an IP address, the server Offers one, the client Requests it, and finally the server Acknowledges the lease. When your logs show a healthy flow of DORA traffic, your network is generally humming along nicely. It’s like watching air traffic control successfully land planes all day long.
Of course, not every DHCP message is sunshine and rainbows. You’ll occasionally see DHCP NAK messages appear in the logs, and that’s not automatically a reason to panic. A DHCP NAK (Negative Acknowledgement) simply means the server rejected a client’s request for an address. This can happen for perfectly normal reasons — maybe a hone was used at home and then used at work, or a device tried renewing an old lease that no longer exists. A few NAKs scattered throughout the day are usually harmless background noise.
The trouble starts when those DHCP NAKs begin piling up like empty coffee cups during an all night study session. Excessive NAKs can point to deeper problems such as overlapping DHCP scopes, rogue DHCP servers, VLAN misconfigurations, stale leases, or devices bouncing between networks unexpectedly. The worst case scenario is some sort of malicious attack. If users complain about intermittent connectivity, random IP assignments, or devices constantly reconnecting, those repeated NAK entries in dhcpmasq.log can become your early warning system. Spotting that pattern before users start flooding the help desk can save hours of downtime and troubleshooting headaches.
The beauty of proactive DHCP monitoring is that it turns you from a firefighter into a detective. By regularly reviewing DHCP logs, watching for abnormal spikes in requests or NAKs, and understanding what healthy DORA traffic looks like, you can identify network issues while they’re still small and manageable. A few minutes spent checking logs today can prevent a full network meltdown tomorrow — and that means fewer angry users, fewer emergency troubleshooting sessions, and maybe even enough spare time to enjoy your coffee while it’s still hot.
For those of you who want to automate, you can write a script in your favorite programming language to review the log or look for problems, or set up syslog, SNMP traps or other alerts to provide a heads up before a problem goes unnoticed.
The best advice I can give when dealing with alerts and errors, is to start with errors that you know and can reproduce so you don't get slammed with a bunch of errors that you do not understand.
