Suricata 8 Performance Tuning on Linux: A Packet Loss Troubleshooting Lab

Most Suricata tuning guides give you a list of numbers to paste into suricata.yaml. That does not help when your sensor still drops packets, because every network and every server is different.

In this guide, you will learn to build a safe test network on one Linux server, send the same traffic every time, and read the Suricata counters after each change. If the drop number goes down, you keep the change. If it does not, you undo it.  

That is the safest way to do Suricata 8 packet drop performance tuning on your own hardware.

For Suricata 8 packet drop performance tuning, make sure you have these things ready:

• A Linux server with root or sudo access. This guide uses Ubuntu 24.04 LTS.
• At least 4 CPU cores and 8 GB RAM. The examples assume 8 cores. If you have fewer, adjust the CPU numbers.
• Suricata 8.0.x LTS.
• Basic Linux command line skills.

A packet can be lost in several places. Some are before Suricata sees it, and some are inside Suricata. Knowing which place is losing packets saves time.

The main sign of packet loss in Suricata is capture.kernel_drops. Ideally it stays at 0. It should never go above 1% of capture.kernel_packets.

Also, your NIC can drop packets, and Suricata never counts those. So check ethtool as well.

In AF_PACKET mode, kernel_drops counts packets that the kernel threw away before they reached Suricata.

The tcp.reassembly_gap counter should also be 0. It goes up when packets are lost. It also goes up when checksums are bad or when Suricata runs out of memory for streams.

We will use this simple formula in every test:

A tuning change only counts if you can compare it with a before number. Here is the plan:

• Build a lab that creates the same traffic every time.
• Start with a weak setup on purpose, so it drops packets.
• Change one thing.
• Run the same test again and compare the counters.

Never change two settings in the same round. If you do, you will not know which one helped.

First, update the server and install the tools we need with the commands below:

Add the official OISF stable repository and install Suricata. The OISF keeps a PPA named suricata-stable that always has the latest stable release:

Check the version and the build features with the commands below:

In the build info, look for a Hyperscan line that says yes. If Hyperscan says no, you can still follow this guide, but skip the Hyperscan part of Round 5 and use mpm-algo: ac-ks instead.

The package starts Suricata as a service. Stop it, because our test script will start Suricata by itself with a different log folder each time:

Make a safe copy of the original config. You will use it to undo mistakes:

We create a virtual network cable, called a veth pair. One end stays on the host, and Suricata watches it. The other end goes inside a separate network space called gen. This is where we run the traffic generator:

Then, use the command below to test the link:

If the ping fails and you use ufw, you must allow the lab interface:

Now start two iperf3 servers on the host. We set them to CPU 0 so they stay away from the Suricata worker CPUs:

Why two servers? One iperf3 server can run only one test at a time. We want two tests at the same time. The first is a TCP test with many flows and large packets. The second is a UDP test with small packets and a high packet rate.

Suricata will watch lab0. AF_PACKET sees traffic in both directions on an interface. So Suricata will see the client packets and the server replies.

In this step, you can download the rules and set up a weak starting config on purpose. Rules make Suricata use CPU, so they give the lab real work to do. The weak config will drop packets, which gives you a baseline number to compare with in every later round.

Rules are what make Suricata use CPU. Download the free Emerging Threats Open ruleset with the built-in updater:

Now use your desired text editor to open the config file:

First, find the HOME_NET line and set it to the lab network:

Next, find the af-packet: section. Replace the first interface entry, the - interface: eth0 block, with this weak baseline. Leave the - interface: default block below it as it is:

• threads: 1 gives you only one worker, so one CPU core does all the work.
• tpacket-v3: no uses the older AF_PACKET version 2.
• ring-size: 2048 is a small buffer. It holds only 2048 packets per thread.

Then, find the stats log output and turn on per-thread numbers. This helps you see which worker is in trouble:

Also, you should find the pattern matcher, detect settings, and set the weak baseline. You can use grep to find the line numbers:

Set these values with the lines that grep shows you:

Your file may already show medium for the profile and auto for the algorithm. The only change here is mpm-algo: ac, which gives you a slower matcher to start from. Save the file and test it:

You should see a message that the configuration was loaded successfully. You must fix any YAML errors before you continue. Indentation errors are the most common problem. Save a copy of this baseline:

You can always print the settings Suricata really loaded. You can use this check for AF_PACKET:

At this point, you can create one script that runs a full test:

1. Stops any old Suricata and starts a fresh one with its own log folder.
2. Waits until Suricata is ready.
3. Sends TCP and UDP traffic from the gen namespace.
4. Saves per-thread CPU use in the middle of the test.
5. Stops Suricata, reads the final stats, and adds one line to a CSV file.

Use the commands below to create the folder and file, and paste the following script to the file:

Once you are done, save and close the file. Make it executable:

Now you can run the first test with the weak config. This gives you the "before" numbers. You should see packet drops here, so you have something to fix. If you see no drops, you must raise the traffic rate until you do.

If kernel_drops is 0, your test traffic is too light. Raise the rates and run the baseline again:

Run each test twice. If the two results are very different, your server has other load, and you should find it before you trust any result. Look at the CPU use per thread:

With one worker, you should see one W#01-lab0 thread near 100% CPU. That is the bottleneck we are going to fix.

In this step, you must change one setting at a time and run the same test again. After each round, you must compare the new numbers with the old ones.

If the drops go down, you can keep the change. If they do not, you can undo it. This way, you always know which change helped. Use this routine for every round:

If a round makes things worse, restore the last file. For example:

AF_PACKET is the Linux capture method. It has version 2 and version 3 ring styles. It is recommended to use v3 for IDS and network monitoring, and v2 for IPS.

Suricata 8 uses v3 by default in non-inline modes. In inline modes, v3 stays off. The default block size is also bigger now. It grew from 32 KiB to 128 KiB. So a fresh Suricata 8 config probably uses v3 already. This round matters most if you moved an old config over from Suricata 7.

Edit the af-packet block. Change only the version line:

Once you are done, test and run with the commands below:

Note: Running Suricata inline as an IPS? Skip this round. Inline mode should stay on TPACKET v2. Your packet copy settings (copy-mode and copy-iface) must also match your IPS setup. Follow the full steps in our Suricata 8 inline IPS tutorial. Use this lab only to measure the counters, not to change the AF_PACKET version.

With one worker, only one core does all the work. More workers share the work across more cores. With cluster_flow, all packets of one connection go to the same worker. So the work is split by connection.

On an 8-core server, we use CPU 0 for the system and the iperf3 servers. We use CPU 1 for the traffic client. That leaves CPUs 2 to 7, which gives Suricata 6 cores for workers.

When you are done, test and run with the following commands:

Now check the per-thread CPU with the following command:

• Good sign: Several W# threads share the load.
• Warning sign: One thread sits at 100% while the others are idle. One big connection is stuck on one worker. More threads cannot split a single connection.
• Fix: Use stream bypass in Round 6.

Also, you can look at drops per thread:

Do not use more worker threads than the CPU cores you can give to Suricata. If two threads share one core, they slow each other down.

The cluster mode tells the kernel how to split packets between your worker threads. The sample config lists these options:

• cluster_flow: all packets of a flow go to the same socket.
• cluster_cpu: all packets handled by one CPU in the kernel go to the same socket.
• cluster_qm: all packets from one NIC RSS queue go to the same socket, which needs Linux 3.14 or newer.

For most servers, cluster_flow is the right choice and default option. Use this table for real hardware:

To see and change RSS queues on a real NIC, you can use the commands below with your interface name:

Read your driver notes before you change queues. On some drivers, a wrong change can cause problems.

In this lab, the veth link has only one queue, so cluster_qm does not apply. Keep cluster_flow.

You can still check the result. Watch tcp.pkt_on_wrong_thread in your results. It shows load balancing problems. With cluster_flow, it should stay at 0 or very low. Set it clearly in the config:

When you are done, test and run with the following commands:

Note: every AF_PACKET interface needs its own cluster-id. Never reuse the same ID on two different interfaces.

The ring is a waiting room for packets. It sits between the kernel and Suricata. Each thread has its own ring, and ring-size sets how many packets it can hold. If a ring fills up, the drop counters go up. The memory use is set at start, and the formula is:

With default-packet-size at 1514, one packet slot costs about 2264 bytes. Here are two examples:

• 6 threads x 10,000 x 2264 bytes = about 136 MB
• 6 threads x 100,000 x 2264 bytes = about 1.36 GB

In Suricata 8 packet drop performance tuning, ring size is usually the first setting people raise. But a bigger ring only helps with short bursts. It does not make Suricata faster. If Suricata is always too slow, a big ring just fills up later. Test it in small steps:

Then, you can try a bigger value:

How to read the result:

• Drops fall a lot, and CPU is not full: your problem was bursts. Keep the ring.
• Drops barely change, and the worker threads are near 100%: the ring is not the problem. Go to the CPU rounds.
• Memory is getting tight: go back to the smaller ring.

If you leave out ring-size, Suricata calculates it from max-pending-packets and the thread count. Set it yourself, which is more predictable. 

With TPACKET v3, you also have block-size. It must be a power of 2 and a multiple of the page size, usually 4096. The official high-performance example uses ring-size: 100000 with block-size: 1048576. Change the block size only if your ring test shows you need it.

For busy systems, there is one more option, which is use-emergency-flush: yes. It helps the ring recover after a drop phase. The cost is that some packets will not be inspected. Use it only if you accept that.

Keep the best ring value and save it:

If all workers are busy and drops continue, look at detection cost next. It is a common cause of CPU saturation in Suricata 8 packet drop performance tuning work.

The pattern matcher (mpm-algo) searches packets for rule patterns. Hyperscan is the best choice on supported platforms. Without Hyperscan, ac-ks is better than the default ac.

First, you must confirm your build supports it, which you did in Step 1:

Edit the top-level settings and the detect profile:

The profile sets how Suricata groups rules. With Hyperscan, use high or a bigger custom group size. Do not use detect.sgh-mpm-context: full, because it makes startup much slower. For a custom size, you can use this format:

Do this in two small tests so you know what helped. First, only mpm-algo: hs, then profile: high:

Expect longer startup time and more RAM with high. If the start takes too long or memory is tight, go back to medium.

If there is no Hyperscan on your build, use mpm-algo: ac-ks and test that instead.

Some flows are huge and boring, like a big file download. Suricata does not need to inspect all of it. The stream.bypass option stops inspection once a flow reaches a set depth. The inspection is skipped when stream.reassembly.depth of 1 MB.

You can find the stream: block and set:

Keep any other lines already in the block, such as memcap.

Also, there is a separate setting for encrypted traffic. In Suricata 8, it no longer depends on stream.bypass. You control TLS and SSH on their own. The options are bypass, track-only, or full. For TLS, find encryption-handling under app-layer.protocols.tls:

Run the test:

Note: Once a flow is bypassed, rules cannot match its later data. An attacker could hide something deep inside a long connection. Many teams accept this for bulk traffic and keep full inspection for everything else. It is your risk, so test first and then decide.

A memcap is a memory limit. When a limit is full, Suricata drops state or data, and that creates gaps even if the capture itself has no drops. Look for signs first, and do not raise limits without a reason:

We already log three counters:

• tcp.ssn_memcap_drop: the stream engine ran out of memory for new sessions.
• tcp.segment_memcap_drop: the reassembly engine ran out of memory for segments.
• flow.emerg_mode_entered: the flow table got too full, so Suricata went into emergency mode.

If you see memcap values in the stats, you can raise the memcap in the config. But this uses more RAM, so plan for it.

If any of these counters is above 0, raise only the matching limit. First, check the real names and current values in your file:

For example, on an 8 GB lab server:

If all memcap counters were 0 in earlier rounds, skip this round. Bigger limits will not fix a problem you do not have.

Also, tcp.reassembly_gap can stay above 0 after a memcap fix. Bad checksums and packet loss before Suricata can cause it too.

Network cards and drivers can merge small packets into larger super-packets (LRO and GRO). This breaks the dsize keyword and TCP state tracking, so these features should be off. For AF_PACKET, checksum offload (rx and tx) can stay on.

Check the current state of the lab link with the command below:

Turn the merge features off on both ends of the lab cable:

In a virtual link, some features may show as fixed or Cannot change. That is fine. Skip them. Run the test:

On a real server NIC, also check the NIC's own ring and error counters. In the ethtool -S, fields like rx_missed_errors and rx_no_buffer_count are shown as signs of NIC drops:

If ethtool -g shows that the current RX ring is lower than the maximum, you can raise it. For example:

Use a value that your own ethtool -g output says is allowed. Offload and ring changes are lost after a reboot. To keep them, you can create a small service:

The - before each command tells systemd to continue even if the NIC says a feature cannot be changed.

Without affinity, Linux can move Suricata threads between cores. That hurts the CPU cache. With affinity, each worker stays on its own core.

In Suricata 8, the threading.cpu-affinity settings use a dictionary format instead of the old list format. Find the threading: block and use this layout for the 8-core lab:

On a server with more than one CPU socket (NUMA), you must keep the workers on the same NUMA node as the capture NIC. Also, avoid CPU 0 for workers where you can. Check your layout and the NIC's node:

For a high-speed setup, irqbalance should be off during tuning:

Once you are done, run the final test with the commands below:

Check that the workers stay on their cores. In threads-cpu.txt, the CPU column shows which core each W# thread uses:

Each worker should stay on one core from the worker-cpu-set range, 2 to 7.

In this step, you must look at the numbers from all your rounds. You can put them in one table and compare each round with the baseline. Then, you use a simple symptom table to see what each counter means and what to fix next. Open the CSV file:

Fill a table like this one with your own numbers. We do not show sample numbers here on purpose. Your hardware and your traffic will give different results, and only your own numbers count.

Use this table to decide what to do next. It keeps Suricata 8 packet drop performance tuning simple, because each symptom has one fix:

A good target is drops under 1% of packets, and ideally zero. If your sensor must not miss any traffic, aim for zero. Treat any drop as a bug you need to explain.

If the softnet number is the one that grows, try a larger kernel queue. This is a Linux setting, not a Suricata setting:

Make it permanent only after the test shows it helps:

The lab found the settings. Now you can apply them to the real interface. This is where Suricata 8 packet drop performance tuning becomes a real change on a real sensor.

To do this, find your capture interface name:

Edit the af-packet block. Use the real interface name, and keep the values that won in your lab:

Set HOME_NET back to your real networks. Test the file and check the service command:

The ExecStart line must use the AF_PACKET capture settings from your file. If it does not, edit the service so it does.

Finally, start the service and watch the live drop rate:

These numbers count from the time Suricata started. Check them at busy hours and after rule updates, not only at quiet times.

Also, your sensor needs to see real traffic. Use a SPAN/mirror port or a network TAP. If you tune an inline setup, keep your inline AF_PACKET settings and follow the inline guide linked in Round 1.

If your Suricata 8 packet drop performance tuning results show you need more cores or a faster port, you can run your sensor on a dedicated server with enough CPU and network speed. You can pick the number of CPU cores and the port speed to match your traffic.

When you finish, you can remove the lab so it does not stay on the server:

Deleting the namespace also removes the virtual cable. Your result files stay in /var/log/suricata-lab/. Delete that folder when you no longer need it.

To get back the original config, run the command below:

Best Suricata 8 packet drop performance tuning is simple. You must measure, change one thing, and measure again. Start with capture.kernel_drops, then check tcp.reassembly_gap, the memcap counters, and CPU use per thread. Also, keep your CSV file, which is the proof of what worked on your hardware.

We hope you enjoy this guide. For more tuning considerations, check the Suricata 8.0 documentation.