[Bug 219316] Wildcard matching of ipfw flow tables

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219316

--- Comment #9 from Julian Elischer <julian at FreeBSD.org> ---
(In reply to lutz from comment #0)
>For Carrier Grade NAT environments any simple NAT table selection is not usable:
>
>1) Large Scale NAT violates the happy eyeball requirement, that a given client
> should always use the same external IP while communicating to a given service.

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 the
> same NAT table using a single external IP. A typical approach is to use 
> 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 small
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
> ...
> 
> This approach is inefficient, tables could help. But tables does not support
> wildcard masking of lookup data. With such an wildcard mask, especially the
> 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?

-- 
You are receiving this mail because:
You are the assignee for the bug.