Re: Initial development for veb(4), a lightweight Ethernet bridge for bhyve and vnet jails
Date: Mon, 28 Sep 2026 00:07:08 UTC
Thank y'all for the kind words! VLAN filtering is something that I want to add in the future. OpenBSD's veb(4) driver allows support for multiple vport interfaces to connect the network stack to different VLANs or connect multiple routing domains to a single VLAN. I feel like a similar implementation for this driver would greatly benefit users with large amounts of vnet jails or Bhyve VMs. Best, Aaron Espinoza On 9/23/26 11:51, Jan Bramkamp wrote: > On 21.09.26 22:02, Aaron Espinoza wrote: >> Hello net@, >> >> I'm Aaron Espinoza, a 2025 GSoC participant. This past summer, I >> worked on an initial veb(4)-style driver for FreeBSD, and I'd >> appreciate some feedback from the community. >> >> Inspired by OpenBSD's veb(4), veb is a stripped L2 bridge aimed at >> bhyve and vnet jail topologies. It’s not meant to replace >> if_bridge(4). It leaves out features such as STP and pfil, and handles >> host membership through a dedicated vport interface. > Nice project. I've been bitten by if_bridge(4) more then once through > the years. It's just too easy to "hold it wrong". I agree demoting the > members from in theory usable network interface to just bridge ports > without IP addresses and splitting the bridge from the host port on it a > much cleaner design. > >> Code and docs: https://github.com/Acesp25/freebsd-veb >> >> docs/overview.md is the best starting point for why this driver was >> created, and docs/design.md lists each design decision with its >> rationale. >> >> I'll be presenting this work at the Fall 2026 Vendor Summit and would >> value the list's feedback beforehand, particularly on: >> - whether this work belongs in the src >> - the implemented approach for vport explicit host membership >> - anything in the design that may look wrong >> - what the best practices are for creating benchmarks against >> if_bridge(4) > The limitations you accepted make sense to get the driver into a working > state. > > In my opinion VLAN filtering and spanning tree are not just nice to have > even if you should disable them for the usecases you mentioned (vnet > jails, bhyve guests) to avoid the delay until it becomes a forwarding > access port.