Date: Mon, 8 Jun 2020 20:30:04 -0700 From: Julian Elischer <julian@freebsd.org> To: Marko Zec <zec@fer.hr>, Tom Marcoen <tom.marcoen@gmail.com> Cc: Jan Bramkamp <crest@rlwinm.de>, freebsd-net@freebsd.org Subject: Re: On Netgraph Message-ID: <be326e29-1372-9908-86b5-b9030eaa54a9@freebsd.org> In-Reply-To: <20200608160317.6966f6d4@x23> References: <CAJ-iVrNn=9-Z5YHG4j=adnFiiTbDLED6ArYh8j9Zepn0k8=6KA@mail.gmail.com> <00686a7c-1035-f214-bb93-4ea69bb97d5e@rlwinm.de> <CAJ-iVrPWaP32S%2BS%2Bbq52Q1S7U0EsVXrJTF1RSU_DyMF=jnA1%2BA@mail.gmail.com> <20200608160317.6966f6d4@x23>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/8/20 7:03 AM, Marko Zec wrote: > On Mon, 8 Jun 2020 15:36:42 +0200 > Tom Marcoen <tom.marcoen@gmail.com> wrote: > >> Hey Jan, >> >> I know about the vast performance improvements with if_bridge(4) >> (Thank you, Kristof Provost), the problem with using it for jails is >> that once you have a lot of jails, your hosts gets way too many epair >> interfaces in its ifconfig, which I really do not like. So I would >> prefer using Netgraph. >> >> I don't understand why is everythin doing everything they can _not_ >> to use Netgraph? > Netgraph is very cool and underrated indeed. A part of the problem > might be that people may find it easier to construct if_bridge > configurations, than to spend some time learning how to establish the > same functionality using netgraph, which requires a few more steps. I > was one of such lazy persons myself... > > But a more down-to-the-earth problem with ng_bridge may be that it is > single-threaded (look around line 319 in sys/netgraph/ng_bridge.c), > which most likely is going to make it less performant than if_bridge > (after recent improvements) Since netgraph was written in 1996 it as required only one rework to add some support for multi-threading so possibly after 24 years we may need to change a few lines... :-) >> On Mon, 8 Jun 2020 at 13:47, Jan Bramkamp <crest@rlwinm.de> wrote: >> >>> On 27.05.20 10:06, Tom Marcoen wrote: >>>> Hey all, >>>> >>>> I'm new to this mailing list and also quite new to FreeBSD >>>> (huray, >>> welcome >>>> to me!) so bare with me, please. >>>> >>>> I'm reading up on Netgraph on how I can integrate it with FreeBSD >>>> jails >>> and >>>> I was looking at some of the examples provided in >>>> /usr/share/examples/netgraph and now have the following question. >>>> The udp.tunnel example shows an iface point-to-point connection >>>> but it is unencrypted. Of course I could encrypt it with an IPsec >>>> tunnel on the >>> host >>>> or tunnel it through SSH, but I was wondering whether there >>>> exists a nice Netgraph solution, e.g. a node with two hooks, >>>> receiving unencrypted traffic on the inside hook and sending out >>>> encrypted traffic on the >>> outside >>>> hook. >>> Netgraph is a very flexible tool, but not needed for this. First of >>> all if_bridge(4) just got a massive throughput gain by at least a >>> factor of 5 in 13-current and 12-stable. Next you would be >>> reinventing the wheel with ng_bridge and ng_ksocket to tunnel >>> ethernet in UDP. As soon as you have more than two jail hosts >>> you'll run into new problems. >>> >>> The canonical solution to your problem is VXLAN. This allows you to >>> learn traffic to the unicast tunnel endpoint address for unicast >>> cast traffic and multicast the rest. These encapsulations have been >>> invented to allow emulate a shared layer 2 Ethernet networks per >>> tennant. Unless your jails are VNET enabled and your jail admins >>> require a shared layer 2 network you can avoid most of this >>> overhead with dynamic routing. I know this sounds a lot like >>> "your're holding it wrong". Your approach would work, but it would >>> cripple performance unless you can wait for FreeBSD 12.2 and switch >>> from netgraph to if_bridge(4). Routing is fast (enough) in the >>> existing FreeBSD releases and in my opinion the cleaner solution, >>> but it complicates hosting services expecting a shared layer 2 e.g. >>> mDNS and DLNA require either multicast routing or proxies. >>> >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to >>> "freebsd-net-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?be326e29-1372-9908-86b5-b9030eaa54a9>