Date: Wed, 17 May 2017 12:33:46 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219316] Wildcard matching of ipfw flow tables Message-ID: <bug-219316-8-59k35TH9UQ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219316-8@https.bugs.freebsd.org/bugzilla/> References: <bug-219316-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219316 Andrey V. Elsukov <ae@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org --- Comment #6 from Andrey V. Elsukov <ae@FreeBSD.org> --- (In reply to lutz from comment #0) > Consequently a deterministically selected group of clients has to share t= he > same NAT table using a single external IP. A typical approach is to use > wildcards to match the right NAT instance: >=20 > add 2100 nat 100 ipv4 from 100.64.0.0:255.192.0.63 to any xmit ext out > add 2101 nat 101 ipv4 from 100.64.0.1:255.192.0.63 to any xmit ext out > add 2102 nat 102 ipv4 from 100.64.0.2:255.192.0.63 to any xmit ext out > ... >=20 > This approach is inefficient, tables could help. But tables does not supp= ort > wildcard masking of lookup data. With such an wildcard mask, especially t= he > flow tables could greatly improve performance. Can you provide an example how your patches solve this problem? Some commands/rules that you use for configuration would be good. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219316-8-59k35TH9UQ>