[Jool-list] NAT64 pool4 size / error when too big

Alberto Leiva ydahhrk at gmail.com
Thu Nov 14 13:54:23 CST 2019


It's a bit of everything.

That warning does in fact mainly exist because I've seen quite a few
users shooting themselves in the foot by going straight to NAT64 when
in fact they are looking for an SIIT.

But there is, in fact, a performance implication. As an example, if
you insert a /30 to pool4, you will notice that Jool refuses to reduce
the addresses into a single entity:

$ sudo jool pool4 add 192.0.2.0/30 100-200 --tcp
$ sudo jool pool4 display --tcp
+------------+-------+--------------------+-----------------+-------------+
|       Mark | Proto |     Max iterations |         Address |       Ports |
+------------+-------+--------------------+-----------------+-------------+
|          0 |   TCP |       1024 ( auto) |       192.0.2.0 |   100-  200 |
|            |       |                    |       192.0.2.1 |   100-  200 |
|            |       |                    |       192.0.2.2 |   100-  200 |
|            |       |                    |       192.0.2.3 |   100-  200 |
+------------+-------+--------------------+-----------------+-------------+

As you can see, there are four different entries above. Ideally, the
table would be optimized into this:

+------------+-------+--------------------+-----------------+-------------+
|       Mark | Proto |     Max iterations |         Address |       Ports |
+------------+-------+--------------------+-----------------+-------------+
|          0 |   TCP |       1024 ( auto) |    192.0.2.0/30 |   100-  200 |
+------------+-------+--------------------+-----------------+-------------+

But this isn't the case due to the current implementation of the port
allocation routine. (The problem with that code is that it's rather
dense. It's trying to simultaneously fulfill quite a few requirements
coming from several different--and sometims contradicting--RFCs.)

So, if you add a /20 to pool4, the table will grow substantially. If
my math isn't failing me, a /20 is a table with like ~4000 entries.
Whether this will really slow you down or not is something you'd have
to test. Because of max-iterations [0], Jool will never need to do a
full table traversal, but it still needs to perform a table copy
during every translation for synchronization reasons. (memcpy()s are
usually compiler-optimized, and thus very fast.)

A /29 would be far lighter, and its performance degradation will
probably be negligible.

This quirk has a chance of being improved during the pool4 refactor
patch, which is #175 [1]. However, I can't guarantee that it will in
fact be included with the solution (because the refactor will make the
code even more dense). Also, this bug is scheduled to be addressed
after #221 and #114--so development would start about six months from
now, if everything goes according to plan.

As you probably know, you can always include --force to ignore the warning.

[0] https://jool.mx/en/pool4.html#algorithm-performance
[1] https://github.com/NICMx/Jool/issues/175

On Thu, Nov 14, 2019 at 12:17 PM Nico Schottelius
<nico.schottelius at ungleich.ch> wrote:
>
>
> Hello again,
>
> I just realised that while testing jool w/ pool4 in stateful NAT64,
> using bigger networks gives the following error message:
>
> fakerouter1:~# jool pool4 add 10.0.0.0/20 2-32000 --tcp
> Error: Warning: You're adding lots of addresses, which might defeat the whole point of NAT64 over SIIT.
> Error: Will cancel the operation. Use --force to override this.
>
> While we certainly won't need a /20 for the first productive site (it
> might actually be more like a /29), I wonder why this should be a
> problem?
>
> Haven't checked the code of jool, but isn't it something on the line of
> having a queue / O(1) based get_next_free_ip_port() in jool that
> shouldn't really care about the size of the IPv4 pool?
>
> Or is the motivation of the error (not warning) message solely to
> prevent people from trying to map a full IPv6 network (/112 or similar)
> to an IPv4 space?
>
> Best regards,
>
> Nico
>
> --
> Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch
> _______________________________________________
> Jool-list mailing list
> Jool-list at nic.mx
> https://mail-lists.nic.mx/listas/listinfo/jool-list


More information about the Jool-list mailing list