W dniu 18.05.2025 o 19:48, Alexander Leidinger pisze:
Am 2025-05-18 18:23, schrieb A FreeBSD User:
Am Tage des Herren Sun, 18 May 2025 18:16:43 +0200
Marek Zarychta <[email protected]> schrieb:
W dniu 18.05.2025 o 18:06, A FreeBSD User pisze:
> Hello,
>
> running recent CURRENT (FreeBSD 15.0-CURRENT #68
main-n277334-d9900b9ea2b2: Sun May 18
> 16:51:02 CEST 2025), I ran into the following problem:
> Can not add interfaces anymore to a bridge device.
> Neither existing physical devices, nor epair devices created
during setup of jails - with
> the result of no jails availabel and/or no bridge working.
>
> A more amusing part of this story is: I ran almost two identical
boxes, based upon elderly
> IvyBridge CPUs, both on outdated ASrock Z77 Pro mainboards. One
machine, the
> now-failing-one, has moved to AMD Ryzen 9700X based box based on
ASrock B850 mainboard -
> just for the record, if this is of importance or interest.
>
> On both systems I use custom kernels, mostly disabling unused
devices. Having an ABI issue
> in mind, I recompiled the whole world/kernel on the system with
AMD CPU, but the issue is
> the still persistent.
>
> A real hardware problem or just a coincidence with faulty code?
>
> Thanks for helping,
>
> O. Hartmann
>
>
Hello Oliver,
please follow this commit:
https://github.com/freebsd/freebsd-src/commit/b61850c4e6f6b0f21b36da7238db969d9090309e
and this thread:
https://lists.freebsd.org/archives/freebsd-current/2025-May/007602.html
TL;DR: set net.link.bridge.member_ifaddrs=1 (the earlier, the better,
loader.conf prefered) and before FreeBSD 16.0-RELEASE (still plenty of
time), either remove addresses the bridge members, or consider
migration
to different bridge (Netmap ?!) or consider migration to different OS.
Cheers
Marek
Hello,
sorry for the noise.
Just after sending, I read the thread started by Cy Schubert "epair(4)".
Adding
net.link.bridge.member_ifaddrs=1
solves the problem for me on the host in question!
You want to make it work without this. Short: use the IP on the bridge
itself, not in the member IF.
Bye,
Alexander.
I'm not sure we should be dictating to Oliver what he must do. There are
multiple possible solutions. One could, for example, use ng_bridge(4),
or take yet another direction entirely. Users should be free to
experiment and work flexibly with the operating system. Forcing everyone
to move all their addresses to the logical bridge(4) interface seems
like it narrows the range of valid deployment scenarios for bridge(4)
That said, is the fact that a few users are experiencing issues with
multicast between interfaces connected to a bridge - or that they
struggle to migrate addresses onto the bridge interface - really a
sufficient reason to prohibit everyone from assigning addresses to
bridge members?
Multicast does work. It just doesn’t work between bridge members. Maybe
someone will fix that someday. And even if they don’t, it’s been this
way from the start, so probably people have learned to live with it.
Back to Cy Schubert’s thread about epair(4), which touches on this
issue: what's striking is that this change doesn’t just shoot users in
the foot, it shoots and surprises committers as well. Committers who,
well, will grit their teeth and defend the change regardless.
Please don’t take this as a defense of the old configuration style. As I
said before, if necessary I’ll just migrate to ng_bridge(4) or even
switch to another OS. Netmap would likely be overkill for a laptop
running a bridge temporarily.
I do miss people like the late Mike Karels, who would have made a clear
and confident decision about how this should be handled.
Where is the Janitor? Mr Grimes - where are you?
As a user with 30 years of experience with this OS, allow me to ask:
who’s actually in charge of all this now?
--
Marek Zarychta
