diff options
| author | Jacob McDonnell <jacob@jacobmcdonnell.com> | 2026-04-25 14:02:27 -0400 |
|---|---|---|
| committer | Jacob McDonnell <jacob@jacobmcdonnell.com> | 2026-04-25 14:02:27 -0400 |
| commit | 6d8bdc65446a704d0750217efd05532fc641ea7d (patch) | |
| tree | 8ae6d698b3c9801750a8b117b3842fb369872a3a /static/openbsd/man4/veb.4 | |
| parent | 2f467bd7ff8f8db0dafa40426166491d7f57f368 (diff) | |
docs: OpenBSD Man Pages Added
Diffstat (limited to 'static/openbsd/man4/veb.4')
| -rw-r--r-- | static/openbsd/man4/veb.4 | 180 |
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 |
