Date: Thu, 19 Feb 2004 15:18:11 +0300 From: Gleb Smirnoff <glebius@cell.sick.ru> To: Andrew Riabtsev <resident@b-o.ru> Cc: freebsd-net@freebsd.org Subject: Re: ng_netflow: request for feature Message-ID: <20040219121811.GB46148@cell.sick.ru> In-Reply-To: <10796883310.20040219143402@b-o.ru> References: <20040121114502.GC17802@cell.sick.ru> <20040218124958.GB40340@cell.sick.ru> <10796883310.20040219143402@b-o.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 19, 2004 at 02:34:02PM +0300, Andrew Riabtsev wrote: A> GS> a port of ng_netflow has been just commited to ports A> GS> tree. It builds both on STABLE and CURRENT, and was tested A> GS> to work on really busy routers. A> GS> As before, I'd be glad for any kind of feedback: ideas, A> GS> patches and else. Thanks. A> A> GS> (Also crossposted to -net). A> A> Few requests: A> A> 1. Is it possible to include ability in that module to turn on rule: A> (accounted = passed) or other words (not accounted = not passed)? In most cases the answer is no. In 90 % cases ng_netflow is used on top of ng_ether(4) node, which passes all data coming on wire. All packet filtering with help of ipfw or ipf are done later. You can try some workarounds using ng_bpf(4) just between ng_netflow and ng_tee(4), but I have not tested such configurations. A> 2. And there is one possible vulnerability. I've tryed A> ng_ipacct befor, as I undestand ng_netflow source code based on A> ng_ipacct, and found the following problem. No matter how much free mem A> has kernel soon or later all mem will be filled with "garbage" if A> "smart" host generates the following trafic, for example: A> A> 14:06:31.194057 95.18.81.203 > 81.176.66.50: icmp: echo request A> 14:06:31.194058 95.18.81.203 > 81.176.66.50: icmp: echo request A> 14:06:31.194059 95.18.81.203 > 81.176.66.50: icmp: echo request A> 14:06:31.194060 95.18.81.203 > 81.176.66.50: icmp: echo request A> 14:06:31.194061 95.18.81.203 > 81.176.66.50: icmp: echo request A> ... A> and so on A> ... Either you have incorrectly described the situation or you are not right at all. The tcpdump you showed is the perfect situation for any traffic accounting soft, because it does not generate any new entries, it just increments byte and packet counters on one entry. A> It could be icmp request, or tcp syn, or udp or anything else, the A> point is to generate as much outgoing packets as it possible, sometimes it A> does few hosts. The result is huge lag (huge accounting hash table A> each packet going throw) and very soon box becomes unavalible to do I am using ng_ipacct in production, and I have never faced such a situation. May be you do not checkpoint/clear accounting database, and it grows to a huge size during some hours? Normal checkpoint interval is 15 minutes. A> any tasks even routing. Is it possible to include ability to limit A> amount of records in accounting hash table for src addr? With policy A> (not accountes = not passed) it will protect box from this kind of A> attacks. Limiting amount of memory used by accounting A> table to not let it grow into huge laggy monster leads to fill with A> "garbage" account table and no more traffic accounting till new check A> point comes. Such things will lead to loss of accounting data. However I have never faced such a problem. May be your problem is a slow box itself? I'm running ng_netflow on 5 FE interfaces that are sometimes running at wire speed with up to 3000 simultaneous flows and I see no real load on it. It is some Athlon XP. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040219121811.GB46148>