From: alexandre derumier <aderumier@odiso.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy
Date: Wed, 14 Jul 2021 12:16:04 +0200 [thread overview]
Message-ID: <8d82333c425f5039c5f8ac15887574344f7e7cad.camel@odiso.com> (raw)
In-Reply-To: <26cb0ae8-18d6-436e-4932-7e9ed812de24@proxmox.com>
> 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`
>
next prev parent reply other threads:[~2021-07-14 10:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-13 5:16 alexandre derumier
2021-07-14 5:38 ` Thomas Lamprecht
2021-07-14 6:19 ` Thomas Lamprecht
2021-07-14 10:16 ` alexandre derumier [this message]
2021-07-14 10:53 ` alexandre derumier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d82333c425f5039c5f8ac15887574344f7e7cad.camel@odiso.com \
--to=aderumier@odiso.com \
--cc=pve-devel@lists.proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.