Bro capture loss without dropped packets

Hi,

Bro is reporting capture loss without dropped packet notices. I’ve read the FAQ entry and poked around, but I’m not sure why I’m seeing this behavior.

I’m running Bro in a docker container on a low-end box and I want to see where it starts having performance problems. I’ve got the Bro box directly connected to a box where I’m running tcpreplay at various speeds using different pcaps.

At 10Mbps everything works as expected. As I increase the speed (20Mbps, 30Mbps… 200Mbps) I start to see capture_loss reported in the 10-30% range, but no dropped packet notices.

Running tcpdump on the box as a sanity check, it collects all the packets at all speeds.

The Bro box has an Intel NIC, and I’ve turned off tso, gro, etc per the Bro FAQ entry.

I’d think it was an artifact of the pcap, but I’ve seen the same results using both my own captures and publicly available ones.

Getting up into the 200Mbps+ range I started to see dropped packet notices, as I’d expect.

Is the capture loss at low rates just something odd about replaying pcaps at various speeds, or are there additional things I should check in my setup?

thanks,
Mike

At 10Mbps everything works as expected. As I increase the speed (20Mbps,
30Mbps... 200Mbps) I start to see capture_loss reported in the 10-30%
range, but no dropped packet notices.

The dropped packet notices come from statistics reported by the packet
sources. In many setups, these statistics are unreliable, which is what
originally led us to develop capture_loss. capture_loss is quite robust;
if you are losing packets from your monitoring and you have any significant
TCP traffic, it *will* flag the problem. So one possibility is that the
statistics for your packet capture setup are indeed unreliable, and are
under-reporting lower rates as no loss.

Another possibility is that the trace you're replaying using tcprelay
itself has capture loss. The capture_loss mechanism will key off of those
even if the replay is perfect with no additional capture loss, i.e., your
packet source doesn't having any problems until the replay speed gets quite
high.

You could diagnose that second possibility by seeing whether just running
directly off the pcap with -r produces capture loss reports.

    Vern