Stop Packet Hoarding: Why Enabling DHCP Logs Will Save Your Sanity

If you’ve ever fired up a packet capture to troubleshoot a DHCP issue, you know the feeling. Suddenly you’re drowning in thousands of packets, most of which have absolutely nothing to do with your problem. Sure, packet captures are powerful, but using them for basic DHCP troubleshooting is like bringing a chainsaw to cut a slice of pizza. Enabling DHCP logging gives you the highlights instead of the entire director’s cut, and your brain will thank you for it.

DHCP logs tell a clean, simple story: who asked for an address, when they asked, what they got, and why they maybe didn’t get one. You can immediately see failed requests, exhausted scopes, duplicate MAC addresses, or clients that just won’t stop asking nicely. Instead of squinting at hex values and scrolling past ARP chatter, you get human-readable entries that point straight to the problem. It’s the difference between reading a police report and watching every security camera in the city at once.

Another big win is time and storage. Packet captures grow fast and get unwieldy even faster. You capture too little and miss the issue, or capture too much and now you’re archiving a multi-gigabyte file named “dhcp_final_FINAL_v3.pcapng.” DHCP logs, on the other hand, are lightweight and continuous. You can leave them on without worrying about disk space or explaining to management why the firewall suddenly needs more storage than the file server.

That’s not to say packet captures are useless—sometimes you really do need the chainsaw. But for day-to-day DHCP troubleshooting, logs are faster, clearer, and far less likely to make you question your career choices at 2 a.m. Enable DHCP logging first, solve the problem in minutes, and save packet captures for when things get truly weird. Your future self, staring at fewer packets and drinking better coffee, will appreciate it.

here is an example of enabling DHCP
logging on a Ubqiuiti Edgrouter that is acting as a DHCP server.

configure

set service dhcp-server global-parameters 'log-facility local2;'

set system syslog file dhcpd facility local2 level debug

set system syslog file dhcpd archive files 5

set system syslog file dhcpd archive size 5000

commit; save

exit

After applying the changes, you can view the DHCP log with:

 show log file dhcpd

 Here is some sample output - before you freak out, do your dhcp homework

@Georgetown:~$ show log file dhcpd

Dec 11 09:57:58 Georgetown dhcpd3: uid lease 10.44.10.173 for client e8:ca:c8:57:fb:4c is duplicate on 10.44.10.0

Dec 11 09:57:58 Georgetown dhcpd3: DHCPDISCOVER from e8:ca:c8:57:fb:4c via eth2

Dec 11 09:57:58 Georgetown dhcpd3: DHCPOFFER on 10.44.10.37 to e8:ca:c8:57:fb:4c via eth2

Dec 11 09:58:12 Georgetown dhcpd3: uid lease 10.44.10.173 for client 24:3f:75:dd:af:38 is duplicate on 10.44.10.0

Dec 11 09:58:12 Georgetown dhcpd3: DHCPDISCOVER from 24:3f:75:dd:af:38 via eth2

Dec 11 09:58:12 Georgetown dhcpd3: DHCPOFFER on 10.44.10.36 to 24:3f:75:dd:af:38 via eth2

Dec 11 09:58:42 Georgetown dhcpd3: DHCPDISCOVER from 3c:7a:aa:9a:c3:8f via eth2

Dec 11 09:58:43 Georgetown dhcpd3: DHCPOFFER on 10.44.10.173 to 3c:7a:aa:9a:c3:8f via eth2

Dec 11 09:58:45 Georgetown dhcpd3: DHCPDISCOVER from 84:c8:a0:d3:b8:2e via eth2

Dec 11 09:58:45 Georgetown dhcpd3: DHCPOFFER on 10.44.10.173 to 84:c8:a0:d3:b8:2e via eth2

Dec 11 10:02:59 Georgetown dhcpd3: uid lease 10.44.10.173 for client e8:ca:c8:57:fb:4c is duplicate on 10.44.10.0

Dec 11 10:02:59 Georgetown dhcpd3: DHCPDISCOVER from e8:ca:c8:57:fb:4c via eth2

Dec 11 10:02:59 Georgetown dhcpd3: DHCPOFFER on 10.44.10.37 to e8:ca:c8:57:fb:4c via eth2

Dec 11 10:03:13 Georgetown dhcpd3: uid lease 10.44.10.173 for client 24:3f:75:dd:af:38 is duplicate on 10.44.10.0

Dec 11 10:03:13 Georgetown dhcpd3: DHCPDISCOVER from 24:3f:75:dd:af:38 via eth2

Dec 11 10:03:13 Georgetown dhcpd3: DHCPOFFER on 10.44.10.36 to 24:3f:75:dd:af:38 via eth2

Dec 11 10:03:43 Georgetown dhcpd3: DHCPDISCOVER from 3c:7a:aa:9a:c3:8f via eth2

Dec 11 10:03:44 Georgetown dhcpd3: DHCPOFFER on 10.44.10.173 to 3c:7a:aa:9a:c3:8f via eth2

Dec 11 10:03:45 Georgetown dhcpd3: DHCPDISCOVER from 84:c8:a0:d3:b8:2e via eth2

Dec 11 10:03:45 Georgetown dhcpd3: DHCPOFFER on 10.44.10.173 to 84:c8:a0:d3:b8:2e via eth2

Dec 11 10:08:00 Georgetown dhcpd3: uid lease 10.44.10.173 for client e8:ca:c8:57:fb:4c is duplicate on 10.44.10.0

---

LinkRunner AT 4000 versus Network Switch Cable Test (Carlo Zakarian)

 

I used to think the network switch was a master detective, capable of solving all my cable mysteries with a single, glowing link light, and remote management cable tests.  We’ve all seen these features on managed switches, select a port, perform a cable test, and watch for the results to be displayed as either pass, fail, split pair, and the length of the cable.

It wasn't until the feature-packed LinkRunner AT 4000 entered the scene that I realized the switch cable test was actually the network equivalent of a Magic 8-Ball, answering every complex problem with a confident “Yes, cable pass!” and not knowing why it passed.

Most technicians assume that if the switch reports “Cable Pass” the cable is having a great day. But if you want to know if that cable is suffering from a hidden split pair or just a minor existential crisis, you call in the Linkrunner AT 4000.

The LinkRunner AT 4000 is a handheld advanced network cable tester, it’s the stern, white-gloved proctor administering the final exam, it has a follow-up list of diagnostic questions, starting with “Did you remember to terminate correctly on both ends of the cable?”  The LRAT 4000 conveniently draws out the pin-to-pin wire mapping on the LCD screen, it can precisely measure cable fault via TDR, indicating cable problems such as split pairs, shorts, opens, mis-wired, and crossovers.  It also can test for port speeds, PoE, network and connectivity issues, and perform a full network map of your environment.  

Follow along with me and watch as I show you the difference between what a basic switch cable test reports versus a LinkRunner AT 4000 advanced precision cable tester.

Carlo Zakarian is a network engineer with over 15yrs experience in the networking implementation, design, and diagnostics field specializing in LAN, WAN, and Wireless.  Owner of NetFocus Technologies, an IT Managed consulting firm based in Chicago, specializes in setting up, configuring, diagnosing software, hardware, and network infrastructure.

 He can be reached via his website at https://www.NetFocusTech.com

---

Packet Sleuthing on the Edge: How tcpdump Saved My DHCP Sanity

When a DHCP issue strikes, it tends to do so with the subtlety of a brick through a window. Devices suddenly stop obtaining addresses, clients complain that “the network is broken,” and the logs seem to be playing hide-and-seek. This situation was a bit different; one client could not get an ip address from wifi, but worked fine on the wired side.  same vlan, same dhcp server.  and yes his wifi works fine everywhere else. Since the router was the dhcp server, I turned to one of the most under-appreciated diagnostic tools hiding inside a Ubiquiti EdgeRouter: tcpdump. While the GUI has plenty of useful stats, nothing beats raw packet visibility when you need to know exactly what’s happening on the wire.

tcpdump is widely used and been documented thoroughly https://www.tcpdump.org/manpages/tcpdump.1.html  

Capturing packets directly on the EdgeRouter has a huge advantage—you’re collecting data at the precise point where traffic passes. No guessing. No relying on secondhand logs. With tcpdump, I could instantly see whether DHCP DISCOVER, OFFER, REQUEST, and ACK packets were actually being exchanged. In my case, that clarity helped me spot that the DISCOVERs were arriving, but the OFFERS weren’t making it back out. Without that level of detail, I would’ve been stuck blaming ghosts or rebooting things out of desperation.

It was a simple process; i simply ssh'd into the router and typed the following command to capture 5MB of dhcp packets and write them to capture_dhcp.cap.

sudo tcpdump -i switch0 -n -vvv port 67 or 68 -C 5 -W 1 -w capture_dhcp_2.pcap

Another perk is how easy it is to filter traffic with tcpdump. Instead of drowning in a sea of packets, I could lock in on port 67/68 traffic or even narrow the view to a single MAC or interface. It’s like having an X-ray machine for your network, where you can zoom right into the failing process without being distracted by everything else. And since captures can be saved and opened in Wireshark later, you get the best of both worlds: lightweight on-device capture with full-blown desktop analysis afterward.

Finally, running tcpdump on an EdgeRouter is fast, simple, and—most importantly—accurate. When troubleshooting something finicky like DHCP, assumptions are the enemy. tcpdump removes the guesswork and replaces it with hard evidence you can act on. In my case, it cut hours of trial-and-error down to minutes and pointed directly at the misconfigured relay causing all the chaos. If you’re working with Ubiquiti gear and not using tcpdump yet, trust me—your future self will thank you.

from the net: 20 Daily Linux Commands System Administrators Use in Production

 As a Linux SysAdmin working in a production environment, your daily routine is all about keeping systems stable, secure, and performing at their best. From troubleshooting issues to monitoring resources and ensuring uptime, you wear many hats, and time is always of the essence.

While Linux offers thousands of commands, not all of them are part of your day-to-day toolbox. However, there’s a core set of powerful, reliable commands that you’ll find yourself using every single day, often multiple times.

In this article, I’ll walk you through the 20 most essential Linux commands every system administrator should master. These aren’t just commands, they’re your go-to tools for monitoring performance, managing logs, controlling services, debugging problems, and much more.

CLICK THE IMAGE FOR THE FULL ARTICLE

---

I have some ideas for some cool challenges and giveaways in the new year which will only be available to email subscribers.

Forgettable Things

After spending decades in the HDD industry, I came to believe that even the slightest loss of stored data was so catastrophic as to justify a hurried team meeting and a frantic search - using the latest high-tech tools - for the root cause. I never hesitated to buy extra storage for my own personal data so that I could always have a backup. Computer memory stores data as a string of 1’s and 0’s, typically represented by either tiny, magnetized regions on a surface, or as electrical charges on floating gate transistors.   Storage integrity is affected by things like temperature, humidity, and mechanical shock. The physics is straightforward, but the possibilities for failure are many.

Of late, I have begun to ponder memory loss of a different kind. It seems that if you sometimes enter a room only to forget why you went there, it is normal. If you misplace your car keys and find them on the bathroom counter, that too is normal. If, however, you find your keys in the freezer, you may need to summon a different team with a separate set of tools to figure out what is going on. The human brain has around 86 billion neurons, each with thousands of connections. A process known as synaptic plasticity alters the strength of these connections, forming the basis for learning and memory. Unlike with digital devices, storage is analog and influenced by emotion, context, and experience.

With all those neurons and connections buzzing away, you would think we could remember pretty much everything, but the design wasn’t meant for that. According to a 2009 report by the Global Information Industry Center at UC San Diego, we are exposed to 34 Gigabytes (nearly 12 hours’ worth) of information on a daily basis. Cognitive psychologist George Miller, in a 1956 paper on memory capacity, suggested that we can only keep 7 things (plus or minus 2) in mind at a time. While researchers are still debating the number, most suggest that it is probably smaller rather than larger. Our brains are mindbogglingly miraculous in function, but they are also selective.

This system of economy looks to filter information as much as possible, store the minimum, and make sure to get maximum benefit from that information. There are occasions, however, where we are surprised and frustrated by the things we miss. I still remember the number for the old dial telephone in the house I grew up in, yet I often forget the name of the person I was just introduced to in an important meeting.

According to memory scientist Charan Ranganath of U.C. Davis, trying to cram more into your head is not the best answer. One suggestion is what he calls “chunking” or grouping items to reduce the overall number. Like the way I apparently stored my first phone number under “home,” or most of us remember the alphabet or our Social Security number, chunking can improve efficiency.

You can find more about Dr. Ranganath’s handy acronym for chunking all these steps, known as “MEDIC”, here.  He also offers additional tips for any of us who may feel frustrated with our forgetfulness. Meaning is an important part of securing a spot in our limited storage space - if a memory is vivid or meaningful, that improves the odds of recall. Addressing the CEO of an important customer by the wrong name in a meeting not only sucks the oxygen out of the room but it also creates a vivid memory unlikely to be forgotten.

At the age of 12, my granddaughter memorized Teddy Roosevelt’s “Strength and Decency” for a regional speech meet. It was distinct from other things she was studying in that it was over 1200 words long and she knew she would be delivering it in front of a 3-judge panel in a packed room. Preparation involved lots of trial and error, first reciting a section and then checking for accuracy. Even though this was an unusually large “chunk,” she nailed it.

Importance and context are also key elements of memory, which brings me back to the disconcerting case of that CEO (which I would like to forget). After all, even though humans aren’t built to remember everything, I thought we were built to survive.