Re: conntrackd master-master IPv4/IPv6 configuration order

	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.

Of course I will use a dedicated socket and port (I use UDP, not mcast)
for each instance.

Possible package enhancement:
provide a [email protected] unit template, which would use
/etc/conntrackd/%I.conf configuration file. Also, the control socket
should probaly live in /run/conntrackd instead of
/var/lib/conntrackd.

-Yenya

> > Or maybe I should run two instances of conntrackd on each node,
> one for
> > synchronizing IPv4 by default in one direction, and other one for IPv6
> > by default in the opposite direction, and having dedicated scripts
> > for promoting to master/demoting to standby/starting up for IPv4
> and IPv6.
>
> The idea of running two instances is sensible. That way, there can
> be a distinct failover procedure for both address families. If you
> do this, remember to give each instance its own UNIX socket path,
> lock file and multicast group/port so that they don't clash.
>
> Also, note that conntrack states are not synchronised in
> one direction. Rather, they are replicated in both directions
> continuously. A receiving node holds the replicated states in a
> so-called external cache until such time as they are committed. The
> commit operation injects them into the kernel conntrack table that
> Netfilter actually consults. The internal cache acts as a mirror of
> the kernel conntrack table (the commit operation does not touch that
> particular cache).
>
> >
> > And two separate conntrackd configs filtering out the unwanted
> L3 protocol
> > by universal prefix address:
> >
> >         Filter From Kernelspace {
> >		Address Ignore { IPv4_address 0.0.0.0/0 }
> >		    # or Address Ignore { IPv6_address ::/0 }
> >		...
> >	}
> >
>
> Yes, this should work exactly as you expect. The first directive should
> result in state changes pertaining to IPv4 being ignored. Likewise
> for the second, only pertaining to IPv6.
>
> --
> Kerin Millar

-- 
| Jan "Yenya" Kasprzak <kas at {fi.muni.cz - work | yenya.net - private}> |
| https://www.fi.muni.cz/~kas/                        GPG: 4096R/A45477D5 |
    I don't like Python; its lack of inline, anonymous, multi-statement
    functions makes me sad.                                --Eric Wastl