1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
|
.\" $OpenBSD: veb.4,v 1.7 2025/11/25 11:56:49 jsg Exp $
.\"
.\" Copyright (c) 2021 David Gwynne <dlg@openbsd.org>
.\"
.\" Permission to use, copy, modify, and distribute this software for any
.\" purpose with or without fee is hereby granted, provided that the above
.\" copyright notice and this permission notice appear in all copies.
.\"
.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
.\"
.Dd $Mdocdate: November 25 2025 $
.Dt VEB 4
.Os
.Sh NAME
.Nm veb ,
.Nm vport
.Nd Virtual Ethernet Bridge network device
.Sh SYNOPSIS
.Cd "pseudo-device veb"
.Sh DESCRIPTION
The
.Nm veb
pseudo-device supports the creation of a single layer 2 Ethernet
network between multiple ports.
Ethernet interfaces are added to the
.Nm veb
bridge to be used as ports.
Unlike
.Xr bridge 4 ,
.Nm 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
.Xr inet 4
or
.Xr inet6 4
addresses or other layer-3 features themselves.
.Pp
The Ethernet network managed by
.Nm veb
can be connected to the network stack by creating a
.Nm vport
interface and adding it as a port to the bridge.
From the perspective of the host network stack, a
.Nm vport
interface acts as a normal interface connected to an Ethernet
network and can be configured with addresses.
.Pp
.Nm veb
is an IEEE 802.1Q VLAN aware bridge.
A single
.Nm 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.
.Pp
Multiple
.Nm 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.
.Pp
.Nm 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.
.Pp
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.
.Pp
.Nm veb
provides multiple mechanisms for filtering packets traversing the
bridge.
.Pp
By default
.Nm 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.
.Pp
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.
.Nm 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.
.Pp
.Nm 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.
.Pp
.Xr 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
.Nm vport
interfaces, where
.Xr 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
.Nm vport
interfaces appear to travel in the opposite direction to packets
travelling over other ports.
.\" Packets traversing vport interfaces get their direction relative
.\" to the host network stack, while other ports get their direction
.\" from their relationship to the bridge.
.Pp
.Nm 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.
.\" .Pp
.\" .Nm veb
.\" interfaces support the following
.\" .Xr ioctl 2
.\" calls:
.Sh SEE ALSO
.Xr ipsec 4 ,
.Xr options 4 ,
.Xr pf 4 ,
.Xr hostname.if 5 ,
.Xr ifconfig 8 ,
.Xr netstart 8
.Sh STANDARDS
.Rs
.%T IEEE 802.1Q standard
.%U https://standards.ieee.org/standard/802_1Q-2018.html
.Re
.Pp
.Rs
.%A S. HomChaudhuri
.%A M. Foschiano
.%D February 2010
.%R RFC 5517
.%T Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment
.Re
.Sh HISTORY
The
.Nm
driver first appeared in
.Ox 6.9 .
VLAN and PVLAN support was added in
.Ox 7.9 .
.Sh AUTHORS
.An David Gwynne Aq Mt dlg@openbsd.org
|
