We recently asked the community something we’ve been curious about for a while: What kind of hardware are you using to run Zeek? What does that setup even look like? What started as a straightforward question about specs and sizing quickly turned into something distinct but similarly useful—people sharing what went wrong and what they wish they’d known before making hardware decisions.

Topic of the Month is a program we launched in October to surface community knowledge that doesn’t make it into documentation. We ask a question, the community shares their experiences and lessons learned, and we pull together what matters.

Here are the patterns that emerged from November’s hardware discussion: common mistakes that are easy to make and worth flagging now to save your future self the trouble.

Ignoring NUMA Domain Impact on Packet Capture

When it comes to multi-CPU systems, we had a few community members admit that more processors don’t always mean better performance. NUMA (Non-Uniform Memory Access) creates performance penalties when processes access memory or NICs across domain boundaries, and every packet pays this cost.

One community member who works on large-scale deployments reports seeing this regularly in production. The fix requires pinning sniffing processes to CPUs in the same NUMA domain as the capture NIC. Modern AMD EPYC processors add complexity—their chiplet architecture creates internal NUMA domains even in single-socket configurations, so high-traffic deployments on these systems may need pinning to specific internal domains.

The straightforward solution: if a single high-thread-count processor provides enough workers for your traffic load, it eliminates NUMA complexity entirely. This matters during hardware selection.

Evaluating NICs for Performance Instead of Longevity

One pattern that emerged in the discussion: teams selecting NICs based on throughput benchmarks and packet capture performance. The hardware works well at first, but when vendor acquisitions end driver support and kernel updates break compatibility, deployments get stuck on old Zeek versions because updating the OS means losing network card functionality.

Multiple community members shared versions of this story, specifically with Myricom NICs. One deployment stayed locked on Bro-era Zeek for its entire operational lifecycle. Another described patching drivers through kernel upgrades until the complexity became unmaintainable, leaving systems on Rocky Linux 8 indefinitely.

This happens because hardware evaluation focuses on current performance metrics when it should prioritize driver ecosystem stability over 3-5 year deployment timelines. Several people in the conversation described moving to AF_PACKET with ConnectX-6 or Intel XXV710 NICs for long-term maintainability. The shift to AF_PACKET matters because it relies on standard Linux kernel drivers rather than vendor-specific implementations. When proprietary driver support ends, you’re stuck. With kernel-level support, driver maintenance continues as part of the broader Linux ecosystem.

When hardware locks you into old software versions, initial performance advantages disappear fast.

Missing NIC Offload Settings

Here’s a specific troubleshooting story from the discussion that stuck with us: Sometimes the problem isn’t what you think it is. In one case from the community, a deployment disabled NIC offloads following Zeek documentation, capture loss stayed high across the cluster, and configuration looked correct. The culprit? A single overlooked offload setting.

This happens because the list of offloads is long and teams scan it quickly during initial setup. One deployment traced cluster-wide capture issues to exactly this—they assumed they’d disabled everything correctly the first time. When unexpected capture loss appears, verify every NIC offload is disabled using the Zeek documentation.

Configuration Defaults That Break Deployments

A couple of configuration issues came up over the course of the month’s discussion. The packages directory @load in local.zeek is commented out by default, so teams install packages with zkg and then wonder why they don’t load. Uncomment this line before installing packages (the Zeekurity Zen guide covers this setup process).

On Ubuntu 24.04, netplan adds capture NICs to the routing table by default. Capture interfaces should never route traffic, so configure netplan to explicitly ignore them and verify they stay out of the routing table after system updates.

Why This Matters

If you’ve run into hardware issues deploying Zeek, now you know you’re in good company. These aren’t edge cases, they’re the reality of deploying packet capture at scale.

Next time you’re speccing hardware, ask about driver longevity. Check NUMA topology before buying multi-CPU systems. These lessons cost other teams time and money—now you can skip straight to what works. For baseline sizing guidance, check CERN’s hardware requirements or the specifications from Security Onion and Malcolm.

Have a hardware question? Made a mistake that taught you something? Share it with us on Slack (there’s always someone who’s been there before!). And if you’re curious what we’re discussing this month, head to #topic-of-the-month to find out.

Thanks to Jakob, Dop, Doug, Seth, Tony, Eric, Mark O., and Mark M. for contributing to this month’s discussion.