<div>Vern,</div>
<div> </div>
<div>Thanks for this info. I had not realized that brolite was applying a number of filters. My main testing pcap was a large variety of services,protocols, and sessions. My testing was semi-automated to check packets sent vs packets bro received. The fillter scewed my results. I applied a redef to the packet filter and I am now seeing excellent statistics on the intel machine.</div>
<div> </div>
<div>I will use this information now to re-test on the Bivio platform.</div>
<div> </div>
<div> </div>
<div>// Joel </div>
<div> </div>
<div class="gmail_quote">On Tue, Mar 11, 2008 at 8:01 PM, Vern Paxson <<a href="mailto:vern@icir.org">vern@icir.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d">> I am running using Suse on PowerPC. I am also using specialty hardware from<br>> Bivio.<br>> I do not belive it is an issue with BPF.<br><br></div>Well, it's very likely *some* issue with packet capture, since I believe<br>
the difference between your policy-scripts-that-work and scripts-that-don't<br>is that the latter capture full-sized packets and the former basically don't.<br><br>Try this. Run with the set of scripts that work plus print-filter.bro to<br>
see what filter is being used. Then run with the scripts that don't work<br>plus print-filter and get that filter. See then how tcpdump fares using<br>each filter (along with -s 0 to capture full-sized packets).<br>
<br>If that doesn't shed light, then what are the dominant types of appications<br>in your traffic, and how do you fare using Bro setups that don't capture them?<br><br>We routinely run on traffic with 100+ Mbps traffic (18K pps), predominantly<br>
SSH and HTTP, without significant problems with drops.<br><font color="#888888"><br> Vern<br></font></blockquote></div><br>