From owner-freebsd-net@freebsd.org Sat Aug 24 19:34:36 2019 Return-Path: Delivered-To: freebsd-net@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 36A54C8494 for ; Sat, 24 Aug 2019 19:34:36 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:c2c:26d8::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 46G7kg0DNzz42lG for ; Sat, 24 Aug 2019 19:34:34 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x7OJYGr8012622 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 24 Aug 2019 19:34:20 GMT (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: vit@otcnet.ru Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x7OJY8MP050593 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 25 Aug 2019 02:34:08 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: finding optimal ipfw strategy To: Victor Gamov , freebsd-net@freebsd.org References: From: Eugene Grosbein Message-ID: <4ff39c8f-341c-5d72-1b26-6558c57bff8d@grosbein.net> Date: Sun, 25 Aug 2019 02:34:00 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: 46G7kg0DNzz42lG X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-4.35 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; IP_SCORE(-1.27)[ip: (-2.54), ipnet: 2a01:4f8::/29(-1.96), asn: 24940(-1.85), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2019 19:34:36 -0000 25.08.2019 1:13, Victor Gamov wrote: > I have nonstandard network task for my FreeBSD box: > many VLANs bridged together via bridge interface and specific multicast traffic must be send > from one VLAN to many (but not all) other VLANs. It is quite standard filtering bridge :-) > I use ipfw to block traffic on unwanted outgoing interfaces. > > And my answer: which ipfw rules more optimal 1 or 2 (see 1 and 2 later) when I have about 100 incoming multicast and about 100 vlans? > > 1 > ===== > ipfw table Mcast1_iface_out create type iface > ipfw table Mcast1_iface_out add vlan20 > ipfw table Mcast1_iface_out add vlan30 > ipfw table Mcast1_iface_out add vlan40 > ipfw add 25000 allow udp from IP1 to mcast1 out via table(Mcast1_iface_out) If you are concerned of performance, general rule applies: less checks, better performance. First, use 'out xmit' instead of 'out via'. They are semantically equal and this is micro-optimization but it still saves extra check unneeded when combined with "out" keyword. Also, you should use old table numbers instead of new symbolic table names when you have many rules checking for interface names and much traffic because checks for numbered tables are slightly more efficient. You may use symbolic names still at source level: Mcast1_iface_out=1 ipfw table $Mcast1_iface_out create type iface Also, use table arguments and not only table values, do not ignore their existence: ipfw table $Mcast1_iface_out add vlan20 $mcast11 ipfw table $Mcast1_iface_out add vlan20 $mcast12 ipfw table $Mcast1_iface_out add vlan20 $mcast13 ipfw add 25000 allow udp from IP1 to tablearg out xmit "table($Mcast1_iface_out)" Note there is one single checking ipfw rules for all used pairs ($Mcast1_iface_out, $mcastXX) and this time it is not micro-optimization but very important one when you have plenty of mcastXX. Both of your first and second rulesets are less efficient comparing this one using tableargs.