Re: conntrackd master-master IPv4/IPv6 configuration order

Hi Yenya,

On Tue, 2 Jun 2026, at 8:44 PM, Jan Kasprzak wrote:
> Hi Kerin,
>
> thanks for your insights. Some follow-up question:
>
> Kerin Millar wrote:
>> # To be run by the script that commits the IPv4 states into the kernel
>> conntrackd -C /etc/conntrackd/conntrackd-v4.conf -c
>>
>> # To be run by the script that commits the IPv6 states into the kernel
>> conntrackd -C /etc/conntrackd/conntrackd-v6.conf -c
>>
>> The same goes for the -f (flush) and -R (resync) options.
>
> I have been thinking about going without takeover actions altogether.
> What could possibly go wrong if I commit the state from an external
> table to the standby node kernel periodically? For example, to run
> conntrackd-v[46].timer systemd unit on the standby node[s] all the time,
> committing the data to the standby node every few (tens of) seconds,
> and should the master node go down, use the data from the last commit.

You could set "DisableExternalCache on", which would allow for the received replicated states to be committed to the kernel conntrack table in realtime. I have never used such a configuration myself. However, I can say that there are some caveats to be aware of. One is that you may need to size the conntrack table accordingly. Another is that the write path becomes more costly, since it reaches into kernel space all the time (event type filtering may help to mitigate this).

--
Kerin Millar