[pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy

[pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy

[alexandre derumier]

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.



(BTW, ifupdown2 3.1 patches have been pushed to master, not yet
released, they are some interesting bugfix with dhcp, and other things.
I don't have tested it yet).

Re: [pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy

[Thomas Lamprecht]

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.

Re: [pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy

[Thomas Lamprecht]

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`

Re: [pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy

[alexandre derumier]

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

Re: [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`
>