[pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy

[alexandre derumier]

ok, I have done some tests.

/etc/network/ifupdown2/policy.d/bridgemac.json

{
    "bridge": {
	"module_globals": {
	     "bridge_set_static_mac_from_port": "yes"
     }
}


test1
-----

auto vmbr4
iface vmbr4 inet manual
        bridge-ports eno4 eno3
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

with eno4 mac: c8:1f:66:f8:e8:bf


"ifreload -a"  (vmbr4 didn't exist before)

info: executing /bin/ip -force -batch - [link set dev eno3 up]
debug: vmbr4: evaluating port expr '['eno4', 'eno3']'
debug: vmbr4: _get_bridge_mac returned (eno4, c8:1f:66:f8:e8:bf)
debug: vmbr4: cached hwaddress value: 1a:dc:cd:5f:95:a2
info: vmbr4: setting bridge mac to port eno4 mac
info: vmbr4: netlink: ip link set dev vmbr4 address c8:1f:66:f8:e8:bf
debug: vmbr4: pre-up : running module bridgevlan
debug: vmbr4: pre-up : running module tunnel
debug: vmbr4: pre-up : running module vrf
debug: vmbr4: pre-up : running module address

vmbr4 correctly inherit eno4 mac


switch eno3,eno4

auto vmbr4
iface vmbr4 inet manual
        bridge-ports eno3 eno4
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

ifreload -a

debug: vmbr4: evaluating port expr '['eno3', 'eno4']'
info: vmbr4: port eno3: already processed
info: vmbr4: port eno4: already processed
info: vmbr4: applying bridge configuration specific to ports
info: vmbr4: processing bridge config for port eno3
info: vmbr4: processing bridge config for port eno4
debug: vmbr4: evaluating port expr '['eno3', 'eno4']'
info: bridge mac is already inherited from eno4
debug: vmbr4: _get_bridge_mac returned (eno4, c8:1f:66:f8:e8:bf)
debug: vmbr4: cached hwaddress value: c8:1f:66:f8:e8:bf


mac don't change on reload.


ifdown vmbr4/ifup vmbr4  --> mac is changed to eno3 mac.


test2
-----
existing vmbr0 + vmbr0.100 + a running tap115i0 on vmbr0

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

auto vmbr0.100
iface vmbr0.100 inet static
        address 10.59.100.233/24
        gateway 10.59.100.1


now, add policy, ifreload -a

info: vmbr0: port tap115i0 will stay enslaved as it matches with
bridge-ports-condone-regex
debug: vmbr0: evaluating port expr '['eno1']'
info: vmbr0: port eno1: already processed
info: vmbr0: applying bridge configuration specific to ports
info: vmbr0: processing bridge config for port eno1
debug: vmbr0: evaluating port expr '['eno1']'
debug: vmbr0: _get_bridge_mac returned (eno1, c8:1f:66:f8:e8:bc)
debug: vmbr0: cached hwaddress value: 42:74:ea:71:d6:fa
info: vmbr0: setting bridge mac to port eno1 mac
info: vmbr0: netlink: ip link set dev vmbr0 down
info: vmbr0: netlink: ip link set dev vmbr0 address c8:1f:66:f8:e8:bc
info: vmbr0: netlink: ip link set dev vmbr0 up

info: executing /sbin/sysctl net.mpls.conf.vmbr0/100.input=0
info: vmbr0.100: netlink: ip link set dev vmbr0.100 down
info: vmbr0.100: netlink: ip link set dev vmbr0.100 address
c8:1f:66:f8:e8:bc
info: vmbr0.100: netlink: ip link set dev vmbr0.100 up


Works too.




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