summaryrefslogtreecommitdiff
path: root/static/openbsd/man4/veb.4
diff options
context:
space:
mode:
authorJacob McDonnell <jacob@jacobmcdonnell.com>2026-04-25 14:02:27 -0400
committerJacob McDonnell <jacob@jacobmcdonnell.com>2026-04-25 14:02:27 -0400
commit6d8bdc65446a704d0750217efd05532fc641ea7d (patch)
tree8ae6d698b3c9801750a8b117b3842fb369872a3a /static/openbsd/man4/veb.4
parent2f467bd7ff8f8db0dafa40426166491d7f57f368 (diff)
docs: OpenBSD Man Pages Added
Diffstat (limited to 'static/openbsd/man4/veb.4')
-rw-r--r--static/openbsd/man4/veb.4180
1 files changed, 180 insertions, 0 deletions
diff --git a/static/openbsd/man4/veb.4 b/static/openbsd/man4/veb.4
new file mode 100644
index 00000000..9c8ccd80
--- /dev/null
+++ b/static/openbsd/man4/veb.4
@@ -0,0 +1,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