From owner-freebsd-net@freebsd.org Wed May 29 13:52:25 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F7BD15C357F for ; Wed, 29 May 2019 13:52:25 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DA4E76D3C3 for ; Wed, 29 May 2019 13:52:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 783CB1DB6A for ; Wed, 29 May 2019 13:52:24 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lj1-f178.google.com with SMTP id q16so2536450ljj.8 for ; Wed, 29 May 2019 06:52:24 -0700 (PDT) X-Gm-Message-State: APjAAAVX0cJTsN9was20n5KhkMAqcnIk+xMBs4DdFeemJkQAtQzJkA3I +/JHokj5eL5yoDyphBdDQFaj7fn/ADi7+0+xHsI= X-Google-Smtp-Source: APXvYqzb5MGCqfi0ahfW0GVA0Owwy7AO7XEAINQPNVmTJNdkeoCc5N8yfTTYs8DCBI0p2uHQ0y4IGEHXLUGdpzRtNjk= X-Received: by 2002:a2e:9cd5:: with SMTP id g21mr15711373ljj.39.1559137943010; Wed, 29 May 2019 06:52:23 -0700 (PDT) MIME-Version: 1.0 References: <716a2edd-96f5-c263-2bd4-38a30808f241@omnilan.de> <050a68a3-7581-4985-e54a-e045259e8cfd@omnilan.de> <77aa3369-a6f0-e9c4-e54e-9fab0d41a937@pobox.com> <02da14d5-dcf9-1717-61e3-8e6fd61fcf4d@pobox.com> In-Reply-To: <02da14d5-dcf9-1717-61e3-8e6fd61fcf4d@pobox.com> From: Kyle Evans Date: Wed, 29 May 2019 08:51:52 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Bridges on VLAN-tagged interfaces. To: Eric Bautsch Cc: "Patrick M. Hausen" , FreeBSD Net Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: DA4E76D3C3 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2019 13:52:25 -0000 [I cast level 3 necromancy and revive this thread from the dead] On Tue, Mar 19, 2019 at 4:02 AM Eric Bautsch 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