Date: Mon, 07 Jan 2008 03:27:01 +0600 From: "Vadim Goncharov" <vadim_nuclight@mail.ru> To: freebsd-net@freebsd.org Subject: Re: Implementation of Sampling for BPF Message-ID: <opt4i1vb0x17d6mn@nuclight.avtf.net> In-Reply-To: <4781337B.40104@alastria.net> References: <4781337B.40104@alastria.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?opt4i1vb0x17d6mn>