Date: Wed, 29 May 2019 07:13:43 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Kyle Evans <kevans@freebsd.org> Cc: Eric Bautsch <eric.bautsch@pobox.com>, "Patrick M. Hausen" <hausen@punkt.de>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Bridges on VLAN-tagged interfaces. Message-ID: <201905291413.x4TEDhOT021170@gndrsh.dnsmgr.net> In-Reply-To: <CACNAnaEegSOpeqtCOu72a_hNnqJ0PhhPJPy4ffxC9-_42ZPD2g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> [I cast level 3 necromancy and revive this thread from the dead] But this is all layer 2 stuff :-) > > On Tue, Mar 19, 2019 at 4:02 AM Eric Bautsch <eric.bautsch@pobox.com> wrote: > > > > Hi Patrick. > > > > > > I get that point, but then I have two options only: I somehow convince the BIOS > > to do a network boot over a VLAN for installation - not a capability this BIOS > > appears to have, or I end up creating a whole new VLAN that's either routed or > > has YP, DNS, time and installation servers on it. That's a massive headache.... > > > > It'd be much neater if FreeBSD could handle the tagged/untagged traffic. It just > > works (TM) on Solaris and Linux, so I expected it to do the same on FreeBSD... :-( > > > > Surely, there must be a way.... > > > > This is a product of how vlans and bridges work on FreeBSD, but I > think it doesn't have to be this way. Let's break it down: re0.33 is a > vlan(4) attached to re0. Ordinary traffic coming in on vlan 33 does > this little dance number: > > incoming -> re0:ether_input -> ether_demux -> vlan_input -> re0.33:ether_input > > Let's mix it up: add re0.33 to a bridge0. Traffic is passed to > potential bridge for processing in ether_input_internal prior to > ether_demux, so you end up with this setup: > > incoming -> re0:ether_input -> ether_demux -> vlan_input -> > re0.33:ether_input -> bridge0:bridge_input -> ether_demux > > Now let's evolve into our final form. add re0 to bridge1; this is what > I'm most certain is happening > > incoming -> re0:ether_input -> bridge1:bridge_input -> bridge_forward > > oops. bridge1 grabs the re0 packet before we have a chance to do any > vlan processing. Traffic isn't bound for *this* bridge or any of the > other interfaces, so it will perform the bridge forwarding function > and everything goes off the rails. That makes sense as to what I saw happening last time I had issues with this. > > This is not an unsolvable problem, though, from a developer > perspective. I think if_bridge(4) simply needs to be taught a little > about if_vlan(4) (needs more hooks...) so that traffic coming in on > re0 with a vlan that matches an if_vlan(4) interface doesn't get > snagged in the wrong bridge too early. Sounds reasonable, both vlan and bridge/switch are layer 2 functionality and should fully co-operate. One thing to note if you are going to dig around in this code it is known to have poor performance and is one of the bottleneck areas for getting packets in and out of a bhyve vm via the tap to bridge path. I defanitly would enjoying having the configuration and performance of the ESXi vswitch paradigm in FreeBSD if we can implement it with this code in a reasonable fasion. I can provide some sample config files if desired. > Thanks, > Kyle Evans -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201905291413.x4TEDhOT021170>