Re: bridge gone wrong?

considered if using the netgraph bridging and vlan support might be a 
cleaner solution?

On 7/28/25 12:12 PM, Bjoern A. Zeeb wrote:
> Hi,
> 
> I wish I would not have had to look into this but I got bitten over
> the weekend.
> 
> My topology on boot looks simplified for the example) like:
> 
> physical interface
>      +--- vlan1
>      +--- vlan2
>      +--- vlan3
> 
> I need addresses on the VLAN interfaces to be able to reach the machine
> in the default setup.
> 
> Now there are use cases that duing the liftime of a boot I need to add
> a bridge interface to a vlanN + fanout:
> 
> physical interface
>      +--- vlan1 --- bridge0 ---++++ other interface[s]
>      +--- vlan2
>      +--- vlan3 --- bridge1 ---++++ other interface[s]
> 
> And that's where things obviously went south after the member_ifaddrs
> sysctl changed (which I had missed).  Sitting on a 14.3-STABLE machine
> didn't help the confusion until I pulled the git tree and checked the
> log and UPDATING.
> 
> So my setup seems to be reverse to what most poeple think they should
> do -- broadcast all packets including vlans over the bridge and deal
> with it behind.
> 
> So for that case vlan filtering tries to solve this makes half-way
> sense.
> 
> I wished we would have added vlan filtering/handling generically to
> interfaces as a "sub-layer" stacking things properly but that's a
> discussion for another decade I fear; but that's where I tink
> "bridge went wrong" now.
> 
> I feels like we tried to make the bridge a switch just not quite right
> (yet).
> 
> 
> I have a few suggestions at least to improve a few things given you are
> active there, and some question.
> 
> 
> I think at least ifconfig(8) needs a few changes (some old problems):
> 
> (a) "Bridge VLAN Filtering Parameters" belongs under "Bridge Interface
>      Parameters" and is not another equal .Ss subsection. (new)
> 
> (b) "Bridge Interface Parameters" really also should have a reference to
>      bridge.4 and mention that the bridge.4 man page documents more 
> specific
>      bits and the sysctls to change other behaviour in addition to the
>      ifocnfig options.  This is good for the vlan filtering part already.
> 
> (c) both ifocnfig "Bridge VLAN Filtering Parameters" and the bridge(4)
>      "VLAN SUPPORT" parts are talking about "interfaces".  I think using
>      "bridge members" or "member interafce(s)" here for clarity would 
> help
>      a lot to have a distinction from (bridge) interface to (bridge) 
> member
>      (interface).
>      This is not a new problem as other older options have that ambiguity
>      as well and should probably be improved along.
> 
> (d) bridge.4 "VLAN SUPPORT" says:
>     ""
>       Traffic sent to or from the host is not assigned to a VLAN by 
> default.
>       To allow the host to communicate on a VLAN, configure a vlan(4) 
> interface
>       on the bridge and (if necessary) assign IP addresses there.
>     ""
> 
>     Question: which VLAN do the addresses on the bridge interface belong
>     to now?
> 
>     If I do (unrelated to my setup, just in general):
>          ifconfig bridge0 inet6 auto_linklocal -ifdisabled up
>          ping -n ff02::1%bridge0
>     where do the packets go?
> 
>     Or in yet another way, how do you set the untagged vlan-id for the
>     bridge interface itself?
>     You can do so for all possible VLANs which are tagged by adding the
>     vlan(4) interface on top but that does not help the untagged case.
> 
> (d.1)
>     Untagged on one member interface could now with filtering be vlan-id
>     123 and on another member interface it could be vlan-id 666.
>     Is that handled correctly on igress->bridge-IPs->egress?
> 
> 
> (e) Something no one seems to have thought of was how this all aligns
>     with etherswitch?
>     Different program different arguments and names for some things which
>     do this "in hw" rather than using the software implementation.
>     Did we loose a chance to fix this and harmonize it?
> 
> 
> (f) bridge.4 says
>     ""
>       Attempting to assign an IP address to a bridge member
>       interface, or add a member interface with an assigned IP address 
> to a
>       bridge, will return an EINVAL ("Invalid argument") error.
>     ""
> 
>     Is this a distinct error for the addm case?  If we can poinpoint it
>     to that problem (along with the sysctl value), we should really give
>     the user a better error message.  That might help all the surprised
>     users now. If we return EINVAL for other addm errors as well we
>     probably lost on this too.
> 
> 
> My .05cts
> /bz
>