hi > if the answer to both these questions is no, it would be helpful if you > could explain why.
I wouldn’t say it’s a definite no to both. But I can explain a scenario where such superposition makes sense (as I am a user of such a setup): % ifconfig ix0 description "trunked uplink" % ifconfig ix1 description "another trunked link" % ifconfig bridge0 create addm ix0 ix1 % ifconfig bridge0.100 create description "Host interface here" so far everything fine - normal usage, bridge handels trunked traffic now I wish to have a number of jails attached to VLAN 101, so I will: % ifconfig bridge0.101 create up description "unwrap VLAN 101" % cbsd jcreate jname=service1 vnet=1 interface=bridge0.101 ... % cbsd jcreate jname=service2 vnet=1 interface=bridge0.101 ... % cbsd jcreate jname=service3 vnet=1 interface=bridge0.101 ... ... sounds quite logical what cbsd (just another jail management software) will do underneath? something like: % ifconfig bridge1 addm bridge0.101 addm epair0a addm epair1a addm epair2a others ends of the epairs will be landed in jails The jails should be able to talk to each other and should not be aware (internally) of any VLANs. Yes, you can argue, that instead, we should evolve the cbsd tool to acknoledge new functionality like % cbsd jcreate jname=service1 vnet=1 interface=bridge0 vlan=101 and then, plug all these jails into bridge0 with proper VLAN unwrapping and filtering But on the other hand, having something that in the real world can be represented as a dumb switch with no VLAN support (and no way to misconfigure it) to connect a room of PCs, where all unwrapping and ACLs are configured once on the smart switch port where the dumb switch is plugged in – also makes sense. I wouldn’t argue about disabling this in 16.x, just wanted to highlight a scenario that does have merit. just my 5 cents, and thank you for your work > On Jul 30, 2025, at 17:04, Lexi Winter <i...@freebsd.org> wrote: > > hello, > > currently we allow users to create a vlan and a bridge on the same > interface, like this: > > % ifconfig ix0.100 create > % ifconfig bridge0 create addm ix0 > > i am aware that some people are using this in production, but because it > doesn't work properly[0], i would like to forbid this configuration in > 16.0, i.e. it would not be possible to add an interface to a bridge if > vlans are present on that interface, and vice versa. > > i am looking for feedback from people who are currently using this: > > - can you switch your untagged traffic to tagged instead and use a > vlan(4) in a bridge? e.g., > > % ifconfig ix0.100 create > % ifconfig ix0.101 create > % ifconfig bridge0 create addm ix0.101 > > - can you switch to a vlan filtering bridge instead? e.g., > > % ifconfig bridge0 create addm ix0 vlanfilter tagged ix0 100,101 > % ifconfig bridge0.100 create > % ifconfig bridge0.101 create > > if the answer to both these questions is no, it would be helpful if you > could explain why. > > [0] specifically, because both bridge(4) and vlan(4) expect to handle > tagged traffic, it is not clear how the tagged packets on the > interface should be handled. currently, they are processed by > bridge(4) unless they are destined for a local Ethernet address, > in which case they processed by vlan(4), but this behaviour is > somewhat non-obvious and breaks things that require promiscuous > mode on the vlan interface (e.g., tcpdump). -- Vladimir Grebenshchikov v...@fbsd.ru
