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
