superfluous host interfaces

[Paul Vixie]

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.

you do not remember correctly.

> [mm1.redbarn:amd64] egrep 'bridge|tap' /etc/rc.conf
> autobridge_interfaces="bridge0"
> autobridge_bridge0="tap* igb1"
> cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7"
> ifconfig_bridge0="inet 24.104.150.210/27"
> ifconfig_bridge0_ipv6="inet6 2001:559:8000:cd::2/64 auto_linklocal up"
> ifconfig_tap0="up"
> ifconfig_tap1="up"
> ifconfig_tap2="up"
> ifconfig_tap3="up"
> ifconfig_tap4="up"
> ifconfig_tap5="up"
> ifconfig_tap6="up"
> ifconfig_tap7="up"
> [mm1.redbarn:amd64] ifconfig | egrep '^(bridge|tap)'
> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> tap1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> tap2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> tap3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> tap4: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> tap5: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> tap6: flags=8903<UP,BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> tap7: flags=8903<UP,BROADCAST,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500

the only bridge i see is the one i statically defined.

> 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).

how did you get bhyve to use the netmap API rather than the tap 
character special device?

-- 
P Vixie