Looking at the policy file (netstats.bro) I am inclined to think that these=
notices are generated because of bro filter. Please correct me here.=20
I'm not sure what you mean by "because of bro filter", but those reports
are generated based on retrieving statistics from libpcap, and "after
filtering" means after applying the filter Bro specified to pcap, which
you can see using print-filter.bro.
What I cannot answer/understand right now is:
Is there any way I can find out is bro actually dropping packets, if at all=
?
Look for AckAboveHole and ContentGap notices. These can both happen for
other reasons, but primarily happen due to dropped packets.
Look for AckAboveHole and ContentGap notices. These can both happen for
other reasons, but primarily happen due to dropped packets.
I looked in previous logs and found no alerts what so ever for AckAboveHole and ContentGap to realize that brolite had notice_ignore for them.
# Remove these notices from logging since they can be too noisy.
redef notice_action_filters += {
[[ContentGap, AckAboveHole]] = notice_ignore,
};
Which I changed to file_notice.
[[ContentGap, AckAboveHole]] = file_notice,
So. in last 1h15m I have 165065 ContentGap and 36596 AckAboveHole notices. Is this normal (noisy?) or is this the traffic getting dropped ?
And by getting dropped - do we mean that bro is not processing this traffic ?
2) Also Can I put it this way :
Of all traffic we get on interfaces we filter a part using bro filter (packetdrop notices) and then there are dropped packets (AckAboveHole and ContentGap notices) and then rest of the traffic is processed by bro ?
I'm not sure what you mean by "because of bro filter", but those reports
Here, I meant is since we have applied bro-filter, all these packet drops could be accounted for. (they are dropped by the bro-filter)
Thanks a lot for all the help. We have been constantly tuning bro and results are great.