NAME
veb, vport
— Virtual Ethernet Bridge
network device
SYNOPSIS
pseudo-device veb
DESCRIPTION
The veb pseudo-device supports the
creation of a single layer 2 Ethernet network between multiple ports.
Ethernet interfaces are added to the veb bridge to
be used as ports. Unlike bridge(4), veb takes over the
operation of the interfaces that are added as ports. They are then
independent of the host network stack: the individual Ethernet ports no
longer function as independent devices and cannot be configured with
inet(4) or
inet6(4)
addresses or other layer-3 features themselves.
The Ethernet network managed by veb can be
connected to the network stack by creating a vport
interface and adding it as a port to the bridge. From the perspective of the
host network stack, a vport interface acts as a
normal interface connected to an Ethernet network and can be configured with
addresses.
veb is an IEEE 802.1Q VLAN aware bridge. A
single veb instance can manage multiple independent
and isolated Ethernet networks scoped by VLAN identifiers. Every packet
traversing the bridge is associated with a VLAN, either by the identifier in
802.1Q VLAN tagged packets or by the VLAN identifier assigned to port
interfaces for untagged packets.
Multiple vport interfaces can be attached
to a single bridge to connect the network stack to different VLANs within
the bridge, or to connect multiple routing domains to a single VLAN.
veb is a learning bridge that maintains a
database of Ethernet addresses and the port that each address in a VLAN is
reachable with. The bridge learns about the reachability of Ethernet
addresses by reading the source address on packets received by ports, and
then entering the address and port into the table dynamically. Static
address entries may also be configured in the table, disabling dynamic
learning for that address. Ethernet address learning can be disabled on
individual ports.
When forwarding a packet, the address table is searched for the destination Ethernet address in the relevant VLAN and the packet is sent to the associated port in the table entry. If no entry is found in the table, or the packet is addressed to a multicast or broadcast address, the packet is flooded to all other ports on the bridge. Flooding of packets to unknown unicast addresses can be disabled on individual ports.
veb provides multiple mechanisms for
filtering packets traversing the bridge.
By default veb filters IEEE 802.1Q VLAN
tagged packets on a port until a set of allowed VLAN identifiers is
configured. Packets without IEEE 802.1Q VLAN tags are assigned the native
VLAN identifier configured on the port for untagged packets. Alternatively,
a port can be configured to drop untagged packets, or have processing
declined by the bridge and passed through to the network stack.
Ports can be configured as members of protected domains to
restrict communication between them. This can be used to construct Virtual
Private LAN Service (VPLS) topologies with protected domains enforcing a
split-horizon forwarding rule. veb supports RFC 5517
Private VLANs to provide isolation between ports within a VLAN, and as part
of a larger PVLAN network topology. The PVLAN implementation also provides
support for configuring ports with the pvptags flag to communicate with VLAN
aware but PVLAN unaware equipment using only primary VLAN identifiers for
VLAN tagged packets.
veb can filter Ethernet packets entering
or leaving ports using bridge rules. Ports can be configured to only allow
relaying of IP (and ARP/RARP) packets by setting the blocknonip flag.
pf(4)
can be used to filter IP packets as they enter or leave the bridge. By
default this filtering is disabled, but can be enabled by setting the link1
flag. This filtering only applies to untagged packets on ports. The
exception to this policy is on vport interfaces,
where pf(4) runs
as packets enter and leave the network stack regardless of the value of the
link1 flag. A consequence of this behaviour is that packets traversing
vport interfaces appear to travel in the opposite
direction to packets travelling over other ports.
veb supports the addition of span ports to
the bridge. Span ports transmit a copy of every packet received by the
bridge, allowing for passive monitoring of traffic on a separate host.
SEE ALSO
ipsec(4), options(4), pf(4), hostname.if(5), ifconfig(8), netstart(8)
STANDARDS
IEEE 802.1Q standard, https://standards.ieee.org/standard/802_1Q-2018.html.
S. HomChaudhuri and M. Foschiano, Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment, RFC 5517, February 2010.
HISTORY
The veb driver first appeared in
OpenBSD 6.9. VLAN and PVLAN support was added in
OpenBSD 7.9.
AUTHORS
David Gwynne <dlg@openbsd.org>