Re: CURRENT: can not add device to bridge: ifconfig: BRDGADD igb0: Invalid argument

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 <zarychtam@plan-b.pwste.edu.pl> 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