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 12C6275F39 for ; Wed, 14 Jul 2021 12:16:13 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 0FAD6F84A for ; Wed, 14 Jul 2021 12:16:13 +0200 (CEST) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 58FFBF83E for ; Wed, 14 Jul 2021 12:16:11 +0200 (CEST) Received: by mail-wr1-x431.google.com with SMTP id m2so2554726wrq.2 for ; Wed, 14 Jul 2021 03:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=odiso-com.20150623.gappssmtp.com; s=20150623; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version:content-transfer-encoding; bh=PIna9ip/OSWDKk7atyxYQ6I9P+Q8kR6pL7mI1X1DCP0=; b=rrx6dcYamjuTeLaZc6tu8v00OB2H7K4VH+i4cS/jH/KW4e1MVfpzjq5/kBRQKSy5gK AdpSID937+dOPNHbHoseJg12uCofFMVtdObKca+gKuHFdQvC4IU0hhItr4N8Z5pTi00H Asur3z7AtURAVpDRazRk6DedaLq7alMJRn6K1msbs9LNaV00G9VjuYl0V9WC9ydm9a/f sBXe4wzKtihXcMo2tnTDixBYIOd93m+d3LDpA9fQ5xpZIW5hXBHF/DYD4A/mGh+ek8S4 5UWf3tr/lJYeZG/vkh2Q9Lr/7+/IZ0tr/DrTXvSaf1Ei9q+r+TV9hQ3Yg09HyQJmG5Bw XPaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=PIna9ip/OSWDKk7atyxYQ6I9P+Q8kR6pL7mI1X1DCP0=; b=JukXQvPD9E46nZ8/0kQDtuVyeQ88BjoVpkJ39D254hnh+BuSiYEnVAOWKLVnxk8y02 gL/nVmigiaykbJ07hXJLky0nR5Jv+Gt2T9Pj9KImIXPXP3MDpMdjjV/E1sigv0wpjtnd NI3w5UOnmS1d9dmAisKpNy+9k93KRz6TtNLd7v7SGD+BKoAsZ7z/dfKjisZHbvEojfyt AlTifrl3/E/bOFmvR8aRYsFfFamaUD/Cr4TKfDq821FcvhZoiP4XpFe8j3wTKOICmZ9G /TlG5MC9x33gYwXzNRgNeDnct8AN3+FNNlpykInl3ABfUUwyqjTUc1lh9IIfOJZY4z6r iS3A== X-Gm-Message-State: AOAM533Ko+CRXf2dQcWcDPHKiJYPakVSiYHCBlQmr754FXo/pbDr9lOE 7iAz1fbdDZRgPRw94Adojkd3cqamMAUkl3r9 X-Google-Smtp-Source: ABdhPJyNl4Pc6HuVZjyycyPkqyQlvHGkqDFKm1MT6uGxVhnu6Q4YFKnAuauO5MBLxlf5rFEwqw0NXg== X-Received: by 2002:a5d:4b44:: with SMTP id w4mr11449348wrs.275.1626257764902; Wed, 14 Jul 2021 03:16:04 -0700 (PDT) Received: from [192.168.178.50] ([79.132.252.54]) by smtp.gmail.com with ESMTPSA id v30sm2204644wrv.85.2021.07.14.03.16.04 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jul 2021 03:16:04 -0700 (PDT) Message-ID: <8d82333c425f5039c5f8ac15887574344f7e7cad.camel@odiso.com> From: alexandre derumier To: Proxmox VE development discussion Date: Wed, 14 Jul 2021 12:16:04 +0200 In-Reply-To: <26cb0ae8-18d6-436e-4932-7e9ed812de24@proxmox.com> References: <75efa993d34cb722b91d0a1b378664c3d026f2a9.camel@odiso.com> <3ac18ec6-e4e2-e52e-a5a0-0949b4b6eccb@proxmox.com> <26cb0ae8-18d6-436e-4932-7e9ed812de24@proxmox.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.830 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust 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 10:16:13 -0000 > 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` I will do tests to be sure.  I don't known if users have usecases with 2 physical interfaces in 1 vmbr without bonding ? Main impacted users are public hosting where ip/mac couple is filtered, so they never have more than 1 interface. some doc about this option: https://support.cumulusnetworks.com/hc/en-us/articles/360005695794- Cumulus-Linux-Derivation-of-MAC-Address-for-a-Bridge Le mercredi 14 juillet 2021 à 08:19 +0200, Thomas Lamprecht a écrit : > 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` >