I'm wondering whether we should turn on DPD by default in 1.6. Doing
so would involve two things:
(1) Loading the DPD signatures (i.e., dpd.bro)
(2) Setting the packet filter to include all packets.
The former shouldn't be a problem, but the latter would be a major
change. We'd still keep the current build-your-filter-dynamically
scheme, but it would have to be enabled explicity (say, with an
option in pcap.bro).
There's a further advantage to doing (2): it would eliminate one of
the most common mistakes: not realizing that Bro's filter doesn't
include what one wants to analyze. With a default-all filter, Bro
does what one would intuitively expect, and changing the filter to
be more restrictive could be filed under "performance tuning".
I like the idea. The common case seems to have become running with DPD enabled anyway. It would be one less thing for most people to have to configure as soon as they do the install. All as long as the filtering system gets some documentation.
Definitely a change to highlight in the INSTALL file and the FAQ page on the web. I imagine some people will be wondering why it slowed down for them on a 1.6 update because of that change. If this change isn't very clear, then they could just give up on 1.6.
I agree with the change. My performance issues seemed to be related to
how many alerts were firing. Once I turned off many of the alerts, the
cluster was more stable. I played with turning the dpd.bro off, and
didn't notice much performance improvement. I also didn't notice much
of a performance change when the packet filter was set to the default
set or all packets.
I think most people will have performance issues with the volume of
traffic they are processing. I was estimating 32 cores would be needed
to handle 1 Gbps comfortably. Our 8 cores are dropping typically around
5-20% of the traffic, while processing 580 Mbps. Using Click! was
critical to getting the cluster processing at a decent rate.
Turning off some of the less-needed alerts might help offset enabling DPD.
