Timeline
Post
Remote status
Fetching context…
This post replies to something we haven't fetched yet. We'll try to pull in the missing thread context in the background.
I'm not sure where the vlans_bridge0 parameter fits in but this is what I have:
ifconfig_ixl0="up -lro -txcsum -txcsum6 -tso4 -tso6 -mextpg"
cloned_interfaces="${cloned_interfaces} bridge0"
ifconfig_bridge0="vlanfilter addm ixl0 tagged 99-115 up"
# core network
cloned_interfaces="${cloned_interfaces} vlan100"
ifconfig_vlan100="vlan 100 vlandev bridge0 10.0.0.8/24"
# iot-snowflakes
cloned_interfaces="${cloned_interfaces} vlan112"
ifconfig_vlan112="vlan 112 vlandev bridge0 10.0.12.8/24"
The result looks something like this:
bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=10<VLAN_HWTAGGING>
bridge flags=1<VLANFILTER>
member: e0a_wfe flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 96 priority 128 path cost 2000 vlan protocol 802.1q untagged 100
...
member: ixl0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 1 priority 128 path cost 55 vlan protocol 802.1q tagged 99-115
groups: bridge
vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496
inet 10.0.0.8 netmask 0xffffff00 broadcast 10.0.0.255
vlan: 100 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0
vlan112: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496
inet 10.0.12.8 netmask 0xffffff00 broadcast 10.0.12.255
vlan: 112 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0
Short version: bridge in hwtagging mode. Each member added identifies what vlans it wants and what's tagged/untagged. e0a_* is half of a jail epair.
ifconfig_ixl0="up -lro -txcsum -txcsum6 -tso4 -tso6 -mextpg"
cloned_interfaces="${cloned_interfaces} bridge0"
ifconfig_bridge0="vlanfilter addm ixl0 tagged 99-115 up"
# core network
cloned_interfaces="${cloned_interfaces} vlan100"
ifconfig_vlan100="vlan 100 vlandev bridge0 10.0.0.8/24"
# iot-snowflakes
cloned_interfaces="${cloned_interfaces} vlan112"
ifconfig_vlan112="vlan 112 vlandev bridge0 10.0.12.8/24"
The result looks something like this:
bridge0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
options=10<VLAN_HWTAGGING>
bridge flags=1<VLANFILTER>
member: e0a_wfe flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 96 priority 128 path cost 2000 vlan protocol 802.1q untagged 100
...
member: ixl0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
port 1 priority 128 path cost 55 vlan protocol 802.1q tagged 99-115
groups: bridge
vlan100: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496
inet 10.0.0.8 netmask 0xffffff00 broadcast 10.0.0.255
vlan: 100 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0
vlan112: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1496
inet 10.0.12.8 netmask 0xffffff00 broadcast 10.0.12.255
vlan: 112 vlanproto: 802.1q vlanpcp: 0 parent interface: bridge0
Short version: bridge in hwtagging mode. Each member added identifies what vlans it wants and what's tagged/untagged. e0a_* is half of a jail epair.
Replies
3I think what you're doing is closer to the old way. You've created a bridge and told it about vlans, but haven't enabled hwfilter mode. When you added the interface to it you didn't tell it what vlans it should be configured for. I think.
Additionally, the host's IP addresses go on the vlan interface, not the bridge. Having it on the bridge is definitely the old Pre-15.x way.
@karinjiri @mWare I brain dumped into a blog post how I got this working with my VNET jails and vm-bhyve. Still needs refinements but at least things are "working".
https://blog.feld.me/posts/2026/02/using-new-bridges-freebsd-15/
cc @dvl as I know you'll want to take a look as a heavy jail user
https://blog.feld.me/posts/2026/02/using-new-bridges-freebsd-15/
cc @dvl as I know you'll want to take a look as a heavy jail user