* Re: [pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy
2021-07-14 6:19 ` Thomas Lamprecht
@ 2021-07-14 10:16 ` alexandre derumier
2021-07-14 10:53 ` alexandre derumier
1 sibling, 0 replies; 5+ messages in thread
From: alexandre derumier @ 2021-07-14 10:16 UTC (permalink / raw)
To: Proxmox VE development discussion
> 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`
>
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [pve-devel] ifupdown2 "bridge_set_static_mac_from_port" policy
2021-07-14 6:19 ` Thomas Lamprecht
2021-07-14 10:16 ` alexandre derumier
@ 2021-07-14 10:53 ` alexandre derumier
1 sibling, 0 replies; 5+ messages in thread
From: alexandre derumier @ 2021-07-14 10:53 UTC (permalink / raw)
To: Proxmox VE development discussion
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`
>
^ permalink raw reply [flat|nested] 5+ messages in thread