[Bro] Troubleshooting crashes
tritium.cat at gmail.com
Mon Sep 17 17:18:38 PDT 2012
On Mon, Sep 17, 2012 at 7:56 PM, Tyler T. Schoenke <
tyler.schoenke at colorado.edu> wrote:
> On 9/11/12 2:34 PM, Tritium Cat wrote:
> > > 614589 data_before_established
> > > 585445 possible_split_routing
> > I'm a little curious about these two. Normally lots of these lines
> > indicates that something is wrong with how Bro is collecting
> > packets. I'm interested to find out if these go away when you adapt
> > the snap length. Is the MTU of your network actually 9600 or did
> > you just set that MTU for the interface to the maximum it would
> I was seeing a lot of these as well. I am mirroring two ports, hence a
> lot of duplicate traffic. Are you doing something similar? When I had
> my networking engineer turn off one of the mirrored ports, I saw a 60%
> reduction in data_before_established and 66% decrease in
> possible_split_routing. I'm comparing data between the same hour on
> Thursday and Friday, so some of that drop is related to a normal drop in
> traffic, but most is probably turning off the mirror.
No. It was due to the traffic being 802.1Q tagged and the default hashing
algorithm for PF_RING. The default hashing included the VLAN id and in
this network the traffic is tagged according to peering session and
direction of flow; as a result a "5-tuple" flow is really two "6-tuple"
flows so the flow ends up split among different workers.
I think the fix should be as easy as including another PF_RING environment
variable when starting bro.
The way I understand possible_split_routing means bro is missing some
packets so you should check the front-end setup.
grep -n -B5 possible_split src/TCP.cc
521- // We've already sent a SYN, but that
522- // hasn't roused the other end, yet we're
523- // ack'ing their data.
525- if ( ! Conn()->DidWeird() )
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Bro