From owner-freebsd-net@freebsd.org Wed May 29 14:13:47 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 425D315C3D64 for ; Wed, 29 May 2019 14:13:47 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1ECE06E142; Wed, 29 May 2019 14:13:45 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x4TEDhhX021171; Wed, 29 May 2019 07:13:43 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x4TEDhOT021170; Wed, 29 May 2019 07:13:43 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201905291413.x4TEDhOT021170@gndrsh.dnsmgr.net> Subject: Re: Bridges on VLAN-tagged interfaces. In-Reply-To: To: Kyle Evans Date: Wed, 29 May 2019 07:13:43 -0700 (PDT) CC: Eric Bautsch , "Patrick M. Hausen" , FreeBSD Net X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 1ECE06E142 X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [2.70 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_SPAM_SHORT(0.61)[0.606,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.40)[0.405,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: gndrsh.dnsmgr.net]; NEURAL_SPAM_LONG(0.75)[0.753,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.04)[ip: (0.15), ipnet: 69.59.192.0/19(0.08), asn: 13868(0.05), country: US(-0.06)] 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 14:13:47 -0000 > [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 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