From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 21:27:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CCD516A46C for ; Sun, 6 Jan 2008 21:27:04 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx7.mail.ru (mx7.mail.ru [194.67.23.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5EAA013C47E for ; Sun, 6 Jan 2008 21:27:04 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from [78.140.2.250] (port=53202 helo=nuclight.avtf.net) by mx7.mail.ru with esmtp id 1JBd1K-000EnW-00 for freebsd-net@freebsd.org; Mon, 07 Jan 2008 00:27:02 +0300 Date: Mon, 07 Jan 2008 03:27:01 +0600 To: freebsd-net@freebsd.org References: <4781337B.40104@alastria.net> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4781337B.40104@alastria.net> User-Agent: Opera M2/7.54 (Win32, build 3865) Subject: Re: Implementation of Sampling for BPF X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 21:27:04 -0000 07.01.08 @ 02:00 Peter Wood wrote: > Hey All, > > I piped up a couple of weeks before Christmas regarding a need to > control or at > least reliably predict which packets a system would drop if too many > packets > where being received by the kernel destined for a BPF program. My > particular > example here is a copy of Snort monitoring a mirror of two 1000mbs > lines, with > data rates averaging about 900mbs now. > > As you can imagin with a reasonable Snort ruleset the kernel is being > forced to > drop packets before Snort can process all data sent to it, it is the > uncertainly of a fair sample (or lack of) that I'm worried about. [...] I don't think that modifying bpf.c is good solution, as userland is not the only consumer of BPF, think, for example, about ng_bpf. Moreover, what is the purpose of sampling, after all? BPF was never intended to be reliable every-packet solution. If you are monitoring in userland, Snort of course will not have enough time to process all of your data, so why not simply put at least two machines in parallel, one for each mirrored line? -- WBR, Vadim Goncharov