superfluous host interfaces

Julian Elischer julian at
Tue Feb 27 21:14:14 UTC 2018

On 26/2/18 8:13 pm, 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:

dated but not too much
> 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
> _______________________________________________
> freebsd-virtualization at mailing list
> To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe at"

More information about the freebsd-virtualization mailing list