From owner-freebsd-net@FreeBSD.ORG Thu Feb 19 04:18:17 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CC1A16A4CE for ; Thu, 19 Feb 2004 04:18:17 -0800 (PST) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A16D43D1F for ; Thu, 19 Feb 2004 04:18:16 -0800 (PST) (envelope-from glebius@cell.sick.ru) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.9/8.12.8) with ESMTP id i1JCICAB046378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2004 15:18:13 +0300 (MSK) (envelope-from glebius@cell.sick.ru) Received: (from glebius@localhost) by cell.sick.ru (8.12.9/8.12.6/Submit) id i1JCICx1046377; Thu, 19 Feb 2004 15:18:12 +0300 (MSK) Date: Thu, 19 Feb 2004 15:18:11 +0300 From: Gleb Smirnoff To: Andrew Riabtsev Message-ID: <20040219121811.GB46148@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Andrew Riabtsev , freebsd-net@freebsd.org References: <20040121114502.GC17802@cell.sick.ru> <20040218124958.GB40340@cell.sick.ru> <10796883310.20040219143402@b-o.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <10796883310.20040219143402@b-o.ru> User-Agent: Mutt/1.5.6i cc: freebsd-net@freebsd.org Subject: Re: ng_netflow: request for feature X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2004 12:18:17 -0000 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