ipt_CLUSTERIP is deprecated and it will removed soon, use xt_cluster instead

[Ralf Hildebrandt]

pacemaker still uses iptable's "CLUSTERIP" -- and dmesg shows a deprecation warning:

[ 15.027333] ipt_CLUSTERIP: ClusterIP Version 0.8 loaded successfully
[ 15.027464] ipt_CLUSTERIP: ipt_CLUSTERIP is deprecated and it will removed soon, use xt_cluster instead

~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
CLUSTERIP all -- anywhere proxy.charite.de CLUSTERIP hashmode=sourceip-sourceport clustermac=EF:EE:6B:F9:7B:67 total_nodes=4 local_node=2 hash_init=0

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: pacemaker 1.1.14-2ubuntu1.1
ProcVersionSignature: Ubuntu 4.4.0-38.57-generic 4.4.19
Uname: Linux 4.4.0-38-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
Date: Fri Sep 23 17:26:01 2016
InstallationDate: Installed on 2014-08-19 (766 days ago)
InstallationMedia: Ubuntu-Server 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.3)
SourcePackage: pacemaker
UpgradeStatus: Upgraded to xenial on 2016-09-22 (1 days ago)

[Christian Ehrhardt  (paelzer)]

Hi,
I tried to recreate the issue by adding a clusterip like in the examples:

pcs resource create ClusterIP IPaddr2 ip=192.168.0.120 cidr_netmask=32

But at least for me that didn't trigger anything.
I might just not have a complete enough configuration to show the issue. I guess I need to config further and start what I defined. It would be nice if you could share whatever you consider required to reproduce.

Looking at the sources I don't see that Ubuntu does anything special to add or select clusterip.
So my assumption would be that this is an upstream bug, but I'd like to see a bit more of what you can share to reproduce before finally deciding on that.

[Christian Ehrhardt  (paelzer)]

And yeah I have seen the kernel code reference calling it deprecated [1] for years [2].
But still that would be an upstream feature request.

The same applies btw to the strongswan hw plugin

[1]: https://github.com/torvalds/linux/blob/master/net/ipv4/netfilter/ipt_CLUSTERIP.c#L510
[2]: https://github.com/torvalds/linux/commit/43270b1bc5f1e33522dacf3d3b9175c29404c36c

[Andreas Hasenack (ahasenack)]

For strongswan, I found a reference in a 2018 workshop to work on xt_cluster support: https://wiki.strongswan.org/projects/strongswan/wiki/Linux_IPsec_Workshop_2018

No open bug reports about moving from ipt_CLUSTERIP to xt_cluster, just references in old bugs about how that was wanted, but just not done yet.

For pacemaker, I couldn't find results even mentioning the problem, other than this bug.

Looks like it will be some time still until ipt_CLUSTERIP is abandoned.

[Rafael David Tinoco (rafaeldtinoco)]

commit 92c49b6f2847546f3f938b10a2a97021774f0be3
Author: Jan Pokorný <email address hidden>
Date: Wed Dec 4 14:36:59 2019 +0100

    IPaddr2: ipt_CLUSTERIP "iptables" extension not "nft" backend compatible

    Reference:
    https://lists.clusterlabs.org/pipermail/users/2019-December/026674.html
    (thread also sketches a future ambition for a [presumably, to revert
    the habit of a functional overloading] separate agent to use
    "xt_cluster" extension/cluster match).

    Signed-off-by: Jan Pokorný <email address hidden>

---

It is a well known upstream decision and it has been recently documented in v4.5.0 of "resource-agents".

The following resource-agent description is about to get added to Focal when FFe:

https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1866383

is accepted and merge is finished.

[Rafael David Tinoco (rafaeldtinoco)]

I'm marking this as Fix Released as the Focal FFe (v4.5.0) will likely be accepted and there is a reference there for this bug. There is also the fact that there is no *fix* properly saying: its just a reference saying upstream knows about this issue and ignores it on purpose for now. If ffe is not accepted, I can always revisit this.