[Jool-list] Active-active NAT64

[Nico Schottelius]

Hey Alberto,


Alberto Leiva <ydahhrk at gmail.com> writes:

>> a follow up from the recent joold discussion: how would one run
>> active-active NAT64 with jool? We would like to get rid of keepalived in
>> our setup and so far we decided to statically assign the routing IPs to
>> both routers.
>
> ss-enabled: true
> ss-flush-asap: true
> ss-flush-deadline: default is fine
> ss-capacity: default is fine
> ss-max-payload: <MTU of the link the translators are using to share
> traffic

Interesting! I have just seen the full description, I missed a page on
jool.mx before.

>> What I'd assume joold could do is basically asking the other side, if it
>> already has a session (if no entry is in the local table) and then
>> create an entry on both sides, if there isn't.
>
> The current implementation works the opposite way: Every time one of
> the translator updates a session, it multicasts this change to let the
> other translators know. There are no requests; only pushes.
>
> Of course, this only works if this multicast traffic is reliably
> faster than the normal (translating) traffic. If the normal traffic is
> faster, all translators risk working with stale data.
>
> I think the approach you're describing is somewhat more reliable, but
> also substantially slower and not completely free from synchronization
> issues. Suppose you have translators A and B, and both receive packets
> from a stream from N6 (port 1234) to N4 (port 80):
>
> 1. A receives the first packet of the N6#1234 -> 64:ff9b::N4#80
> stream. A asks "Who has a session for this packet?"
> 2. B receives the second packet of the N6#1234 -> 64:ff9b::N4#80
> stream. B asks "Who has a session for this packet?"
> 3. A responds "I don't."
> 4. B responds "I don't."
> 5. A creates session entry N6#1234 | 64:ff9b::N4#80 | A#5678 | N4#80
> 6. B creates session entry N6#1234 | 64:ff9b::N4#80 | A#9123 | N4#80
>
> As you can see, we just created a conflict.

I wonder, if this is actually a "real" problem: we only need session
sychronisation to have the "minimum set", having multiple entries
(besides wasting space) is not actually a problem:

N4#80-A5678 and N4#80-A9123 can both be returned to the client.
Reading the "fake NAT64" ticket, this would even be lesser of a
problem.

> The way I see it, active-active session synchronization is an
> unsolvable problem, which is why I was honestly thinking about
> removing it.

I can understand that. However, keepalived (alone) is not reliable
enough in our case to handle router failures. So maybe neither
keepalived nor active-active might be the proper solution.

I'll brainstorm a bit internally and come back to you soon.

Best,

Nico


--
Modern, affordable, Swiss Virtual Machines. Visit www.datacenterlight.ch