On 03/12/19 23:38 +0100, Valentin Vidić wrote: > On Tue, Dec 03, 2019 at 11:14:41PM +0100, Jan Pokorný wrote: >> The conclusion is hence that even with bleeding edge software >> collection, there's no real problem in using ipt_CLUSTERIP >> (when compiled in or alongside kernel) when a proper interface >> is used, which may boil down to using an appropriate version of >> iptables command. The respective logic to select the proper one >> could be easily extended in the IPaddr2 agent (sorry, I mis-cased >> this name previously; in a nutshell: if there's iptables-legacy >> command, prefer that instead), which looks far more attainable >> than porting to xt_cluster any time soon unless there are >> volunteers. > > Indeed, I have tested with 2 nodes and TCP connections work as > expected: packets arrive at both nodes but only one of them > responds - sometimes the first node and sometimes the second. > > For ARP both nodes respond with the same multicast MAC: > > 22:33:14.231779 ARP, Request who-has 192.168.122.101 tell 192.168.122.1, > length 28 > 22:33:14.231833 ARP, Reply 192.168.122.101 is-at 21:53:69:51:3e:b1, length 28 > 22:33:14.231833 ARP, Reply 192.168.122.101 is-at 21:53:69:51:3e:b1, length 28 > >> Is there any iptables-legacy command equivalent in Debian? > > Yes, iptables package in Debian installs both: > > /usr/sbin/iptables-legacy > /usr/sbin/iptables-nft > > so the agent can be modified to prefer iptables-legacy over > iptables.
Perfect, thanks for the affirmation, Valentin. -> https://github.com/ClusterLabs/resource-agents/pull/1439 For the record, based on my feedback, iptables-extensions man page is headed to (finally) align with the actual in-kernel deprecation message: https://lore.kernel.org/netfilter-devel/20191204130921.2914-1-p...@nwl.cc/ Woot! -- Jan (Poki)
pgpi0b3Lz8I_i.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
