From: Mike Larkin <mlarkin@nested.page>
Subject: Re: replace bridge(4) with veb(4) in faq16
To: Solène Rapenne <solene@openbsd.org>, tech <tech@openbsd.org>
Date: Thu, 11 Jul 2024 07:55:05 -0700

On Thu, Jul 11, 2024 at 03:18:51PM +0200, Florian Obser wrote:
> Hi,
>
> I understand bridge(4) can do weird things with network traffic. For
> example, I couldn't get dhcpd(8) to work with the "Option 3" setup from
> the faq. On the other hand, after switching everything to veb/vport
> dhcpd(8) just works™. Since we don't need anything fancy for the simple
> vmm networking of "Option 3" in the faq I think it's best to point
> people at veb(4) instead of bridge(4).
>
> OK?

yes, please do. I think veb(4) is a much better option for vmm/vmd networking
in this fashion than bridge(4) and have been using it this way for some time
now.

TBH I thought we had already updated the FAQ :)

-ml

>
> Index: faq16.html
> ===================================================================
> RCS file: /cvs.d/reposync/www/faq/faq16.html,v
> diff -u -p -r1.24 faq16.html
> --- faq16.html	3 Apr 2024 19:59:04 -0000	1.24
> +++ faq16.html	11 Jul 2024 13:10:10 -0000
> @@ -229,25 +229,31 @@ Reload the pf ruleset and the VM(s) can
>
>  Sometimes you may want additional control over the virtual network for your
>  VMs, such as being able to put certain ones on their own virtual switch.
> -This can be done using a <a href="https://man.openbsd.org/bridge">bridge(4)</a>
> -and a <a href="https://man.openbsd.org/vether">vether(4)</a> interface.
> +This can be done using a <a href="https://man.openbsd.org/veb">veb(4)</a>
> +and a <a href="https://man.openbsd.org/vport">vport(4)</a> interface.
>
>  <p>
> -Create a <code>vether0</code> interface that will have a private IPv4 address
> +Create a <code>vport0</code> interface that will have a private IPv4 address
>  as defined above.
>  In this example, we'll use the <code>10.0.0.0/8</code> subnet.
>
>  <pre class="cmdbox">
> -# <b>echo 'inet 10.0.0.1 255.255.255.0' > /etc/hostname.vether0</b>
> -# <b>sh /etc/netstart vether0</b>
> +# <b>cat &lt;&lt;END > /etc/hostname.vport0
> +inet 10.0.0.1 255.255.255.0
> +up
> +END</b>
> +# <b>sh /etc/netstart vport0</b>
>  </pre>
>
> -Create the <code>bridge0</code> interface with the <code>vether0</code>
> -interface as a bridge port:
> +Create the <code>veb0</code> interface with the <code>vport0</code>
> +interface as a child interface:
>
>  <pre class="cmdbox">
> -# <b>echo 'add vether0' > /etc/hostname.bridge0</b>
> -# <b>sh /etc/netstart bridge0</b>
> +# <b>cat &lt;&lt;END > /etc/hostname.veb0
> +add vport0
> +up
> +END</b>
> +# <b>sh /etc/netstart veb0</b>
>  </pre>
>
>  Ensure that NAT is set up properly if the guests on the virtual network
> @@ -255,7 +261,7 @@ need access beyond the physical machine.
>  An adjusted NAT line in <code>/etc/pf.conf</code> might look like this:
>
>  <pre class="cmdbox">
> -match out on egress from vether0:network to any nat-to (egress)
> +match out on egress from vport0:network to any nat-to (egress)
>  </pre>
>
>  The following lines in <a href="https://man.openbsd.org/vm.conf">vm.conf(5)</a>
> @@ -263,7 +269,7 @@ can be used to ensure that a virtual swi
>
>  <pre class="cmdbox">
>  switch "my_switch" {
> -    interface bridge0
> +    interface veb0
>  }
>
>  vm "my_vm" {
>
> --
> In my defence, I have been left unsupervised.
>