OpenBSD Journal

Introducing veb(4) - a new Virtual Ethernet Bridge

Contributed by Paul 'WEiRD' de Weerd on from the very-efficient-bridge(4) dept.

In this commit, David Gwynne (dlg@) adds a new veb(4) driver to the tree. David's goal is to replace the old bridge(4) driver:

add veb(4), a Virtual Ethernet Bridge driver.

my intention is to replace bridge(4), but the way it works is
different enough from from bridge that a name change is justified
to distinguish them. it also makes it easier to commit it to the
tree and work on it in parallel to bridge, and allows a window of
migration.

the main difference between veb(4) and bridge(4) is how they use
interfaces as ports. veb takes over interfaces completely and only
uses them to receive and transmit ethernet packets. bridge also use
each interface as a port to the ethernet segment it's connected to,
but also tries to continue supporting the use of the interface as
a way to talk to the network stack on the local system. supporting
the use of interfaces for both external and local communication is
where most of my confusion with bridge comes from, both when i'm
trying to operate it and also understand the code. changing this
semantic is where most of the simplification in veb comes from
compared to bridge.

because veb takes over interfaces, the ethernet network set up on
a veb is isolated from the host network stack. by default veb does
not interact with pf or the ip (and mpls) stacks. to enable pf for
ip frames going over veb ports link1 on the veb interface must be
set. to have the stack interact with a veb network, vport interfaces
must be created and added as ports to a veb.

the vport interface driver is provided as part of veb, and is handled
specially by veb. veb usually prevents the use of ports by the stack
for sending an receiving packets, but that's why vports exist, so
veb has special handling for them.

veb already supports a lot of the other features that bridge has,
including bridge rules and protected domains, but i got tired of
working out of the tree and stopped implementing them. the main
outstanding features is better address table management, the
blocknonip flag on ports, transparent ipsec interception, and
spanning tree. i may not bother with spanning tree unless someone
tells me that they actually use it.

the core ethernet learning bridge functionality is provided by the
etherbridge code that was factored out of nvgre and bpe. veb is
already (a lot) faster than bridge, and is better prepared to operate
in parallel on multiple CPUs concurrently.

thanks to hrvoje popovski for testing some earlier versions of this.
discussed with many
ok patrick@ jmatthew@

While performance wasn't the main goal for the veb(4) bridge code, it does run a bit faster, as David explained in an e-mail to tech@:
oh, veb(4) should be a lot faster than bridge(4) too. and mpsafe. and
able to be run concurrently. hrvoje popovski has tested some versions of
these diffs and has the following numbers so far:

> 3550m4 - slower box
> forwarding - 560 Kpps
> bridge - 400 Kpps
> veb - 850 Kpps
> tpmr - 920 Kpps
> 
> r620 - faster box
> forwarding - 1 Mpps
> bridge - 680 Kpps
> veb - 1.5 Mpps
> tpmr - 1.75 Mpps

If you're currently using bridge(4), you may want to give the new veb(4) a try! Getting some more real-world experience with the new code will help flush out the bugs, if any.

(Comments are closed)


Comments
  1. By rueda (rueda) on https://www.openbsdfoundation.org/donations.html

    The driver has been enabled:

    CVSROOT:	/cvs
    Module name:	src
    Changes by:	dlg@cvs.openbsd.org	2021/02/24 18:19:35
    
    Modified files:
    	sys/conf       : GENERIC 
    
    Log message:
    enable veb(4), it's time for wider testing.
    
    apart from the semantic differences between bridge(4) and veb(4),
    the only missing bits in veb(4) is the transparent ipsec interception
    support, and spanning tree.

    Comments
    1. By d.c. (d.c.) on

      Looks interesting.

      Just a few days ago I started to think about SPT/RSPT (802.1w) after a very long time. Our testing network somehow starts to look dangerous and I guess that without a kind of spanning tree or similar protection is a trouble just a matter of time :-)

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]