From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 B913B75DBB for ; Wed, 14 Jul 2021 08:20:00 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id A7532BC88 for ; Wed, 14 Jul 2021 08:19:30 +0200 (CEST) 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 id 35C5FBC79 for ; Wed, 14 Jul 2021 08:19:30 +0200 (CEST) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id F290341027; Wed, 14 Jul 2021 08:19:29 +0200 (CEST) Message-ID: <26cb0ae8-18d6-436e-4932-7e9ed812de24@proxmox.com> Date: Wed, 14 Jul 2021 08:19:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Thunderbird/90.0 Content-Language: en-US From: Thomas Lamprecht To: Proxmox VE development discussion , alexandre derumier Reply-To: Proxmox VE development discussion References: <75efa993d34cb722b91d0a1b378664c3d026f2a9.camel@odiso.com> <3ac18ec6-e4e2-e52e-a5a0-0949b4b6eccb@proxmox.com> In-Reply-To: <3ac18ec6-e4e2-e52e-a5a0-0949b4b6eccb@proxmox.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.631 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment NICE_REPLY_A -0.368 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2021 06:20:00 -0000 On 14.07.21 07:38, Thomas Lamprecht wrote: > On 13.07.21 07:16, alexandre derumier wrote: >> Hi, >> it seem that it's possible to enable some policy on bridge in ifupdown2 >> >> >> cumulus linux distro for example, have this policy >> >> $ cat /var/lib/ifupdown2/policy.d/bridge.json >> { >> "bridge": { >> "module_globals": { >> "warn_on_untagged_bridge_absence": "yes", >> "vxlan_bridge_default_igmp_snooping": "off", >> "allow_arp_nd_suppress_only_on_vxlan": "yes", >> "bridge_set_static_mac_from_port": "yes" >> }, >> "defaults": { >> "bridge-stp": "on", >> "bridge-vlan-stats" : "on", >> "bridge-mcstats" : "on", >> "bridge-portprios": "8", >> "bridge-hashel": "4096", >> "bridge-hashmax": "4096", >> "bridge-ageing": "1800" >> } >> } >> } >> >> >> bridge_set_static_mac_from_port could be usefull to reuse physical >> interface mac on bridge. >> > > sounds good in theory, but to which port? As with more than one it's important > to be deterministic - that's why we had that kernel patch in the first place. Found it, they use first in port list, which is almost always good. But if one would add another bridge port or switch order of existing ones, and then do a `ifreload -a` it could change the bridge MAC address? I mean, it happens in the `up_bridge` function, not sure if that is called on reload or just when really doing something like `ifdown vmbr0; ifup vmbr0`