Date: Wed, 29 May 2019 08:51:52 -0500 From: Kyle Evans <kevans@freebsd.org> To: Eric Bautsch <eric.bautsch@pobox.com> Cc: "Patrick M. Hausen" <hausen@punkt.de>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: Bridges on VLAN-tagged interfaces. Message-ID: <CACNAnaEegSOpeqtCOu72a_hNnqJ0PhhPJPy4ffxC9-_42ZPD2g@mail.gmail.com> In-Reply-To: <02da14d5-dcf9-1717-61e3-8e6fd61fcf4d@pobox.com> References: <c3bbab99-1612-2f65-644f-a380f8233e11@pobox.com> <716a2edd-96f5-c263-2bd4-38a30808f241@omnilan.de> <050a68a3-7581-4985-e54a-e045259e8cfd@omnilan.de> <aadfded1-b3d6-23cd-a1db-88b86b11f73b@pobox.com> <77aa3369-a6f0-e9c4-e54e-9fab0d41a937@pobox.com> <B5F26EB1-2779-4AD0-9A4F-8417A94E9367@punkt.de> <02da14d5-dcf9-1717-61e3-8e6fd61fcf4d@pobox.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] 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. 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. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaEegSOpeqtCOu72a_hNnqJ0PhhPJPy4ffxC9-_42ZPD2g>