Re: [security-onion] help troubleshooting BRO_NOTICE packet loss messages

[Liam Randall]

Bro counts tcp sequence numbers looking for gaps and then will extrapolate that number across all of your traffic- the final % includes icmp and udp as well.

Did you allow the wizard to setup the NIC and disable offloading?

http://securityonion.blogspot.com/2011/10/when-is-full-packet-capture-not-full.html

Check your nic: ethtool -S eth1

Look for something like 

rx_long_length_errors: 208402

Does the interface being monitored have any tagged traffic?  802.11q or QinQ?

Are you on a span port or a tap?  If a tap, is it an aggregation tap (ie, 1 Gbps TX + 1 Gbps RX down a single 1 Gbps tap)?  You could be exceeding the 1 Gbps total during peak times like during backups.

Thanks,

Liam Randall

On Sun, Jun 2, 2013 at 11:57 AM, Josh Patton <5265644...@gmail.com> wrote:

I am consistently getting "The capture loss script detected an estimated loss rate above x" in my bro_notice log yet I am unable to find where loss is coming from.  The rate is sometimes huge, ie - 55.760% etc.

I have no lost packets when looking at sostat on any of the sensors and when I check netstats in broctl I look fine too, ie - recvd=43712191 dropped=0 link=43712191.  Received and link are always paired up and dropped at 0.  I am not missing any huge amounts of data in ELSA (or any for that matter) that I can see.  Not sure if I am missing something or...?

My setup is one server with three sensors.  All sensors have 4 bro and 2 snort instances and are not under heavy load. Over the last 6 months I have been learning the SO setupand  I don't think I looked in the notice log until a few weeks ago.

--
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
To post to this group, send email to securit...@googlegroups.com.
Visit this group at http://groups.google.com/group/security-onion?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

[Liam Randall]

Disable all of the offloading per Dougs awesome article.

Are you terminating other things on the firewall as well- routing, ACLs, etc?  Are you monitoring the switch to see if you are exceeded an aggregate 1 Gbps from the combination of RX & TX?

Span ports are typically problematic.  Grab a dual-comm tap, they are very economical.

Thanks,

Liam Randall

On Sun, Jun 2, 2013 at 2:57 PM, Josh Patton <5265644...@gmail.com> wrote:

I actually had some issues several months ago when I let the wizard to set up the NIC, I believe some settings were not available with the card I was using and through the troubleshooting I realized setting the NIC back to the way I used it with debian/snort made the issue go away.  It's been so long I can't even recall the issue. As soon as you said wizard I realized what I probably overlooking.

I will go over that full packet capture guide and see what I am missing.  That being said I don't have any rx_long_length_errors and nothing from the ethtool output jumps out at me as severe (attached).  My ethtool -k does show some basics that don't match the comments Doug made on the page you linked though so I will start with those changes.

And just to finish of answering your questions -
no dot1q through this monitored traffic, all traveling over a native vlan so it is untagged

I am on a span port(s) at the ingress/egress right behind the firewall.

Thanks for the quick reply Liam