From owner-freebsd-questions@freebsd.org Tue Aug 24 21:45:31 2021 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D60156675E9 for ; Tue, 24 Aug 2021 21:45:31 +0000 (UTC) (envelope-from 93ab.82.c3790001bedf7f.dbc6e9a2e9bf10a6baac14772c79def5@email-od.com) Received: from s1-b515.socketlabs.email-od.com (s1-b515.socketlabs.email-od.com [142.0.181.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4GvN2L2z9kz3RHc for ; Tue, 24 Aug 2021 21:45:30 +0000 (UTC) (envelope-from 93ab.82.c3790001bedf7f.dbc6e9a2e9bf10a6baac14772c79def5@email-od.com) X-Thread-Info: OTNhYi4xMi5jMzc5MDAwMWJlZGY3Zi5mcmVlYnNkLXF1ZXN0aW9ucz1mcmVlYnNkLm9yZw== Received: from r3.sg.in.socketlabs.com (r3.sg.in.socketlabs.com [142.0.179.13]) by mxh4.email-od.com with ESMTP; Tue, 24 Aug 2021 17:45:21 -0400 Received: from oceanview.tundraware.com (oceanview.tundraware.com [45.55.60.57]) by r3.sg.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Tue, 24 Aug 2021 17:45:21 -0400 Received: from [192.168.0.2] (ozzie.tundraware.com [75.145.138.73]) (authenticated bits=0) by oceanview.tundraware.com (8.16.1/8.16.1) with ESMTPSA id 17OLj2VQ077954 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 24 Aug 2021 16:45:03 -0500 (CDT) (envelope-from tundra@tundraware.com) To: FreeBSD Mailing List From: Tim Daneliuk Subject: ipfw Table Organization Message-ID: <9e6cd8e2-a06e-468b-7245-d5ff13309763@tundraware.com> Date: Tue, 24 Aug 2021 16:44:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.4 (oceanview.tundraware.com [45.55.60.57]); Tue, 24 Aug 2021 16:45:03 -0500 (CDT) X-TundraWare-MailScanner-Information: Please contact the ISP for more information X-TundraWare-MailScanner-ID: 17OLj2VQ077954 X-TundraWare-MailScanner: Found to be clean X-TundraWare-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-2.823, required 6, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, TW_PF 0.08) X-TundraWare-MailScanner-From: tundra@tundraware.com X-Spam-Status: No X-Rspamd-Queue-Id: 4GvN2L2z9kz3RHc X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[tundraware.com:s=slkey,email-od.com:s=dkim]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:142.0.176.0/20]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[tundraware.com:+,email-od.com:+]; DMARC_POLICY_ALLOW(-0.50)[tundraware.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[142.0.181.21:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[tundra@tundraware.com,93ab.82.c3790001bedf7f.dbc6e9a2e9bf10a6baac14772c79def5@email-od.com]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:53658, ipnet:142.0.180.0/22, country:US]; FROM_NEQ_ENVFROM(0.00)[tundra@tundraware.com,93ab.82.c3790001bedf7f.dbc6e9a2e9bf10a6baac14772c79def5@email-od.com]; MAILMAN_DEST(0.00)[freebsd-questions]; DWL_DNSWL_NONE(0.00)[email-od.com:dkim] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Aug 2021 21:45:31 -0000 Is there any particular advantage - performance or otherwise - to breaking up a large ipfw table into smaller tables? We have a few firewalls approaching 100,000 rules for blocking addresses and CIDR blocks. The IPS are read from separate text files in a loop in the firewall init code, but are all written to a single table. This is easy to maintain, but the concern is that we may be clobbering runtime performance. Thanks...