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

[Andrei Borzenkov]

14.01.2020 17:47, 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!)?
> 

That's how I understand it.

> 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?
> 

I expect MAC addresses be different (they are on different interfaces).
Copy-paste result?

If this is intentional and actually denotes same MAC, I have no
explanation and my guess is probably wrong.

> ($DEITY bless all the good people documenting even what
> seems obvious to them at the moment :-)
> 
> 
> _______________________________________________
> Manage your subscription:
> https://lists.clusterlabs.org/mailman/listinfo/users
> 
> ClusterLabs home: https://www.clusterlabs.org/
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20200114/92af74f1/attachment.sig>