[Oisf-users] Suricata load/latency spikes

Oliver Humpage oliver at watershed.co.uk
Thu Jul 9 16:09:28 UTC 2015

Just a couple of updates on this one.

I tried setting up OpenBSD with pf's divert-packet (i.e. ipfw mode), but hit a very similar problem: downloading a large file would just stall (at anywhere between 5MB and 100MB - no pattern to it). The eve.json log shows lines like:


but no clue at all as to *why* the packet is dropping - no logs have an alert ID or anything. Any ideas?

Separately, I also tried to use suricata in netmap mode (on FreeBSD), but unfortunately incoming packets aren't being copied to the outgoing interface. Running snort with the daq in netmap mode works fine on the same box, so I think it's a suricata issue. Aleksey (who wrote the netmap code) has been great helping me diagnose the problem, but I don't know how much time he has to work on a fix.

Again, any ideas/help/pointers are welcome.

Many thanks,


On 1 Jul 2015, at 14:12, Oliver Humpage <oliver at watershed.co.uk> wrote:

> Well, researching further leads me to suppose this is likely a FreeBSD/ipfw/divert issue.
> Not only is there nothing in the stats.log (the increase in DNS mem wasn't replicated when I looked at more results), but I now see large file downloads randomly stalling in the middle, with nothing at all logged in suricata. I see packets coming through the neighbouring routers, and then never making it through the suricata interface.
> I've even tried only diverting my own laptop traffic through suricata, and still file downloads stall (I'm testing downloading FreeBSD ISO images, they normally stall at <100MB of the way through, but never stall if I switch off the suricata divert). My connection speed is currently around 50Mb.
> Does anyone have any experience with suricata and ipfw, and how to tune it for reliable throughput? Or equally, has anyone had success using OpenBSD's pf divert-to rules instead of ipfw divert?
> Thanks,
> Oliver.

More information about the Oisf-users mailing list