[ClusterLabs] Making xt_cluster IP load-sharing work with IPv6

[Jan Pokorný]

On 11/01/20 19:47 +0300, Andrei Borzenkov wrote:
> 04.01.2020 01:42, Valentin Vidić пишет:
>> On Thu, Jan 02, 2020 at 09:52:09PM +0100, Jan Pokorný wrote:
>>> What you've used appears to be akin to what this chunk of manpage
>>> suggests (amongst others):
>>> https://git.netfilter.org/iptables/tree/extensions/libxt_cluster.man
>>> 
>>> which is (yet another) indicator to me that xt_cluster extension
>>> doesn't carry that functionality on its own (like CLUSTERIP target
>>> did, as mentioned).
>> 
> ...
>> 
>>> * But it doesn't explain the suggested destination MAC renormalization
>>> * on INPUT, which is currently yet to be heard of for our purpose...
>> 
>> I did not use the INPUT rules from the xt_cluster documentation and
>> to be honest don't understand the setup described there.
>> 
> 
> ARP RFC says that on reply source and target hardware addresses are
> swapped, so reply is supposed to carry original source MAC as target
> MAC. AFAICT Linux ARP driver does not check it, but I guess it is good
> practice to make sure received packet conforms to standard's requirement.

Ah, thanks.

So does it mean that the initiator of the ARP request would assume the
native MAC address of the interface was used (possibly remembering it),
then OUTPUT rule would overwrite the source unconditionally, and upon
delivery of the response back (with said source-target flip performed
by the responder), the INPUT rule would overwrite it back, so that
said initiator would be happy even if it performed said
guarantee-verification per said RFC (or possibly connection
tracking facility of the firewall that might make these
RFC-imposed assumptions, even!)?

Makes sense, unless I am distoring it even more :-)

What confused me is that 00:zz:yy:xx:5a:27 appears as if the same
address shall be used -- but in your explanation, it would definitely
be that case, correct?

($DEITY bless all the good people documenting even what
seems obvious to them at the moment :-)

-- 
Poki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20200114/e9fe2f50/attachment.sig>