From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <a.lauterer@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id 068E290A24
 for <pve-devel@lists.proxmox.com>; Fri, 24 Mar 2023 14:03:49 +0100 (CET)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id DD9A1BB35
 for <pve-devel@lists.proxmox.com>; Fri, 24 Mar 2023 14:03:48 +0100 (CET)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS
 for <pve-devel@lists.proxmox.com>; Fri, 24 Mar 2023 14:03:48 +0100 (CET)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 02AEE46876
 for <pve-devel@lists.proxmox.com>; Fri, 24 Mar 2023 14:03:48 +0100 (CET)
From: Aaron Lauterer <a.lauterer@proxmox.com>
To: pve-devel@lists.proxmox.com
Date: Fri, 24 Mar 2023 14:03:47 +0100
Message-Id: <20230324130347.737762-1-a.lauterer@proxmox.com>
X-Mailer: git-send-email 2.30.2
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL -0.090 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DMARC_MISSING             0.1 Missing DMARC policy
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: [pve-devel] [PATCH docs] network: rephrase corosync and bonds
 recommendations
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Fri, 24 Mar 2023 13:03:49 -0000

I suspect that the old one seems to be related to multicast traffic and
LACP bonds.

The link in the comment is dead by now. It seems this is one occasion
where the internet actually forgets as I cannot find the actual message
of that mailing list thread anymore. Therefore I cannot say for sure
what the exact issue was. But it was introduced in commit
649098a64ecaffc7215ec0556e76787595b38e88 which unfortunately also
doesn't have more information.

Since with Corosync 3, unicast is used, that recommentation is probably
not accurate anymore. At least I am not aware of any issues with
Corosync on LACP bonds in recent years. Therefore, rather recommend to
configure Corosync on multiple networks instead of bonds to follow best
practice.

Signed-off-by: Aaron Lauterer <a.lauterer@proxmox.com>
---
 pve-network.adoc | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/pve-network.adoc b/pve-network.adoc
index 0c67c62..4567ed4 100644
--- a/pve-network.adoc
+++ b/pve-network.adoc
@@ -337,11 +337,11 @@ traffic.
 
 If your switch support the LACP (IEEE 802.3ad) protocol then we recommend using
 the corresponding bonding mode (802.3ad). Otherwise you should generally use the
-active-backup mode. +
-// http://lists.linux-ha.org/pipermail/linux-ha/2013-January/046295.html
-If you intend to run your cluster network on the bonding interfaces, then you
-have to use active-passive mode on the bonding interfaces, other modes are
-unsupported.
+active-backup mode.
+
+For the cluster network (Corosync) we recommend configuring it with multiple
+networks. Corosync does not need a bond for network reduncancy as it can switch
+between networks by itself, if one becomes unusable.
 
 The following bond configuration can be used as distributed/shared
 storage network. The benefit would be that you get more speed and the
-- 
2.30.2