With net.link.bridge.inherit_mac set to 1, when a bridge is created via rc.conf eg: cloned_interfaces="bridge0" ifconfig_bridge0="addm igb1 addm igb2 10.0.0.65 netmask 255.255.255.0 " ifconfig_igb1="up" ifconfig_igb2="up" the MAC address of igb1 is not applied to the bridge. Using: ifconfig bridge0 create addm igb1 addm igb2 10.0.0.65 netmask 255.255.255.0 the MAC address is inherited as expected.
how are you bringing the bridges up? does this only fail on boot, or also on service netif restart?
(In reply to Mina Galić from comment #1) > how are you bringing the bridges up? Via rc.conf as above > does this only fail on boot, or also on service netif restart? On `service netif restart' it doesn't fail. Weird.
(In reply to Bob Bishop from comment #0) I think that is expected behavior as per if_bridge(4): > If sysctl(8) node net.link.bridge.inherit_mac has a non-zero value, the > **newly** created bridge will inherit the MAC address from its first member > instead of choosing a random link-level address. You config in rc.conf > ifconfig_bridge0="addm igb1 addm igb2 10.0.0.65 netmask 255.255.255.0 " is adding bridge members to an **existing** bridge bridge0.
(In reply to Zhenlei Huang from comment #3) (In reply to Bob Bishop from comment #0) > I think that is expected behavior as per if_bridge(4): Sorry I'm wrong. >> If sysctl(8) node net.link.bridge.inherit_mac has a non-zero value, the >> **newly** created bridge will inherit the MAC address from its first member >> instead of choosing a random link-level address. > You config in rc.conf >> ifconfig_bridge0="addm igb1 addm igb2 10.0.0.65 netmask 255.255.255.0 " > is adding bridge members to an **existing** bridge bridge0. The bridge0 has no members and igb1 is its first member and net.link.bridge.inherit_mac should work.
Found an interesting bug while repeating. `ifconfig bridge0 addm ` was executed twice when `service netif restart`. After enabled auditd, the audit log shows that devd invoked `hyperv` rules.
(In reply to Zhenlei Huang from comment #5) > After enabled auditd, the audit log shows that devd invoked `hyperv` rules. And then `hyperv` executed the second `ifconfig bridge0 addm` .
The sysctl does not exist if the if_bridge kmod is not loaded. For this mechanism to work as expected at boot time you need to load the module early e.g. by placing if_bridge_load="YES" in /boot/loader.conf. HTH, Patrick
could we document that dependency somehow?
Just adding some proof: # freebsd-version 13.1-RELEASE-p7 # kldstat | grep bridge # sysctl net.link.bridge sysctl: unknown oid 'net.link.bridge' # ifconfig bridge0 create # kldstat | grep bridge 34 1 0xffffffff8301e000 7638 if_bridge.ko 35 1 0xffffffff83026000 50d8 bridgestp.ko # sysctl net.link.bridge net.link.bridge.ipfw: 0 net.link.bridge.allow_llz_overlap: 0 net.link.bridge.inherit_mac: 0 net.link.bridge.log_stp: 0 net.link.bridge.pfil_local_phys: 0 net.link.bridge.pfil_member: 1 net.link.bridge.ipfw_arp: 0 net.link.bridge.pfil_bridge: 1 net.link.bridge.pfil_onlyip: 1 # The behavior which I claimed happens during the boot process follows from that. The interfaces are brought up after /etc/sysctl.conf is applied, so no bridge, hence no kmod, hence no sysctl. Kind regards, Patrick
(In reply to punkt.de Hosting Team from comment #7) Good catch. I confirm that loading if_bridge early produces the expected behaviour. So this is `just' a documentation problem. The paragraph in IF_BRIDGE(4) that describes net.link.bridge.inherit_mac needs to say something like: "Note that node net.link.bridge.inherit_mac does not exist until if_bridge is loaded."
Given `net.link.bridge.inherit_mac` changes the behavior of clone creating for all bridges, it might be better to have per bridge parameter `inherit_mac`. See IFCONFIG(8) section lagg.
@Bob Bishop Once https://reviews.freebsd.org/D39638 is done, you can also add `net.link.bridge.inherit_mac=1` to /boot/loader.conf . `net.link.bridge.inherit_mac` is actually a loader tunable, but does not work without the fix.
(In reply to Zhenlei Huang from comment #12) Note that that DR was committed Sep 9 2023.