Date: Sat, 20 May 2017 15:52:35 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ipfw@FreeBSD.org Subject: [Bug 219316] Wildcard matching of ipfw flow tables Message-ID: <bug-219316-7515-Lq75OIfVdv@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219316-7515@https.bugs.freebsd.org/bugzilla/> References: <bug-219316-7515@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 --- Comment #9 from Julian Elischer <julian@FreeBSD.org> --- (In reply to lutz from comment #0) >For Carrier Grade NAT environments any simple NAT table selection is not u= sable: > >1) Large Scale NAT violates the happy eyeball requirement, that a given cl= ient > should always use the same external IP while communicating to a given ser= vice. On what timescale? Forever? If a client is idle for 5 minutes (no sessions)= can it start using a new IP? > >2) Mapping all customers to a single IP does not work either, because there > are too much connections originating by those customers. How may remote addresses are you talking too? You can reuse the same address and port to may different remote addresses.. > > 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=20 > wildcards to match the right NAT instance: you just said that "Mapping all customers to a single IP does not work .." and yet that is what you show here.. Am I misreading it? How many clients are we talking about here? 10? 100? 1000? 10K? 100K? 1M? and are these clients all on separate hardware? or are they coming from a s= mall number of session aggregator machines? > > 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. I don't quite understand this bit my memory is that you can have a table 100.64.0.0:255.192.0.63 0 100.64.0.1:255.192.0.63 1 100.64.0.2:255.192.0.63 2 ... etc followed by nat tablearg ip from table (x) to any out xmit XX0 now getting the return packets back to the same NAT instance could be a challenge depending on what the NAT does but it should be possible if each = NAT uses a different address as you suggest. what am I missing? --=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-7515-Lq75OIfVdv>