superfluous host interfaces

Ruben mail at
Mon Feb 26 12:28:41 UTC 2018

Hi Harry,

Following some examples in the presentation you linked, Im rather
suprised that i'm apparently already utilizing the ng subsystem on some
of my machines (ngctl list lists entries and a couple of hooks as well).

Ill put a rig together for some playing around with the netgraph
subsystem, very interesting!

Thank you (again) for your elaboration :)

Kind regards,

On 26/02/2018 13:13, Harry Schmalzbauer wrote:
> Bezüglich Ruben's Nachricht vom 26.02.2018 11:34 (localtime):
>> On 26/02/2018 10:56, Harry Schmalzbauer wrote:
>>>> Another, personally very significant, reason is that you'll get a
>>> superfluous host interface for each if_bridge(4), which makes the output
>>> of plain ifconfig(8) kind of unreadable.
>>> By superflous host interfaces, do you mean the tap interfaces configured
>> for each vm together with the bridge interfaces they are "bundled" in?
> Additionally to the if_tap(4) ethernet host interfaces, you also get
> if_bridge(4) ethernet interfaces, named bridgeX if I remember correctly.
> The if_bridge(4) host interface is for control purposes only on a VM-SDN
> host – at least with my setups.  I never needed to make use of IP
> numbered bridges.  And I don't need to utilize any if_bridge(4) features
> like STP, so I consider the bridgeX host interfaces as superfluous in
> the VM-SDN use case.
> I'd call the if_tap(4) host interfaces likewise superfluous – you would
> only need the corresponding character devices – but that's been
> implemented long before the need for SDN setups, so it is like it is.
> And using ng_bridge(4) instead of if_bridge(4) doesn't change the need
> for if_tap(4).  Only with vale(4) switches, bhyve(8) was able to provide
> virtio-net connection wihtout "spamming" the host's ethernet interface
> list (no tapX, no bridgeX).
>> Overall I'm very happy with my bhyve setups atm. If there are any
>> speed-/administrative-advantages that come with bridge_ng however, I'm
>> very interested in switching to such a setup (or at least play with it).
>> I'm running my vm's without any helper project so I'm flexible enough to
>> do some fiddling :P
>> Do you know of any documentation on using bridge_ng together with bhyve?
>> My search-engines don't turn up much Im affraid and I haven't stumbled
>> on it before.
> Unfortunately it's not too easy to get started with netgraph.
> Besides numerous man pages for the different nodes (ng_bridge(4) e.g.),
> I only know the following source for a good overview:
> One convenience disadvantage with ng_bridge(4) is that you have to
> assign MACs manually, while if_bridge(4) does that itself (adjustable by
> sysctl
> And you need to script all setups yourself.  Almost all of my setups
> seem to be awkward enough that I always had to do some local scripting,
> so that wasn't really a disadvantage for me.
> If you're happy with your setup, I don't think you gain anything from
> switching to ng_bridge(4), besides learning to control netgraph(4)
> (which is very desirable imho).
> I haven't had time left to do useful benchmarking regarding ng_bridge(4)
> vs. if_bridge(4). I even don't know if netgraph nodes are still limited
> to single threads.  But rough load comparings on a IvyBride machine
> showed similar resource usage for both bridges, both easy capable of
> 1GbE saturation with small frames (while I remember one run with
> ng_bridge(4) and if_vmnet(4), which couldn't deliver 1GbE speed, and I
> wanted to falsify for vmnet/tap difference... just ran out of time :-( ).
> -harry

More information about the freebsd-virtualization mailing list